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

Написал статью по оптимизации кода на С++. Ее можно почитать тут:
[ссылка удалена]

А вы какие еще способы оптимизации кода знаете? (я не говорю про оптимизацию алгоритмов. Речь идет про код вообще)

	Комментарий модератора
	Ссылки на сторонние ресурсы у нас и так не приветствуются, а уж битые и подавно...

1

Ошибка: 404

К сожалению, такой страницы не существует. Вероятно, она была удалена с сервера, либо ее здесь никогда не было.

0

Прошу прощения, вот исправленная ссылка:
http://itw66.ru/blog/c_plus_plus/13.html

0

Статья выглядит как СООБРАЖЕНИЯ программиста. Надо бы привести замеры времени.

0

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

0

а это выражение разве не эквивалентно этому?
и мне кажется что второе выполняется быстрее.

0

Допустим есть. C++ 1 2 3 const int a = 100; some1 = some3 * 1 / a; some2 = some4 * 1 / a; более эффективно написать не: C++ 1 2 3 const int a_inv = 1 / a; some1 = some3 * a_inv; some2 = some4 * a_inv; а так: C++ 1 2 some1 = some3 * (1 / a); some2 = some4 * (1 / a);

Ужас какой. Вместо последних двух строчек смело можно было написать
Вот уж что наверняка будет эффективнее

Добавлено через 1 минуту
Да и во втором случае то же самое.

0

Сообщение от aram_gyumri C++ 1 some1 = some3 * 1 / a; а это выражение разве не эквивалентно этому? C++ 1 some1 = some3 / a; и мне кажется что второе выполняется быстрее.

Нет, не быстрее.

1: some1 = some3 * (1.0f / a) - в рантайме будет только умножение. деление будет делать компилятор
2: some1 = some3 / a - будет деление в рантайме. Оно медленнее умножения.
3: some1 = some3 * 1.0f / a - это то же самое что и предыдущее

вариант 1 наиболее эффективный. А заменять на a_inv не нужно, чтобы не портить читаемость кода.

Добавлено через 1 минуту

Сообщение от grizlik78 Ужас какой. Вместо последних двух строчек смело можно было написать C++ 1 2 some1 = 0; some2 = 0; Вот уж что наверняка будет эффективнее Добавлено через 1 минуту Да и во втором случае то же самое.

да, ошибся. Исправил на вещественные числа.

0

int i; ... x = array[ i++ ]; - более эффективно, чем x = array[ ++i ];

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

В первом случае процессор может одновременно (без ожидания сложения) начать складывать и получать значение по адресу в массиве, а во втором случае он это будет делать последовательно.

на то были и придуманы термины префикс и постфикс - для удобства программистам

if( a || b) - нужно первым ставить более вероятное собятие, для большей эффективности if( func1() && func2() ) - нужно ставить более быстрый оператор первым

аналогично и сдесь дело не в эффективности, а в приоритете, при операции || в случае истинности 1-го операнда, 2-й просто напросто не вычисляется, а при операции && в случае ложности 1-го операнда, 2-й тоже не вычисляется, но это не вычисляется != эффективно

int a[ 1000 ]; for( int i =0; i<1000; ++i ) a[ i ] = 50; Значительно эффективнее будет: int* p = a; for( int i =0; i<1000; ++i, ++p ) *p = 50;

с чего бы это?

float f = 1.0f; *(int*)&f ^= 0x80000000; - быстрее чем f *= -1.0f;

а тут так вообще без пол-литры не разберёшся

2

12 C 1 2 3 u32 a; f32 b; b = (f32)(i32)a; - быстрее b = (f32)a;

А это что ещё за магия?

Добавлено через 17 минут
В общем в этой статье нет главного, что нередко пишут в хороших книгах.
Заниматься оптимизацией стоит только тогда, когда это действительно необходимо. Ранняя "оптимизация" нередко приводит к "пессимизации" кода. Кроме того, приведённые в статье трюки могут привести к ускорению (а могут и не привести) только для конкретного процессора и конкретного компилятора. Стоит сменить то или другое, как плюсы могут неожиданно превратиться в минусы. Ну и, как уже было замечено, без реальных цифр это всё-равно ни о чём. Хотя как заметка "что ещё можно попробовать, когда ничего не помогает", может и сгодится.

2

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

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

Оптимизация алгоритма - это наиболее важная оптимизация. Но иногда нужно делать такие системы, в который каждая строчка кода может быть решающей. Тогда и нужно понимать подобные принципы.

Допустим идет разработка системы частиц (particle system). Каждая частица будет апдейтиться в каждом кадре. Если частиц 10000 то любая лишняя операция будет сказываться на производительности. А если добавить несколько if то можно вообще ее убить.

Сообщение от Maxwe11 аналогично и сдесь дело не в эффективности, а в приоритете, при операции || в случае истинности 1-го операнда, 2-й просто напросто не вычисляется, а при операции && в случае ложности 1-го операнда, 2-й тоже не вычисляется, но это не вычисляется != эффективно

В данной статье под эффективностью понимается скорость выполнения. Согласись - более эффективный тот вариант, который делает меньше действий для получения результата. Значительно эффективнее код, который может не делать бесполезные действия. А самое главное, что от того как программист расположит операторы в if выражении будет зависеть скорость работы кода. Именно поэтому нужно думать, когда в if помещаешь функции. Может эта функция будет к серверу обращаться впустую только из за того, что программист поленился поставить первым оператором выражение, которое всегда вернет false.

Сообщение от Maxwe11 с чего бы это?

Инкремент указателя быстрее, чем его вычисление по произвольному смещению. Именно это будет при a[x].

0

FiloXSee, если бы вы привели ассемблерный код в обоих случаях, то все увидели бы, что НА САМОМ ДЕЛЕ эффективно.
А пока, повторюсь, статья выглядит просто как соображения программиста. Что ОЧЕНЬ ЧАСТО не соответствует действительности.

0

Еще одной хорошей практикой является следующее: Пусть у нас есть цикл C++ 1 2 3 for ( int i = 0; i < strlen( string ); ++i ) { } у нас на каждой итерации цикла вычисляется длина строки. Это плохо (за исключением когда строка в теле цикла меняется — но его мы рассматривать не будем). Лучше написать следующим образом: C++ 1 2 3 for ( int i = 0, size = strlen( string ); i < size; ++i ) { } И вообще — когда условие терминации цикла не меняется в ходе самого цикла (а в ином случае лучше использовать while) следует проводить предварительный расчет.

В данном случае можно сделать в 2 раза быстрее.

Сообщение от pito211 ?????

См. #3

2

Ошибка: 404 К сожалению, такой страницы не существует. Вероятно, она была удалена с сервера, либо ее здесь никогда не было. Вернуться назад, перейти на главную

?????

0

Сообщение от diagon В данном случае можно сделать в 2 раза быстрее. C++ 1 2 3 for (int i = 0; str[i]; ++i) { }

Спасибо за первый нормальный ответ.
Хотя это не ускорит код. Основное время тратится не на вычисление, а на условие. Его проверка остается даже в этом случае.

Более того, вариант for ( int i = 0, size = strlen( string ); i < size; ++i ) будет сравнивать две целые стековые переменные, а вариант for (int i = 0; str[i]; ++i) будет вычислять текущий указатель, разыменовывать его получая по нему данные, брать от них только 1 байт и только потом сравнивать его с нулем. Это будет дольше, чем просто сравнение.

0

Сообщение от FiloXSee Спасибо за первый нормальный ответ. Хотя это не ускорит код. Основное время тратится не на вычисление, а на условие. Его проверка остается даже в этом случае. Более того, вариант for ( int i = 0, size = strlen( string ); i < size; ++i ) будет сравнивать две целые стековые переменные, а вариант for (int i = 0; str[i]; ++i) будет вычислять текущий указатель, разыменовывать его получая по нему данные, брать от них только 1 байт и только потом сравнивать его с нулем. Это будет дольше, чем просто сравнение.

Вы забываете о том, как работает strlen
Примерная реализация
Т.е. в этом коде
Мы пробегаем по строке 2 раза, один раз, чтобы вычислить длину.
В моем же коде пробегаем всего 1 раз.

0

Сообщение от FiloXSee Спасибо за первый нормальный ответ. Хотя это не ускорит код. Основное время тратится не на вычисление, а на условие. Его проверка остается даже в этом случае. Более того, вариант for ( int i = 0, size = strlen( string ); i < size; ++i ) будет сравнивать две целые стековые переменные, а вариант for (int i = 0; str[i]; ++i) будет вычислять текущий указатель, разыменовывать его получая по нему данные, брать от них только 1 байт и только потом сравнивать его с нулем. Это будет дольше, чем просто сравнение.

Это опять-таки только ВАШИ соображения. Покажите ассемблерный текст для обоих вариантов.

1

Сообщение от FiloXSee Да, это разные операции. Вот только программист может организовать код так, чтобы использовать любую из них.

Две этих строки (с постфиксом и префиксом) сравнивать совершенно не корректно, т.к. они не взаимозаменяемы.

0

Сообщение от diagon Мы пробегаем по строке 2 раза, один раз, чтобы вычислить длину. В моем же коде пробегаем всего 1 раз.

Да, видимо там не очень удачный комментарий. Видимо комментатор там имел в виду, что нужно выносить все сложные вычисления из части условия в раздел объявления переменных, чтобы вычислять верхний предел один раз.

Добавлено через 3 минуты

Сообщение от voral Две этих строки (с постфиксом и префиксом) сравнивать совершенно не корректно, т.к. они не взаимозаменяемы.

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

0

Просто тогда явно не хватает сравнения что лучше
или
и отдельно
или

0