Я понимаю большинство существующих микрооптимизаций, но действительно ли они полезны?
Exempli gratia: действительно ли выполнение ++i вместо i++, while(1) или for(;;) приводит к повышению производительности (по отпечаткам памяти или циклам ЦП)?
Итак, вопрос в том, какие микрооптимизации можно сделать в C? Действительно ли они полезны?
Вы должны полагаться на свой компилятор, чтобы оптимизировать этот материал. Сконцентрируйтесь на использовании соответствующих алгоритмов и написании надежного, читаемого и обслуживаемого кода.
День, когда tclhttpd, веб-сервер, написанный на Tcl, одном из самых медленных языков сценариев, смог превзойти Apache, веб-сервер, написанный на C, одном из предположительно самых быстрых компилируемых языков, был днем, когда я убедился, что микрооптимизации значительно блекнут по сравнению к использованию более быстрого алгоритма / техники *.
Никогда не беспокойтесь о микрооптимизациях, пока вы не докажете в отладчике, что это проблема. Даже в этом случае я бы порекомендовал сначала прийти сюда, в SO, и спросить, стоит ли надеяться, что кто-то убедит вас не делать этого.
Это противоречит интуиции, но очень часто код, особенно жесткие вложенные циклы или рекурсия, оптимизируется путем добавления кода, а не его удаления. Игровая индустрия придумала бесчисленное множество уловок для ускорения вложенных циклов с помощью фильтров, чтобы избежать ненужной обработки. Эти фильтры добавляют значительно больше инструкций, чем разница между i ++ и ++ i.
* примечание: с тех пор мы многому научились. Осознание того, что медленный язык сценариев может превзойти скомпилированный машинный код, поскольку создание потоков обходится дорого, привело к разработке lighttpd, NginX и Apache2.
Я думаю, что есть разница между микрооптимизацией, уловкой и альтернативными средствами что-то сделать. Использование ++i вместо i++ может быть микрооптимизацией, хотя я бы подумал об этом просто как о предотвращении пессимизации, потому что, когда вы предварительно увеличиваете (или уменьшаете), компилятору не нужно вставлять код для отслеживания текущего значения переменная для использования в выражении. Если использование предварительного приращения / декремента не меняет семантику выражения, вам следует использовать его и избегать накладных расходов.
С другой стороны, уловка - это код, который использует неочевидный механизм для достижения результата быстрее, чем это сделал бы простой механизм. Следует избегать уловок, если в этом нет крайней необходимости. Получение небольшого процента ускорения обычно не стоит ущерба для читабельности кода, если этот небольшой процент не отражает значимое количество времени. Чрезвычайно долго выполняющиеся программы, особенно программы с большим объемом вычислений, или программы реального времени часто являются кандидатами на уловки, потому что сэкономленное время может быть необходимо для достижения целей производительности системы. При использовании уловок следует четко задокументировать их.
Альтернативы - это просто так. Прирост производительности может быть незначительным или отсутствовать; они просто представляют собой два разных способа выражения одного и того же намерения. Компилятор может даже создать такой же код. В этом случае выберите наиболее читаемое выражение. Я бы посоветовал сделать это, даже если это приведет к некоторой потере производительности (хотя см. Предыдущий абзац).
Я думаю, вам не нужно думать об этих микрооптимизациях, потому что большинство из них выполняется компилятором. Эти вещи могут только затруднить чтение кода.
Помните, [отредактированная] преждевременная [/ отредактированная] оптимизация - это зло.
Честно говоря, этот вопрос, хотя и актуален, сегодня не актуален - почему?
Авторы компиляторов намного умнее, чем 20 лет назад, они возвращаются назад во времени, тогда эти оптимизации были бы очень актуальны, мы все работали со старыми процессорами 80286/386, и кодеры часто прибегали к уловкам, чтобы сжать еще больше байтов из скомпилированного кода.
Сегодня процессоры слишком быстры, разработчики компиляторов знают тонкие детали инструкций операндов, чтобы все работало, учитывая, что есть конвейерная обработка, основные процессоры, акры ОЗУ, помните, с процессором 80386 было бы 4 Мб ОЗУ и если повезет, 8Мб было сочтено лучше !!
Парадигма изменилась, теперь речь шла о том, чтобы выжать каждый байт из скомпилированного кода, теперь это больше касается производительности программистов и выпуска релиза гораздо раньше.
Выше я изложил природу процессора и компиляторов, я говорил о семействе процессоров Intel 80x86, компиляторах Borland / Microsoft.
Надеюсь, это поможет, С уважением, Том.
Если вы можете легко увидеть, что две разные кодовые последовательности дают одинаковые результаты, без каких-либо предположений о данных, кроме тех, которые присутствуют в коде, то компилятор тоже может, и обычно будет.
Это только тогда, когда преобразование от одного к другому крайне неочевидно или требует допущения чего-то, что вы можете знать как истинное, но компилятор не имеет возможности сделать вывод (например, что операция не может переполниться или что два указателя никогда не будут псевдонимами, даже если они не объявлены с ключевым словом restrict), вам следует подумать об этих вещах. Даже в этом случае лучше всего найти способ сообщить компилятору о предположениях, которые он может сделать.
Если вы обнаружите конкретные случаи, когда компилятор пропускает простые преобразования, в 99% случаев вам следует просто сообщить об ошибке компилятору и продолжить работу над более важными вещами.
Помня о том, что память - это новый диск, вы, вероятно, улучшите вашу производительность намного больше, чем применение любой из этих микрооптимизаций.
Для более прагматичного подхода к вопросу ++ i и i ++ (по крайней мере, в контексте C ++) см. http://llvm.org/docs/CodingStandards.html#micro_preincrement.
Если это говорит Крис Латтнер, я должен обращать внимание. ;-)
Вам лучше рассматривать каждую программу, которую вы пишете, в первую очередь, как язык, на котором вы передаете свои идеи, намерения и рассуждения другим людям, которым придется исправлять ошибки, повторно использовать и понимать их. Они будут тратить больше времени на декодирование искаженного кода, чем любой компилятор или исполняющая система потратит на его выполнение. Подводя итог, скажите, что вы имеете в виду, самым ясным образом, используя общие идиомы рассматриваемого языка.
Для этих конкретных примеров в C for (;;) - это идиома для бесконечного цикла, а «i ++» - это обычная идиома для «добавить единицу к i», если вы не используете значение в выражении, и в этом случае это зависит от того, значение с наиболее ясным значением - это значение до или после приращения.
По моему опыту, здесь настоящая оптимизация.
Кто-то из SO однажды заметил, что микрооптимизация похожа на «стрижку, чтобы похудеть». По американскому телевидению идет передача «Самый большой неудачник», в которой тучные люди соревнуются за похудение. Если бы они смогли снизить вес тела до нескольких граммов, то стрижка могла бы помочь.
Возможно, это преувеличение аналогии с микрооптимизацией, потому что я видел (и написал) код, в котором микрооптимизация действительно действительно имела значение, но если начать, можно получить гораздо больше, просто не решая проблем, которых у вас нет.
++ i следует предпочесть i ++ в ситуациях, когда вы не используете возвращаемое значение, потому что оно лучше представляет семантику того, что вы пытаетесь сделать (приращение i), а не любую возможную оптимизацию (это может быть немного быстрее и наверное не хуже).
Как правило, циклы, которые считают до нуля, быстрее, чем циклы, которые считаются до некоторого другого числа. Я могу представить себе ситуацию, когда компилятор не может сделать эту оптимизацию за вас, но вы можете сделать это сами.
Скажем, у вас есть массив длины x, где x - очень большое число, и что вам нужно выполнить некоторую операцию с каждым элементом x. Далее, допустим, вам все равно, в каком порядке происходят эти операции. Вы можете сделать это ...
int i;
for (i = 0; i < x; i++)
doStuff(array[i]);
Но вы могли бы немного оптимизировать, сделав это таким образом -
int i;
for (i = x-1; i != 0; i--)
{
doStuff(array[i]);
}
doStuff(array[0]);
Компилятор не делает этого за вас, потому что не может предполагать, что порядок не важен.
Код примера MaR лучше. Учтите это, предполагая, что doStuff () возвращает int:
int i = x;
while (i != 0)
{
--i;
printf("%d\n",doStuff(array[i]));
}
Это нормально, если допустима печать содержимого массива в обратном порядке, но компилятор не может решить это за вас.
Эта оптимизация зависит от оборудования. Из того, что я помню о написании ассемблера (много-много лет назад), счет вверх, а не обратный отсчет до нуля, требует дополнительной машинной инструкции каждый раз, когда вы проходите цикл.
Если ваш тест похож на (x ‹y), тогда оценка теста будет примерно такой:
Если ваш тест (x! = 0), вы можете сделать это:
Вы можете пропустить инструкцию вычитания для каждой итерации.
Существуют архитектуры, в которых вы можете заставить команду вычитания устанавливать флаги на основе результата вычитания, но я почти уверен, что x86 не входит в их число, поэтому большинство из нас не используют компиляторы, у которых есть доступ к такой машинная инструкция.
