Должны ли мы все еще оптимизировать «в малом»?

Question

Я изменял свой цикл for на инкремент, используя ++i вместо i++, и подумал, действительно ли это необходимо? Конечно, современные компиляторы делают эту оптимизацию самостоятельно.

В этой статье http://leto.net/docs/C-optimization.php, от 1997 года Майкл Ли занимается другими оптимизациями, такими как встраивание, разворачивание петли, заклинивание петли, инверсия петли, снижение прочности и многие другие. Они все еще актуальны?

Какие низкоуровневые оптимизации кода мы должны делать и какие оптимизации мы можем игнорировать?

Редактировать: Это не имеет никакого отношения к преждевременной оптимизации. Решение по оптимизации уже принято. Теперь вопрос в том, какой из них наиболее эффективен.

анекдот: однажды я просмотрел спецификацию требований, в которой говорилось: «Программист должен оставить сдвиг на единицу вместо умножения на 2».

Answer 1

Я все еще делаю такие вещи, как ra << = 1; вместо ra * = 2; И продолжим. Но компиляторы (какими бы плохими они ни были) и, что еще важнее, скорость компьютеров настолько высоки, что эти оптимизации часто теряются в шуме. В общем, нет, это того не стоит, если вы находитесь на платформе с ограниченными ресурсами (скажем, на микроконтроллере), где каждый дополнительный такт действительно имеет значение, то вы, вероятно, уже делаете это и, вероятно, делаете немало настроек ассемблера. По привычке я стараюсь не давать компилятору слишком много дополнительной работы, но из-за читаемости и надежности кода я не отказываюсь от своих усилий. </p>

Суть в производительности, хотя никогда не менялась. Найдите способ рассчитать код, измерить, чтобы найти низко висящий фрукт и исправить его. Майк Д. ударил ногтем по голове в ответ. Я слишком много раз видел, как люди беспокоятся о конкретных строках кода, не понимая, что они либо используют плохой компилятор, либо изменяя одну опцию компилятора, они могут увидеть увеличение производительности в несколько раз.

Answer 2

Прежде всего - всегда запускайте профилирование для проверки.

Во-первых, если вы оптимизируете правильную часть кода. Если код выполняется на 1% от общего времени - забудьте. Даже если вы уменьшите его на 50%, вы получите ускорение всего на 0,5%. Если вы не делаете что-то странное, ускорение будет намного медленнее (особенно если вы использовали хороший оптимизирующий компилятор). Во-вторых, если вы оптимизируете это правильно. Какой код будет работать быстрее на x86?

inc eax

или

add eax, 1

Хорошо. Насколько я знаю, в более ранних процессорах первый, а на P4 второй (здесь неважно, выполняются ли эти конкретные инструкции быстрее или медленнее, дело в том, что они все время меняются). Компилятор может быть в курсе таких изменений - вы не будете.

По моему мнению, основной целью является оптимизация, которая не может быть выполнена компилятором - как упоминалось ранее, размер данных (вы можете подумать, что в настоящее время он не нужен на компьютерах с 2 ГиБ - но если ваши данные больше, чем кэш процессора - это будет работать намного медленнее).

В общем, делайте это только в том случае, если вы должны и / или знаете, что делаете. Это потребует некоторого количества знаний о коде, компиляторе и низкоуровневой компьютерной архитектуре, которые не упомянуты в этом вопросе (и, честно говоря, мне это не нужно). И это, вероятно, ничего не выиграет. Если хочешь оптимизировать - делай это на более высоком уровне.