(C'est limite débats, mais je préfère d'abord une réponse *technique*)
Bonsoir,
Coutumier des distributions binaires, je me suis attelé ce week-end à
l'installation d'une Gentoo 2004.3.
Avec le manuel, tout s'est bien passé (pas loin de 50h de compilation
sur un P-3 450), mais j'ai été stupéfait par ... le nombre de warning
lors de la compilation.
Est-ce normal, et ont-ils une incidence sur le bon fonctionnement des
programmes? Je pense notamment aux avertissements concernant une
comparaison entre pointeur et entier sans cast de celui-ci, ce qui, si
mes souvenirs sont bons, n'est pas une manière "propre" de travailler,
ou encore aux messages avertissant de l'utilisation de variable non
initialisées.
J'ai un peu d'expérience en programmation, et je me souviens que c'était
le genre de messages qui faisait sauter mon prof au plafond, d'où mon
inquiétude.
Le Mon, 22 Nov 2004 19:25:43 +0100, Jerome Lambert a écrit :
[cut]
* Comment remplir la variable CFLAGS pour mon architecture (je pensais mettre -O2 -march=athlon-xp -pipe ) ?
En lisant le manuel de gcc, je dirais -O3 -march=athlon-xp -pipe -funroll-loops -fomit-frame-pointer
et puis un petit coup de cat /proc/cpuinfo pour voir ce que l'on peut activer (sse, 3dnow, etc.), mais les pros me corrigeront.
Pas pro, mais de mon point de vue -O3 ne semble pas apporter grand chose mis a part une occupation disque (et mémoire?) plus importante, je pencherais pour -Os -march=athlon-xp -pipe -fomit-frame-pointer (peut être -fpmath=sse). Et LDFLAGS=-s , si possible.
Le Mon, 22 Nov 2004 19:25:43 +0100, Jerome Lambert a écrit :
[cut]
* Comment remplir la variable CFLAGS pour mon architecture (je pensais
mettre -O2 -march=athlon-xp -pipe ) ?
En lisant le manuel de gcc, je dirais -O3 -march=athlon-xp -pipe
-funroll-loops -fomit-frame-pointer
et puis un petit coup de cat /proc/cpuinfo pour voir ce que l'on peut
activer (sse, 3dnow, etc.), mais les pros me corrigeront.
Pas pro, mais de mon point de vue -O3 ne semble pas apporter grand chose
mis a part une occupation disque (et mémoire?) plus importante, je
pencherais pour -Os -march=athlon-xp -pipe -fomit-frame-pointer (peut
être -fpmath=sse). Et LDFLAGS=-s , si possible.
Le Mon, 22 Nov 2004 19:25:43 +0100, Jerome Lambert a écrit :
[cut]
* Comment remplir la variable CFLAGS pour mon architecture (je pensais mettre -O2 -march=athlon-xp -pipe ) ?
En lisant le manuel de gcc, je dirais -O3 -march=athlon-xp -pipe -funroll-loops -fomit-frame-pointer
et puis un petit coup de cat /proc/cpuinfo pour voir ce que l'on peut activer (sse, 3dnow, etc.), mais les pros me corrigeront.
Pas pro, mais de mon point de vue -O3 ne semble pas apporter grand chose mis a part une occupation disque (et mémoire?) plus importante, je pencherais pour -Os -march=athlon-xp -pipe -fomit-frame-pointer (peut être -fpmath=sse). Et LDFLAGS=-s , si possible.
billiob
[cut]
* Comment remplir la variable CFLAGS pour mon architecture (je pensais mettre -O2 -march=athlon-xp -pipe ) ?
En lisant le manuel de gcc, je dirais -O3 -march=athlon-xp -pipe -funroll-loops -fomit-frame-pointer
et puis un petit coup de cat /proc/cpuinfo pour voir ce que l'on peut activer (sse, 3dnow, etc.), mais les pros me corrigeront.
Pas pro, mais de mon point de vue -O3 ne semble pas apporter grand chose mis a part une occupation disque (et mémoire?) plus importante, je pencherais pour -Os -march=athlon-xp -pipe -fomit-frame-pointer (peut être -fpmath=sse). Et LDFLAGS=-s , si possible.
voici ce que me donne cat /proc/cpuinfo:
processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 6 model name : AMD Athlon(tm) XP 2000+ stepping : 2 cpu MHz : 1666.932 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3d nowext 3dnow bogomips : 3301.37 Je suppose qu'il faut comprendre -mfpmath=sse à la place de -fpmath=sse
Avec ces falgs, puis-je ajouter d'autre options ? Pourriez-vous m'expliquer à quoi servent -funroll-loops et -fomit-frame-pointer, ou -momit-leaf-frame-pointer car la doc de gcc m'est peu claire ? -- @+ billiob Utilisateur de Linux n°342916 Enregistrez-vous sur http:counter.li.org !! Remplaçez INVALID par swissinfo pour m'envoyer un mail.
[cut]
* Comment remplir la variable CFLAGS pour mon architecture (je pensais
mettre -O2 -march=athlon-xp -pipe ) ?
En lisant le manuel de gcc, je dirais -O3 -march=athlon-xp -pipe
-funroll-loops -fomit-frame-pointer
et puis un petit coup de cat /proc/cpuinfo pour voir ce que l'on peut
activer (sse, 3dnow, etc.), mais les pros me corrigeront.
Pas pro, mais de mon point de vue -O3 ne semble pas apporter grand chose
mis a part une occupation disque (et mémoire?) plus importante, je
pencherais pour -Os -march=athlon-xp -pipe -fomit-frame-pointer (peut
être -fpmath=sse). Et LDFLAGS=-s , si possible.
voici ce que me donne cat /proc/cpuinfo:
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 6
model name : AMD Athlon(tm) XP 2000+
stepping : 2
cpu MHz : 1666.932
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3d nowext 3dnow
bogomips : 3301.37
Je suppose qu'il faut comprendre -mfpmath=sse à la place de -fpmath=sse
Avec ces falgs, puis-je ajouter d'autre options ?
Pourriez-vous m'expliquer à quoi servent -funroll-loops et
-fomit-frame-pointer, ou -momit-leaf-frame-pointer car la doc de gcc
m'est peu claire ?
--
@+
billiob
Utilisateur de Linux n°342916
Enregistrez-vous sur http:\counter.li.org !!
Remplaçez INVALID par swissinfo pour m'envoyer un mail.
* Comment remplir la variable CFLAGS pour mon architecture (je pensais mettre -O2 -march=athlon-xp -pipe ) ?
En lisant le manuel de gcc, je dirais -O3 -march=athlon-xp -pipe -funroll-loops -fomit-frame-pointer
et puis un petit coup de cat /proc/cpuinfo pour voir ce que l'on peut activer (sse, 3dnow, etc.), mais les pros me corrigeront.
Pas pro, mais de mon point de vue -O3 ne semble pas apporter grand chose mis a part une occupation disque (et mémoire?) plus importante, je pencherais pour -Os -march=athlon-xp -pipe -fomit-frame-pointer (peut être -fpmath=sse). Et LDFLAGS=-s , si possible.
voici ce que me donne cat /proc/cpuinfo:
processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 6 model name : AMD Athlon(tm) XP 2000+ stepping : 2 cpu MHz : 1666.932 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3d nowext 3dnow bogomips : 3301.37 Je suppose qu'il faut comprendre -mfpmath=sse à la place de -fpmath=sse
Avec ces falgs, puis-je ajouter d'autre options ? Pourriez-vous m'expliquer à quoi servent -funroll-loops et -fomit-frame-pointer, ou -momit-leaf-frame-pointer car la doc de gcc m'est peu claire ? -- @+ billiob Utilisateur de Linux n°342916 Enregistrez-vous sur http:counter.li.org !! Remplaçez INVALID par swissinfo pour m'envoyer un mail.
Jerome Lambert
billiob wrote: (...)
Je suppose qu'il faut comprendre -mfpmath=sse à la place de -fpmath=sse Avec ces falgs, puis-je ajouter d'autre options ? Pourriez-vous m'expliquer à quoi servent -funroll-loops et
C'est l'option la plus discutée dans les optimisations... ;-)
-funroll-loops déroule les boucles dont on connait par avance le nombre de fois que l'opération se répète.
Ainsi, la boucle suivante exécute les instructions 10 fois: pour i de 1 à 10 faire <instructions> fin_pour
optimisée, elle devient une répétition bout à bout:
<instructions> <instructions> ... <instructions>
Cela évite quelques opérations, comme l'incrémentation du i, le test pour savoir si on continue ou si on arrète, etc.
Le problème est que cela ne marche que pour des boucles dont on connait par avance le nombre d'itérations (10 dans l'exemple), ce qui est assez rare. De même, le code généré est plus volumineux, donc il arrive que le gain de vitesse soit perdu par la lourdeur du code, donc bof. Il faut tester et voire si cela vaut la peine.
(...)
billiob wrote:
(...)
Je suppose qu'il faut comprendre -mfpmath=sse à la place de -fpmath=sse
Avec ces falgs, puis-je ajouter d'autre options ?
Pourriez-vous m'expliquer à quoi servent -funroll-loops et
C'est l'option la plus discutée dans les optimisations... ;-)
-funroll-loops déroule les boucles dont on connait par avance le nombre
de fois que l'opération se répète.
Ainsi, la boucle suivante exécute les instructions 10 fois:
pour i de 1 à 10 faire
<instructions>
fin_pour
optimisée, elle devient une répétition bout à bout:
<instructions>
<instructions>
...
<instructions>
Cela évite quelques opérations, comme l'incrémentation du i, le test
pour savoir si on continue ou si on arrète, etc.
Le problème est que cela ne marche que pour des boucles dont on connait
par avance le nombre d'itérations (10 dans l'exemple), ce qui est assez
rare. De même, le code généré est plus volumineux, donc il arrive que le
gain de vitesse soit perdu par la lourdeur du code, donc bof. Il faut
tester et voire si cela vaut la peine.
Je suppose qu'il faut comprendre -mfpmath=sse à la place de -fpmath=sse Avec ces falgs, puis-je ajouter d'autre options ? Pourriez-vous m'expliquer à quoi servent -funroll-loops et
C'est l'option la plus discutée dans les optimisations... ;-)
-funroll-loops déroule les boucles dont on connait par avance le nombre de fois que l'opération se répète.
Ainsi, la boucle suivante exécute les instructions 10 fois: pour i de 1 à 10 faire <instructions> fin_pour
optimisée, elle devient une répétition bout à bout:
<instructions> <instructions> ... <instructions>
Cela évite quelques opérations, comme l'incrémentation du i, le test pour savoir si on continue ou si on arrète, etc.
Le problème est que cela ne marche que pour des boucles dont on connait par avance le nombre d'itérations (10 dans l'exemple), ce qui est assez rare. De même, le code généré est plus volumineux, donc il arrive que le gain de vitesse soit perdu par la lourdeur du code, donc bof. Il faut tester et voire si cela vaut la peine.
(...)
no_spam
On Mon, 22 Nov 2004 20:33:54 +0100, billiob wrote:
[cut]
* Comment remplir la variable CFLAGS pour mon architecture (je pensais mettre -O2 -march=athlon-xp -pipe ) ?
En lisant le manuel de gcc, je dirais -O3 -march=athlon-xp -pipe -funroll-loops -fomit-frame-pointer
et puis un petit coup de cat /proc/cpuinfo pour voir ce que l'on peut activer (sse, 3dnow, etc.), mais les pros me corrigeront.
Pas pro, mais de mon point de vue -O3 ne semble pas apporter grand chose mis a part une occupation disque (et mémoire?) plus importante, je pencherais pour -Os -march=athlon-xp -pipe -fomit-frame-pointer (peut être -fpmath=sse). Et LDFLAGS=-s , si possible.
-Os génère du code optimisé pour la taille, généralement lent (beaucoup de sauts et d'appels de fonction, pas d'inlining, ...). -O3 est souvent buggé (et oui !). Un bon compromis est -O2 -fexpensive-optimisations Le '-fomit-frame-pointer' est à utiliser avec circonspection car il empêche le debug et est complètement inadapté pour les libs de développement.
voici ce que me donne cat /proc/cpuinfo:
processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 6 model name : AMD Athlon(tm) XP 2000+ stepping : 2 cpu MHz : 1666.932 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3d nowext 3dnow bogomips : 3301.37 Je suppose qu'il faut comprendre -mfpmath=sse à la place de -fpmath=sse
Avec ces falgs, puis-je ajouter d'autre options ?
Pas besoin, -march=athlon-xp indique déjà celà.
Pourriez-vous m'expliquer à quoi servent -funroll-loops et -fomit-frame-pointer, ou -momit-leaf-frame-pointer car la doc de gcc m'est peu claire ?
-funroll-loops: gcc essaye d'optimiser les boucles en les déroulant: par ex, si tu fait une boucle pour mettre la mémoire à zéro octet par octet, il se rendra compte qu'il peut faire ça de façon beaucoup plus sioux (c'est un exemple simplifié puisque memset est de toute façon précompilé dans la libgcc...). -fomit-frame-pointer: habituellement, les programmes gardent un pointeur contenant l'adresse de la pile à l'entrée d'une fonction, ce qu'on appelle la frame. C'est un peu embêtant car le i86 a très peu de registres. Donc, cette option permet d'utiliser ce registre pour autre chose. En contrepartie, ça peut compliquer un peu les fins de fonctions puisque la restauration de la pile peut devenir non triviale et ça peut empêcher le bon fonctionnement d'un débuggueur, qui a généralement besoin de connaitre la frame pour savoir comment on est arrivé là ou on est et ou sont stockées les variables locales. -momit-leaf-frame-pointer est la même chose que -fomit-frame-pointer mais uniquement sur les fonctions terminales, c'est à dire celles qui n'appellent pas d'autre fonction.
On Mon, 22 Nov 2004 20:33:54 +0100, billiob wrote:
[cut]
* Comment remplir la variable CFLAGS pour mon architecture (je pensais
mettre -O2 -march=athlon-xp -pipe ) ?
En lisant le manuel de gcc, je dirais -O3 -march=athlon-xp -pipe
-funroll-loops -fomit-frame-pointer
et puis un petit coup de cat /proc/cpuinfo pour voir ce que l'on peut
activer (sse, 3dnow, etc.), mais les pros me corrigeront.
Pas pro, mais de mon point de vue -O3 ne semble pas apporter grand chose
mis a part une occupation disque (et mémoire?) plus importante, je
pencherais pour -Os -march=athlon-xp -pipe -fomit-frame-pointer (peut
être -fpmath=sse). Et LDFLAGS=-s , si possible.
-Os génère du code optimisé pour la taille, généralement lent
(beaucoup de sauts et d'appels de fonction, pas d'inlining, ...).
-O3 est souvent buggé (et oui !).
Un bon compromis est -O2 -fexpensive-optimisations
Le '-fomit-frame-pointer' est à utiliser avec circonspection car il
empêche le debug et est complètement inadapté pour les libs de
développement.
voici ce que me donne cat /proc/cpuinfo:
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 6
model name : AMD Athlon(tm) XP 2000+
stepping : 2
cpu MHz : 1666.932
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3d nowext 3dnow
bogomips : 3301.37
Je suppose qu'il faut comprendre -mfpmath=sse à la place de -fpmath=sse
Avec ces falgs, puis-je ajouter d'autre options ?
Pas besoin, -march=athlon-xp indique déjà celà.
Pourriez-vous m'expliquer à quoi servent -funroll-loops et
-fomit-frame-pointer, ou -momit-leaf-frame-pointer car la doc de gcc
m'est peu claire ?
-funroll-loops: gcc essaye d'optimiser les boucles en les déroulant:
par ex, si tu fait une boucle pour mettre la mémoire à zéro octet par
octet, il se rendra compte qu'il peut faire ça de façon beaucoup plus
sioux (c'est un exemple simplifié puisque memset est de toute façon
précompilé dans la libgcc...).
-fomit-frame-pointer: habituellement, les programmes gardent un pointeur
contenant l'adresse de la pile à l'entrée d'une fonction, ce qu'on
appelle la frame. C'est un peu embêtant car le i86 a très peu de
registres. Donc, cette option permet d'utiliser ce registre pour autre
chose. En contrepartie, ça peut compliquer un peu les fins de fonctions
puisque la restauration de la pile peut devenir non triviale et ça peut
empêcher le bon fonctionnement d'un débuggueur, qui a généralement
besoin de connaitre la frame pour savoir comment on est arrivé là ou on
est et ou sont stockées les variables locales.
-momit-leaf-frame-pointer est la même chose que -fomit-frame-pointer mais
uniquement sur les fonctions terminales, c'est à dire celles qui
n'appellent pas d'autre fonction.
On Mon, 22 Nov 2004 20:33:54 +0100, billiob wrote:
[cut]
* Comment remplir la variable CFLAGS pour mon architecture (je pensais mettre -O2 -march=athlon-xp -pipe ) ?
En lisant le manuel de gcc, je dirais -O3 -march=athlon-xp -pipe -funroll-loops -fomit-frame-pointer
et puis un petit coup de cat /proc/cpuinfo pour voir ce que l'on peut activer (sse, 3dnow, etc.), mais les pros me corrigeront.
Pas pro, mais de mon point de vue -O3 ne semble pas apporter grand chose mis a part une occupation disque (et mémoire?) plus importante, je pencherais pour -Os -march=athlon-xp -pipe -fomit-frame-pointer (peut être -fpmath=sse). Et LDFLAGS=-s , si possible.
-Os génère du code optimisé pour la taille, généralement lent (beaucoup de sauts et d'appels de fonction, pas d'inlining, ...). -O3 est souvent buggé (et oui !). Un bon compromis est -O2 -fexpensive-optimisations Le '-fomit-frame-pointer' est à utiliser avec circonspection car il empêche le debug et est complètement inadapté pour les libs de développement.
voici ce que me donne cat /proc/cpuinfo:
processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 6 model name : AMD Athlon(tm) XP 2000+ stepping : 2 cpu MHz : 1666.932 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3d nowext 3dnow bogomips : 3301.37 Je suppose qu'il faut comprendre -mfpmath=sse à la place de -fpmath=sse
Avec ces falgs, puis-je ajouter d'autre options ?
Pas besoin, -march=athlon-xp indique déjà celà.
Pourriez-vous m'expliquer à quoi servent -funroll-loops et -fomit-frame-pointer, ou -momit-leaf-frame-pointer car la doc de gcc m'est peu claire ?
-funroll-loops: gcc essaye d'optimiser les boucles en les déroulant: par ex, si tu fait une boucle pour mettre la mémoire à zéro octet par octet, il se rendra compte qu'il peut faire ça de façon beaucoup plus sioux (c'est un exemple simplifié puisque memset est de toute façon précompilé dans la libgcc...). -fomit-frame-pointer: habituellement, les programmes gardent un pointeur contenant l'adresse de la pile à l'entrée d'une fonction, ce qu'on appelle la frame. C'est un peu embêtant car le i86 a très peu de registres. Donc, cette option permet d'utiliser ce registre pour autre chose. En contrepartie, ça peut compliquer un peu les fins de fonctions puisque la restauration de la pile peut devenir non triviale et ça peut empêcher le bon fonctionnement d'un débuggueur, qui a généralement besoin de connaitre la frame pour savoir comment on est arrivé là ou on est et ou sont stockées les variables locales. -momit-leaf-frame-pointer est la même chose que -fomit-frame-pointer mais uniquement sur les fonctions terminales, c'est à dire celles qui n'appellent pas d'autre fonction.
TiChou
Dans le message <news:41a228b9$0$3363$, *billiob* tapota sur f.c.o.l.configuration :
Auriez-vous une petite doc pour savoir quoi mettre dans la variable cflags ?
Mais boouuuuh, il n'y a pas les options pour Amd64... :-(
Merci d'avoir pris de votre temps pour m'avoir lu.
De rien et bienvenue dans ce monde merveilleux qu'est la Gentoo. :-)
Merci bien...
no_spam
On Tue, 23 Nov 2004 00:33:47 +0100, Jerome Lambert wrote:
billiob wrote: (...)
Je suppose qu'il faut comprendre -mfpmath=sse à la place de -fpmath=sse Avec ces falgs, puis-je ajouter d'autre options ? Pourriez-vous m'expliquer à quoi servent -funroll-loops et
C'est l'option la plus discutée dans les optimisations... ;-)
-funroll-loops déroule les boucles dont on connait par avance le nombre de fois que l'opération se répète.
Ainsi, la boucle suivante exécute les instructions 10 fois: pour i de 1 à 10 faire <instructions> fin_pour
optimisée, elle devient une répétition bout à bout:
<instructions> <instructions> ... <instructions>
Cela évite quelques opérations, comme l'incrémentation du i, le test pour savoir si on continue ou si on arrète, etc.
Le problème est que cela ne marche que pour des boucles dont on connait par avance le nombre d'itérations (10 dans l'exemple), ce qui est assez rare. De même, le code généré est plus volumineux, donc il arrive que le gain de vitesse soit perdu par la lourdeur du code, donc bof. Il faut tester et voire si cela vaut la peine.
Ca n'optimise pas uniquement les boucles dont on connait le nombre d'itération à l'avance. Il y a pas mal d'autres cas qui peuvent être optimisés en testant en début de boucle si le nombre d'itération correspond à des critères particuliers. Le code généré est plus volumineux mal il est rare qu'on y perde en vitesse, à moins d'avoir un CPU avec des caches extrèmement petits: quand on a une boucle dont la vitesse d'execution est critique, il vaut mieux s'assurer qu'elle ne soit jamais éjectée du cache durant son execution.
On Tue, 23 Nov 2004 00:33:47 +0100, Jerome Lambert wrote:
billiob wrote:
(...)
Je suppose qu'il faut comprendre -mfpmath=sse à la place de -fpmath=sse
Avec ces falgs, puis-je ajouter d'autre options ?
Pourriez-vous m'expliquer à quoi servent -funroll-loops et
C'est l'option la plus discutée dans les optimisations... ;-)
-funroll-loops déroule les boucles dont on connait par avance le nombre
de fois que l'opération se répète.
Ainsi, la boucle suivante exécute les instructions 10 fois:
pour i de 1 à 10 faire
<instructions>
fin_pour
optimisée, elle devient une répétition bout à bout:
<instructions>
<instructions>
...
<instructions>
Cela évite quelques opérations, comme l'incrémentation du i, le test
pour savoir si on continue ou si on arrète, etc.
Le problème est que cela ne marche que pour des boucles dont on connait
par avance le nombre d'itérations (10 dans l'exemple), ce qui est assez
rare. De même, le code généré est plus volumineux, donc il arrive que le
gain de vitesse soit perdu par la lourdeur du code, donc bof. Il faut
tester et voire si cela vaut la peine.
Ca n'optimise pas uniquement les boucles dont on connait le nombre
d'itération à l'avance. Il y a pas mal d'autres cas qui peuvent être
optimisés en testant en début de boucle si le nombre d'itération
correspond à des critères particuliers. Le code généré est plus
volumineux mal il est rare qu'on y perde en vitesse, à moins d'avoir un
CPU avec des caches extrèmement petits: quand on a une boucle dont la
vitesse d'execution est critique, il vaut mieux s'assurer qu'elle ne soit
jamais éjectée du cache durant son execution.
On Tue, 23 Nov 2004 00:33:47 +0100, Jerome Lambert wrote:
billiob wrote: (...)
Je suppose qu'il faut comprendre -mfpmath=sse à la place de -fpmath=sse Avec ces falgs, puis-je ajouter d'autre options ? Pourriez-vous m'expliquer à quoi servent -funroll-loops et
C'est l'option la plus discutée dans les optimisations... ;-)
-funroll-loops déroule les boucles dont on connait par avance le nombre de fois que l'opération se répète.
Ainsi, la boucle suivante exécute les instructions 10 fois: pour i de 1 à 10 faire <instructions> fin_pour
optimisée, elle devient une répétition bout à bout:
<instructions> <instructions> ... <instructions>
Cela évite quelques opérations, comme l'incrémentation du i, le test pour savoir si on continue ou si on arrète, etc.
Le problème est que cela ne marche que pour des boucles dont on connait par avance le nombre d'itérations (10 dans l'exemple), ce qui est assez rare. De même, le code généré est plus volumineux, donc il arrive que le gain de vitesse soit perdu par la lourdeur du code, donc bof. Il faut tester et voire si cela vaut la peine.
Ca n'optimise pas uniquement les boucles dont on connait le nombre d'itération à l'avance. Il y a pas mal d'autres cas qui peuvent être optimisés en testant en début de boucle si le nombre d'itération correspond à des critères particuliers. Le code généré est plus volumineux mal il est rare qu'on y perde en vitesse, à moins d'avoir un CPU avec des caches extrèmement petits: quand on a une boucle dont la vitesse d'execution est critique, il vaut mieux s'assurer qu'elle ne soit jamais éjectée du cache durant son execution.
Michel Tatoute
Le Sun, 21 Nov 2004 22:42:03 +0100, Jerome Lambert a écrit :
(C'est limite débats, mais je préfère d'abord une réponse *technique*)
Bonsoir,
Coutumier des distributions binaires, je me suis attelé ce week-end à l'installation d'une Gentoo 2004.3.
Avec le manuel, tout s'est bien passé (pas loin de 50h de compilation sur un P-3 450), mais j'ai été stupéfait par ... le nombre de warning lors de la compilation.
Ca y va, tu as raison
Est-ce normal, et ont-ils une incidence sur le bon fonctionnement des programmes? Je pense notamment aux avertissements concernant une comparaison entre pointeur et entier sans cast de celui-ci, ce qui, si mes souvenirs sont bons, n'est pas une manière "propre" de travailler, ou encore aux messages avertissant de l'utilisation de variable non initialisées.
Pour la comparaison de pointeurs/entiers c'est pas terrible, mais c'est parfois tres difficile à chercher. Surtout quand tu developpe de manière générique.
Les fonctions des librairies que tu utilise peuvent avoir une interface changeante.
Pour les variables non initialisées, malheureusement gcc est un peu trop généreux... Parfois il se laisse emporter par un graphe excessif:
int f(int a) { int i; switch(a) { default: i=0; } return i; }
en general ce code annonce que i n'est pas initialisé... bien à tort. Si des questions de perf interdisent d'initialiser i au départ, il faut vivre avec le warning. Les prozelites (hum) du 0 warning diront que le compilateur va éliminer l'init inutile en optimisant... mais c'est justement par ce que il n'a pas vu l'inutilité qu'il va le laisser.
Sans critiqiue excessive, ajourd'hui (il y a peu en tout cas ) gcc n'est pas tip top sur les warnings.
J'ai un peu d'expérience en programmation, et je me souviens que c'était le genre de messages qui faisait sauter mon prof au plafond, d'où mon inquiétude.
Merci de vos éclaircissements,
de rien.
Jérôme. Michel.
Le Sun, 21 Nov 2004 22:42:03 +0100, Jerome Lambert a écrit :
(C'est limite débats, mais je préfère d'abord une réponse *technique*)
Bonsoir,
Coutumier des distributions binaires, je me suis attelé ce week-end à
l'installation d'une Gentoo 2004.3.
Avec le manuel, tout s'est bien passé (pas loin de 50h de compilation
sur un P-3 450), mais j'ai été stupéfait par ... le nombre de warning
lors de la compilation.
Ca y va, tu as raison
Est-ce normal, et ont-ils une incidence sur le bon fonctionnement des
programmes? Je pense notamment aux avertissements concernant une
comparaison entre pointeur et entier sans cast de celui-ci, ce qui, si
mes souvenirs sont bons, n'est pas une manière "propre" de travailler,
ou encore aux messages avertissant de l'utilisation de variable non
initialisées.
Pour la comparaison de pointeurs/entiers c'est pas terrible, mais c'est
parfois tres difficile à chercher. Surtout quand tu developpe de manière
générique.
Les fonctions des librairies que tu utilise peuvent avoir une interface
changeante.
Pour les variables non initialisées, malheureusement gcc est un peu trop
généreux... Parfois il se laisse emporter par un graphe excessif:
int f(int a)
{
int i;
switch(a) {
default:
i=0;
}
return i;
}
en general ce code annonce que i n'est pas initialisé... bien à tort. Si
des questions de perf interdisent d'initialiser i au départ, il faut
vivre avec le warning. Les prozelites (hum) du 0 warning diront que le
compilateur va éliminer l'init inutile en optimisant... mais c'est
justement par ce que il n'a pas vu l'inutilité qu'il va le laisser.
Sans critiqiue excessive, ajourd'hui (il y a peu en tout cas ) gcc n'est
pas tip top sur les warnings.
J'ai un peu d'expérience en programmation, et je me souviens que c'était
le genre de messages qui faisait sauter mon prof au plafond, d'où mon
inquiétude.
Le Sun, 21 Nov 2004 22:42:03 +0100, Jerome Lambert a écrit :
(C'est limite débats, mais je préfère d'abord une réponse *technique*)
Bonsoir,
Coutumier des distributions binaires, je me suis attelé ce week-end à l'installation d'une Gentoo 2004.3.
Avec le manuel, tout s'est bien passé (pas loin de 50h de compilation sur un P-3 450), mais j'ai été stupéfait par ... le nombre de warning lors de la compilation.
Ca y va, tu as raison
Est-ce normal, et ont-ils une incidence sur le bon fonctionnement des programmes? Je pense notamment aux avertissements concernant une comparaison entre pointeur et entier sans cast de celui-ci, ce qui, si mes souvenirs sont bons, n'est pas une manière "propre" de travailler, ou encore aux messages avertissant de l'utilisation de variable non initialisées.
Pour la comparaison de pointeurs/entiers c'est pas terrible, mais c'est parfois tres difficile à chercher. Surtout quand tu developpe de manière générique.
Les fonctions des librairies que tu utilise peuvent avoir une interface changeante.
Pour les variables non initialisées, malheureusement gcc est un peu trop généreux... Parfois il se laisse emporter par un graphe excessif:
int f(int a) { int i; switch(a) { default: i=0; } return i; }
en general ce code annonce que i n'est pas initialisé... bien à tort. Si des questions de perf interdisent d'initialiser i au départ, il faut vivre avec le warning. Les prozelites (hum) du 0 warning diront que le compilateur va éliminer l'init inutile en optimisant... mais c'est justement par ce que il n'a pas vu l'inutilité qu'il va le laisser.
Sans critiqiue excessive, ajourd'hui (il y a peu en tout cas ) gcc n'est pas tip top sur les warnings.
J'ai un peu d'expérience en programmation, et je me souviens que c'était le genre de messages qui faisait sauter mon prof au plafond, d'où mon inquiétude.
Merci de vos éclaircissements,
de rien.
Jérôme. Michel.
billiob
Dans le message <news:41a228b9$0$3363$, *billiob* tapota sur f.c.o.l.configuration :
Auriez-vous une petite doc pour savoir quoi mettre dans la variable cflags ?
Merci d'avoir pris de votre temps pour m'avoir lu.
De rien et bienvenue dans ce monde merveilleux qu'est la Gentoo. :-)
Merci tout le monde, je l'installerais ce week-end !
-- @+ billiob Utilisateur de Linux n°342916 Enregistrez-vous sur http:counter.li.org !! Remplaçez INVALID par swissinfo pour m'envoyer un mail.
Sebastien Kirche
Le 21 nov 2004, Jerome Lambert a formulé :
Salut Jérôme,
En effet, c'est assez stupéfiant d'avoir un P-III 450/128Mo à peine moins réactif qu'un Athlon64 3000+/1Go, le premier avec une Gentoo, le second avec une Fedora Core 3 Amd64.
Troll à part, ça vaut *vraiment* le coup de se taper la compilation de *tout* ? La machine est à ce point réactive ?
Je vois que l'architecture Sparc est supportée, ça pourrait redonner un coup de fouet à ma chère SS20 (bi-75) ?
Vu que c'est ma passerelle et que ça m'embêterait de la couper trop longtemps je me demande si je peux envisager la cross-compilation ?
Sébastien Kirche
Le 21 nov 2004, Jerome Lambert a formulé :
Salut Jérôme,
En effet, c'est assez stupéfiant d'avoir un P-III 450/128Mo à peine
moins réactif qu'un Athlon64 3000+/1Go, le premier avec une Gentoo, le
second avec une Fedora Core 3 Amd64.
Troll à part, ça vaut *vraiment* le coup de se taper la compilation de
*tout* ? La machine est à ce point réactive ?
Je vois que l'architecture Sparc est supportée, ça pourrait redonner un coup
de fouet à ma chère SS20 (bi-75) ?
Vu que c'est ma passerelle et que ça m'embêterait de la couper trop
longtemps je me demande si je peux envisager la cross-compilation ?
En effet, c'est assez stupéfiant d'avoir un P-III 450/128Mo à peine moins réactif qu'un Athlon64 3000+/1Go, le premier avec une Gentoo, le second avec une Fedora Core 3 Amd64.
Troll à part, ça vaut *vraiment* le coup de se taper la compilation de *tout* ? La machine est à ce point réactive ?
Je vois que l'architecture Sparc est supportée, ça pourrait redonner un coup de fouet à ma chère SS20 (bi-75) ?
Vu que c'est ma passerelle et que ça m'embêterait de la couper trop longtemps je me demande si je peux envisager la cross-compilation ?
