@karat39

Вопрос банальный. Предлагаю некий мозговой штурм. Сам не очень владею этой темой.

Код работает с целыми числами. Для целых чисел в с++ разработан целый набор типов для конкретных задач. На что может повлиять выбор того или иного типа?
Если я работаю с числами до 1000, то например, можно использовать short int и unsigned short int и int. При этом логично использовать short int в целях экономии памяти. Но не проиграю ли я в производительности? Что очень важно.

Заранее спасибо за аргументированные мысли.

0

@rao

Мне кажется на быстродействие кода размер и тип операндов не влияет потому что процессору без разницы что складывать/вычитать/умножать/делить char'ы (или byte), short'ы или int'ы - количество тактов на операцию будет одинаковое.

0

@liv

Не совсем так...
Short-ы преобразуются в int-ы.
Так что, если хотите (совсем чуть-чуть!) выиграть в скорости, то лучше хранить в int-ах.

1

@rao

_liv_, а с чего это short'ам преобразовываться в int'ы если процессор может спокойно работать не только с целыми регистрами (32 битными: EAX, ECX, EDX и т.д.), но и с их половинками (8 битными AX, BX, и тд.) ?

0

@liv

rao, разумеется, может. Но, при работе, например, на 32-битной системе, основной единицей является 32-битный int.
При работе с 16-битными регистрами, в код добавляется префикс, который удлиняет и код, и время работы, даже если не будет преобразования в 32-битный int.
Поэтому оптимальнее всего работать именно с 32-битными величинами.
Посмотрите в отладчике ассемблерный код и сами убедитесь...

1

@rao

Посмотрел, но сомнения остались. Потому что преобразование происходит не всегда. Например строка
компилируется в Т.е. никакого преобразования нет.
А вот сложение двух ячеек памяти происходит с "расширением:"
выглядит так: Так себя ведет компилятор Visual Studio 2008 с выключенной оптимизацией. Вполне возможно, что другие компиляторы генерируют другой код. Поэтому однозначно утверждать об оптимальности 32-битных переменных я бы все таки не стал.

2

@karat39

Спасибо, хорошее обсуждение получается

Добавлено через 8 минут
я правильно понял, что удлинение кода ведет к увеличению времени работы?

0

@Почтальон

Такое бывает не всегда, все зависит от сложности алгоритма, наличие циклов, вызовы библиотек и т.п.

0

@CheshireCat

Premature optimization is the root of all evil. (c) Donald Ervin Knuth.

Не лучше ли сначала написать правильный алгоритм, и, если он "вдруг" окажется недостаточно производительным, - посмотреть профилировщиком, где узкое место, и оптимизировать именно и только это узкое место?

0

@karat39

конечно лучше. Код и так не плох. Я просто человек въедливый и мне важна каждая мелочь. Если есть шанс на данной платформе выжать еще микросекунду, я буду ее выжимать. =)

0

@CheshireCat

Ну ты перфекционист ) А что говорит Заказчик по этому поводу? Нужно ли ее выжимать? Будет ли Заказчик платить за это деньги?

0

@karat39

Да, бьемся за каждую микросекунду.
Приходится замерять под конкретной платформой даже стандартные функции (например, sprintf, atoi) и реализовывать свои решения.

0

@CheshireCat

Тады да, согласен. Ну что ж, лучший выход в твоем случае - спускаться на уровень ассемблерного кода и смотреть. Потому что даже из одного и того же исходного кода две разные версии одного и того же компилятора (например, GCC 4.8 и 5.2) могут нагенерировать разный код.

0

@karat39

Спасибо, так и эксперементирую. Применяю даже Intel. Но сколько бы его не хвалили, ощутимо в моих задачах он себя еще не показал.
Что касается ассма, тоже пытаюсь до него спуститься. Не все пока получалось. Я заводил тут тему соответствующую.
Пытаюсь банально на асме обогнать и strcpy и memcpy, подгоняя размеры блоков памяти (db, dw, и тд) для меньшего количества итераций, не получается обогнать. Хотя дизассебмлерный strcpy генерирует невероятное кол-во кода. Не хватает знаний скорее всего про память, процессор, взаимодействие и тд. Ну ничего, решатся более глобальные задачи, спущусь до оптимизации и до этого уровня =))

0

@liv

rao, Вы забыли добавить, что перед каждой командой, у которой стоит word ptr
добавляется префикс 0x66, который удлиняет и команду и время работы на один цикл
Если в одном месте, то немного, но если будет везде, то может и набежать...
Кроме того, некоторые компиляторы формируют так:
mov eax, [dword]
and eax, 0xffff
что тоже удлиняет код

2

@karat39

Расскажите на пальцах, как длина кода влияет на скорость?
Я начинал читать книгу, но пока отложил из важности других задач. Там рассказывалось, что исполняемый код помещается в кэш процессора, от сюда я и подумал, что чем меньше код, тем больше его туда поместится и быстрее будет алгоритм.
Сильно не смейтесь над моей мыслью, я тут (в этой области знаний) явно не авторитет.

0

@liv

karat39, в общем-то, по большому счету, не стоит заморачиваться на оптимизации каждой команды...
Хоть это и может дать эффект, но весьма незначительный. Т.к. кэш процессора весьма существенно сглаживает
все эти мелкие потери.
Можно немного убыстрить, если стараться меньше работать непосредственно с памятью, а больше с регистрами, такие команды и размером меньше, и быстрее работают. Но это обеспечивают, по крайней мере, должны, оптимизаторы кода.
А вот сосредоточиться максимально на оптимизации алгоритма стоит. Именно здесь обычно самые большие потери времени. Т.к. кэш тут не поможет, да и оптимизаторы, скорее всего, тоже. Можно так накрутить, что, будут делаться элементарно лишние вычисления... Или, как пример, если в наличии много ветвлений, то это заставит процессор постоянно перестраивать кэш, тем самым уменьшая выгоду от кэша и, соответственно, увеличивая время работы. Правда, оптимизаторы и с ветвлениями тоже пытаются справляться. Но все же...
И наконец, если передо мной стоит задача написать что-то действительно быстро работающее, я пишу полностью на Ассемблере
Я не надеюсь на оптимизаторы, а пишу так, как мне надо
Но таких задач на современных компьютерах уже практически нет

0

@Nick Alte

И измерения показывают, что получается таки лучше, чем у оптимизаторов? Если да, то на сколько процентов? Если измерения не производились, то как знать, что получается вообще лучше, а не хуже?

0

@liv

Nick Alte, Вы знаете, лично мне не требуется проводить измерения. Мой 30-летний опыт рассматривания всевозможного кода под микроскопом говорит о том, что никогда не сделать автоматом так, как можно сделать ручками.
Безусловно, оптимизаторы неплохо компонуют код, особенно, если код хорошо написан. Но все равно, человек, хорошо знающий Ассемблер, сделает лучше. Я говорю не об отдельных вставках и фрагментах, а обо всем приложении в целом.
Я, разумеется, не призываю всех писать на асме, нужды нет, да и не каждому это дано. Сейчас для современных компьютеров более, чем достаточно, ЯВУ с оптимизаторами, да и неоптимизированные программы вполне сносно работают
А вот для контроллеров, где ресурсов не так много, лично я пишу исключительно на асме.

0

@ct0r

А еще лично вам не нужно ничего тестировать, потому что ваш код всегда работает. Сразу вспоминается Чак Норрис программирования - Джефф Дин
"Джефф Дин компилирует и запускает свой код перед коммитом, но только чтобы проверить на баги компилятор и CPU".

А когда он сделает лучше, его сразу уволят, потому что все дедлайны пройдут. Есть такая вероятность. Нерационально тратить много человеческих ресурсов там, где еще не выяснили, что это нужно.

А у нас и тут плюсы - и все норм!

1