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  

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à

 
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.
 
 

 
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  
 

 
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.
 

 
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.

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

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

idem ci-dessus
 
 

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
 
 

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 (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  

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 (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  

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
qq'un saurait me dire ?
 
EDIT : merde, cette option est pour gcc3.2  

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

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

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

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  

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

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

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

 
Des femmes en furie ?

 

non des pertes de données    
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

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

 
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)

 
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  

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

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

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

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

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é

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

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

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 )