Optimisation de GCC

From Gentoo Wiki
Revision as of 11:32, 12 September 2013 by FuzzyBot (Talk | contribs)

Jump to: navigation, search
Other languages:English 100% • ‎español 100% • ‎français 100% • ‎italiano 100% • ‎日本語 2% • ‎한국어 81% • ‎русский 100% • ‎Türkçe 95%

Ce guide est une introduction à l'optimisation de code compilé en recourant à des variables CFLAGS et CXXFLAGS saines. Il présente aussi la théorie sousjacente à l'optimisation en général.

Introduction

Que sont les variables CFLAGS et CXXFLAGS ?

CFLAGS and CXXFLAGS are environment variables that are used to tell the GNU Compiler Collection, GCC , 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.

Comment sont-elles utilisées ?

Les variables CFLAGS et CXXFLAGS peuvent être utilisées de deux façons. Premièrement, elles peuvent être utilisées par programme dans des Makefiles générés par automake.

Cependant, ceci ne devrait pas être fait lors de l'installation de paquets provenant de l'arbre de Portage. Au lieu de cela, définissez vos variables CFLAGS et CXXFLAGS dans le fichier /etc/portage/make.conf. De cette manière, tous les paquets seront compilés en utilisant les options que vous y aurez définies.

CodeCFLAGS in /etc/portage/make.conf

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

Comme vous pouvez le voir, CXXFLAGS est définie pour utiliser toutes les options présentes dans CFLAGS. C'est ce que vous devriez faire sans risque la plupart du temps. Vous ne devriez jamais spécifier des options additionnelles dans CXXFLAGS.

Erreurs de conception

ALors que CFLAGS et CXXFLAGS peuvent être un moyen efficace de produire des binaires plus compacts et/ou plus rapides, elles peuvent aussi empêcher votre code de fonctionner, augmenter sa taille, ralentir son exécution et même causer des erreurs de compilation.

Les options de CFLAGS ne sont pas une baguette magique ; elles ne feront pas tourner votre système plus vite ou ne réduiront pas la taille de vos binaires automatiquement. Ajouter de plus en plus d'options dans l'espoir d'optimiser votre système est une recette garantie d'échec. Il y a un point à partir duquel les retours seront négatifs.

Malgré toute la vantardise que vous trouverez sur Internet, des options de CFLAGS et CXXFLAGS agressives créeront du tort à vos programmes plus qu'elles ne leur feront de bien. Souvenez-vous que ces options ont été conçues pour être employées à des endroits précis pour des objectifs précis. La simple raison qu'une option particulière de CFLAGS est profitable à un morceau de code, ne signifie pas qu'elle convient à n'importe quelle programme que vous installerez sur votre machine !

Prêt ?

Maintenant que vous avez pris conscience des risques potentiels, jetons un coup d'œil à quelques optimisations saines et sûres pour votre ordinateur. Elles vous maintiendront en bons termes avec les développeurs la prochaine fois que vous rapporterez un problème sur Bugzilla. (Les développeurs vous demanderont généralement de recompiler un paquet avec des options de la variable CFLAGS minimales, pour voir si le problème subsiste. Souvenez-vous que des options agressives peuvent causer du tort à votre code.)

Optimiser

Les bases

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 GCC manual (there are hundreds), but we'll cover the basic, most common flags.

Note
Whenever you're not sure what a flag actually does, refer to the relevant chapter of the GCC manual . If you're still stumped, try Google, or check out the GCC mailing lists .

-march

La première, et la plus importante, option est -march. Elle dit au compilateur quel code il devrait produire pour votre architecture de processeur (ou arch) ; elle dit qu'il devrait produire du code pour un certain type de processeur. Des processeurs différents ont des aptitudes différentes, prennent en charge différents jeux d'instructions et ont des manières différentes d'exécuter le code. L'option -march renseigne le compilateur pour qu'il produise le code spécifique à votre processeur, en tenant compte de toutes les aptitudes, fonctionnalités, jeux d'instructions, comportements, etc. de ce processeur.

Même si la variable CHOST dans le fichier /etc/portage/make.conf spécifie l'architecture générale utilisée, -march devrait quand même être utilisée pour que les programmes soient optimisés pour votre processeur spécifique. Les processeur x86 et x86-64 (parmi d'autres) devrait utiliser l'option -march.

De quel type de processeur disposez-vous ? Pour le trouver, exécutez la commande suivante :

user $ cat /proc/cpuinfo

Maintenant, regardons l'option -march en action. Ceci est un exemple pour un ancien Pentium III :

Code/etc/portage/make.conf: Pentium III

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

En voici un autre pour un processeur AMD 64-bit :

Code/etc/portage/make.conf: AMD64

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

S'il vous reste un doute quand au type de votre processeur, vous pouvez utiliser l'option -march=native. Lorsque cette option est utilisée, GCC détecte automatiquement votre processeur et positionne lui-même les options appropriées pour ce processeur. Néanmoins, celle-ci ne devrait pas être utilisée si votre intention est de compiler des paquets pour un autre processeur !

Si vous compilez des paquets sur un ordinateur, mais avez l'intention les exécuter sur un autre (comme c'est parfois le cas lorsqu'on compile sur un ordinateur récent et rapide pour un ordinateur plus ancien et plus lent), alors n'utilisez pas l'option -march=native. Native signifie que ce code s'exécutera seulement sur ce type de processeur. Les applications compilées avec l'option -march=native sur un processeur AMD Athlon 64 ne pourront pas tourner sur un ancien processeur VIA C3.

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

Sur les processeurs x86 et x86-64, -march produira un code spécifique pour ce type de processeur en utilisant tout le jeu d'instructions disponibles et l'ABI (Application Binary Interface) correcte ; il n'y aura pas de rétrocompatibilité pour des processeurs plus anciens ou différents. Si vous n'avez pas besoin d'exécuter le code sur autre chose que le système sur lequel vous faites tourner Gentoo, continuez à utiliser -march. Vous devriez seulement considérer l'utilisation de -mtune pour le cas où vous avez besoin de générer du code pour un processeur plus ancien comme les i386 et I486. -mtune produit un code plus générique que march</code> ; bien qu'il adapte le code pour un certain processeur, il ne prend pas en compte l'ensemble du jeu d'instructions et de l'ABI. N'utilisez pas -mcpu sur des systèmes x86 ou x86-64, car cette option est maintenant déconseillée pour ces architectures.

Only non-x86/x86-64 CPUs (such as Sparc, Alpha, and PowerPC) may require -mtune or -mcpu instead of -march. On these architectures, -mtune / -mcpu will sometimes behave just like -march (on x86/x86-64)... but with a different flag name. Again, GCC's behavior and flag naming just isn't consistent across architectures, so be sure to check the GCC manual to determine which one you should use for your system.

Note
For more suggested -march / -mtune / -mcpu settings, please read chapter 5 of the appropriate Gentoo Installation Handbook for your 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

Vient ensuite l'option -O. Elle contrôle le niveau global d'optimisation. Ceci rend le temps de compilation quelque peu plus long, et peut nécessiter plus de mémoire, en particulier si vous augmentez le niveau d'optimisation.

Il y a 5 réglages de -O : -O0 , -O1 , -O2 , -O3 et -Os. Vous ne devriez en utiliser qu'un dans /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.

Examinons les différents niveaux d'optimisation :

  • -O0 : This level (that's 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 : C'est le niveau d'optimisation le plus basique. Le compilateur va essayer de produire un code plus rapide et plus compact sans prendre trop de temps de compilation. C'est très basique mais ça fait toujours le travail.
  • -O2 : Un échelon au-dessus de -O1 . C'est le niveau recommandé d'optimisation si vous n'avez de besoin spécifique. -O2 active quelques options de plus que -O1 . Avec -O2 , le compilateur va essayer d'augmenter la performance sans compromettre la taille et sans prendre trop de temps en compilation.
  • -O3 : This is 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. Therefore, using -O3 is not recommended.
  • -Os : This option will optimize your code for size. It activates all -O2 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, -O2 is the recommended optimization level. If package compilation fails and you aren't using -O2, try rebuilding with that option. As a fallback option, try setting your 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 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 -O (except -O0) 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 GCC manual does not specify all architectures it is turned on by using -O, you will need to explicitly activate it on x86. However, using this flag will make debugging hard to impossible.

En particulier, cela rend le dépannage des applications écrites en Java beaucoup plus difficile, même si Java n'est pas le seul code affecté par l'utilisation de cette option. C'est pourquoi même si l'option apporte des bénéfices, elle rend le débogage plus difficile ; les backtraces en particulier seront inutiles. Cependant, si vous n'envisagez pas de faire beaucoup de débogage, et n'avez pas ajouté d'autres options en rapport avec le débogage à CFLAGS comme -ggdb, alors vous pouvez essayer d'utiliser -fomit-frame-pointer.

Important
Ne combinez pas -fomit-frame-pointer avec l'option similaire -momit-leaf-frame-pointer . Utiliser cette dernière option est déconseillé car -fomit-frame-pointer fait déjà le travail proprement. De plus, -momit-leaf-frame-pointer a démontré un impact négatif sur la performance du code.

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

Ces options activent les jeux d'instructions SSE , SSE2 , SSE3 , MMX et 3DNow! pour les architectures x86 and x86-64. Ils sont utiles avant tout dans le multimedia, les jeux et autres applications utilisant les calculs en virgule flottante de manière intensive, bien qu'ils incluent aussi plusieurs autres améliorations mathématiques. Ces jeux d'instructions se rencontrent dans les processeurs les plus modernes.

Important
Vérifiez que votre processeur les prend en charge en exécutant la commande cat /proc/cpuinfo . La sortie présentera tous les jeux d'instructions additionnels pris en charge. Notez que pni n'est qu'un nom différent pour SSE3.

Vous n'avez normalement pas besoin d'ajouter ces options à /etc/portage/make.conf tant que vous utilisez l'option -march (par exemple, -march=nocona implique -msse3 ). Quelques exceptions notables sont les processeurs plus récents VIA et AMD64 qui prennent en charge des instructions qui ne découlent pas de l'utilisation de -march (telles que SSE3). Pour de tels processeurs, vous devrez activer des options additionnelles là ou c'est approprié après avoir vérifié la sortie de cat /proc/cpuinfo .

Note
You should 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 you don't need to specify it; it will be turned on by using the proper -march setting.

FAQs sur l'optimisation

Mais j'obtiens de meilleures performance avec -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 GCC manual says that using -funroll-loops and -funroll-all-loops makes 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.

La vérité sur ce sujet, c'est qu'il y a des options dangereusement agressives. Jetez donc un coup d'œil aux forums Gentoo et à Bugzilla pour savoir ce que ces options font réellement : rien de bon !

Vous n'avez pas besoin d'utiliser ces options globalement dans CFLAGS ou CXXFLAGS. Cela ne fera que dégrader la performance. Elles peuvent vous faire penser que vous avez une haute performance en fonctionnant à la limite, mais elles ne font que faire grossir votre code et vous apporter des bogues marquées INVALID ou WONTFIX.

Vous n'avez pas besoin de telles options dangereuses. Ne les utilisez pas !. Contentez-vous de vous en tenir aux basiques : -march , -O et -pipe.

Que dire des niveaux -O supérieurs à 3 ?

Quelques utilisateurs se vantent même d'obtenir une meilleure performance en utilisant -O4 , -O9 et plus, mais en réalité, une option -O d'un niveau supérieur à 3 n'a aucun effet. Le compilateur peut accepter des options telles que -O4 pour CFLAGS, mais il n'en fait rien. Il ne cherche à optimiser que jusqu'à -O3, rien de plus.

Need more proof? Examine the code source code:

Code-O source code

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);
    }

Comme vous pouvez le constater, aucune valeur supérieure à -O3 n'est prise en compte.

Que dire des options redondantes ?

Très souvent des options CFLAGS et CXXFLAGS qui sont activées par des niveaux de -O sont spécifiées de manière redondante dans /etc/portage/make.conf. Quelques fois cela est fait par ignorance, mais c'est aussi fait pour éviter le filtrage d'options ou le remplacement d'options.

Le filtrage/remplacement d'options est fait dans de nombreux ebuilds de l'arbre de Portage. C'est généralement fait parce que la compilation de certains paquets échoue à certains niveaux de -O, ou quand le code source est trop sensible pour que des options supplémentaires soient ajoutées. L'ebuild soit filtrera quelques options de CFLAGS et CXXFLAGS, soit remplacera le niveau de -O par un autre.

Le Manuel du développeur de Gentoo indique quand et comment le filtrage/remplacement d'options fonctionne.

Il est possible de contrecarrer le filtrage de -O en listant de manière redondante les options d'un certain niveau, (tel que -O3) en faisant ceci :

CodeSpecifying redundant CFLAGS

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

Néanmoins, ce n'est pas très élégant de le faire. Les options de CFLAGS sont filtrées pour une raison ! Quand des options sont filtrées, cela signifie que ce n'est pas sûr de compiler un paquet avec de telles options. Clairement, ce n'est pas sûr de compiler tout votre système avec l'option -O3 si quelques unes des options activées par ce niveau sont susceptibles de provoquer des problèmes à certains paquets. En conséquence, vous ne devriez pas essayer d'être plus intelligent que les développeurs qui maintiennent ces paquets. Faites confiance aux développeurs ! . Le filtrage et le remplacement d'options est fait pour votre intérêt ! Si un ebuild spécifie des options alternatives, n'essayez pas de l'éviter.

Vous continuerez probablement à rencontrer des problèmes si vous compilez un paquet avec des options inacceptables. Quand vous rapportez vos problèmes sur Bugzilla, les options que vous utilisez dans /etc/portage/make.conf seront pleinement visibles et on vous demandera de recompiler le paquet sans ces options. Évitez d'avoir à recompiler en n'utilisant pas ces options redondantes dès l'origine ! Ne supposez pas de manière automatique que vous en savez plus que les développeurs.

Que dire de LDFLAGS ?

Les développeurs de Gentoo ont déjà défini des options de base sûres de la variable LDFLAGS dans les profils de base. Vous n'avez donc pas besoin de les changer.

Puis-je utiliser des options par paquet ?

Attention !
L'utilisation d'options par paquet complique le débogage et l'assistance. Pensez à signaler dans vos rapport de bogues si vous utilisez cette fonctionnalité et quels changements vous avez faits.

Une information sur comment utiliser les variables d'environnement par paquet (y compris CFLAGS) est fournie dans le manuel de Gentoo , "Variables d'environnement par paquet" .

Ressources

Les ressources suivantes vous seront utiles pour aller plus loin dans la compréhension de l'optimisation :

  • man make.conf

Remerciements

Nous tenons à remercier les auteurs, éditeurs et traducteurs suivants pour leur contribution à ce guide :

  • nightmorph
  • jaaf