GCC optimization/ru

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

Что такое CFLAGS и CXXFLAGS?
Флаги CFLAGS и CXXFLAGS - это переменные среды, которые используются для сообщения компиляторам GNU Compiler Collection, , какие виды ключей использовать при компиляции исходного кода. CFLAGS используются для кода написанного на C, в то время как флаги CXXLFAGS - для кода написанного на C++.

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

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

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

Флаги CFLAGS в /etc/portage/make.conf

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

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

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

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

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

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

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

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

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

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

/etc/portage/make.conf: Pentium III

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

/etc/portage/make.conf: AMD64

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

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

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

На процессорах 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
Next up is the  variable. This controls the overall level of optimization. This makes the code compilation take somewhat more time, and can take up much more memory, especially as you increase the level of optimization.

There are five  settings:  ,   ,   ,   , and. You should use only one of them in.

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.

Let's examine each optimization level:


 * : 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. Your code will not be optimized; it's not normally desired.


 * : This is the most basic optimization level. The compiler will try to produce faster, smaller code without taking much compilation time. It's pretty basic, but it should get the job done all the time.


 * : A step up from  . This is the recommended level of optimization unless you have 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.


 * : This is the highest level of optimization possible, and also the riskiest. It will take a longer time to compile your code with this option, and in fact it should not be used system-wide with  4.x . The behavior of   has changed significantly since version 3.x. In 3.x,   has been shown to lead to marginally faster execution times over  , but this is no longer the case with   4.x. Compiling all your packages with   will result in larger binaries that require more memory, and will significantly increase the odds of compilation failure or unexpected program behavior (including errors). The downsides outweigh the benefits; remember the principle of diminishing returns. Using   is not recommended for   4.x.


 * : This level 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. However, it can cause quite a few problems, which is why it is filtered out by many of the ebuilds in the tree. Using   is not recommended.

As previously mentioned,  is the recommended optimization level. If package compilations error out, check to make sure that you aren't using. 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) and recompile the package.

-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 GNU  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.

In particular, it makes troubleshooting applications written in Java much harder, though Java is not the only code affected by using this flag. So while the flag can help, it also makes debugging harder; backtraces in particular will be useless. However, if you don't plan to do much software debugging and haven't added any other debugging-related CFLAGS such as , then you can try using.

-msse, -msse2, -msse3, -mmmx, -m3dnow
These flags enable the SSE, SSE2 , SSE3 , MMX , and 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.

You normally don't need to add any of these flags to as long as you are using the correct   (for example,   implies   ). Some notable exceptions are newer VIA and AMD64 CPUs that support instructions not implied by  (such as SSE3). For CPUs like these you'll need to enable additional flags where appropriate after checking the output of.

But I get better performance with -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.

The truth of the matter is that they are dangerously aggressive flags. Take a good look around the Gentoo Forums and Bugzilla to see what those flags do: nothing good!

You don't need to use those flags globally in CFLAGS or CXXFLAGS. They will only hurt performance. They may make you sound like you have a high-performance system running on the bleeding edge, but they don't do anything but bloat your code and get your bugs marked INVALID or WONTFIX.

You don't need dangerous flags like these. Don't use them. Stick to the basics: ,   , and.

What about -O levels higher than 3?
Some users boast about even better performance obtained by using ,   , and so on, but the reality is that   levels higher than 3 have no effect. The compiler may accept CFLAGS like , but it actually doesn't do anything with them. It only performs the optimizations for , nothing more.

Need more proof? Examine the  source code :

-O source code

As you can see, any value higher than 3 is treated as just.

What about redundant flags?
Oftentimes CFLAGS and CXXFLAGS that are turned on at various  levels are specified redundantly in. Sometimes this is done out of ignorance, but it is also done to avoid flag filtering or flag replacing.

Flag filtering/replacing is done in many of the ebuilds in the Portage tree. It is usually done because packages fail to compile at certain  levels, or when the source code is too sensitive for any additional flags to be used. The ebuild will either filter out some or all CFLAGS and CXXFLAGS, or it may replace  with a different level.

The Gentoo Developer Manual outlines where and how flag filtering/replacing works.

It's possible to circumvent  filtering by redundantly listing the flags for a certain level, such as  , by doing things like:

Specifying redundant CFLAGS

However,this is not a smart thing to do. CFLAGS are filtered for a reason! When flags are filtered, it means that it is unsafe to build a package with those flags. Clearly, it is not safe to compile your whole system with  if some of the flags turned on by that level will cause problems with certain packages. Therefore, you shouldn't try to "outsmart" the developers who maintain those packages. Trust the developers. Flag filtering and replacing is done for your benefit! If an ebuild specifies alternative flags, then don't try to get around it.

You will most likely continue to run into problems when you build a package with unacceptable flags. When you report your troubles on Bugzilla, the flags you use in will be readily visible and you will be told to recompile without those flags. Save yourself the trouble of recompiling by not using redundant flags in the first place! Don't just automatically assume that you know better than the developers.

What about LDFLAGS?
The Gentoo developers have already set basic, safe LDFLAGS in the base profiles, so you don't need to change them.

Can I use per-package flags?
Information on how to use per-package environment variables (including CFLAGS) is described in the Gentoo Handbook, "Per-Package Environment Variables".

Resources
The following resources are of some help in further understanding optimization:


 * The GNU gcc manual


 * Chapter 5 of the Gentoo Installation Handbooks




 * Wikipedia


 * The Gentoo Forums

Acknowledgements
We would like to thank the following authors and editors for their contributions to this guide:


 * nightmorph