GCC optimization/fr

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 et CXXFLAGS sont des variables d'environnement utilisées pour dire aux compilateurs de la collection GNU,, quels types de commutateurs utiliser lors de la compilation du code source. CFLAGS concerne le code écrit en C, tandis que CXXFLAGS concerne le code écrite en C++.

Elles peuvent être utilisées pour diminuer le nombre de messages de débogage pour un programme, augmenter le niveau d'alerte, et bien-sûr, optimiser le code produit. Le manuel de GNU gcc (en anglais) tient à jour une liste exhaustive des options disponibles et de leurs objectifs.

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. De cette manière, tous les paquets seront compilés en utilisant les options que vous y aurez définies.

CFLAGS in /etc/portage/make.conf

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

Les bases
L'objectif derrière l'utilisation des options des variables CFLAGS et CXXFLAGS est de créer un code parfaitement adapté à votre système ; il devrait fonctionner parfaitement tout en étant aussi compact et rapide que possible. Parfois, ces conditions sont incompatibles entre elles, c'est pourquoi nous nous en tiendrons à des combinaisons réputées pour bien fonctionner. Idéalement, elles sont les meilleurs disponibles pour toute architecture de processeur. Nous parlerons des options agressives plus tard, ainsi vous saurez à quoi vous en tenir. Nous ne discuterons pas chacune des options listées dans le manuel de   (elles sont des centaines), mais nous couvrirons les options les plus basiques et courantes.

-march
La première, et la plus importante, option est. 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  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 spécifie l'architecture générale utilisée,   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.

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

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

/etc/portage/make.conf: Pentium III

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

/etc/portage/make.conf: AMD64

S'il vous reste un doute quand au type de votre processeur, vous pouvez utiliser l'option. 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. Native signifie que ce code s'exécutera seulement  sur ce type de processeur. Les applications compilées avec l'option  sur un processeur AMD Athlon 64 ne pourront pas tourner sur un ancien processeur VIA C3.

Sont aussi disponibles, les options  et. Ces options sont normalement utilisées quand il n'y a pas d'option  disponible ; certaines architecture de processeur peuvent demander les options  ou même. Malheureusement, le comportement de  n'est pas très cohérent sur la manière d'interpréter une option d'une architecture à une autre.

Sur les processeurs x86 et x86-64,  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. Vous devriez seulement considérer l'utilisation de   pour le cas où vous avez besoin de générer du code pour un processeur plus ancien comme les i386 et I486. produit un code plus générique que march  ; 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   sur des systèmes x86 ou x86-64,  car cette option est maintenant déconseillée pour ces architectures.

Seuls les processeurs non x86/x-86-64 (comme Sparc, Alpha et PowerPC) peuvent nécessiter  ou   plutôt que. Sur ces architectures, /   donneront parfois des résultats identiques à ceux fournis par   (sur x86/x86-64)... mais avec un nom d'option différent. Là encore, le comportement de   et le nommage des options n'est pas cohérent à travers les différentes architectures, c'est pourquoi, vous devez consulter le des options  de    pour déterminer laquelle utiliser pour votre système.

-O
Vient ensuite l'option. 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  :  ,   ,   ,   et. Vous ne devriez en utiliser qu'un dans.

À l'exception de  ,les réglages de   activent chacun une série d'options additionnelles, c'est pourquoi vous devriez lire le chapitre sur les  options d'optimisation dans le manuel de  gcc, pour connaître les options qui sont activées par chacun des niveaux de   , et des explications sur ce qu'elles font.

Examinons les différents niveaux d'optimisation :


 * : Ce niveau (la lettre O suivi du chiffre 0 ) supprime complètement toute optimisation et est la valeur par défaut si un aucune option  n'est précisée dans  CFLAGS ou CXXFLAGS. Votre code ne sera pas optimisé, ce qui n'est pas, normalement, souhaité.


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


 * : Un échelon au-dessus de   . C'est le niveau recommandé d'optimisation  si vous n'avez de besoin  spécifique.    active quelques options de plus que   . Avec  , le compilateur va essayer d'augmenter la performance sans compromettre la taille et sans prendre trop de temps en compilation.


 * : C'est le plus haut niveau d'optimisation possible mais aussi le plus risqué. Il prendra plus de temps en compilation et, en fait, il ne devrait pas être utilisé pour tout le système avec  4.x . Le comportement de   a changé de manière significative  depuis la version 3.x. Avec  3.x,   s'est avéré ne produire qu'une amélioration de la vitesse marginale par rapport à    , mais ce n'est plus le cas avec    4.x. Compiler tous vos paquets avec   donnera'' des binaires plus volumineux qui réclament plus de mémoire, et qui augmentera de manière significative les risque de plantage de la compilation ou de comportements inattendus des programmes (y compris des erreurs). Les inconvénients contrebalance les avantages ; rappelez-vous le principe de retours en diminution. Utiliser     n'est pas recommandé avec   4.x.

Néanmoins, elle peut engendrer quelques problèmes, ce qui explique pourquoi, cette option est rejetée par beaucoup d'ebuilds dans l'arbre de Portage. Utiliser  n'est pas recommandé.
 * : Cette option optimise la taille de votre code. Elle active toutes les options activée par   qui n'augmentent pas la taille du code. Elle peut être utile pour des machines qui ont un espace disque très limité et/ou ont des processeurs avec un cache de petite taille.

Comme mentionné précédemment,  est le niveau d'optimisation recommandé. Si des erreurs de compilation se produisent, vérifiez que vous n'utilisez pas. Comme option de repli, essayez de définir un niveau d'optimisation plus faible dans CFLAGS et CXXFLAGS, comme    ou même   (pour le rapport des erreurs et la vérification de problèmes possibles) et recompilez le paquet.

-pipe
Une option commune est. Celle-ci n'a aucun effet sur le code produit, mais réduit le temps de compilation. Elle indique au compilateur d'utiliser des ''pipelines' pendant la compilation à la place de fichiers temporaires qui requièrent plus de mémoire. Sur les systèmes avec peu de mémoire, gcc peut se retrouver tué. Dans un tel cas, n'utilisez pas cette option.

-fomit-frame-pointer
C'est une option très commune conçue pour réduire la taille du code généré. Elle est activée pour tous les niveaux de l'option  (except   ) sur les architectures pour lesquelles procéder de cette manière n'interfère pas avec le débogage (comme x86-64), mais vous pouvez avoir besoin de l'activer vous-même en l'ajoutant à vos options. Bien que le manuel de GNU  ne précise pas toutes les architectures sur lesquelles cette option est activée par l'utilisation de l'option GNU , vous pourrez avoir besoin de l'activer sur x86. Néanmoins, l'utilisation de cette option rendra le débogage difficile voire 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 faire beaucoup de débogage, et n'avez pas ajouté d'autres options en rapport avec le débogage à CFLAGS comme, alors vous pouvez essayer d'utiliser.

-msse, -msse2, -msse3, -mmmx et -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