[ GCC ] Options de compilations / optimisations ?

Options de compilations / optimisations ? [ GCC ] - Divers - Linux et OS Alternatifs

Marsh Posté le 30-01-2003 à 20:55:49    

Je me pose quelque question sur les options de gcc
notamment, j'aimerais savoir si ça pose problème de virer l'option -g ? si l'enlever peut améliorer les performances ? et si -g et -fomit-frame-pointer ne seraient pas incompatible entre elle ?
 
et j'aimerais savoir si en règle général l'option non-ANSI "-ffast-math" pose des problèmes. il semblerait que ce soit une bonne optimisation mais je voudrais des binaires stables ...
 
 
quand vous aurez répondu à tout ça, j'aimerais que vous me donniez votre avis si je compile kde3.1 avec -ffast-math , -fomit-frame-pointer, et sans -g ... pour une grosse appli comme ça je me demande si c'est bon ... si ça plante tant pis, je recompilerais, mais je voudrais être sur que ça ne puisse corrompre aucune donné
 
voilà, merci d'avance pour vos réponses   :)


Message édité par udok le 30-01-2003 à 22:15:12
Reply

Marsh Posté le 30-01-2003 à 20:55:49   

Reply

Marsh Posté le 30-01-2003 à 21:07:44    

tiens, sinon je viens de trouver ça qui est interessant :
http://www.freehackers.org/gentoo/gccflags/faq.html
 
comme ça ça évite de cumuler des options qui veulent dire la même chose  ;)  
mais ça répond pas à ma question alors je compte sur vous là :o

Reply

Marsh Posté le 30-01-2003 à 21:08:20    

udok a écrit :


notamment, j'aimerais savoir si ça pose problème de virer l'option -g ? si l'enlever peut améliorer les performances ?  


 
Ca améliore. -g permet d'ajouter les symbole de debug dans le binaire. Le fichier est plus gros, et le soft est plus lent.
 
 

udok a écrit :


et si -g et -fomit-frame-pointer ne seraient pas incompatible entre elle ?


 
Ca empêche généralement d'utiliser le débugger (ce que permet justement -g). Ce qui est chiant (merci de la blague au bureau, je me demandait pourquoi ce con de débugger me sautait deux lignes sur trois [:kadreg]  
 

udok a écrit :


et j'aimerais savoir si en règle général l'option non-ANSI "-ffast-math" pose des problèmes. il semblerait que ce soit une bonne optimisation mais je voudrais des binaires stables ...


 
Ca dépend du programme, si il repose de manière importantes sur les spécification des flottants IEEE (programmes de simulation numérique lourd par exemple).
 
Si c'est pour tracer des icônes à l'écran, ça ne change rien.
 

udok a écrit :


quand vous aurez répondu à tout ça, j'aimerais que vous me donniez votre avis si je compile kde3.1 avec -ffast-math , -fomit-frame-pointer, et sans -g ... pour une grosse appli comme ça je me demande si c'est bon ... si ça plante tant pis, je recompilerais, mais je voudrais être sur que ça ne puisse corrompre aucune donné


 
Vu les options dont tu parles, ça ne peut que roulaizer. Mais rajoute -O3 tant que tu y est. Et rajoutes -funroll-loops.
 
PS: si tu utilises une distribution digne de ce nom, la compilation de KDE est généralement faite avec des options de kalitai. En recompilant un KDE dispo directement dans ta distrib, a moins que tu ai des besoins tordus, tu risque d'avoir un KDE plus lent que celui fourni avec la distrib.


Message édité par kadreg le 30-01-2003 à 21:08:55

---------------
brisez les rêves des gens, il en restera toujours quelque chose...  -- laissez moi troller sur discu !
Reply

Marsh Posté le 30-01-2003 à 21:19:09    

tout d'abord, merci pour ces réponses précises et rapide :jap:
 

kadreg a écrit :


 
Ca améliore. -g permet d'ajouter les symbole de debug dans le binaire. Le fichier est plus gros, et le soft est plus lent.


c'est ce que je pensais, merci pour la confirmation ;)
 
 

kadreg a écrit :


Ca empêche généralement d'utiliser le débugger (ce que permet justement -g). Ce qui est chiant (merci de la blague au bureau, je me demandait pourquoi ce con de débugger me sautait deux lignes sur trois [:kadreg]


idem ci-dessus :D
 
 

kadreg a écrit :


Ca dépend du programme, si il repose de manière importantes sur les spécification des flottants IEEE (programmes de simulation numérique lourd par exemple).
 
Si c'est pour tracer des icônes à l'écran, ça ne change rien.


ok, c'est ce que j'avais compris du man. le mieux pour kde, c'est que je teste mais je pense que ça devrait passer
 
 

kadreg a écrit :


Vu les options dont tu parles, ça ne peut que roulaizer. Mais rajoute -O3 tant que tu y est. Et rajoutes -funroll-loops.
 
PS: si tu utilises une distribution digne de ce nom, la compilation de KDE est généralement faite avec des options de kalitai. En recompilant un KDE dispo directement dans ta distrib, a moins que tu ai des besoins tordus, tu risque d'avoir un KDE plus lent que celui fourni avec la distrib.


pour -O3 j'hésitais au debut parce que le inline ça doit quand décupler pas mal la taille des binaires :/
mais on a rien sans rien donc je vais tester, je verrais bien
pour funroll-loops, qui fait du "inline" mais pour les boucles, j'ai cru comprendre que ça apportait pas grand chose mais c'est encore pire que le inline-function niveau place donc celle là je vais la laisser de coté :)
 
ma distro c'est une debian sarge, et il ne prévoit pas de faire des binaires expres pour, avant que le gcc3.2 passe en sarge (pas avant quelque mois quoi :/ )
et celui de la woody semble ne pas tout installer correctement
et vu que je voulais apprendre un peu comment on fait des packages debian, je m'y mets :D (enfin pour kde je me contente de reprendre le boulot fait pour woody, trop dur pour moi kde)
et j'en profite pour mettre les opti pour mon proc (parce que i386 c'est pas top ...)
 
voilà, merci encore  :)

Reply

Marsh Posté le 30-01-2003 à 21:44:49    

si /tmp/ n'est pas en ramdisk, "-pipe" est bienvenu pour compiler plus vite  :)
 
ne pas non plus oublié "-s" pour striper les binaires au moment du link. (ou "strip ./a.out" )
 
sinon "-O3 -fomit-frame-pointer", classique mais efficace
 
http://www.freehackers.org/gentoo/ [...] _gcc3.html
 
je trouve beaucoup trop de #ifndef NDEBUG dans les sources que je compile, alors un "-DNDEBUG" peut aussi faire son effet

Reply

Marsh Posté le 30-01-2003 à 21:51:37    

++Taz a écrit :

si /tmp/ n'est pas en ramdisk, "-pipe" est bienvenu pour compiler plus vite  :)
 
ne pas non plus oublié "-s" pour striper les binaires au moment du link. (ou "strip ./a.out" )
 
sinon "-O3 -fomit-frame-pointer", classique mais efficace
 
http://www.freehackers.org/gentoo/ [...] _gcc3.html
 
je trouve beaucoup trop de #ifndef NDEBUG dans les sources que je compile, alors un "-DNDEBUG" peut aussi faire son effet


 
le -pipe j'y ai pensé aussi parce que mon /tmp est un peu petit :D (alors que la swap se rajoute facilement)
-s, ça sert à quoi ?
-fomit-frame-pointer est compris dans -O1 donc dans -O3 si je ne m'abuse (enfin le man est pas très claire à ce sujet)
 
par contre j'avais cru voir qu'on pouvait mettre k7 à -march mais il a pas l'air de vouloir me le prendre là ... bizarre
donc je sais pas le mieux pour un duron, ça doit être athlon-tbird mais j'aimerais quand même avoir confirmation  :/

Reply

Marsh Posté le 30-01-2003 à 21:54:04    

d'ailleurs je crois que je peux pousser jusqu'à athlon-4 parce que c'est la 2eme génération de duron qui à le sse et c'est pas forcement du luxe :D
qq'un saurait me dire ?
 
EDIT : merde, cette option est pour gcc3.2  :/


Message édité par udok le 30-01-2003 à 21:55:30
Reply

Marsh Posté le 30-01-2003 à 22:09:02    

putain mais c'est dingue ça !
pourquoi k7 marche pas ... j'étais pourtant sur que ça avait déjà marcher  :/ :sweat:

Reply

Marsh Posté le 30-01-2003 à 22:34:45    

pas bon, il faut mettre : -march=i686 -mcpu=TON_CPU
 
il me semblait un moment qu'il existait -march=athlon, mais ça a dut être supprimé et donc les opti se font avec -mcpu, j'avais essayé sur une fausse manip avec gcc3.2, il me le crachait à la gueule mon -march=athlon
mais il me semble que ça dépendait des sources aussi  
 
donc, pour un duron, c'est...............
 
 
 
 
 
 
 
...... -march=i686 -mcpu=pentiumpro
 
et oui chose étrange, mais ça fait un moment que j'ai vu ça et que je compile les applies avec mcpu comme ça... le duron est considéré comme un ppro
 
-mcpu=k7 est une optimisation pour les premiers athlon

Reply

Marsh Posté le 30-01-2003 à 22:49:04    

j'ai matté là :
http://gcc.gnu.org/onlinedocs/gcc- [...] .html#SEC2
 
donc apparemment, pas de k7, athlon, ou autre joyeuseté dans le 2.95
et d'ailleurs quand j'essaie, il me les jette à la gueule
pas de -mmmx, et encore moins de -3dnow ...
et le -mcpu est appelé par -march d'après ce que dit la doc
 
c'est quand même un peu le bordel ... j'aurais juré avoir déjà utilisé le -march=k7 ... :/
bref, dixit toute opti de ce type puisqu'apparemment pas connu
enfin je pense que déjà entre i386 et i686 on doit bien voir la différence, mais ça fait quand même un peu chier ... j'ai hatte au gcc3.2

Reply

Marsh Posté le 30-01-2003 à 22:49:04   

Reply

Marsh Posté le 31-01-2003 à 00:18:13    

tu peux t'amuser avec l'option  -finline-limit aussi, parce que gcc-3.2 est vraiment une grosse daube à ce niveau (il inline quasiment rien par défaut). Par contre attention aux temps de compilation ça peut faire très très mal  [:kurrupt]

Reply

Marsh Posté le 31-01-2003 à 00:45:50    

ma distri est entierement compilee avec ca sur dudu morgan (sse):
 
-march=athlon -mcpu=athlon -msse -m3dnow -mmmx -ffast-math -fomit-frame-pointer -O3 -DNDEBUG
 
sauf pour la glibc qui n'encaisse pas le -fomit-frame-pointer !

Reply

Marsh Posté le 31-01-2003 à 02:19:40    

apolon34 a écrit :

ma distri est entierement compilee avec ca sur dudu morgan (sse):
 
-march=athlon -mcpu=athlon -msse -m3dnow -mmmx -ffast-math -fomit-frame-pointer -O3 -DNDEBUG
 
sauf pour la glibc qui n'encaisse pas le -fomit-frame-pointer !


 
-mcpu est inutile si tu utilises déjà -march d'après la doc
de plus, tu es sur que -m3dnow, -mmmx et -msse ne sont pas déjà réalisés par -march=athlon-4 ?
et de même pour fomit-fram-pointer : c'est déjà fait par -O1 normalement ...

Reply

Marsh Posté le 31-01-2003 à 02:47:12    

de toutes façons, ça ne coûte rien de répéter les cflags, ça va pas faire bugger le shmilblick, je prends le cas de kde, à la fin j'étais à 5 fois la déclaration des cflags, sûrement parce qu'il devait faire : CFLAGS=$CFLAGS:XXXXX à chaque fois, alors au bout d'un moment tu te retrouves avec 10 lignes d'optimisations répétées juste pour compiler un seul objet :D  
 
ça gêne en rien... mais si t'es un dev, c'est sûr que ça fait plus propre et à la fin tes sources prennent moins de place s'il y a moins de déclarations, mais bon...

Reply

Marsh Posté le 31-01-2003 à 02:57:08    

je me tate pour installer la sid et avoir le 3.2 là :o
mais j'ai peur des dépendances pétées ou pire qui sait ... :/

Reply

Marsh Posté le 31-01-2003 à 08:47:25    

udok a écrit :

ou pire qui sait ... :/


 
Des femmes en furie ?


---------------
brisez les rêves des gens, il en restera toujours quelque chose...  -- laissez moi troller sur discu !
Reply

Marsh Posté le 31-01-2003 à 14:37:15    

kadreg a écrit :


 
Des femmes en furie ?


 
:D
non des pertes de données  :sweat:  
mais bon ,à priori les paquets entrant en sid sont des programmes déjà testé un minimum donc je me lance (en espérant qu'il n'y est pas une merde dans la fs un jour en sid)
mais la netinst marche pas, ça commence bien :cry:

Reply

Marsh Posté le 31-01-2003 à 15:45:16    

udok a écrit :


 
-mcpu est inutile si tu utilises déjà -march d'après la doc
de plus, tu es sur que -m3dnow, -mmmx et -msse ne sont pas déjà réalisés par -march=athlon-4 ?
et de même pour fomit-fram-pointer : c'est déjà fait par -O1 normalement ...


 
march et mcpu, certainement mais autant etre sur !
 
m3dnow et mmx, idem
 
msse n'est specifie que avec athlon-xp, les precedents ne le supportaient pas

Reply

Marsh Posté le 31-01-2003 à 20:38:05    

apolon34 a écrit :


 
march et mcpu, certainement mais autant etre sur !
 
m3dnow et mmx, idem
 
msse n'est specifie que avec athlon-xp, les precedents ne le supportaient pas


 
si tu as le msse c'est que tu as un athlon-4(je sais pas ce que c'est :D ) ou un athlon-xp donc tu peux surement utilisé ça plutot que msse
enfin j'ai jamais testé, c'est de la théorie tout ça, mais si ces flag existe c'est qu'ils ont une utilité et comme dit plus haut, vaut mieux être sur et en mettre trop que pas assez, ça coute rien :D

Reply

Marsh Posté le 31-01-2003 à 21:20:45    

udok a écrit :


 
si tu as le msse c'est que tu as un athlon-4(je sais pas ce que c'est :D ) ou un athlon-xp donc tu peux surement utilisé ça plutot que msse
enfin j'ai jamais testé, c'est de la théorie tout ça, mais si ces flag existe c'est qu'ils ont une utilité et comme dit plus haut, vaut mieux être sur et en mettre trop que pas assez, ça coute rien :D  


 
athlon 4 = 4ème génération = MP et XP

Reply

Marsh Posté le 01-02-2003 à 15:03:59    

BMOTheKiller a écrit :


 
athlon 4 = 4ème génération = MP et XP


 
non ça doit plutot être la génération juste avant, sinon ils se seraient pas emmerdé à faire deux cible pour la même chose
ça doit être la génération pour mon proc par exemple : duron 1.1Ghz (y-a eu deux générations de duron, mais la deuxième n'est pas basée sur le core de l'athlon xp mais sur le proc juste avant (il me semble)

Reply

Marsh Posté le 01-02-2003 à 15:25:56    

:non:
 
mplayer avec un XP :
(athlon 4 correspond au core palomino)
CPU: Advanced Micro Devices Athlon 4 PM Palomino/Athlon MP Multiprocessor/Athlon XP eXtreme Performance (Family: 6, Stepping: 2)
Detected cache-line size is 64 bytes
CPUflags:  MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 0
 
 
mplayer avec un Duron :
(là c'est myennement bon, c'est pas un morgan, mais bon...)
CPU: Advanced Micro Devices Duron MG Morgan (Family: 6, Stepping: 0)
Detected cache-line size is 64 bytes
CPUflags:  MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 0


Message édité par BMOTheKiller le 01-02-2003 à 15:27:25
Reply

Marsh Posté le 01-02-2003 à 21:23:57    

BMOTheKiller a écrit :

:non:
 
mplayer avec un XP :
(athlon 4 correspond au core palomino)
CPU: Advanced Micro Devices Athlon 4 PM Palomino/Athlon MP Multiprocessor/Athlon XP eXtreme Performance (Family: 6, Stepping: 2)
Detected cache-line size is 64 bytes
CPUflags:  MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 0
 
 
mplayer avec un Duron :
(là c'est myennement bon, c'est pas un morgan, mais bon...)
CPU: Advanced Micro Devices Duron MG Morgan (Family: 6, Stepping: 0)
Detected cache-line size is 64 bytes
CPUflags:  MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 0


 
donc duron 2 != de athlon 4 et athlon 4 == athlon xp ? c'est bizarre quand même  :??:

Reply

Marsh Posté le 02-02-2003 à 00:42:54    

il me semble que l'athlon 4 c'est le xp pour les mobiles.
 
il doit bien y avoir une difference, mais laquelle ??

Reply

Marsh Posté le 02-02-2003 à 05:20:02    

apolon34 a écrit :

il me semble que l'athlon 4 c'est le xp pour les mobiles.
 
il doit bien y avoir une difference, mais laquelle ??


 
non, j'ai pas l'impression
je viens de faire une compil de mplayer avec mon duron de 2nd génération et il me le trouve comme un athlon 4
mais je me demande s'il n'y a pas eu 2 générations d'athlon xp e que le 4 en serait la première ... je suis un peu pommé avec tout ça moi :D

Reply

Marsh Posté le 02-02-2003 à 09:43:16    

pose la question sur o/c, ils te diront...
 
mais le Duron 2 (core morgan) est reconnu normalement comme le miens au dessus (qui n'est normalement pas un core morgan car < 1.2 GHz, mais je l'ai acheté d'occase alors peut-être que... :whistle: )
 
edit : apolon34 a entièrement raison, l'athlon 4 est le nom de l'athlon XP mobile : http://www.google.fr/search?q=athl [...] %3Dlang_fr


Message édité par BMOTheKiller le 02-02-2003 à 09:56:45
Reply

Marsh Posté le 02-02-2003 à 13:20:18    

les dudu c'est des morgan a partir de 1ghz

Reply

Marsh Posté le 02-02-2003 à 14:05:18    

ah oui,je me rappelais plus : palomino et morgan c'est le même core en fait (le palomino à priori)
et le core qui vient après c'est le Thoroughbred
et celui avant c'est le tbird
et bientot on aura des hammer ... voilà, je crois que c'est ça

Reply

Marsh Posté le 02-02-2003 à 14:23:49    

on aura des barton avant les hammer...
 
enfin on devie du sujet la...

Reply

Marsh Posté le 02-02-2003 à 14:30:05    

apolon34 a écrit :

on aura des barton avant les hammer...
 
enfin on devie du sujet la...


 
oué enfin l'opteron c'est du hammer d'après ce que j'ai lu, donc on en a déjà, mais c'est vraique ça ne nous est pas adressé :D

Reply

Marsh Posté le 02-02-2003 à 17:03:11    

apolon34 a écrit :

les dudu c'est des morgan a partir de 1ghz


 
ouai je sais, me suis mal exprimé, les 1ers morgan sont sortis à partir de 1.2 GHz, puis ils ont sortis le 1.1 et le 1 GHz, mais le miens est antérieur normalement, donc y avait pas encore en dessous du 1.2, c'est pour ça que je trouve étrange que mon dudu soit détecté comme morgan... :??:

Reply

Marsh Posté le 02-02-2003 à 17:17:55    

moi je penses que c'est un morgan le tien...

Reply

Marsh Posté le 02-02-2003 à 18:21:04    

y-a que le morgan qui a le sse (les duron avant n'en avait pas)
donc je pense que mplayer sait correctement détecté ça
donc, comme apolon, je pense que c'est un morgan ton duron (comme le mien quoi :D )

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed