Otimização do GCC

From Gentoo Wiki
Jump to: navigation, search
This page is a translated version of the page GCC optimization and the translation is 26% complete.

Outdated translations are marked like this.
Other languages:
English • ‎Türkçe • ‎español • ‎français • ‎italiano • ‎português do Brasil • ‎русский • ‎中文(中国大陆)‎ • ‎日本語 • ‎한국어

Este guia fornece uma introdução à otimização de códigos usando CFLAGS e CXXFLAGS seguras e sensatas. Também descreve a teoria por trás da otimização em geral.

Introdução

O que são CFLAGS e CXXFLAGS?

CFLAGS e CXXFLAGS estão entre as variáveis de ambiente convencionalmente usadas para especificar opções do compilador para um sistema de compilação ao compilar códigos C e C++. Enquanto estas variáveis não são padronizadas, o seu uso é essencialmente onipresente e qualquer construção escrita corretamente deve compreender estas para passar opções extras ou opções personalizadas quando se invoca o compilador. Veja a página de informação do GNU make para uma lista de algumas das variáveis comumente usadas nesta categoria.

Como uma grande proporção dos pacotes que compõem o sistema do Gentoo são escritos em C e C++, estas são duas variáveis que certamente os administradores irão querer definir corretamente como elas vão influenciar significativamente a forma como grande parte do sistema é construída.

Elas podem ser usadas para diminuir a quantidade de mensagens de debug para um programa, aumentar os níveis de alertas de erro e, é claro, otimizar o código produzido. O Manual do GCC mantém uma lista completa das opções disponíveis e seus propósitos.

Como elas são usadas?

Normalmente, CFLAGS e CXXFLAGS seria definida no ambiente ao chamar um script de configuração ou com makefiles gerados pelo programa automake. Em sistemas baseados no Gentoo, defina as variáveis CFLAGS e CXXFLAGS no /etc/portage/make.conf. As variáveis definidas neste arquivo serão exportadas para o ambiente de programas chamados pelo Portage de tal forma que todos os pacotes serão compilados usando estas opções como base.

CODE Definindo CFLAGS no /etc/portage/make.conf
CFLAGS="-march=athlon64 -O2 -pipe"
CXXFLAGS="${CFLAGS}"
Important
Ainda que seja possível ter múltiplas linhas nas flags USE, tendo várias linhas na CFLAGS pode e "irá" resultar em problemas com programas como cmake. Certifique-se que as declarações da CFLAGS estejam em uma única linha, com o mínimo de espaço possível entre elas para evitar problemas. Veja bug #500034 como um exemplo.

Como vimos no exemplo anterior, a variável CXXFLAGS é definida para usar todas as opções presentes na CFLAGS. A maioria dos sistemas devem ser configurados desta maneira. Opções adicionais para as CXXFLAGS são menos comuns e usualmente não são aplicáveis de forma geral o suficiente para merecer colocá-los globalmente.

Tip
Safe CFLAGS article might help beginners start optimizing their systems.

Equívocos

Enquanto CFLAGS e CXXFLAGS podem ser muito eficazes de obter o código fonte e produzer binários menores e/ou rápidos, elas podem também prejudicar o funcionamento do código, inchar seu tamanho, desacelerar o tempo de execução. Definindo-as incorretamente pode até mesmo causar falhas na compilação!

Remember, the global CFLAGS configured in /etc/portage/make.conf will be applied to every package on the system so administrators typically only set general, widely-applicable options. Individual packages further modify these options either in the ebuild or the build system itself to generate the final set of flags used when invoking the compiler.

Pronto?

Estando ciente dos riscos envolvidos, dê uma olhada em algumas otimizações seguras e sensatas. Estas serão mantidas em um bom lugar e serão agradáveis para os desenvolvedores da próxima vez que um problema for relatado no Bugzilla. (Os desenvolvedores irão, normalmente, solicitar aos usuários para recompilar um pacote com o mínimo de CFLAGS para ver se o problema persiste. Lembre-se: flags agressivas podem arruinar o código!)

Otimizando

O básico

O objetivo por trás da CFLAGS e CXXFLAGS é a criação de código feito sob medida para o seu sistema; deve funcionar perfeitamente ao ser enxuto e rápido, se possível. Às vezes estas condições são mutuamente exclusivas, assim este guia irá manter combinações conhecidas por funcionarem bem. Idealmente, elas são as melhores disponíveis para qualquer arquitetura de CPU. Para fins informativos, flags agressivas serão cobertas posteriormente. Nem toda opção listada no manual do GCC (há centenas) serão discutidas, mas basicamente, a maioria das flags serão revistas.

Note
Quando desconhecer o que uma flag faz refira-se ao capítulo do manual do GCC se ainda desconhecer após ver o manual, tente um mecanismo de busca ou verifique a lista de discussão do GCC.

-march

A primeira e mais importante opção é -march. Isto informa ao compilador que código deve produzir para a arquitetura do processador (ou "arch"); ele informa ao GCC que deverá produzir código para um determinado tipo de CPU. Diferentes CPUs tem diferentes capacidades, suporta diferentes conjuntos de instruções e tem maneiras diferentes de execução de código. A flag -march irá instruir o compilador para produzir um código específico para a CPU do sistema, com todas as suas capacidades, recursos, conjunto de instruções, particularidades e assim por diante.

-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[1].

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

Mesmo que a variável CHOST no /etc/portage/make.conf especifique a arquitetura geral usada, -march ainda deve ser usado de modo que os programas possam ser otimizados para o processador específico do sistema. CPUs x86 e x86-64 (entre outras) devem utilizar a flag -march.

Que tipo de CPU o sistema tem? Para encontrar, execute o seguinte comando:

user $cat /proc/cpuinfo

or even install app-portage/cpuid2cpuflags and add the available CPU-specific options to the /etc/portage/package.use/00cpuflags 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 "*/* $(cpuid2cpuflags)" >> /etc/portage/package.use/00cpuflags

Para obter maiores detalhes, incluindo os valores march e mtune, dois comandos podem ser usados.

  • O primeiro comando informa ao compilador não fazer nenhuma ligação (-c) e, ao invés de interpretar a opção --help para esclarecer as opções da linha de comando, ele agora irá mostrar se certas opções estão habilitadas ou desabilitadas (-Q). Neste caso, as opções mostradas são aquelas habilitadas para o alvo selecionado:
user $gcc -c -Q -march=native --help=target
  • O segundo comando irá mostrar as diretivas do compilador para construir o arquivo cabeçalho, mas sem realmente executar os passos e ao invés disto mostrá-los na tela (-###). A saída final é o comando que contém todas as opções de otimização e seleção de arquitetura:
user $gcc -### -march=native /usr/include/stdlib.h

Agora vamos ver -march em ação. Este exemplo é para um antigo chip Pentium III:

FILE /etc/portage/make.confPentium III exemplo
CFLAGS="-march=pentium3"
CXXFLAGS="${CFLAGS}"

Aqui está outro para uma CPU AMD 64-bit:

FILE /etc/portage/make.confAMD64 exemplo
CFLAGS="-march=athlon64"
CXXFLAGS="${CFLAGS}"

Se o tipo da CPU é indeterminado, ou se o usuário não sabe qual configuração escolher, é possível usar a configuração -march=native. Quando esta flag é usada, o GCC tentará detectar o processador e automaticamente definir as flags apropriadas para ele. Entretanto, isto não deve ser usado quando se pretende compilar pacotes para diferentes CPUs!

Warning
Não use -march=native ou -mtune=native nas variáveis CFLAGS ou CXXFLAGS do make.conf quando compilar com distcc.

Se compilar pacotes em um computador a fim de executá-los em um computador diferente (tal como quando se utiliza um computador rápido para construir para uma máquina antiga, lenta), então "não" use -march=native. "Native" significa que o código produzido executará "apenas" naquele tipo de CPU. As aplicações construídas com -march=native em um AMD Athlon 64 CPU não serão capazes de executar em uma antiga CPU VIA C3.

Também estão disponíveis as flags -mtune e -mcpu. Estas flags são normalmente usadas apenas quando não há a opção -march disponível; certas arquiteturas de processadores podem exigir -mtune ou até mesmo -mcpu. Infelizmente o comportamento do GCC não é muito consistente com a forma como cada flag se comporta de uma arquitetura para outra.

Em CPUs x86 e x86-64, -march irá gerar um código especificamente para esta CPU usando seu conjunto de instruções disponíveis e a correta ABI; ele não terá compatibilidade com versões anteriores para antigas/diferentes CPUs. Considere usar -mtune quando gerar códigos para antigas CPUs tais como i386 e i486. -mtune produz um código mais genérico do que -march; mas isto vai ajustar o código para uma determinada CPU, ele não leva em conta os conjuntos de instruções disponíveis e ABI. Não use -mcpu em sistemas x86 e x86-64, de forma que ele é obsoleto para estas arquiteturas.

Apenas em CPUs não x86/x86-64 (como Sparc, Alpha e PowerPC) pode exigir -mtune ou -mcpu ao invés de -march. Nestas arquiteturas, -mtune / -mcpu às vezes se comportam como -march (em x86/x86-64), com um nome de flag diferente. Mais uma vez, o comportamento do GCC e nomeação de flag não é consistente em todas as arquiteturas, por isso não deixe de verificar o manual do GCC para determinar qual deve ser usado.

Note
For more suggested -march / -mtune / -mcpu settings, please read chapter 5 of the appropriate Gentoo Installation Handbook for the arch. Also, read the GCC manual's list of architecture-specific options, as well as more detailed explanations about the differences between -march, -mcpu, and -mtune.

-O

Warning
Using -O3 or -Ofast may cause some packages to break during the compilation.
Note
To print all packages that were built with specified CFLAGS/CXXFLAGS it's possible to use the following command: grep Ofast /var/db/pkg/*/*/CFLAGS

Next up is the -O variable. This variable controls the overall level of optimization. Changing this value will make the code compilation take more time and will use much more memory, especially as the level of optimization is increased.

There are seven -O settings: -O0, -O1, -O2, -O3, -Os, -Og, and -Ofast. Only use one of them in /etc/portage/make.conf.

With the exception of -O0, the -O 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 -O level, as well as some explanations as to what they do.

Let us examine each optimization level:

  • -O0: This level (that is the letter "O" followed by a zero) turns off optimization entirely and is the default if no -O 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.
  • -O1: the most basic optimization level. The compiler will try to produce faster, smaller code without taking much compilation time. It is basic, but it should get the job done all the time.
  • -O2: A step up from -O1. The recommended level of optimization unless the system has special needs. -O2 will activate a few more flags in addition to the ones activated by -O1. With -O2, 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 -ftree-vectorize is also enabled.
  • -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: optimizes code for size. It activates all -O2 options that do not increase the size of the generated code. It can be useful for machines that have extremely limited disk storage space and/or CPUs with small cache sizes.
  • -Og: In GCC 4.8, a new general optimization level, -Og, has been introduced. It addresses the need for fast compilation and a superior debugging experience while providing a reasonable level of runtime performance. Overall experience for development should be better than the default optimization level -O0. Note that -Og does not imply -g, it simply disables optimizations that may interfere with debugging.
  • -Ofast: New in GCC 4.7, consists of -O3 plus -ffast-math, -fno-protect-parens, and -fstack-arrays. This option breaks strict standards compliance, and is not recommended for use.

As previously mentioned, -O2 is the recommended optimization level. If package compilation fails and while not using -O2, try rebuilding with that option. As a fallback option, try setting the CFLAGS and CXXFLAGS to a lower optimization level, such as -O1 or even -O0 -g2 -ggdb (for error reporting and checking for possible problems).

-pipe

A common flag is -pipe. This flag 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 those cases 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 -O (except -O0) on architectures where doing so does not interfere with debugging (such as x86-64), but it may need to be activated. In that case add it to the flags. Though the GCC manual does not specify all architectures, it is turned on by using the -O option. It's still necessary to explicitly enable the -fomit-frame-pointer option, to activate it on x86-32 with GCC up to version 4.6, or when using -Os on x86-32 with any version of GCC. However, using -fomit-frame-pointer will make debugging hard or impossible.

In particular, it makes troubleshooting applications written in Java and compiled by gcj 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. When not doing software debugging and no other debugging-related CFLAGS such as -ggdb have been used, then try using -fomit-frame-pointer.

Important
Do not combine -fomit-frame-pointer with the similar flag -momit-leaf-frame-pointer. Using the latter flag is discouraged, as -fomit-frame-pointer already does the job properly. Furthermore, -momit-leaf-frame-pointer has been shown to negatively impact code performance.

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

These flags enable the Streaming SIMD Extensions (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.

Important
Be sure to see if the CPU supports these instruction sets by running cat /proc/cpuinfo. The output will include any supported additional instruction sets. Note that pni is just a different name for SSE3.

Normally none of these flags need to be added to /etc/portage/make.conf, as long as the system is using the correct -march (for example, -march=nocona implies -msse3). Some notable exceptions are newer VIA and AMD64 CPUs that support instructions not implied by -march (such as SSE3). For CPUs like these additional flags will need to be enabled where appropriate after checking /proc/cpuinfo.

Note
Check the list of x86 and x86-64-specific flags to see which of these instruction sets are activated by the proper CPU type flag. If an instruction is listed, then it does not need to be separately specified; it will be turned on by using the proper -march setting.

Optimization FAQs

But I get better performance with -funroll-loops -fomg-optimize!

No, people only think they do because someone has convinced them that more flags are better. Aggressive flags will only hurt applications when used system-wide. Even the GCC manual says that using -funroll-loops and -funroll-all-loops will make code larger and run more slowly. Yet for some reason, these two flags, along with -ffast-math, -fforce-mem, -fforce-addr, 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!

These flags are not needed globally in CFLAGS or CXXFLAGS. They will only hurt performance. They might bring on the idea of having a high-performance system running on the bleeding edge, but they don't do anything but bloat the code and get bugs marked INVALID or WONTFIX.

Dangerous flags like these are not needed. Don't use them. Stick to the basics: -march, -O, and -pipe.

What about -O levels higher than 3?

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

Need more proof? Examine the source code:

CODE -O source code
case OPT_LEVELS_3_PLUS:
      enabled = (level >= 3);
      break;
 
 case OPT_LEVELS_3_PLUS_AND_SIZE:
      enabled = (level >= 3 || size);
      break;

As can be seen, any value higher than 3 is treated as just -O3.

What about compiling outside the target machine?

Some readers might wonder if compiling outside the target machine with a strictly inferior CPU or GCC sub-architecture will result in inferior optimization results (compared to a native compilation). The answer is simple: No. Regardless of the actual hardware on which the compilation takes place and the CHOST for which GCC was built, as long as the same arguments are used (except for -march=native) and the same version of GCC is used (although minor version might be different), the resulting optimizations are strictly the same.

To exemplify, if Gentoo is installed on a machine whose GCC's CHOST is i686-pc-linux-gnu, and a Distcc server is setup on another computer whose GCC's CHOST is i486-linux-gnu, then there is no need to be afraid that the results would be less optimal because of the strictly inferior sub-architecture of the remote compiler and/or hardware. The result would be as optimized as a native build, as long as the same options are passed to both compilers (and the -march parameter doesn't get a native argument). In this particular case the target architecture needs to be specified explicitly as explained in Distcc and -march=native.

The only difference in behavior between two GCC versions built targeting different sub-architectures is the implicit default argument for the -march parameter, which is derived from the GCC's CHOST when not explicitly provided in the command line.

What about redundant flags?

Oftentimes CFLAGS and CXXFLAGS that are turned on at various -O levels are specified redundantly in /etc/portage/make.conf. 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 -O 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 -O with a different level.

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

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

CODE Specifying redundant CFLAGS
CFLAGS="-O3 -finline-functions -funswitch-loops"

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 the whole system with -O3 if some of the flags turned on by that level will cause problems with certain packages. Therefore, don't try to "outsmart" the developers who maintain those packages. Trust the developers. Flag filtering and replacing is done to ensure stability of the system and application! If an ebuild specifies alternative flags, then don't try to get around it.

Building packages with unacceptable flags will most likely lead to problems. When reporting problems on Bugzilla, the flags that are used in /etc/portage/make.conf will be readily visible and developers will ask to recompile without those flags. Save the trouble of recompiling by not using redundant flags in the first place! Don't just automatically assume to be more knowledgeable than the developers.

What about LDFLAGS?

The Gentoo developers have already set basic, safe LDFLAGS in the base profiles, so they do not need to be changed.

Can I use per-package flags?

Warning
Using per-package flags complicates debugging and support. Make sure to mention the use of this feature in the bug reports together with the changes made.

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

See also

External resources

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

  • man make.conf

References

  1. GNU GCC Bugzilla, AVX/AVX2 no ymm registers used in a trivial reduction. Retrieved on 2017/07/18.

This page is based on a document formerly found on our main website gentoo.org.