II. Les options génériques
La différence entre -mcpu (-mtune avec gcc 3.4) et -march
Voilà la question qui hante bon nombre de gentooistes. La réponse est très simple:
-
-mcpu: produit un binaire optimisé pour le processeur indiqué, mais qui reste
compatible avec l'architecture de celui-ci. Le mot architecture est ici employé au
sens x86, donc un programme compilé avec l'option "-mcpu=athlon-xp" tournera sur
un 386 (à tester). Les optimisations sont donc limitées à une meilleure
exploitation de la mémoire cache et autre subtilités. A partir de gcc 3.4 ce nom
devient obsolète et est remplacé par -mtune
-
-march: produit un binaire optimisé pour le processeur indiqué, mais qui ne
fonctionnera pas sur les machines de génération précédente. Voyez le dessin 1 pour
savoir quels sont les processeurs susceptibles de faire tourner du code optimisé
pour un autre
La virgule flottante et -mfpmath
Le co-processeur mathématique est spécialisé dans les calculs sur les nombres réels (et
disposant de fonctions mathématiques comme les fonctions trigonométriques par exemple),
c'est l'unité de calcul en virgule flottante (Floating Point Unit).
Les premiers modèles (du 8087 au 80387) étaient physiquement séparés du processeur,
jusqu'à ce qu'Intel l'intègre dans le 80486DX (certains 80486SX l'ont aussi mais il est
désactivé), puis finalement sur tous les Pentium. Cela correspond à l'époque à laquelle
les jeux en 3D ont vraiment commencé à se développer sur PC.
Le Pentium MMX fut une véritable évolution, son efficacité était vraiment visible: Un
Pentium 166 était utilisé à environ 20% pour lire un mp3, alors qu'un 166 MMX n'était plus
utilisé qu'à 3% (avec x11amp si je me rappelle bien).
La technologie MMX étend le co-processeur mathématique en augmentant le nombre des
registres et en y rajoutant des instructions. Sous certaines conditions, les instructions
sont exécutables sur plusieurs registres simultanément, c'est une technique appelée SIMD
(Single Instruction, Multiple Data).
S'étant jusque-là cantonné à la production de clones des processeurs Intel, AMD créa le
jeu d'instructions 3DNow! en collaboration (me semble-t-il) avec Cyrix et d'autres
compagnies qui tentaient de percer sur le marché du x86. On retiendra surtout les K6-II et
K6-III qui furent les premiers processeurs à en bénéficier.
Intel améliora ensuite ses processeurs avec le SSE (Pentium III), puis le SSE2 (Pentium 4)
tandis qu'AMD proposa le 3DNow2! avec les Athlons. A ce jour, le nouveau Pentium 4 (nom de
code Prescott) est supposé débarquer avec un SSE3 histoire d'en rajouter une couche. Il
est important de noter que l'unité de calcul du SSE est indépendante de l'unité x87/MMX,
on peut donc se servir des deux en même temps!
-fpmath
Cette option peut recevoir plusieurs valeurs:
-
387 : C'est l'option utilisée par défaut sur la plateforme x86 pour les
processeurs 32 bits, il est donc inutile de la spécifier. En cas d'absence
d'un co-processeur mathématique sur la machine, il est émulé
logiciellement
-
sse : Permet d'utiliser la technologie SSE (oui je manque d'inspiration
là), pour que cette option soit prise en compte il faut aussi
activer le support de sse avec une des options suivantes: -march, -msse,
-msse2. Comme la précision des calculs est augmentée, cela peut nuire à
quelques programmes, en effet il y a des normes précises sur les calculs
en virgule flottante, comme par exemple l'IEEE 754
-
pni: Active le support du SSE3 du Prescott (le nouveau Pentium 4
paraît-il), ce n'est pas bien expliqué dans le manuel de gcc mais je
suppose qu'il faut utiliser l'option conjointement à -msse2 pour qu'elle
soit effective
-
sse,387: Essaie d'exploiter les deux unités de calcul x87/MMX et SSE,
puisque celles-ci sont séparées. Le gain de performances doit être très
appréciable, mais le manuel avertit que l'option est encore expérimentale
(mais est-il à jour?)
Compléments sur march
L'utilisation de cette option va entraîner l'emploi par le compilateur d'instructions et/ou
registres supplémentaires par rapport à un i386. De plus, cela va activer les différentes
instructions multimédia et unités de calcul, les MMX et autres SSE.
Important: Les options de compilation -mcpu (même valeur que march), -mmmx, -m3dnow, -msse, -msse2
sont implicites lorsqu'on utilise march, donc ce n'est pas la peine de les rajouter.
Redondance des options et filtrage des ebuilds
Comme vous ne le savez peut-être pas, certains ebuilds filtrent les options passées à gcc pour
des raisons de stabilité. Pour ceux qui veulent conserver quelques optimisations, une solution
pour contourner ce filtrage est de spécifier les deux options -march et -mcpu, puisque normalement
seul -march sera filtré. On peut aussi rajouter les options -mmmx et -msse par exemple, mais là
il est plus difficile de savoir si la stabilité du binaire est mise en péril ou non. C'est à
chacun de faire son choix, prudence ou audace (enfin relativisons, ce n'est que d'un programme
qu'il s'agit).
Il fait bande à part: -pipe
L'option -pipe n'est pas à proprement parler une option d'optimisation, parce qu'elle n'influe
absolument pas sur le code généré, mais je trouve quand même important de la citer. Cette option
va indiquer à gcc que les fichiers temporaires doivent être créés en mémoire plutôt que sur le
disque dur. Cela permet de réduire le temps de compilation en réduisant le nombre d'accès disques.
Mais en conséquence, la consommation de mémoire de gcc devient plus importante, attention car si
la mémoire vient à manquer, la compilation échouera, mais pas forcément avec un message d'erreur
explicite.
Les optimisations indépendantes de la machine
Je ne vais pas me donner la peine de faire ne serait-ce qu'un copier/coller de la page du manuel
de gcc, je vous laisse le soin de regarder la liste. Ces options sont "résumées" par une autre
plus générale: -O (grand o)
-
-On : avec n compris entre 1 et 3, plus le chiffre est grand, plus les options
activées sont nombreuses. Certains de ces optimisations peuvent changer
subtilement le comportement d'un programme (involontairement), il est donc
déconseillé de trop optimiser les applications système, ainsi que les grosses du
genre openoffice.
-
-Os : là, on optimise la taille des binaires créés, gcc créera les plus petits
possibles
Sans rentrer dans les détails de la programmation (et encore moins de l'assembleur), l'informatique
est soumise à une loi omniprésente et très contrariante: L'optimisation de la vitesse se fait au
détriment de la taille, et l'optimisation de la taille au détriment de la vitesse. Prenons un
exemple simple, celui du déroulage de boucles (funroll-loops): le fait de dérouler une boucle de
n itérations accélère son exécution parce qu'on supprime n tests et n-1 sauts conditionnels dans
le code. Mais le fait d'écrire le code n fois à la suite va augmenter la taille du programme.
Attention: ce genre de manipulations peut avoir des effets contraires à celui attendu: plus un
programme est gros, et plus il va tenir de place en mémoire, donc plus le processeur va devoir
effectuer des accès en mémoire vive (dont les temps d'accès sont lents par rapport à la mémoire
cache), et plus on a des risques de voir le processeur se mettre en attente avant que les
nouvelles données lui parviennent.
Valid XHTML 1.0!
Valid CSS!
Bon j'avoue que c'était pas dur...
Copyright (c) 2005 Leander256.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
Texts. The license is available at this URL: http://www.gnu.org/licenses/fdl.html.