Оптимизация в GCC
Другой возможный способ решить это до редактор dconf , см. org.gnome.nautilus.preferences и default-folder-viewer там.
Это означает, что было бы простое короткое выражение для изменения этого, таким образом, можно включать его легко в сценарии конфигурации/установки. Посмотрите больше на dconf.
6 ответов
Единственный способ узнать наверняка - это протестировать ваше приложение, скомпилированное с -O2 и -O3. Также есть некоторые индивидуальные параметры оптимизации, которые включает -O3, и вы можете включать и выключать их по отдельности. Что касается предупреждения о больших двоичных файлах, обратите внимание, что простое сравнение размеров исполняемых файлов, скомпилированных с помощью -O2 и -O3, здесь не принесет особой пользы, потому что именно размер небольших критических внутренних циклов имеет здесь наибольшее значение. Вам действительно нужно выполнить тест.
Это приведет к увеличению размера исполняемого файла, но не должно быть заметного замедления.
Попробовать
Вы редко можете сделать точные суждения о скорости и оптимизации без каких-либо данных.
ps. Это также скажет вам, стоит ли это усилий. Сколько миллисекунд, сэкономленных в функции, используемой один раз при запуске, стоит?
Во-первых, похоже, что команда компиляторов, по сути, признает, что -O3 ненадежен. Похоже, они говорят: попробуйте -O3 в ваших критических циклах или критических модулях, или в вашей программе Lattice QCD , но она недостаточно надежна для построения всей системы или библиотеки.
Во-вторых, проблема с увеличением размера кода (встроенные функции и другие вещи) не только в том, что он использует больше памяти. Даже если у вас есть лишняя оперативная память, это может замедлить работу. Это связано с тем, что чем быстрее становится чип ЦП, тем больнее обращаться к DRAM. Они говорят, что некоторые программы будут работать быстрее с дополнительными вызовами подпрограмм и неразорвавшимися ветвями (или чем-то, что O3 заменяет более крупными вещами), потому что без O3 они все равно будут помещаться в кеш, и
-g и / или -ggdb просто добавляет отладочные символы в исполняемый файл. Это увеличивает исполняемый файл, но эта часть не загружается в память (кроме случаев, когда запускается в отладчике или подобном).
Что касается того, что лучше для производительности -O2 и -O3, серебряной пули нет. Вы должны измерить / профилировать его для вашей конкретной программы.
Я думаю, это в значительной степени отвечает на ваш вопрос:
. Недостатки перевешивают преимущества; помните принцип убывающей отдачи. Использование -O3 не рекомендуется для gcc 4.x.
По своему опыту я обнаружил, что GCC не генерирует лучшую сборку с O2 и O3. Лучший способ - применить определенные флаги оптимизации, которые вы можете найти из этого, определенно сгенерирует лучший код, чем -O2 и -O3, потому что есть флаги, которые вы не можете найти в -O2 и -O3, и они будут полезны для вашего более быстрого кода.
Хорошим примером является то, что код и инструкция предварительной выборки данных никогда не будут вставлены в ваш код с -O2 и -O3, но использование дополнительных флагов для предварительной выборки сделает ваш код, интенсивно использующий память, на 2–3% быстрее.
Вы можете список флагов оптимизации GCC можно найти на http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html .