| 1 |
titefleur 08/03/04 13:18:37 |
| 2 |
|
| 3 |
Modified: metadoc.xml |
| 4 |
Added: gcc-optimization.xml |
| 5 |
Log: |
| 6 |
new french translation : gcc-optimization |
| 7 |
|
| 8 |
Revision Changes Path |
| 9 |
1.137 xml/htdocs/doc/fr/metadoc.xml |
| 10 |
|
| 11 |
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/fr/metadoc.xml?rev=1.137&view=markup |
| 12 |
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/fr/metadoc.xml?rev=1.137&content-type=text/plain |
| 13 |
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/fr/metadoc.xml?r1=1.136&r2=1.137 |
| 14 |
|
| 15 |
Index: metadoc.xml |
| 16 |
=================================================================== |
| 17 |
RCS file: /var/cvsroot/gentoo/xml/htdocs/doc/fr/metadoc.xml,v |
| 18 |
retrieving revision 1.136 |
| 19 |
retrieving revision 1.137 |
| 20 |
diff -u -r1.136 -r1.137 |
| 21 |
--- metadoc.xml 3 Mar 2008 13:14:47 -0000 1.136 |
| 22 |
+++ metadoc.xml 4 Mar 2008 13:18:37 -0000 1.137 |
| 23 |
@@ -1,5 +1,5 @@ |
| 24 |
<?xml version="1.0" encoding="UTF-8"?> |
| 25 |
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/fr/metadoc.xml,v 1.136 2008/03/03 13:14:47 cam Exp $ --> |
| 26 |
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/fr/metadoc.xml,v 1.137 2008/03/04 13:18:37 titefleur Exp $ --> |
| 27 |
<!DOCTYPE metadoc SYSTEM "/dtd/metadoc.dtd"> |
| 28 |
|
| 29 |
<metadoc lang="fr" parent="/doc/en/metadoc.xml"> |
| 30 |
@@ -440,7 +440,7 @@ |
| 31 |
<file id="zsh">/doc/fr/zsh.xml</file> |
| 32 |
<file id="change-chost">/doc/fr/change-chost.xml</file> |
| 33 |
<file id="xfce-config">/doc/fr/xfce-config.xml</file> |
| 34 |
- <file id="gcc-optimization">/doc/en/gcc-optimization.xml</file> |
| 35 |
+ <file id="gcc-optimization">/doc/fr/gcc-optimization.xml</file> |
| 36 |
<file id="vpnc-howto">/doc/en/vpnc-howto.xml</file> |
| 37 |
<file id="qa-autofailure">/proj/fr/qa/autofailure.xml</file> |
| 38 |
<file id="qa-automagic">/proj/fr/qa/automagic.xml</file> |
| 39 |
|
| 40 |
|
| 41 |
|
| 42 |
1.1 xml/htdocs/doc/fr/gcc-optimization.xml |
| 43 |
|
| 44 |
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/fr/gcc-optimization.xml?rev=1.1&view=markup |
| 45 |
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/fr/gcc-optimization.xml?rev=1.1&content-type=text/plain |
| 46 |
|
| 47 |
Index: gcc-optimization.xml |
| 48 |
=================================================================== |
| 49 |
<?xml version='1.0' encoding='UTF-8'?> |
| 50 |
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> |
| 51 |
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/fr/gcc-optimization.xml,v 1.1 2008/03/04 13:18:37 titefleur Exp $ --> |
| 52 |
|
| 53 |
<guide link="/doc/fr/gcc-optimization.xml"> |
| 54 |
<title>Guide d'optimisation de la compilation</title> |
| 55 |
|
| 56 |
<author title="Auteur"> |
| 57 |
<mail link="nightmorph@g.o">Joshua Saddler</mail> |
| 58 |
</author> |
| 59 |
<author title="Traducteur"> |
| 60 |
<mail link="titefleur@g.o">Marion Agé</mail> |
| 61 |
</author> |
| 62 |
|
| 63 |
<abstract> |
| 64 |
Ce guide constitue une introduction à l'optimisation du code compilé en |
| 65 |
utilisant des variables CFLAGS et CXXFLAGS sûres de manière sensée. Il décrit |
| 66 |
également la théorie sur laquelle se base l'optimisation en général. |
| 67 |
</abstract> |
| 68 |
|
| 69 |
<!-- The content of this document is licensed under the CC-BY-SA license --> |
| 70 |
<!-- See http://creativecommons.org/licenses/by-sa/2.5 --> |
| 71 |
<license/> |
| 72 |
|
| 73 |
<version>1.8</version> |
| 74 |
<date>2007-11-09</date> |
| 75 |
|
| 76 |
<chapter> |
| 77 |
<title>Introduction</title> |
| 78 |
<section> |
| 79 |
<title>Que sont les CFLAGS et les CXXFLAGS ?</title> |
| 80 |
<body> |
| 81 |
|
| 82 |
<p> |
| 83 |
Les CFLAGS et CXXFLAGS sont des variables d'environnement utilisées pour dire au |
| 84 |
compilateur GNU Compiler Collection, <c>GCC</c>, quels genres de paramètres |
| 85 |
utiliser quand il compile le code source. Les CFLAGS s'appliquent au code écrit |
| 86 |
en C alors que les CXXFLAGS s'appliquent au code écrit en C++. |
| 87 |
</p> |
| 88 |
|
| 89 |
<p> |
| 90 |
Ces variables peuvent permettre de diminuer le nombre de messages de débogage |
| 91 |
d'un programme, d'augmenter les niveaux d'alertes d'erreurs et, bien sûr, |
| 92 |
d'optimiser le code obtenu. Le <uri |
| 93 |
link="http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Invoking-GCC.html#Invoking-GCC">manuel |
| 94 |
de GCC</uri> maintient une liste exhaustive des options disponibles et de leur |
| 95 |
utilité. |
| 96 |
</p> |
| 97 |
|
| 98 |
</body> |
| 99 |
</section> |
| 100 |
<section> |
| 101 |
<title>Comment sont-elles utilisées ?</title> |
| 102 |
<body> |
| 103 |
|
| 104 |
<p> |
| 105 |
Les CFLAGS et CXXFLAGS peuvent être utilisées de deux façons. La première est de |
| 106 |
les définir pour chaque programme avec les fichiers Makefiles générés par |
| 107 |
<c>automake</c>. |
| 108 |
</p> |
| 109 |
|
| 110 |
<p> |
| 111 |
Toutefois, cette méthode ne doit pas être utilisée lors de l'installation de |
| 112 |
paquets installés depuis l'arbre Portage. À la place de cela, réglez vos |
| 113 |
variables CFLAGS et CXXFLAGS dans le fichier <path>/etc/make.conf</path>. De |
| 114 |
cette façon, tous les paquets qui seront compilés utiliseront les options que |
| 115 |
vous avez spécifiées. |
| 116 |
</p> |
| 117 |
|
| 118 |
<pre caption="Les CFLAGS dans le /etc/make.conf"> |
| 119 |
CFLAGS="-march=athlon64 -O2 -pipe" |
| 120 |
CXXFLAGS="${CFLAGS}" |
| 121 |
</pre> |
| 122 |
|
| 123 |
<p> |
| 124 |
Comme vous pouvez le voir, la variable CXXFLAGS est paramétrée pour utiliser |
| 125 |
toutes les options présentes dans la variable CFLAGS. Généralement, ceci vous |
| 126 |
suffira et ne créera pas de problème. Vous ne devriez pas avoir besoin de |
| 127 |
spécifier des options supplémentaires dans votre variable CXXFLAGS. |
| 128 |
</p> |
| 129 |
|
| 130 |
</body> |
| 131 |
</section> |
| 132 |
<section> |
| 133 |
<title>Idées fausses</title> |
| 134 |
<body> |
| 135 |
|
| 136 |
<p> |
| 137 |
Bien que les variables CFLAGS et CXXFLAGS peuvent se révéler très utiles pour |
| 138 |
obtenir du code source plus léger et/ou des binaires plus rapides, elles peuvent |
| 139 |
aussi détériorer les fonctionnalités de votre code, augmenter son poids, |
| 140 |
ralentir son temps d'exécution, et même causer des erreurs de compilation ! |
| 141 |
</p> |
| 142 |
|
| 143 |
<p> |
| 144 |
Les CFLAGS ne sont pas magiques ; elles ne vont pas rendre automatiquement |
| 145 |
votre système plus rapide ou vos binaires plus légers. Le fait d'ajouter encore |
| 146 |
et encore des options pour essayer d'optimiser votre système est le meilleur |
| 147 |
moyen d'obtenir des erreurs. À partir d'un moment, vous serez confronté à la loi |
| 148 |
des rendements décroissants. |
| 149 |
</p> |
| 150 |
|
| 151 |
<p> |
| 152 |
Malgré les vantards que vous trouverez sur Internet, les CFLAGS et CXXFLAGS |
| 153 |
aggressives sont de loin plus susceptibles de nuire à vos programmes que de les |
| 154 |
améliorer. Gardez à l'esprit que ces options existent en premier lieu pour être |
| 155 |
utilisées à des endroits spécifiques et à des fins spécifiques. Le fait qu'une |
| 156 |
variable CFLAG particulière soit bonne pour un fragment de code ne signifie pas |
| 157 |
qu'elle soit adaptée à la compilation de tout ce que vous aurez installé sur |
| 158 |
votre machine ! |
| 159 |
</p> |
| 160 |
|
| 161 |
</body> |
| 162 |
</section> |
| 163 |
<section> |
| 164 |
<title>Prêt ?</title> |
| 165 |
<body> |
| 166 |
|
| 167 |
<p> |
| 168 |
Maintenant que vous êtes informé des risques encourus, jetons un coup d'œil à |
| 169 |
quelques options sûres et raisonnables à utiliser pour l'optimisation de votre |
| 170 |
ordinateur. Cela vous tiendra en bonne posture et vous fera aimer des |
| 171 |
développeurs la prochaine fois que vous rapporterez un problème sur le <uri |
| 172 |
link="http://bugs.gentoo.org">Bugzilla</uri>. (Les développeurs vont |
| 173 |
généralement vous prier de bien vouloir recompiler un paquet avec un minimum de |
| 174 |
CFLAGS afin de voir si le problème persiste. Souvenez-vous, les options |
| 175 |
agressives peuvent ruiner le code.) |
| 176 |
</p> |
| 177 |
|
| 178 |
</body> |
| 179 |
</section> |
| 180 |
</chapter> |
| 181 |
<chapter> |
| 182 |
<title>Optimisation</title> |
| 183 |
<section> |
| 184 |
<title>Les bases</title> |
| 185 |
<body> |
| 186 |
|
| 187 |
<p> |
| 188 |
Le but de l'utilisation des CFLAGS et CXXFLAGS est de créer un code conçu |
| 189 |
spécialement pour votre système ; celui-ci devrait fonctionner parfaitement |
| 190 |
tout en étant léger et rapide, si possible. Quelques fois ces conditions sont |
| 191 |
mutuellement exclusives, donc nous allons nous en tenir aux combinaisons connues |
| 192 |
pour fonctionner correctement. Idéalement, ce sont les meilleures disponibles |
| 193 |
quelque soit l'architecture du processeur. Nous expliquerons ce que sont les |
| 194 |
options agressives plus tard ainsi vous saurez ce à quoi il faut faire |
| 195 |
attention. Nous ne parlerons pas de chaque option listée dans le manuel de |
| 196 |
<c>GCC</c> (il y en a des centaines), mais nous couvrirons les options |
| 197 |
classiques, les plus courantes. |
| 198 |
</p> |
| 199 |
|
| 200 |
<note> |
| 201 |
À tout moment si vous n'êtes pas sûr de l'utilité d'une option, référez-vous au |
| 202 |
chapitre approprié du <uri |
| 203 |
link="http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Optimize-Options.html#Optimize-Options">manuel |
| 204 |
de GCC</uri>. Si vous êtes toujours dubitatif, essayez Google ou jetez un œil |
| 205 |
aux <uri link="http://gcc.gnu.org/lists.html">listes de diffusion</uri> de |
| 206 |
<c>GCC</c>. |
| 207 |
</note> |
| 208 |
|
| 209 |
</body> |
| 210 |
</section> |
| 211 |
<section> |
| 212 |
<title>-march</title> |
| 213 |
<body> |
| 214 |
|
| 215 |
<p> |
| 216 |
La première et la plus importante des options est <c>-march</c>. Elle indique au |
| 217 |
compilateur quel code il doit produire pour <uri |
| 218 |
link="http://fr.wikipedia.org/wiki/Microarchitecture">l'architecture</uri> (ou |
| 219 |
<e>arch</e>) de votre processeur : elle indique qu'il doit fournir un code |
| 220 |
pour un certain type de processeur. Les différents processeurs ont des capacités |
| 221 |
différentes, supportent des jeux d'instructions différents et exécutent le code |
| 222 |
de façon différente. L'option <c>-march</c> va permettre de signaler au |
| 223 |
compilateur quel code créer spécifiquement pour votre processeur, avec toutes |
| 224 |
ses capacités, ses fonctionnalités, ses jeux d'instructions, ses gorges |
| 225 |
(NdT : "quirks"), et ainsi de suite. |
| 226 |
</p> |
| 227 |
|
| 228 |
<p> |
| 229 |
Même si la variable CHOST dans le <path>/etc/make.conf</path> spécifie |
| 230 |
l'architecture générale utilisée, <c>-march</c> devrait toujours être renseignée |
| 231 |
pour que les programmes puissent être optimisés pour votre processeur en |
| 232 |
particulier. Les processeurs x86 et x86-64 (entre autres) doivent utiliser |
| 233 |
l'option <c>-march</c>. |
| 234 |
</p> |
| 235 |
|
| 236 |
<p> |
| 237 |
Quel type de processeur avez-vous ? Pour le savoir, tapez ceci : |
| 238 |
</p> |
| 239 |
|
| 240 |
<pre caption="Information du CPU"> |
| 241 |
$ <i>cat /proc/cpuinfo</i> |
| 242 |
</pre> |
| 243 |
|
| 244 |
<p> |
| 245 |
À présent, voyons l'option <c>-march</c> en action. Cet exemple est paramétré |
| 246 |
pour un vieux processeur Pentium III : |
| 247 |
</p> |
| 248 |
|
| 249 |
<pre caption="/etc/make.conf: Pentium III"> |
| 250 |
CFLAGS="-march=pentium3" |
| 251 |
CXXFLAGS="${CFLAGS}" |
| 252 |
</pre> |
| 253 |
|
| 254 |
<p> |
| 255 |
Voici un autre exemple pour un processeur AMD 64 bits : |
| 256 |
</p> |
| 257 |
|
| 258 |
<pre caption="/etc/make.conf: AMD64"> |
| 259 |
CFLAGS="-march=athlon64" |
| 260 |
CXXFLAGS="${CFLAGS}" |
| 261 |
</pre> |
| 262 |
|
| 263 |
<p> |
| 264 |
Les options <c>-mtune</c> et <c>-mcpu</c> sont également disponibles. Elles ne |
| 265 |
sont normalement utilisées que s'il n'y a pas d'option <c>-march</c> disponible |
| 266 |
pour votre processeur ; certaines architectures de processeurs peuvent |
| 267 |
avoir besoin de <c>-mtune</c> ou même de <c>-mcpu</c>. Malheureusement, le |
| 268 |
comportement de <c>GCC</c> n'est pas vraiment cohérent avec la façon dont chaque |
| 269 |
option se comporte d'une architecture à l'autre. |
| 270 |
</p> |
| 271 |
|
| 272 |
<p> |
| 273 |
Sur les processeurs x86 et x86-64, l'option <c>-march</c> va générer du code |
| 274 |
spécifique à tous les processeurs en utilisant tous ses jeux d'instructions |
| 275 |
disponibles et les bonnes interfaces d'applications binaires (NdT : ABI, |
| 276 |
pour « Application Binary Interface ») ; il n'y aura pas de |
| 277 |
problème de compatibilité ascendante pour les processeurs plus vieux ou |
| 278 |
différents. Si vous n'avez pas besoin d'exécuter du code sur d'autres systèmes |
| 279 |
que celui sur lequel vous utilisez Gentoo, continuez d'utiliser <c>-march</c>. |
| 280 |
Vous ne devriez prendre en considération <c>-mtune</c> que si vous devez générer |
| 281 |
du code pour des vieux processeurs tels que les i386 et i486. L'option |
| 282 |
<c>-mtune</c> produit du code plus générique que <c>-march</c> ; même s'il |
| 283 |
va harmoniser le code pour un processeur spécifique, il ne prendra pas compte |
| 284 |
des jeux d'instructions disponibles et de l'ABI. N'utilisez pas <c>-mcpu</c> sur |
| 285 |
les systèmes x86 ou x86-64, car c'est déconseillé pour ces architectures. |
| 286 |
</p> |
| 287 |
|
| 288 |
<p> |
| 289 |
Seuls les processeurs non-x86/x86-64 (tels que Sparc, Alpha, et PowerPC) peuvent |
| 290 |
avoir besoin de <c>-mtune</c> ou de <c>-mcpu</c> au lieu de <c>-march</c>. Sur |
| 291 |
ces architectures, <c>-mtune</c>/<c>-mcpu</c> vont parfois se comporter |
| 292 |
simplement comme <c>-march</c> (sur x86/x86-64)... mais avec un nom d'option |
| 293 |
différent. De nouveau, le comportement de <c>GCC</c> et le nommage des options |
| 294 |
ne sont pas homogènes selon les architectures, donc assurez-vous de bien lire le |
| 295 |
<uri |
| 296 |
link="http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Submodel-Options.html#Submodel-Options">manuel</uri> |
| 297 |
de <c>GCC</c> pour déterminer celles que vous devez utiliser sur votre système. |
| 298 |
</p> |
| 299 |
|
| 300 |
<note> |
| 301 |
Pour plus de suggestions de paramètres pour les options |
| 302 |
<c>-march</c>/<c>-mtune</c>/<c>-mcpu</c>, veuillez lire le chapitre 5 du |
| 303 |
<uri link="/doc/fr/handbook/">Manuel d'installation de Gentoo</uri> approprié à |
| 304 |
votre architecture. De même, lisez la liste des <uri |
| 305 |
link="http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Submodel-Options.html#Submodel-Options">options |
| 306 |
spécifiques</uri> aux architectures dans le manuel de <c>GCC</c>, qui détaillent |
| 307 |
davantage les différences entre <c>-march</c>, <c>-mcpu</c>, et <c>-mtune</c>. |
| 308 |
</note> |
| 309 |
|
| 310 |
</body> |
| 311 |
</section> |
| 312 |
<section> |
| 313 |
<title>-O</title> |
| 314 |
<body> |
| 315 |
|
| 316 |
<p> |
| 317 |
La variable suivante est <c>-O</c>. Elle contrôle le niveau global |
| 318 |
d'optimisation. Plus vous augmentrez le niveau d'optimisation, plus la |
| 319 |
compilation du code prendra du temps et utilisera de la mémoire. |
| 320 |
</p> |
| 321 |
|
| 322 |
<p> |
| 323 |
Il y a cinq paramètres <c>-O</c> : <c>-O0</c>, <c>-O1</c>, <c>-O2</c>, |
| 324 |
<c>-O3</c>, et <c>-Os</c>. Vous ne devrez utiliser qu'un seul d'entre eux dans |
| 325 |
le fichier <path>/etc/make.conf</path>. |
| 326 |
</p> |
| 327 |
|
| 328 |
<p> |
| 329 |
À l'exception de <c>-O0</c>, les paramètres <c>-O</c> activent chacun plusieurs |
| 330 |
options supplémentaires, donc assurez-vous de bien lire le chapitre sur les |
| 331 |
<uri |
| 332 |
link="http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Optimize-Options.html#Optimize-Options">options |
| 333 |
d'optimisation</uri> du manuel de <c>GCC</c> pour savoir quelles options sont |
| 334 |
activées à chaque niveau <c>-O</c>, ainsi que pour obtenir quelques explications |
| 335 |
sur ce qu'elles font. |
| 336 |
</p> |
| 337 |
|
| 338 |
<p> |
| 339 |
Examinons chaque niveau d'optimisation : |
| 340 |
</p> |
| 341 |
|
| 342 |
<ul> |
| 343 |
<li> |
| 344 |
<c>-O0</c>: Ce niveau (la lettre "O" suivie d'un zéro) désactive entièrement |
| 345 |
l'optimisation, c'est le niveau par défaut si aucun niveau <c>-O</c> n'est |
| 346 |
spécifié dans les variables CFLAGS ou CXXFLAGS. Votre code ne sera pas |
| 347 |
optimisé : ce n'est généralement pas ce qui est voulu. |
| 348 |
</li> |
| 349 |
<li> |
| 350 |
<c>-O1</c>: C'est le niveau le plus classique d'optimisation. Le compilateur |
| 351 |
va essayer de générer un code plus rapide et plus léger sans prendre plus de |
| 352 |
temps à compiler. C'est relativement classique, mais cela devrait |
| 353 |
fonctionner dans tous les cas. |
| 354 |
que le travail soit fait. |
| 355 |
</li> |
| 356 |
<li> |
| 357 |
<c>-O2</c>: Un étape au-dessus du <c>-O1</c>. C'est le niveau |
| 358 |
<e>recommandé</e> d'optimisation sauf si vous avez des besoins spécifiques. |
| 359 |
Le niveau <c>-O2</c> va activer quelques options en plus de celles du |
| 360 |
<c>-O1</c>. Avec le niveau <c>-O2</c>, le compilateur va tenter d'augmenter |
| 361 |
les performances du code sans faire de compromis sur la taille et sans |
| 362 |
prendre trop de temps à compiler. |
| 363 |
</li> |
| 364 |
<li> |
| 365 |
<c>-O3</c>: Il s'agit du plus haut niveau d'optimisation possible mais aussi |
| 366 |
du plus risqué. Le temps de compilation sera plus long avec cette option qui |
| 367 |
en fait ne <e>devrait pas être utilisée de façon globale avec <c>GCC</c> |
| 368 |
4.x</e>. Le comportement de <c>GCC</c> a changé de façon significative |
| 369 |
depuis la version 3.x. Dans la version 3.x, <c>-O3</c> a montré que son |
| 370 |
utilisation conduisait à des temps d'exécution marginaux plus rapides |
| 371 |
qu'avec <c>-O2</c>, mais ce n'est plus le cas avec <c>GCC</c> 4.x. Compiler |
| 372 |
tous vos paquets avec <c>-O3</c> <e>produira</e> des plus gros binaires qui |
| 373 |
demanderont plus de mémoire et va augmenter de façon significative les |
| 374 |
étranges erreurs de compilation ou provoquer des comportements inattendus |
| 375 |
pour les programmes (y compris des erreurs). Les inconvénients sont plus |
| 376 |
nombreux que les avantages ; souvenez-vous du principe des rendements |
| 377 |
décroissants. <b>L'utilisation du niveau <c>-O3</c> n'est pas recommandé |
| 378 |
pour <c>GCC</c> 4.x.</b> |
| 379 |
</li> |
| 380 |
<li> |
| 381 |
<c>-Os</c>: Ce niveau va optimiser votre code en taille. Il active toutes |
| 382 |
les options du niveau <c>-O2</c> qui n'influent pas sur la taille du code |
| 383 |
généré. Il peut être utile pour les machines qui ont une taille très limitée |
| 384 |
d'espace libre sur le disque dur et/ou qui ont des processeurs avec une |
| 385 |
petite taille de cache. Toutefois, ce niveau peut tout à fait causer |
| 386 |
d'autres problèmes, c'est pourquoi il est filtré par beaucoup d'ebuilds dans |
| 387 |
l'arbre. L'utilisation de <c>-Os</c> n'est pas recommandé. |
| 388 |
</li> |
| 389 |
</ul> |
| 390 |
|
| 391 |
<p> |
| 392 |
Comme mentionné précédemment, le niveau <c>-O2</c> est le niveau requis pour |
| 393 |
l'optimisation. Si certains paquets créent des erreurs de compilation, |
| 394 |
assurez-vous que vous n'utilisez pas <c>-O3</c>. Comme option de repli, essayez |
| 395 |
de régler vos variables CFLAGS et CXXFLAGS a un niveau d'optimisation plus bas, |
| 396 |
tel que <c>-O1</c> ou même <c>-O0 -g2 -ggdb</c> (pour les rapports d'erreurs et |
| 397 |
la vérification des problèmes si possible) et recompilez le paquet. |
| 398 |
</p> |
| 399 |
|
| 400 |
</body> |
| 401 |
</section> |
| 402 |
<section> |
| 403 |
<title>-pipe</title> |
| 404 |
<body> |
| 405 |
|
| 406 |
<p> |
| 407 |
Une option sûre et sympa à utiliser est <c>-pipe</c>. Cette option en fait n'a |
| 408 |
pas d'effet sur le code généré, mais va accélerer le processus de compilation. |
| 409 |
Elle dit au compilateur d'utiliser des tubes à la place des fichiers temporaires |
| 410 |
pendant les différentes étapes de la compilation. |
| 411 |
</p> |
| 412 |
|
| 413 |
</body> |
| 414 |
</section> |
| 415 |
<section> |
| 416 |
<title>-fomit-frame-pointer</title> |
| 417 |
<body> |
| 418 |
|
| 419 |
<p> |
| 420 |
C'est une option très commune créée dans le but de réduire la taille du code |
| 421 |
généré. Elle est active pour tous les niveaux de <c>-O</c> (à l'exception de |
| 422 |
<c>-O0</c>) sur les architectures pour lesquelles faire cela ne va pas pas |
| 423 |
interférer avec le débogage (tels que les x86-64), mais vous pourriez avoir |
| 424 |
besoin de l'activer vous-même en l'ajoutant à vos options. Bien que le manuel du |
| 425 |
compilateur GNU <c>GCC</c> ne spécifie pas toutes les architectures sur |
| 426 |
lesquelles elle est active en utilisant <c>-O</c>, vous aurez besoin de |
| 427 |
l'activer explicitement sur les architectures x86. Toutefois, l'utilisation de |
| 428 |
cette option rendra le débogage difficile, voire impossible. |
| 429 |
</p> |
| 430 |
|
| 431 |
<p> |
| 432 |
En particulier, cela rend le débogage des applications écrites en Java beaucoup |
| 433 |
plus difficile, bien que Java ne soit pas le seul code affecté par l'utilisation |
| 434 |
de cette option. Donc même si cette option peut aider, elle rend le débogage |
| 435 |
plus délicat : les traçages en particulier seront inutiles. Toutefois, si |
| 436 |
vous n'avez pas l'intention de faire trop de débogage de logiciels et que vous |
| 437 |
n'avez pas ajouté d'autres CFLAGS en relation avec le débogage telles que |
| 438 |
<c>-ggdb</c>, alors vous pouvez essayer d'utiliser <c>-fomit-frame-pointer</c>. |
| 439 |
</p> |
| 440 |
|
| 441 |
<impo> |
| 442 |
Ne combinez <e>pas</e> <c>-fomit-frame-pointer</c> avec l'option similaire |
| 443 |
<c>-momit-leaf-frame-pointer</c>. L'utilisation de cette dernière est obsolète, |
| 444 |
<c>-fomit-frame-pointer</c> fait déjà son travail comme il faut. De plus, |
| 445 |
<c>-momit-leaf-frame-pointer</c> a montré des impacts négatifs sur les |
| 446 |
performances du code. |
| 447 |
<!-- |
| 448 |
source for this info: |
| 449 |
http://www.coyotegulch.com/products/acovea/aco5p4gcc40.html |
| 450 |
--> |
| 451 |
</impo> |
| 452 |
|
| 453 |
</body> |
| 454 |
</section> |
| 455 |
<section> |
| 456 |
<title>-msse, -msse2, -msse3, -mmmx, -m3dnow</title> |
| 457 |
<body> |
| 458 |
|
| 459 |
<p> |
| 460 |
Ces options activent les jeux d'instructions <uri |
| 461 |
link="http://fr.wikipedia.org/wiki/Streaming_SIMD_Extensions">SSE</uri>, <uri |
| 462 |
link="http://fr.wikipedia.org/wiki/SSE2">SSE2</uri>, <uri |
| 463 |
link="http://fr.wikipedia.org/wiki/SSE3">SSE3</uri>, <uri |
| 464 |
link="http://fr.wikipedia.org/wiki/MMX_%28processeur%29">MMX</uri>, et <uri |
| 465 |
link="http://fr.wikipedia.org/wiki/3DNow%21">3DNow!</uri> pour les architectures |
| 466 |
x86 et x86-64. Elles sont pratiques principalement pour le multimédia, le jeu et |
| 467 |
d'autres tâches de calcul à virgule flottante, bien qu'elles contiennent |
| 468 |
plusieurs autres améliorations mathématiques. Ces jeux d'instructions se |
| 469 |
trouvent dans les CPU les plus modernes. |
| 470 |
</p> |
| 471 |
|
| 472 |
<impo> |
| 473 |
Assurez-vous de vérifier que votre processeur supporte ces options en exécutant |
| 474 |
la commande <c>cat /proc/cpuinfo</c>. La sortie va inclure quelques jeux |
| 475 |
d'instruction supplémentaires supportés. Notez que <b>pni</b> n'est qu'un nom |
| 476 |
différent pour SSE3. |
| 477 |
</impo> |
| 478 |
|
| 479 |
<p> |
| 480 |
Normalement vous n'avez pas besoin d'ajouter ces options dans le fichier |
| 481 |
<path>/etc/make.conf</path> si vous utilisez la bonne option <c>-march</c> (par |
| 482 |
exemple, <c>-march=nocona</c> implique <c>-msse3</c>). Il y a quelques |
| 483 |
exceptions notables pour les nouveaux processeurs VIA et AMD64 qui supportent |
| 484 |
des instructeurs non implicites avec <c>-march</c> (tel que SSE3). Pour les |
| 485 |
processeurs comme ceux-là, vous devrez activer les options supplémentaires où il |
| 486 |
faut après avoir regardé la sortie de <c>cat /proc/cpuinfo</c>. |
| 487 |
</p> |
| 488 |
|
| 489 |
<note> |
| 490 |
Vous devriez regarder la <uri |
| 491 |
link="http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options">liste</uri> |
| 492 |
des options x86 et spécifiques aux x86-64 pour voir les jeux d'instructions qui |
| 493 |
sont activés simplement par l'option du type de processeur. Si une instruction |
| 494 |
est listée, alors vous n'avez pas besoin de la spécifier, elle sera activée en |
| 495 |
utilisant le bon paramètre <c>-march</c>. |
| 496 |
</note> |
| 497 |
|
| 498 |
</body> |
| 499 |
</section> |
| 500 |
</chapter> |
| 501 |
<chapter> |
| 502 |
<title>Questions courantes sur l'optimisation</title> |
| 503 |
<section> |
| 504 |
<title>J'obtenais de meilleures performances avec -funroll-loops |
| 505 |
-fomg-optimize !</title> |
| 506 |
<body> |
| 507 |
|
| 508 |
<p> |
| 509 |
Non, vous <e>pensez</e> juste que c'était le cas parce que quelque vous a |
| 510 |
persuadé que le fait de mettre plus d'options était une bonne chose. Les options |
| 511 |
offensives vont seulement nuire à vos applications quand elles sont utilisées à |
| 512 |
l'échelle du système. Même le <uri |
| 513 |
link="http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Optimize-Options.html#Optimize-Options">manuel</uri> |
| 514 |
de <c>GCC</c> dit que le fait d'utiliser les options <c>-funroll-loops</c> et |
| 515 |
<c>-funroll-all-loops</c> provoque un alourdissement du code et le rend plus |
| 516 |
lent à l'exécution. Pourtant, pour une raison quelconque, ces deux options, |
| 517 |
ainsi que <c>-ffast-math</c>, <c>-fforce-mem</c>, <c>-fforce-addr</c>, et les |
| 518 |
autres similaires, continuent à être très populaires chez les personnes qui |
| 519 |
suivent une course à la vantardise. |
| 520 |
</p> |
| 521 |
|
| 522 |
<p> |
| 523 |
La vérité sur ce sujet, c'est qu'il s'agit d'options dangereusement aggressives. |
| 524 |
Jetez un œil sur les <uri link="http://forums.gentoo.org">forums de |
| 525 |
Gentoo</uri> et au <uri link="http://bugs.gentoo.org">Bugzilla</uri> pour voir |
| 526 |
ce que font ces options : rien de bon ! |
| 527 |
</p> |
| 528 |
|
| 529 |
<p> |
| 530 |
Vous n'avez pas besoin d'utiliser ces options de manière globale dans les |
| 531 |
variables CFLAGS et CXXFLAGS. Elles ne feront que nuire à vos performances. |
| 532 |
Elles peuvent vous faire croire que votre système est à la pointe et a de hautes |
| 533 |
performances, mais elles ne feront rien d'autre que de gonfler votre code et |
| 534 |
provoquer des bogues marqués INVALID ou WONTFIX. |
| 535 |
</p> |
| 536 |
|
| 537 |
<p> |
| 538 |
Vous n'avez pas besoin d'options dangereuses telles que celles-ci. <b>Ne les |
| 539 |
utilisez pas</b>. Collez aux options classiques : <c>-march</c>, <c>-O</c>, |
| 540 |
et <c>-pipe</c>. |
| 541 |
</p> |
| 542 |
|
| 543 |
</body> |
| 544 |
</section> |
| 545 |
<section> |
| 546 |
<title>Que dire au sujet des niveaux de l'option -O supérieurs à 3 ?</title> |
| 547 |
<body> |
| 548 |
|
| 549 |
<p> |
| 550 |
Certains utilisateurs friment d'avoir de bien meilleures performances grâce à |
| 551 |
l'utilisation de <c>-O4</c>, <c>-O9</c>, et plus encore, mais en réalité les |
| 552 |
niveaux de l'option <c>-O</c> supérieurs à 3 n'ont aucun effet. Le compilateur |
| 553 |
peut accepter des CFLAGS telles que <c>-O4</c>, mais en fait il ne va rien en |
| 554 |
faire. Il n'optimise que pour <c>-O3</c>, rien de plus. |
| 555 |
</p> |
| 556 |
|
| 557 |
<p> |
| 558 |
Besoin de plus de preuves ? Regardez le <uri |
| 559 |
link="http://gcc.gnu.org/viewcvs/trunk/gcc/opts.c?revision=124622&view=markup">code |
| 560 |
source</uri> de <c>GCC</c> : |
| 561 |
</p> |
| 562 |
|
| 563 |
<pre caption="Source code de -O"> |
| 564 |
if (optimize >= 3) |
| 565 |
{ |
| 566 |
flag_inline_functions = 1; |
| 567 |
flag_unswitch_loops = 1; |
| 568 |
flag_gcse_after_reload = 1; |
| 569 |
/* Allow even more virtual operators. */ |
| 570 |
set_param_value ("max-aliased-vops", 1000); |
| 571 |
set_param_value ("avg-aliased-vops", 3); |
| 572 |
} |
| 573 |
</pre> |
| 574 |
|
| 575 |
<p> |
| 576 |
Comme vous pouvez le voir, une valeur supérieure à 3 est tout simplement traitée |
| 577 |
comme un <c>-O3</c>. |
| 578 |
</p> |
| 579 |
|
| 580 |
</body> |
| 581 |
</section> |
| 582 |
<section> |
| 583 |
<title>Que dire au sujet des options redondantes ?</title> |
| 584 |
<body> |
| 585 |
|
| 586 |
<p> |
| 587 |
Souvent, les variables CFLAGS et CXXFLAGS qui sont mises à plusieurs niveaux de |
| 588 |
<c>-O</c> sont spécifiées comme redondantes dans le fichier |
| 589 |
<path>/etc/make.conf</path>. Parfois cela se fait par ignorance, mais c'est |
| 590 |
également fait pour éviter le filtrage des options ou le remplacement des |
| 591 |
options. |
| 592 |
</p> |
| 593 |
|
| 594 |
<p> |
| 595 |
Le filtrage/remplacement des options est réalisé dans beaucoup d'ebuilds de |
| 596 |
l'arbre Portage. Cela est habituellement dû au fait que les paquets n'arrivent |
| 597 |
pas à compiler avec certains niveaux de <c>-O</c> ou que le code source est |
| 598 |
trop facilement alteré avec d'autres options utilisées. L'ebuild va filtrer |
| 599 |
certaines ou toutes les options CFLAGS et CXXFLAGS, ou alors il les remplacera |
| 600 |
par un différent niveau <c>-O</c>. |
| 601 |
</p> |
| 602 |
|
| 603 |
<p> |
| 604 |
Le <uri |
| 605 |
link="http://devmanual.gentoo.org/ebuild-writing/functions/src_compile/build-environment/index.html">manuel |
| 606 |
du développeur Gentoo</uri> explique où et comment le filtrage et le |
| 607 |
remplacement des options fonctionnent. |
| 608 |
</p> |
| 609 |
|
| 610 |
<p> |
| 611 |
Il est possible d'éviter le filtrage des <c>-O</c> par redondance en listant les |
| 612 |
options pour un certain niveau, tel que <c>-O3</c>, en faisant quelque chose |
| 613 |
comme cela : |
| 614 |
</p> |
| 615 |
|
| 616 |
<pre caption="Spécifier les CFLAGS redondantes"> |
| 617 |
CFLAGS="-O3 -finline-functions -funswitch-loops" |
| 618 |
</pre> |
| 619 |
|
| 620 |
<p> |
| 621 |
Toutefois, <brite>ce n'est pas une chose intelligente à faire</brite>. Les |
| 622 |
CFLAGS ont une bonne raison pour d'être filtrées ! Si les options sont |
| 623 |
filtrées, cela signifie qu'il n'est pas sûr de compiler un paquet avec ces |
| 624 |
options. Il n'est clairement <e>pas</e> prudent de compiler votre système entier |
| 625 |
avec <c>-O3</c> si certaines des options mises par ce niveau vont causer des |
| 626 |
problèmes avec certains paquets. Ainsi, n'essayez pas d'être plus "fûté" que les |
| 627 |
développeurs qui maintiennent ces paquets. <e>Faites confiance aux |
| 628 |
développeurs</e>. Le filtrage des options et leur remplacement est fait dans |
| 629 |
votre intérêt ! Si un ebuild spécifie des options alternatives, n'essayez |
| 630 |
donc pas de les contourner. |
| 631 |
</p> |
| 632 |
|
| 633 |
<p> |
| 634 |
Vous allez sans doute continuer à rencontrer des difficultés lors de la |
| 635 |
compilation d'un paquet avec des options inacceptables. Si vous rapportez vos |
| 636 |
problèmes sur le Bugzilla, les options que vous utilisez dans le fichier |
| 637 |
<path>/etc/make.conf</path> seront facilement visibles et il vous sera dit de |
| 638 |
recompiler sans ces options. Épargnez-vous le problème de recompiler en |
| 639 |
n'utilisant tout simplement pas les options redondantes ! Ne prétendez |
| 640 |
pas que vous êtes forcément meilleur que les développeurs. |
| 641 |
</p> |
| 642 |
|
| 643 |
</body> |
| 644 |
</section> |
| 645 |
<section> |
| 646 |
<title>Que dire au sujet des LDFLAGS ?</title> |
| 647 |
<body> |
| 648 |
|
| 649 |
<p> |
| 650 |
Vous ne devrez certainement pas les définir. Il se peut que vous ayez entendu |
| 651 |
qu'elles accélèrent le temps de chargement des applications, ou qu'elles |
| 652 |
réduisent la taille des binaires produits, mais elles peuvent également empêcher |
| 653 |
tout simplement vos applications de fonctionner. Ces options ne sont pas |
| 654 |
officiellement supportées, et vos bogues pourraient être fermés ou marqués |
| 655 |
INVALID si vous rapportez des erreurs concernant des paquets utilisant les |
| 656 |
LDFLAGS. Dans le meilleur des cas, vous devez recompiler tous les paquets |
| 657 |
affectés sans ces LDFLAGS. |
| 658 |
</p> |
| 659 |
|
| 660 |
</body> |
| 661 |
</section> |
| 662 |
<section> |
| 663 |
<title>Puis-je utiliser les paramètres définis par paquet ?</title> |
| 664 |
<body> |
| 665 |
|
| 666 |
<p> |
| 667 |
Il n'y a pas de méthode qui permettrait de définir des CFLAGS ou d'autres |
| 668 |
variables par paquet, bien qu'il existe quelques <uri |
| 669 |
link="http://forums.gentoo.org/viewtopic-p-3832057.html#3832057">moyens un peu |
| 670 |
brutaux</uri> pour forcer Portage à le faire. |
| 671 |
</p> |
| 672 |
|
| 673 |
<p> |
| 674 |
Vous <e>ne devriez pas</e> essayer de forcer Portage à utiliser des variables |
| 675 |
par paquet, puisqu'il ne le supporte en aucune manière et que cela risque de |
| 676 |
grandement compliquer les rapports de bogue. Renseignez juste vos variables dans |
| 677 |
le fichier <path>/etc/make.conf</path> afin de les utiliser de manière globale |
| 678 |
sur le système. |
| 679 |
</p> |
| 680 |
|
| 681 |
</body> |
| 682 |
</section> |
| 683 |
</chapter> |
| 684 |
|
| 685 |
<chapter> |
| 686 |
<title>Ressources</title> |
| 687 |
<section> |
| 688 |
<body> |
| 689 |
|
| 690 |
<p> |
| 691 |
Les ressources suivantes sont d'une certaine utilité pour comprendre |
| 692 |
l'optimisation : |
| 693 |
</p> |
| 694 |
|
| 695 |
<ul> |
| 696 |
<li> |
| 697 |
Le <uri link="http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/">manuel de GNU |
| 698 |
GCC</uri> |
| 699 |
</li> |
| 700 |
<li> |
| 701 |
Le chapitre 5 du <uri link="/doc/en/handbook/">Manuel d'installation de |
| 702 |
Gentoo</uri> |
| 703 |
</li> |
| 704 |
<li><c>man make.conf</c></li> |
| 705 |
<li><uri link="http://fr.wikipedia.org">Wikipedia</uri></li> |
| 706 |
<li> |
| 707 |
<uri link="http://www.coyotegulch.com/products/acovea/">Acovea</uri>, une |
| 708 |
suite de test et d'analyse comparative (NdT : "benchmarking") qui peut |
| 709 |
être utile pour déterminer de quelle façon les différentes options de |
| 710 |
compilation intéragissent et affectent le code généré, bien sûr ces |
| 711 |
suggestions de code ne sont pas appropriées pour une utilisation globale. |
| 712 |
Cette suite est disponible dans Portage : <c>emerge acovea</c>. |
| 713 |
</li> |
| 714 |
<li>Les <uri link="http://forums.gentoo.org">forums Gentoo</uri></li> |
| 715 |
</ul> |
| 716 |
|
| 717 |
</body> |
| 718 |
</section> |
| 719 |
</chapter> |
| 720 |
</guide> |
| 721 |
|
| 722 |
|
| 723 |
-- |
| 724 |
gentoo-commits@l.g.o mailing list |
Archives