GCC optimization/ru

This guide provides Article description::an introduction to optimizing compiled code using safe, sane CFLAGS and CXXFLAGS . It also as describes the theory behind optimizing in general.

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

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

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

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

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

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

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

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

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

-march
The first and most important option is. 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  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.

is an ISA selection option; it tells the compiler that it may use the instructions from the ISA. On an Intel/AMD64 platform with  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,   or   options should be used as well.

is an optimization option (default at  and  ), which attempts to vectorize loops using the selected ISA if possible. The reason it isn't enabled at  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 в и указывает основную используемую архитектуру, параметр   все еще должен использоваться, так чтобы программы были оптимизированы для конкретного процессора. Процессоры x86 и x86-64 (в числе других) должны использовать флаг.

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

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

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


 * Первая команда говорит компилятору не производить линковку, и вместо того, чтобы интерпретировать опцию  для уточнения параметров командной строки, показывает какие опции включены или отключены . В этом случае показаны те опции, которые были включены для выбранной цели:


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

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

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

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

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

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

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

Only non-x86/x86-64 CPUs (such as SPARC, Alpha, and PowerPC) may require  or   instead of. On these architectures,  /   will sometimes behave just like   (on x86/x86-64) but with a different flag name. Again, GCC's behavior and flag naming is not consistent across architectures, so be sure to check the GCC manual to determine which one should be used.

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

There are seven  settings: ,  ,  ,  ,  ,  , and. Only use one of them in.

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

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


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


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


 * : A step up from . The recommended level of optimization unless the system has special needs.   will activate a few more flags in addition to the ones activated by  . With , the compiler will attempt to increase code performance without compromising on size, and without taking too much compilation time. SSE or AVX may be be utilized at this level but no YMM registers will be used unless   is also enabled.


 * : the highest level of optimization possible. It enables optimizations that are expensive in terms of compile time and memory usage. Compiling with   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.   is also known to break several packages. Using   is not recommended. However, it also enables   so that loops in the code get vectorized and will use AVX YMM registers.


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


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


 * : Новое в GCC 4.7, состоит из  плюс ,  , и  . Этот параметр нарушает строгое соответствие стандарту, и не рекомендуется для использования.

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

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

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

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

-msse, -msse2, -msse3, -mmmx, -m3dnow
These flags enable the Streaming SIMD Extensions (SSE), SSE2, SSE3, MMX, and [https://en.wikipedia.org/wiki/3DNow! 3DNow!] instruction sets for x86 and x86-64 architectures. These are useful primarily in multimedia, gaming, and other floating point-intensive computing tasks, though they also contain several other mathematical enhancements. These instruction sets are found in more modern CPUs.

Обычно, нет необходимости добавлять какие-либо из этих флагов в пока в системе используется корректный параметр   (например,   подразумевает использование   ). Некоторые заметные исключения - новые процессоры VIA и AMD64, которые поддерживают инструкции, не включаемые параметром  (такие как SSE3). Для таких процессоров, нужно включить дополнительные флаги, где это необходимо, после проверки.

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

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

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

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

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

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

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

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

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

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

А что об избыточных флагах?
Часто переменные CFLAGS и CXXFLAGS, которые включаются на разных уровнях , указаны избыточно в. Иногда, это сделано по неосведомленности, но также и для того, чтобы избежать отфильтровывание флагов или их замещение.

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

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

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

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

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

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

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

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


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




 * Wikipedia


 * форумы Gentoo