Методы оптимизации кода

[pu4koff]

Статья по оптимизации такого плана без демонстрации ассемблерного кода, т.е. того кода, который и будет исполняться компилятором, яйца выеденного не стоит.
В общем, куча текста ни о чём. Оптимизируем непонятно что (в одном месте выигрываем такты за счет большего расхода памяти, в другом - наоборот), непонятно под какой компилятор, непонятно под какой процессор...

[revaldo666]

а давайте ещё вместо int , bool использовать)) это ведь сэкономит аж 3 байта..неплохая оптимизация))

[Blade]

Сообщение от Granus

Но почему бы не писать оптимизированно просто для души или на всякий случай?)

Потому что эти бесполезные действия:
1. Тратят время разработчика впустую, следовательно искусственно увеличивается стоимость проекта.
2. Ухудшают читабельность кода, который, возможно, будут смотреть\редактировать другие разработчики, следовательно трата времени других разработчиков впустую, снова потеря денег.
3. Противоречат правилам хорошего программирования, главным принципом которых является простота. Код усложняется, следовательно возрастает вероятность допущения ошибки (того, кто это пишет, и того, кто это потом будет редактировать).

[Пепел Феникса]

это ведь сэкономит аж 3 байта..неплохая оптимизация))

тут корректнее сказать уж char тогда.

[pproger]

А еще корректнее - unsigned val : 1;

[f.hump]

Фигня какая-то. Всю эту так называемую "оптимизацию" нормальный компилятор выполнит самостоятельно.
Относительно пунта 8 - то процессору мягко говоря пофиг, он заполняет строку кеша (которая шириной 64 байта), а дальше влияние на перфоманс оказывает только выравние данных относительно начала строки, ну и порядок запроса данных.
Пункт 13 - откуда такие цифры? самое страшное, что может случиться - отсутствие данных в кеше, при этом процессор тратит порядка 100 тактов на поиск по всем уровням кеша и подрузгу из памяти если необходимо.
16, 17 - чо за нах. Основная задача х86 процессора анализ кода и "предвидиние" действия. И тут надо понимать, что проц не только пытается угадать, он еще ведет статистику переходов. Так что основная рекоммендация тут - избегать создания равновероятных переходов.
21 - если кто-то действительно пишет так, то наверное стоит вообще не писать

И нет ничего про SSE. А это действительно оптимизация.



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

[Granus]

Blade, я не думаю, что замена i++ на ++i так уж сильно затуманит код. А про оптимизацию, которая делает код нечитабельным даже для себя я и не говорю, только про приятные мелочи)

[FiloXSee]

Сообщение от revaldo666

а давайте ещё вместо int , bool использовать)) это ведь сэкономит аж 3 байта..неплохая оптимизация))

Сообщение от Пепел Феникса

тут корректнее сказать уж char тогда.

Если у вас используется выравнивание, то не сэкономит. А если использовать char то еще и медленнее работать будет.
int i;
char c;
int arr[ 1000 ];

arr[ i ] - это на архитектуре х86 будет намного быстрее чем
arr[ с ]

Сообщение от pproger

А еще корректнее - unsigned val : 1;

Это тоже память не сэкономит и работать будет долго, но иногда кэшмисы страшнее и приходится так упаковывать.

Сообщение от f.hump

Относительно пунта 8 - то процессору мягко говоря пофиг, он заполняет строку кеша (которая шириной 64 байта), а дальше влияние на перфоманс оказывает только выравние данных относительно начала строки, ну и порядок запроса данных.

Так в пункте и говорится, что выравнивать нужно. Если сделать размер структуры 12 байт, то проходить по массиву таких структур будет значительно дольше, чем если эта структура будет 16 байт. Добавление фиктивной переменной ускорит работу.

Сообщение от f.hump

16, 17 - чо за нах. Основная задача х86 процессора анализ кода и "предвидиние" действия. И тут надо понимать, что проц не только пытается угадать, он еще ведет статистику переходов. Так что основная рекоммендация тут - избегать создания равновероятных переходов.

По пункту 16: если в switch перечислены подряд идущие кейсы, то он выберет подходящий за одно действие. а конструкция
if ( )
else if ( )
else if ( )
Будет вычислять все выражения.

По пункту 17 - конструкция if и переход будет значительно дольше чем просто вернуть значение в массиве. Это не ломает конвеер процессора.

Сообщение от f.hump

21 - если кто-то действительно пишет так, то наверное стоит вообще не писать

Не подходи так прямолинейно. Смысл пункта в том, что если у тебя большие числа во флоат переменной, то работа с ней и с маленькими значениями даст большую погрешность. Почитай:
http://itw66.ru/blog/c_plus_plus/481.html

[Пепел Феникса]

Добавление фиктивной переменной ускорит работу.

а умение пользоваться компилятором избавит от этого.

Если у вас используется выравнивание, то не сэкономит. А если использовать char то еще и медленнее работать будет.

я знаю, речь то про память была.

Это тоже память не сэкономит и работать будет долго, но иногда кэшмисы страшнее и приходится так упаковывать.

ну тут да, не сэкономит, так как меньше байта мы не адресуем.
насчет долго, не, не будет.
там элементарные команды проца, по смене битов.

[Blade]

Сообщение от Granus

Blade, я не думаю, что замена i++ на ++i так уж сильно затуманит код.

Как сказали выше - если нет разницы какую форму инкремента использовать, лучше использовать префиксную. А если используется постфиксная, то на это должна быть причина. И тот кто читает код, не должен гадать, почему же в 100 случаях до этого написано ++i, а теперь вдруг i++