GCC optimization/ru

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

Что такое CFLAGS и CXXFLAGS?
CFLAGS and CXXFLAGS are environment variables that are used to tell the GNU Compiler Collection, , what kinds of switches to use when compiling source code. CFLAGS are for code written in C, while CXXFLAGS are for code written in C++.

They can be used to decrease the amount of debug messages for a program, increase error warning levels, and, of course, to optimize the code produced. The GCC manual maintains a complete list of available options and their purposes.

Как их использовать?
Флаги CFLAGS и CXXFLAGS могут использоваться двумя путями. Во-первых, они могут использоваться на уровне единственной программы с помощью make-файлов, генерируемых утилитой automake.

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

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

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

CFLAGS - это не панацея; они не смогут автоматически заставить Вашу систему работать быстрее или двоичные файлы занимать меньше места на диске. Добавление все большего и большего количества флагов в попытке оптимизировать (или "разогнать") систему - верный рецепт для неудачи. Существует точка, в которой Вы достигнете худших результатов.

Вопреки хвастовству, которое Вы найдете в Интернете, агрессивные флаги компиляции CFLAGS и CXXFLAGS, скорее всего, принесут больше вреда, чем пользы для Ваших программ. Держите в уме, что причина, по которой флаги существуют с самого начала - это потому что они созданы для использования в определенном месте с определенной целью. Просто потому что один отдельный CFLAG хорош для одного участка кода, вовсе не означает что он подходит для компиляции всего, что Вы можете установить на Ваш компьютер!

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

Основы
The goal behind using CFLAGS and CXXFLAGS is to create code tailor-made to your system; it should function perfectly while being lean and fast, if possible. Sometimes these conditions are mutually exclusive, so we'll stick with combinations known to work well. Ideally, they are the best available for any CPU architecture. We'll mention the aggressive flags later so you know what to look out for. We won't discuss every option listed on the  manual (there are hundreds), but we'll cover the basic, most common flags.

-march
Самой первым, и наиболее важным параметром, является. Он сообщает компилятору какой код он должен генерировать для архитектуры Вашего процессора; он сообщает компилятору, что тот должен генерировать код для определенного типа CPU. Разные типы CPU имеют разные возможности, поддерживают различные наборы команд, и обладают разными способами исполнения кода. Флаг  проинструктирует компилятор генерировать код специально для Вашего типа CPU, со всеми доступными возможностями, особенностями, наборами команд, интересными функциями, и так далее.

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

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

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

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

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

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

Also available are the  and   flags. These flags are normally only used when there is no available  option; certain processor architectures may require   or even. Unfortunately, 's behavior isn't very consistent with how each flag behaves from one architecture to the next.

На процессорах x86 и x86-64, параметр  будет генерировать код, предназначенный специально для этих типов процессоров, используя все доступные наборы команд и корректный двоичный интерфейс приложений; он не будет обладать обратной совместимостью с более старыми/другими типами процессоров. Если Вам не требуется исполнять код на чем либо другом, кроме системы, на которой работает Gentoo, продолжайте использовать. Вы должны рассмотреть использование  только тогда, когда Вам необходимо сгенерировать код для более старых процессоров, таких как 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, 's behavior and flag naming just isn't consistent across architectures, so be sure to check the   manual to determine which one you should use for your system.

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

Существует пять видов настроек для переменной :  ,   ,   ,   , и. Вы должны использовать только одну из них в.

With the exception of , the   settings each activate several additional flags, so be sure to read the GCC manual's chapter on optimization options to learn which flags are activated at each   level, as well as some explanations as to what they do.

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


 * : This level (that's the letter "O" followed by a zero) turns off optimization entirely and is the default if no  level is specified in CFLAGS or CXXFLAGS.  This reduces compilation time and can improve debugging info, but some applications will not work properly without optimization enabled.  This option is not recommended except for debugging purposes.


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


 * : Шаг вперед из  . Это рекомендуемый уровень оптимизации, до тех пор пока Вам не понадобится что-то особенное.   активирует несколько дополнительных флагов вдобавок к флагам, активированным на   . С параметром  , компилятор попытается увеличить производительность кода без нарушения размера, и без затрачивания большого количества времени компиляции.


 * : This is 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.  Therefore, using   is not recommended.


 * : This option will optimize your code for size. It activates all  options that don't increase the size of the generated code. It can be useful for machines that have extremely limited disk storage space and/or have CPUs with small cache sizes.

As previously mentioned,  is the recommended optimization level. If package compilation fails and you aren't using, try rebuilding with that option. As a fallback option, try setting your CFLAGS and CXXFLAGS to a lower optimization level, such as  or even   (for error reporting and checking for possible problems).

-pipe
A common flag is. This flag actually has no effect on the generated code, but it makes the compilation process faster. It tells the compiler to use pipes instead of temporary files during the different stages of compilation, which uses more memory. On systems with low memory, GCC might get killed. In that case, do not use this flag.

-fomit-frame-pointer
This is a very common flag designed to reduce generated code size. It is turned on at all levels of  (except  ) on architectures where doing so does not interfere with debugging (such as x86-64), but you may need to activate it yourself by adding it to your flags. Though the  manual does not specify all architectures it is turned on by using , you will need to explicitly activate it on x86. However, using this flag will make debugging hard to impossible.

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

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

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

Но я получаю лучшую производительность с -funroll-loops -fomg-optimize!
No, you only think you do because someone has convinced you that more flags are better. Aggressive flags will only hurt your applications when used system-wide. Even the  manual says that using   and   makes code larger and run more slowly. Yet for some reason, these two flags, along with,  ,  , and similar flags, continue to be very popular among ricers who want the biggest bragging rights.

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

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

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

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

Need more proof? Examine the  source code:

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

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

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

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

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

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

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

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

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

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


 * The GCC online documentation


 * Глава 5 настольной книги по установке Gentoo




 * Wikipedia


 * форумы Gentoo

Благодарности
Мы хотели бы поблагодарить следующих авторов и редакторов за их вклад в это руководство:


 * nightmorph