Qui utilise ce compilo? Vos impressions par rapport a GCC
Le meme code source (en c) compilé avec GCC 4 sur G5 1.8 Ghtz (O3 -fast) est
20 % moins rapide que sur un Athlon 32 bits 1.8... Ghtz (O3
-fomit-frame...). Bizare non?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Schmurtz
Bruno CAUSSE wrote:
Bonsoir,
Qui utilise ce compilo? Vos impressions par rapport a GCC
Le meme code source (en c) compilé avec GCC 4 sur G5 1.8 Ghtz (O3 -fast) est 20 % moins rapide que sur un Athlon 32 bits 1.8... Ghtz (O3 -fomit-frame...). Bizare non?
La vitesse dépend de beaucoup de paramètres, ça dépendra donc beaucoup de ce que fait ton programme et comment il le fait.
Rajoute toujours -fomit-frame-pointer pour la compilation PPC.
Tu peux aussi tester l'auto-vectorisation : -ftree-vectorize -maltivec
Profiler le code avec shark permettra peut-être de trouver d'où vient cette différence de vitesse, qui peut-être due à une mauvaise manière de coder.
-- Schmurtz
Bruno CAUSSE <envoi@lesSpam.fr> wrote:
Bonsoir,
Qui utilise ce compilo? Vos impressions par rapport a GCC
Le meme code source (en c) compilé avec GCC 4 sur G5 1.8 Ghtz (O3 -fast) est
20 % moins rapide que sur un Athlon 32 bits 1.8... Ghtz (O3
-fomit-frame...). Bizare non?
La vitesse dépend de beaucoup de paramètres, ça dépendra donc beaucoup
de ce que fait ton programme et comment il le fait.
Rajoute toujours -fomit-frame-pointer pour la compilation PPC.
Tu peux aussi tester l'auto-vectorisation : -ftree-vectorize -maltivec
Profiler le code avec shark permettra peut-être de trouver d'où vient
cette différence de vitesse, qui peut-être due à une mauvaise manière de
coder.
Qui utilise ce compilo? Vos impressions par rapport a GCC
Le meme code source (en c) compilé avec GCC 4 sur G5 1.8 Ghtz (O3 -fast) est 20 % moins rapide que sur un Athlon 32 bits 1.8... Ghtz (O3 -fomit-frame...). Bizare non?
La vitesse dépend de beaucoup de paramètres, ça dépendra donc beaucoup de ce que fait ton programme et comment il le fait.
Rajoute toujours -fomit-frame-pointer pour la compilation PPC.
Tu peux aussi tester l'auto-vectorisation : -ftree-vectorize -maltivec
Profiler le code avec shark permettra peut-être de trouver d'où vient cette différence de vitesse, qui peut-être due à une mauvaise manière de coder.
-- Schmurtz
Bruno CAUSSE
dans l'article 432d5aad$0$17547$, Schmurtz à a écrit le 18/09/05 14:16 :
Profiler le code avec shark
Oui, j'experimente shark, pas tout piger encore (les options qui vont biens). Doit t'on profiler une release ou une debug, profiler une debug est t'il pertiment? Avec une release comment avoir des info comprehensibles?
permettra peut-être de trouver d'où vient cette différence de vitesse, qui peut-être due à une mauvaise manière de coder.
le code source est le MEME pas une virgule ne manque.
-- Bruno Causse http://perso.wanadoo.fr/othello
dans l'article 432d5aad$0$17547$626a14ce@news.free.fr, Schmurtz à
moi@ici.com a écrit le 18/09/05 14:16 :
Profiler le code avec shark
Oui, j'experimente shark, pas tout piger encore (les options qui vont
biens). Doit t'on profiler une release ou une debug, profiler une debug est
t'il pertiment? Avec une release comment avoir des info comprehensibles?
permettra peut-être de trouver d'où vient
cette différence de vitesse, qui peut-être due à une mauvaise manière de
coder.
le code source est le MEME pas une virgule ne manque.
dans l'article 432d5aad$0$17547$, Schmurtz à a écrit le 18/09/05 14:16 :
Profiler le code avec shark
Oui, j'experimente shark, pas tout piger encore (les options qui vont biens). Doit t'on profiler une release ou une debug, profiler une debug est t'il pertiment? Avec une release comment avoir des info comprehensibles?
permettra peut-être de trouver d'où vient cette différence de vitesse, qui peut-être due à une mauvaise manière de coder.
le code source est le MEME pas une virgule ne manque.
-- Bruno Causse http://perso.wanadoo.fr/othello
pmanet
Bruno CAUSSE wrote:
cette différence de vitesse, qui peut-être due à une mauvaise manière de coder.
le code source est le MEME pas une virgule ne manque.
ça ne veut rien dire... il n'y a pas que la compilation,il y a aussi la façon de gérer les flux de données qui peut être optimisée.
on ne travaille pas pareil avec des proc sans registres et pipeline long, ou avec registre, unités vectorielles et pipeline court. Et ce ne sont pas les options de compilation qui gèrent ça. -- Philippe Manet
Bruno CAUSSE <envoi@lesSpam.fr> wrote:
cette différence de vitesse, qui peut-être due à une mauvaise manière de
coder.
le code source est le MEME pas une virgule ne manque.
ça ne veut rien dire... il n'y a pas que la compilation,il y a aussi la
façon de gérer les flux de données qui peut être optimisée.
on ne travaille pas pareil avec des proc sans registres et pipeline
long, ou avec registre, unités vectorielles et pipeline court. Et ce ne
sont pas les options de compilation qui gèrent ça.
--
Philippe Manet
cette différence de vitesse, qui peut-être due à une mauvaise manière de coder.
le code source est le MEME pas une virgule ne manque.
ça ne veut rien dire... il n'y a pas que la compilation,il y a aussi la façon de gérer les flux de données qui peut être optimisée.
on ne travaille pas pareil avec des proc sans registres et pipeline long, ou avec registre, unités vectorielles et pipeline court. Et ce ne sont pas les options de compilation qui gèrent ça. -- Philippe Manet
Schmurtz
Bruno CAUSSE wrote:
dans l'article 432d5aad$0$17547$, Schmurtz à a écrit le 18/09/05 14:16 :
Profiler le code avec shark
Oui, j'experimente shark, pas tout piger encore (les options qui vont biens). Doit t'on profiler une release ou une debug, profiler une debug est t'il pertiment? Avec une release comment avoir des info comprehensibles?
Debug = sans optimisation (-O0) Release = avec toutes les optimisations utilisées
L'activation des symboles de déboggage n'a absolument aucun impact sur la vitesse d'execution.
Pour ce qui est de la recherche des zones sensibles (ie les fonctions consommant le plus de CPU), travailler sur une version release ou debug n'a pas beaucoup d'importance : la version debug ralenties légèrement, mais de manière assez uniforme.
Pour ce qui est de l'optimisation d'un algorithme, on peut aussi utiliser la version debug.
Pour ce qui est de l'optimisation d'implémentation(*) d'une fonction, il faut optimiser sur la version Release : ça n'a aucun sens d'optimiser manuellement du code avant de regarder ce que les compilateurs font.
(*) des optimisations de bouts de chandelle : utilisation d'assembleur, forcer l'utilisation de registres, optimiser l'organisation en mémoire, optimiser l'usage des caches L1 et L2, dérouler des boucles...
-- Schmurtz
Bruno CAUSSE <envoi@lesSpam.fr> wrote:
dans l'article 432d5aad$0$17547$626a14ce@news.free.fr, Schmurtz à
moi@ici.com a écrit le 18/09/05 14:16 :
Profiler le code avec shark
Oui, j'experimente shark, pas tout piger encore (les options qui vont
biens). Doit t'on profiler une release ou une debug, profiler une debug est
t'il pertiment? Avec une release comment avoir des info comprehensibles?
Debug = sans optimisation (-O0)
Release = avec toutes les optimisations utilisées
L'activation des symboles de déboggage n'a absolument aucun impact sur
la vitesse d'execution.
Pour ce qui est de la recherche des zones sensibles (ie les fonctions
consommant le plus de CPU), travailler sur une version release ou debug
n'a pas beaucoup d'importance : la version debug ralenties légèrement,
mais de manière assez uniforme.
Pour ce qui est de l'optimisation d'un algorithme, on peut aussi
utiliser la version debug.
Pour ce qui est de l'optimisation d'implémentation(*) d'une fonction, il
faut optimiser sur la version Release : ça n'a aucun sens d'optimiser
manuellement du code avant de regarder ce que les compilateurs font.
(*) des optimisations de bouts de chandelle : utilisation d'assembleur,
forcer l'utilisation de registres, optimiser l'organisation en mémoire,
optimiser l'usage des caches L1 et L2, dérouler des boucles...
dans l'article 432d5aad$0$17547$, Schmurtz à a écrit le 18/09/05 14:16 :
Profiler le code avec shark
Oui, j'experimente shark, pas tout piger encore (les options qui vont biens). Doit t'on profiler une release ou une debug, profiler une debug est t'il pertiment? Avec une release comment avoir des info comprehensibles?
Debug = sans optimisation (-O0) Release = avec toutes les optimisations utilisées
L'activation des symboles de déboggage n'a absolument aucun impact sur la vitesse d'execution.
Pour ce qui est de la recherche des zones sensibles (ie les fonctions consommant le plus de CPU), travailler sur une version release ou debug n'a pas beaucoup d'importance : la version debug ralenties légèrement, mais de manière assez uniforme.
Pour ce qui est de l'optimisation d'un algorithme, on peut aussi utiliser la version debug.
Pour ce qui est de l'optimisation d'implémentation(*) d'une fonction, il faut optimiser sur la version Release : ça n'a aucun sens d'optimiser manuellement du code avant de regarder ce que les compilateurs font.
(*) des optimisations de bouts de chandelle : utilisation d'assembleur, forcer l'utilisation de registres, optimiser l'organisation en mémoire, optimiser l'usage des caches L1 et L2, dérouler des boucles...
