Оптимизации GCC

Это руководство предлагает введение в оптимизацию компилируемого кода используя безопасные, разумные флаги CFLAGS и CXXFLAGS. Оно также описывает теорию оптимизации в общих чертах.

Введение

Что такое CFLAGS и CXXFLAGS?

Переменные CFLAGS и CXXFLAGS входят в число переменных окружения, традиционно используемых для указания системе сборки параметров компилятора при сборке кода C и C++. Хотя эти переменные не стандартизованы, они используются повсеместно и любой грамотно написанный сборочный файл должен их понимать для того чтобы иметь возможность передавать дополнительные или индивидуальные параметры компилятору при его запуске. Info-страница GNU make содержит перечень некоторых наиболее широко используемых переменных из этой категории.

Поскольку большое количество пакетов, составляющих большинство систем Gentoo, написано на C и C++, администраторам следует правильно установить эти две переменные, так как они оказывают большое влияние на сборку системы.

Они могут быть использованы для уменьшения количества отладочных сообщений программы, увеличения уровня сообщений об ошибках, и, конечно же, оптимизации производимого кода. GCC manual поддерживает полный список доступных параметров и их предназначений.

Как они используются?

Как правило, переменные CFLAGS и CXXFLAGS устанавливаются в окружении при вызове скрипта configure или с помощью файла make-файлов, созданных программой automake. В системах на базе Gentoo эти переменные устанавливаются в файле /etc/portage/make.conf. Переменные, установленные в этом файле, экспортируются в окружение программ, запускаемых portage — таким образом, все пакеты собираются, используя эти параметры в качестве основы.

Код Настройка CFLAGS в /etc/portage/make.conf

CFLAGS="-march=athlon64 -O2 -pipe"
CXXFLAGS="${CFLAGS}"

Важно
Хоть и можно записать USE-флаги в несколько строк, запись в несколько строк переменной CFLAGS может привести к ошибкам в некоторых программах, например, в cmake. Убедитесь, что CFLAGS записаны в одну строку и с короткими пробелам, во избежании лишних проблем. Посмотрите bug #500034 например.

В примере выше переменная CXXFLAGS установлена таким образом, что она использует все параметры, установленные в переменной CFLAGS. Почти все системы следует настраивать таким образом. Дополнительные параметры для переменной CXXFLAGS менее распространены и, как правило, используются недостаточно широко для того, чтобы имело смысл устанавливать их глобально.

Совет
Статья Safe CFLAGS может помочь новичкам начать оптимизацию их систем.

Заблуждения

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

Параметры глобальной переменной CFLAGS, установленной в файле /etc/portage/make.conf, применяются ко всем пакетам в системе, поэтому обычно администраторы устанавливают в этой переменной только наиболее общие, широко используемые параметры. Отдельные пакеты могут изменять эти параметры либо в файле ebuild либо в самой системе сборки, создавая окончательный набор флагов, подаваемых компилятору.

Готовы?

Теперь, зная о некоторых рисках, давайте посмотрим на некоторые из разумных, безопасных оптимизаций. Они окажут большую пользу и расположат разработчиков в следующий раз, когда будете сообщать о проблеме на Bugzilla. (Разработчики обычно просят пользователей перекомпилировать пакет с минимальным количеством переменных CFLAGS для того, чтобы определить, продолжает ли проблема существовать. Запомните: агрессивные флаги могут разрушить код!)

Оптимизация

Основы

Целью использования CFLAGS и CXXFLAGS является создание кода, приспособленного под систему; он должен отлично функционировать, будучи легковесным и быстрым, если это возможно. Иногда это взаимоисключающие условия, поэтому это руководство будет придерживаться комбинаций, о которых известно, что они работают хорошо. В идеале, они являются легко доступными на любой архитектуре CPU. Для ознакомления агрессивное использование флага будет рассмотрено позднее. Не будет описываться каждый параметр из руководства GCC (их очень много), но опишем основные, наиболее часто используемые флаги.

Заметка
Если не уверены что делает флаг, проконсультируйтесь с соответствующей главой GCC руководства. Если после просмотра руководства все еще не уверены, то попробуйте поискать в интернете, или в списках рассылок GCC.

-march

The first and most important option is -march. This tells the compiler what code it should produce for the system's processor architecture (or arch); it tells GCC that it should produce code for a certain kind of CPU. Different CPUs have different capabilities, support different instruction sets, and have different ways of executing code. The -march flag will instruct the compiler to produce specific code for the system's CPU, with all its capabilities, features, instruction sets, quirks, and so on provided the source code is prepared to use them. For instance, to take benefit from AVX instructions, the source code needs to be adapted to support it.

-march= is an ISA selection option; it tells the compiler that it may use the instructions from the ISA. On an Intel/AMD64 platform with -march=native -O2 or lower OPT level, the code will likely end up with AVX instructions used but using shorter SSE XMM registers. To take full advantage of AVX YMM registers, the -ftree-vectorize, -O3 or -Ofast options should be used as well.

-ftree-vectorize is an optimization option (default at -O3 and -Ofast), which attempts to vectorize loops using the selected ISA if possible. The reason it isn't enabled at -O2 is that it doesn't always improve code, it can make code slower as well, and usually makes the code larger; it really depends on the loop etc.

Хотя переменная CHOST в /etc/portage/make.conf и указывает основную используемую архитектуру, параметр -march все еще должен использоваться, так чтобы программы были оптимизированы для конкретного процессора. Процессоры x86 и x86-64 (в числе других) должны использовать флаг -march.

Какой вид CPU имеется в системе? Чтобы это узнать, введите следующую команду:

user $cat /proc/cpuinfo

or even install app-portage/cpuid2cpuflags and add the available CPU-specific options to the make.conf file, which the tool does through e.g. the CPU_FLAGS_X86 variable:

user $cpuid2cpuflags

CPU_FLAGS_X86: aes avx avx2 f16c fma3 mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3

root #echo "CPU_FLAGS_X86='aes avx avx2 f16c fma3 mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3'" >> /etc/portage/make.conf

Чтобы получить более детальную информацию, включая значения march и mtune можно использовать две команды.

• Первая команда говорит компилятору не производить линковку (-c), и вместо того, чтобы интерпретировать опцию --help для уточнения параметров командной строки, показывает какие опции включены или отключены (-Q). В этом случае показаны те опции, которые были включены для выбранной цели:

user $gcc -c -Q -march=native --help=target

• Вторая команда покажет директивы компилятора для построения заголовочного файла, но без фактического выполнения, а результат работы выведет на экран (-###). Вывод содержит все параметры оптимизации, а также выбранную архитектуру:

user $gcc -### -march=native /usr/include/stdlib.h

Давайте теперь рассмотрим -march в действии. Этот пример приведен для более старого чипа Pentium III:

Файл /etc/portage/make.confPentium III example

CFLAGS="-march=pentium3"
CXXFLAGS="${CFLAGS}"

А это другой пример для 64-разрядного AMD CPU:

Файл /etc/portage/make.confпример для AMD64

CFLAGS="-march=athlon64"
CXXFLAGS="${CFLAGS}"

Если тип процессора все еще нее определен, либо не знаете какую настройку выбрать, то можно воспользоваться параметром -march=native. Когда используется этот флаг, GCC попытается распознать процессор и автоматически установит для него подходящие флаги. Однако, не нужно его использовать, если собираетесь компилировать пакеты для разных CPU!

Предупреждение
Не используйте -march=native или -mtune=native в переменных CFLAGS или CXXFLAGS файла make.conf при компиляции с помощью distcc.

При сборке пакетов на одном компьютере с целью их запуска на другом (например, при сборке на более быстром компьютере с целью запуска на более старом и медленном) не используйте параметр -march=native. "Native" означает, что полученный код может запускаться только на этом типе CPU. Приложения, собранные с параметром -march=native на AMD Athlon 64 CPU не будут работать на VIA C3 CPU.

Также, доступны флаги -mtune и -mcpu. Эти флаги обычно используются только тогда, когда нет доступного параметра -march; определенные архитектуры процессоров могут требовать -mtune или даже -mcpu. К сожалению, поведение GCC не совсем предсказуемо для того, как эти флаги ведут себя при переходе от одной архитектуры к другой.

На процессорах x86 и x86-64, параметр -march будет генерировать код, предназначенный специально для этих типов процессоров, используя все доступные наборы команд и корректный двоичный интерфейс приложений; он не будет обладать обратной совместимостью с более старыми/другими типами процессоров. Рассмотрите возможность использования -mtune, когда необходимо сгенерировать код для более старых процессоров, таких как i386 и i486. Параметр -mtune производит более общий код, чем -march; хотя он и настроит код под определенный процессор, он не будет рассматривать доступные наборы команд и двоичный интерфейс приложений. Не используйте -mcpu на системах с x86 или x86-64, так как это не рекомендуется для этих архитектур.

Только не x86/x86-64 процессоры (такие как SPARC, Alpha, и PowerPC) могут потребовать параметры -mtune или -mcpu вместо -march. На этих архитектурах, -mtune/-mcpu иногда будут вести себя как -march (на x86/x86-64), но с другим именем флага. Опять же, поведение GCC и именование флагов не является единообразным на каждой из архитектур, поэтому удостоверьтесь, что проконсультировались с GCC manual, для того чтобы определить какой из них должен быть использован.

Заметка
Для большего количества предполагаемых настроек -march/-mtune/-mcpu, пожалуйста, прочитайте главу 5 подходящей настольной книги Gentoo для архитектуры. Также, прочтите список руководств по архитектурно-зависимым параметрам GCC, наряду с более подробным объяснением различий между -march, -mcpu, и -mtune.

-O

Предупреждение
Использование -O3 или -Ofast может привести к тому, что компиляция некоторых пакетов будет завершаться с ошибкой.

Заметка
Для отображения всех пакетов, которые были скомпилированы с определенным CFLAGS/CXXFLAGS, можно использовать следующую команду: grep Ofast /var/db/pkg/*/*/CFLAGS

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

Существует семь видов настроек переменной -O: -O0, -O1, -O2, -O3, -Os, -Og и -Ofast. Используйте только одну из них в /etc/portage/make.conf.

За исключением -O0, каждая из настроек с префиксом -O активирует несколько дополнительных флагов, поэтому удостоверьтесь, что Вы прочитали главу руководства GCC по параметрам оптимизации для изучения того, какие флаги активируются на каждом уровне с приставкой -O, также как и некоторые из объяснений того, что они делают.

Давайте исследуем каждый уровень оптимизации:

• -O0: Этот уровень (буква "O" и ноль за ней) отключает оптимизацию полностью и является уровнем по умолчанию, если никакого уровня с префиксом -O не указано в переменных CFLAGS или CXXFLAGS. Это сокращает время компиляции и может улучшить данные для отладки, но некоторые приложения не будут работать должным образом без оптимизации. Эта опция не рекомендуется, за исключением использования в целях отладки.

• -O1: Это наиболее простой уровень оптимизации. Компилятор попытается сгенерировать быстрый, занимающий меньше объема код, без затрачивания наибольшего времени компиляции. Он достаточно простой, но должен всегда выполнять свою работу.

• -O2: Шаг вперед от -O1. Рекомендуемый уровень оптимизации, до тех пор пока не понадобится что-то особенное. -O2 активирует несколько дополнительных флагов вдобавок к флагам, активированных -O1. С параметром -O2, компилятор попытается увеличить производительность кода без нарушения размера, и без затрачивания большого количества времени компиляции. На этом уровне могут быть использованы SSE и AVX, но YMM-регистры не будут использоваться пока не будет включена опция -ftree-vectorize.

• -O3: the highest level of optimization possible. It enables optimizations that are expensive in terms of compile time and memory usage. Compiling with -O3 is not a guaranteed way to improve performance, and in fact, in many cases, can slow down a system due to larger binaries and increased memory usage. -O3 is also known to break several packages. Using -O3 is not recommended. However, it also enables -ftree-vectorize so that loops in the code get vectorized and will use AVX YMM registers.

• -Os: На этом уровне код будет оптимизирован по объему. Он активирует все параметры -O2, которые не приводят к увеличению размера генерируемого кода. Он может быть полезным на компьютерах, которые обладают чрезвычайно ограниченным пространством жесткого диска и/или процессоры с небольшим размером кэша.

• -Og: В GCC 4.8 был введен новый общий уровень оптимизации -Og. Он удовлетворяет потребность в быстрой компиляции и имеет превосходные возможности для отладки, обеспечивая при этом приемлемый уровень производительности во время выполнения. Общий опыт разработки должен быть лучше, чем с уровнем оптимизации по умолчанию -O0. Обратите внимание, что -Og не означает -g, он просто отключает оптимизацию кода, которая может помешать отладке.

• -Ofast: Новое в GCC 4.7, состоит из -O3 плюс -ffast-math, -fno-protect-parens, и -fstack-arrays. Этот параметр нарушает строгое соответствие стандарту, и не рекомендуется для использования.

Как упомянуто ранее, параметр -O2 - рекомендуемый уровень оптимизации. Если компиляция пакета выдает сообщение об ошибке и не используется параметр -O2, то попробуйте перекопилировать с этой опцией. В качестве выхода, попробуйте установить переменные CFLAGS и CXXFLAGS на наименьший уровень оптимизации, такой как -O1, или даже -O0 -g2 -ggdb (для сообщения об ошибках и проверки возможных проблем).

-pipe

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

-fomit-frame-pointer

Это очень часто используемый флаг, предназначенный для того, чтобы уменьшить размер генерируемого кода. Он включается на всех уровнях с префиксом -O (исключая -O0) на тех архитектурах, где это не затрудняет отладку (таких как x86-64), но его, возможно, необходимо активировать. В этом случае добавьте его к флагам. Хотя руководство по GCC не указывает все архитектуры, но он включается с использованием параметра -O. Также нужно явно активировать -fomit-frame-pointer для x86-32, если GCC версии ниже 4.6, либо при использовании -Os на x86 -32 с любой версией GCC. Однако, использование -fomit-frame-pointer может сделать отладку сложной, или даже невозможной.

В частности, это делает устранение неполадок в приложениях, написанных на Java и скомпилированных в gcj, намного сложнее, хотя код, написанный на Java - не единственный, который затронут использованием этого флага. Поэтому, в то время как использование этого флага может помочь, оно также затрудняет отладку; трассировка стека, в частности, будет бесполезна. Если не планируется отлаживать программы и нет других переменные CFLAGS, связанные с отладкой, такие как -ggdb, то попробуйте использовать -fomit-frame-pointer.

Важно
Не комбинируйте -fomit-frame-pointer с подобным флагом -momit-leaf-frame-pointer. Использование последнего флага не рекомендуется, так как -fomit-frame-pointer уже выполняет всю работу. Кроме того, показано, что -momit-leaf-frame-pointer негативно влияет на производительность кода.

-msse, -msse2, -msse3, -mmmx, -m3dnow

Эти флаги разрешают наборы команд Streaming SIMD Extensions (SSE), SSE2, SSE3, MMX, и 3DNow! для архитектур x86 и x86-64. Они используются в основном в мультимедиа, играх, и других вычислительных задачах с интенсивным использованием плавающей точки, хотя они также включают несколько других математических расширений. Эти наборы команд предоставляются большинством современных процессоров.

Важно
Убедитесь, что проверили поддерживает ли процессор эти наборы команд, введя команду cat /proc/cpuinfo. Результат будет включать любые дополнительные наборы команд, которые поддерживаются. Заметьте, что pni - это просто другое имя для SSE3.

Обычно, нет необходимости добавлять какие-либо из этих флагов в /etc/portage/make.conf пока в системе используется корректный параметр -march (например, -march=nocona подразумевает использование -msse3 ). Некоторые заметные исключения - новые процессоры VIA и AMD64, которые поддерживают инструкции, не включаемые параметром -march (такие как SSE3). Для таких процессоров, нужно включить дополнительные флаги, где это необходимо, после проверки /proc/cpuinfo.

Заметка
Сверьтесь с списком флагов, характерных для архитектур x86 и x86-64, чтобы увидеть, какие из этих инструкций активированы соответствующим флагом типа процессора. Если инструкция перечислена, то не нужно ее указывать отдельно; она будет включена с помощью подходящей настройки -march.

FAQ по оптимизации

Но я получаю лучшую производительность с -funroll-loops -fomg-optimize!

Нет, людям только кажется что они получают лучшую производительность, потому что кто-то их убедил в том, что чем больше флагов, тем лучше. Агрессивные флаги только повредят приложениям при глобальном использовании. Даже GCC manual говорит, что использование параметров -funroll-loops и -funroll-all-loops может увеличить объем кода и время его исполнения. Хотя, по каким-то причинам, эти два флага, вместе с флагами -ffast-math, -fforce-mem, -fforce-addr, и им подобными, продолжают пользоваться популярностью среди гонщиков, которые хотят повысить чувство собственной важности.

Истина в том, что это чрезвычайно агрессивные флаги. Посмотрите по форумам Gentoo и Bugzilla, чтобы увидеть, что эти флаги могут сделать: ничего хорошего!

Не нужно использовать эти флаги глобально, в переменных CFLAGS и CXXFLAGS. Они только ухудшат производительность. Может показаться, что они сделают систему более высокопроизводительной, работающей по последнему слову техники, но они ничего не делают, кроме раздувания кода и приведут к тому, что ваши сообщения о багах пометят как INVALID или WONTFIX.

Такие опасные флаги, как эти не нужны. Не используйте их. Придерживайтесь основ: -march, -O, и -pipe.

Что по поводу уровней оптимизации -O больших чем 3?

Некоторые пользователи хвалятся даже большей производительностью, достигнутой использованием -O4, -O9, и так далее, но в действительности, уровни -O большие чем 3 не имеют никакого эффекта. Компилятор может принимать переменные CFLAGS, такие как -O4, но, на самом деле, ничего с ними не делает. Он только выполняет оптимизацию до уровня -O3, и ничего больше:

Нужно больше доказательств? Исследуйте исходный код:

Код Исходный код параметра -O

if (optimize >= 3)
    {
      flag_inline_functions = 1;
      flag_unswitch_loops = 1;
      flag_gcse_after_reload = 1;
      /* Allow even more virtual operators.  */
      set_param_value ("max-aliased-vops", 1000);
      set_param_value ("avg-aliased-vops", 3);
    }

Как можно увидеть, любое значение больше тройки рассматривается как -O3.

Что насчет компиляции не на целевой машине?

Некоторые читатели могут спросить, не приведет ли компиляция не на целевой машине, сильно отличающейся архитектурой процессора или структурой GCC, к плохому качеству оптимизации (по сравнению с нативной компиляцией). Ответ прост: Нет. Независимо от используемого оборудования, на котором проводится компиляция, и от значения переменной CHOST, с использованием которой был собран GCC, если используются те же аргументы (кроме -march=native) и та же версия GCC (хотя небольшие оптимизации могут отличаться), результирующий уровень оптимизации останется строго тем же.

Например, если Gentoo установлен на компьютере, на котором переменная CHOST для GCC равна i686-pc-linux-gnu, а сервер Distcc настроен на другом компьютере, на котором CHOST для GCC равна i486-linux-gnu, то не нужно бояться, что результаты будут менее оптимальны из-за отличающейся архитектуры удаленного компилятора и/или оборудования. Результат будет оптимизирован в той же степени, как и при сборке на целевом компьютере, если, конечно, обоим компиляторам передаются одинаковые параметры (и параметр -march не включает значение native). В данном конкретном случае целевую архитектуру нужно явно определять, как указано в статье Distcc и -march=native.

Единственная разница в поведении между двумя версиями GCC, построенными с использованием разных архитектур в значении параметра -march по умолчанию. Он берется из переменной CHOST для GCC, если он не указан явно в командной строке.

А что об избыточных флагах?

Часто переменные CFLAGS и CXXFLAGS, которые включаются на разных уровнях -O, указаны избыточно в /etc/portage/make.conf. Иногда, это сделано по неосведомленности, но также и для того, чтобы избежать отфильтровывание флагов или их замещение.

Фильтрация/замещение флагов используется во многих ebuild-файлах, находящихся в дереве Portage. Обычно, это делается потому что пакеты не компилируются на определенных уровнях -O, или когда исходный код очень чувствителен к дополнительно используемым флагам. Ebuild-файл или отфильтровывает некоторые или все переменные CFLAGS и CXXFLAGS, или может заменить -O другим уровнем.

Руководство разработчика Gentoo описывает в общих чертах, где и как работает фильтрация/замещение флагов.

Возможно обойти фильтрацию уровней -O, избыточно перечисляя флаги для определенного уровня, например -O3, делая такие вещи как:

Код Указание избыточных CFLAGS

CFLAGS="-O3 -finline-functions -funswitch-loops"

Однако, это не самая умная вещь, которую можно сделать. CFLAGS отфильтровываются не зря! Когда флаги фильтруются, это означает, что собирать пакет с этими флагами небезопасно. Очевидно, что небезопасно компилировать всю систему с -O3 если некоторые из флагов, включенных на этом уровне, вызовут проблемы с определенными пакетами. Следовательно, не пытайтесь обхитрить разработчиков, которые поддерживают эти пакеты. Доверяйте разработчикам. Фильтрация флагов и их замена делаются для обеспечения стабильности системы и приложения! Если ebuild-файл указывает альтернативные флаги, то не пытайтесь это обойти.

Сборка пакетов с недопустимыми флагами скорее всего вызовет проблемы. При создании отчета об ошибке на Bugzilla флаги, установленные в файле /etc/portage/make.conf, отчетливо видны, и разработчики все равно попросят пересобрать пакет без этих флагов. Чтобы избежать необходимости повторной сборки, не используйте эти флаги изначально. Не стоит автоматически полагать себя более сведущим, чем разработчики.

Что по поводу LDFLAGS?

Разработчики Gentoo уже установили простые, безопасные LDFLAGS в базовых профилях, поэтому не нужно их изменять.

Могу ли я использовать флаги для отдельных пакетов?

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

Информация об использовании переменных среды для каждого пакета по отдельности (включая CFLAGS) описана в настольной книге Gentoo, "Переменное окружение для отдельных пакетов".

Смотрите также

• Настройка параметров компиляции (AMD64 Handbook)

Внешние ресурсы

Следующие источники могут быть полезными в дальнейшем изучении оптимизации:

• Онлайн-документация GCC

• man make.conf

• Wikipedia

• форумы Gentoo

Ссылки

---

This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Joshua Saddler (nightmorph)
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article's associated history page.