[Débutant] Optimiser la compilation

Salut à tous,

Si j'ai bien compris, les applications fournies sur les CD de Mandrake
sont destinées à tous les processeurs de la famille i586 - ce qui est tout
à fait normal pour assurer une large compatibilité.
Mais j'ai entendu dire qu'il était possible d'optimiser la compilation
d'un programme pour des processeurs plus évolués que le 586.

Cela m'intéresserait, car d'une part j'utilise un athlon-XP, et d'autre
part la commande `uname -a' me retourne la valeur "i686". J'en déduis que
si je compile un programme à l'aide de la commande make, le programme de
compilation produira un binaire optimisé pour i686, mais pas pour un
athlon-XP.

Moi j'ai :
Linux gentoo 2.4.22 #6 dim sep 21 13:17:02 CEST 2003 i686 AMD Athlon(tm) XP
2000+ AuthenticAMD GNU/Linux

Cela renseigne uniquement selon la façon dont le noyau a été compilé.

Donc, ma question est : comment faire en sorte que la compilation prenne
en compte les particularités du processeur ? Faut-il ajouter une option
après la commande make ? (J'ai regardé dans `man make', mais je n'ai pas
trouvé.) Faut-il changer quelque chose dans le makefile ?

En fait, il faut que le compilateur reçoivent les bonnes options.

Ceci devrait t'intéresser :
http://reviewed.homelinux.org/en/howtocflags.html

En gros, il faut définir les variables environnementales suivantes, dans un
script de login :
export CHOST="i686-pc-linux-gnu"
export CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer"
export CXXFLAGS="${CFLAGS}"

Néanmoins, ceci n'est pas une solution universelle, et il faut parfois
éditer le makefile, ou indiquer les options sur la ligne de commande à
make, par exemple avec :
make 'CFLAGS = -march=athlon-xp -O3 -pipe -fomit-frame-pointer'

A voir donc selon le cas.

A noter aussi que les meilleures options varient selon le programme à
compiler, il n'est donc pas certain qu'un réglage globale soit *la*
solution.

--
Richard

On Sun, 26 Oct 2003 15:18:42 +0100, Richard Delorme wrote:

Donc, ma question est : comment faire en sorte que la compilation prenne
en compte les particularités du processeur ? Faut-il ajouter une option
après la commande make ? (J'ai regardé dans `man make', mais je n'ai pas
trouvé.) Faut-il changer quelque chose dans le makefile ?

En fait, il faut que le compilateur reçoivent les bonnes options.

Ceci devrait t'intéresser :
http://reviewed.homelinux.org/en/howtocflags.html

En gros, il faut définir les variables environnementales suivantes, dans un
script de login :
export CHOST="i686-pc-linux-gnu"
export CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer"
export CXXFLAGS="${CFLAGS}"

Néanmoins, ceci n'est pas une solution universelle, et il faut parfois
éditer le makefile, ou indiquer les options sur la ligne de commande à
make, par exemple avec :
make 'CFLAGS = -march=athlon-xp -O3 -pipe -fomit-frame-pointer'

A voir donc selon le cas.

A noter aussi que les meilleures options varient selon le programme à
compiler, il n'est donc pas certain qu'un réglage globale soit *la*
solution.

Attention, tou de même:
pour compîler des applications et être capable de les debugger,
il faut -O2 à la place de -O3 et ne _pas_ mettre -fomit-frame-pointer
D'une façon générale, il est plus prudent de laisser -O2,
car le -O3 peut générer des problèmes vicieux avec certains programmes
pour lesquels il ne faut surtout pas que le compilateur réordonne
les instructions executées.

On Sun, 26 Oct 2003 15:18:42 +0100, Richard Delorme wrote:

Donc, ma question est : comment faire en sorte que la compilation prenne
en compte les particularités du processeur ? Faut-il ajouter une option
après la commande make ? (J'ai regardé dans `man make', mais je n'ai pas
trouvé.) Faut-il changer quelque chose dans le makefile ?

En fait, il faut que le compilateur reçoivent les bonnes options.

Ceci devrait t'intéresser :
http://reviewed.homelinux.org/en/howtocflags.html

En gros, il faut définir les variables environnementales suivantes, dans
un script de login :
export CHOST="i686-pc-linux-gnu"
export CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer"
export CXXFLAGS="${CFLAGS}"

Néanmoins, ceci n'est pas une solution universelle, et il faut parfois
éditer le makefile, ou indiquer les options sur la ligne de commande à
make, par exemple avec :
make 'CFLAGS = -march=athlon-xp -O3 -pipe -fomit-frame-pointer'

A voir donc selon le cas.

A noter aussi que les meilleures options varient selon le programme à
compiler, il n'est donc pas certain qu'un réglage globale soit *la*
solution.

Attention, tou de même:
pour compîler des applications et être capable de les debugger,
il faut -O2 à la place de -O3 et ne _pas_ mettre -fomit-frame-pointer

oui, et ajouter -g bien sûr.
cela dit -fomit-frame-pointer est une option d'optimisation assez efficace,
et il est bête de ne pas l'utiliser.

D'une façon générale, il est plus prudent de laisser -O2,
car le -O3 peut générer des problèmes vicieux avec certains programmes
pour lesquels il ne faut surtout pas que le compilateur réordonne
les instructions executées.

L'option -O2 réordonne déjà les instructions. -O3, en plus de ce que fait
-O2, met en ligne automatiquement certaines fonctions. Il est vrai que des
bugs dus à l'utilisation de -O3 (ou de -finline-functions) sont
régulièrement trouvés, mais il existe aussi des bugs ailleurs dans gcc.
Utiliser -O2 ne garantit donc pas l'absence de problème. Et si personne
n'utilise gcc avec l'option -O3, cela va être dur de débogguer cette option
de gcc :-)
L'utilisation de -O3 peut aussi ralentir le code, par rapport à -O2. Mais,
bon, j'avais déjà dit que les meilleures options dépendent du programme.

--
Richard

Richard Delorme wrote:

On Sun, 26 Oct 2003 15:18:42 +0100, Richard Delorme wrote:

Donc, ma question est : comment faire en sorte que la compilation
prenne en compte les particularités du processeur ? Faut-il ajouter une
option après la commande make ? (J'ai regardé dans `man make', mais je
n'ai pas trouvé.) Faut-il changer quelque chose dans le makefile ?

En fait, il faut que le compilateur reçoivent les bonnes options.

Ceci devrait t'intéresser :
http://reviewed.homelinux.org/en/howtocflags.html

En gros, il faut définir les variables environnementales suivantes, dans
un script de login :
export CHOST="i686-pc-linux-gnu"
export CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer"
export CXXFLAGS="${CFLAGS}"

Néanmoins, ceci n'est pas une solution universelle, et il faut parfois
éditer le makefile, ou indiquer les options sur la ligne de commande à
make, par exemple avec :
make 'CFLAGS = -march=athlon-xp -O3 -pipe -fomit-frame-pointer'

A voir donc selon le cas.

A noter aussi que les meilleures options varient selon le programme à
compiler, il n'est donc pas certain qu'un réglage globale soit *la*
solution.

Attention, tou de même:
pour compîler des applications et être capable de les debugger,
il faut -O2 à la place de -O3 et ne _pas_ mettre -fomit-frame-pointer

oui, et ajouter -g bien sûr.
cela dit -fomit-frame-pointer est une option d'optimisation assez
efficace, et il est bête de ne pas l'utiliser.

D'une façon générale, il est plus prudent de laisser -O2,
car le -O3 peut générer des problèmes vicieux avec certains programmes
pour lesquels il ne faut surtout pas que le compilateur réordonne
les instructions executées.

L'option -O2 réordonne déjà les instructions. -O3, en plus de ce que fait
-O2, met en ligne automatiquement certaines fonctions. Il est vrai que des
bugs dus à l'utilisation de -O3 (ou de -finline-functions) sont
régulièrement trouvés, mais il existe aussi des bugs ailleurs dans gcc.
Utiliser -O2 ne garantit donc pas l'absence de problème. Et si personne
n'utilise gcc avec l'option -O3, cela va être dur de débogguer cette
option de gcc :-)
L'utilisation de -O3 peut aussi ralentir le code, par rapport à -O2. Mais,
bon, j'avais déjà dit que les meilleures options dépendent du programme.

Merci pour votre réponse.
Cependant, je n'ai pas encore tout compris. En particulier : qu'est-ce qu'un
"script de login" ? Est-ce un simple script ou y a-t-il une procédure
spéciale pour l'activer ?

Merci pour votre réponse.
Cependant, je n'ai pas encore tout compris. En particulier : qu'est-ce
qu'un "script de login" ? Est-ce un simple script ou y a-t-il une
procédure spéciale pour l'activer ?

Tu peux mettre ça dans un simple script, où même le taper directement dans
bash (ou un autre shell). Néanmoins, si tu écris ces lignes dans .bashrc
(ou le fichier semblable de ton shell), ce serait fait une fois pour toute
à chaque lancement de bash.

--
Richard

Ce cher Richard Delorme <abulmo@nospam.fr> a dit :

Moi j'ai :
Linux gentoo 2.4.22 #6 dim sep 21 13:17:02 CEST 2003 i686 AMD Athlon(tm) XP
^^^^^^

C'est le nom de ta bécane ? :-]

2000+ AuthenticAMD GNU/Linux

Duh...

$ uname -a
Linux marvin 2.4.22 #2 lun oct 27 09:09:29 CET 2003 i686 GNU/Linux
$

J'aimerais bien avoir mon zoli "AMD Athlon(tm) Processor AuthenticAMD"...
Sachant que j'ai un Athlon ThunderBird, que mplayer se compile avec
les options -march=athlon-tbird -mcpu =athlon-tbird et que rajouter
ces options de compile dans mon /usr/src/linux/Makefile à HOSTCFLAGS
ne donne rien du tout ( je vois un pauvre -march=athlon à la compile).

Quelques pistes svp ?

Cela renseigne uniquement selon la façon dont le noyau a été compilé.

Oui mais ça en jette, aussi ;-)

--
« La plus value latente d'une entreprise est toujours a priori
subordonnée aux moins-values éventuelles de la concurrence. »
- L'auberge espagnole -

Richard Delorme wrote:

Néanmoins, si tu écris ces lignes dans .bashrc
(ou le fichier semblable de ton shell), ce serait fait une fois pour toute
à chaque lancement de bash.

Pas vraiment une bonne idée, on oublie vite ce qu'on a mis dans .bashrc :)
Il vaux mieux créer un utilisateur spécial uniquement pour la compilation
avec les flags désirés dans le script de login de cet utilisateur.

--
Pascal

On Mon, 27 Oct 2003 10:15:09 +0100, Hugues Hiegel wrote:

J'aimerais bien avoir mon zoli "AMD Athlon(tm) Processor AuthenticAMD"...
Sachant que j'ai un Athlon ThunderBird, que mplayer se compile avec
les options -march=athlon-tbird -mcpu =athlon-tbird et que rajouter
ces options de compile dans mon /usr/src/linux/Makefile à HOSTCFLAGS
ne donne rien du tout ( je vois un pauvre -march=athlon à la compile).

Quelques pistes svp ?

La meilleure: ne jamais modifier le Makefile du kernel:
si tu sélectionne ton CPU de façon appropriée quand tu configure
la compil du kernel, tout ira bien. Si tu change les flags de compil,
gare aux résultats... Il y a quelques parties du code qui ne compilent
correctement _que_ avec les options qui sont dans le Makefile...

On Sun, 26 Oct 2003 18:04:38 +0100, Richard Delorme wrote:

Attention, tou de même:
pour compîler des applications et être capable de les debugger,
il faut -O2 à la place de -O3 et ne _pas_ mettre -fomit-frame-pointer

oui, et ajouter -g bien sûr.
cela dit -fomit-frame-pointer est une option d'optimisation assez efficace,
et il est bête de ne pas l'utiliser.

-g n'est pas indispensable pour debugger, à mon sens. C'est une grosse
aide en cours de développement, mais c'est inutilisable pour un logiciel
installé. Par contre, le -fomit-frame-pointer interdit tout debuggage
à partir d'un core-dump, par exemple, ce qui rend impossible même de
rapporter un bug à l'auteur du soft. Il y a même des applications qui
ne fonctionnent plus avec cette option (par ex: gestion de thread
en mode user...).

D'une façon générale, il est plus prudent de laisser -O2,
car le -O3 peut générer des problèmes vicieux avec certains programmes
pour lesquels il ne faut surtout pas que le compilateur réordonne
les instructions executées.

L'option -O2 réordonne déjà les instructions. -O3, en plus de ce que fait
-O2, met en ligne automatiquement certaines fonctions. Il est vrai que des
bugs dus à l'utilisation de -O3 (ou de -finline-functions) sont
régulièrement trouvés, mais il existe aussi des bugs ailleurs dans gcc.

C'est vrai que O2 réordonne déjà le code. Les problèmes de -O3 viennent
généralement du fait qu'il réordonne également l'utilisation des
registres (-frename-registers) ce qui peut parfois être une bonne
idée, mais dans les cas ou ça ne l'est pas, le crash est garanti
et il est assez difficile de retrouver le bug (le seul moyen est
le pas à pas en assembleur, pour ceux que ça tente).
A mon sens, -finline-function n'a pas grand sens: le programmeur moyen
devrait être capable de décider par lui même de façon judicieuse
quelles fonctions il faut "inliner", mais c'est un avis personel,
bien sur :=)

Utiliser -O2 ne garantit donc pas l'absence de problème. Et si personne
n'utilise gcc avec l'option -O3, cela va être dur de débogguer cette option
de gcc :-)
C'est plein de bon sens :=)

Pour ceux qui veulent des bugs avec -O2, la version 3.2 de gcc réserve
des pièges assez diaboliques...