salut,
j'ai réinstallé une gentoo récemment, et j'ai donc
été faire un petit tour sur le forum gentoo pour
me remettre à jour.
Tout en cliquant nonchalament, je suis tombé sur ce
post :
http://forums.gentoo.org/viewtopic-t-309752-start-0.html(...)
Que j'ai trouvé fort amusant, et qui rappellera à certains
de nombreux débats animés
bonne lecture
[ 1 ] Et oui Debian est optimisée pour 386
# Les optimisations de gcc, ça optimise _vraiment_ !
Posté par Christophe Merlet (site web personnel) . Évalué à 3.
Il est trés difficile de quantifier le gain de performance, mais voici les résultats de ma propre expérience :
Sur un Athlon XP 1900+ / 512 Mo de RAM
Debian/Ubuntu : dans mozilla, on fait défiler la page d'accueil de linuxfr de haut en bas le plus vite possible plusieurs dizaines de fois avec la souris et l'ascenseur => la barre de défilement n'arrive pas à suivre , le curseur prends de l'avance et on consomme 100% du CPU.
Idem pour les autres distrib installé sur mon pc genre Mandrake.
Gentoo avec "-03 -pipe -march=athlon-xp -ffast-math" : le meme test et le barre de défilement ne décroche pas d'un pixel du curseur de la souris et on ne consomme pas 100% du CPU.
L'ensemble du système est bien plus réactif, gnome-terminal est *beaucoup* plus rapide.
Autre exemple sur un iMac DV SE. C'est un PowerPC G3 à 400 MHz avec 384 Mo de RAM.
Le système est entièrement compilé à la mimine (c'est ma propre distribution) avec les bonnes optimisations lors de la compilation.
Mon mozilla est presque aussi rapide que le mozilla fourni pas une debian/ubuntu sur mon athlon.
Conclusion : Ne pas croire les esprits chagrin qui essaieront de vous faire croire que ça ne sert à rien d'optimiser la compilation d'une distrib sous pretexte qu'on ne gagne "même pas 5%". Le fait est qu'au final, on gagne vraiment a optimiser lors de la compilation. Mais il faut TOUT compiler de manière optimisé et pas seulement le kernel et la glibc.
[^] # Re: Les optimisations de gcc, ça optimise _vraiment_ !
Posté par Éric (site web personnel) . Évalué à 2.
Pire, le binaire Mozilla officiel (très générique) est plus rapide (nettement) que celui compilé sous ma gentoo avec toutes les optimisations et peu d'options activées.
Faut croire qu'il y a beaucoup d'expériences différentes. Pour moi l'intérêt de la gentoo ce n'est vraiment pas l'optimisation. J'ai tendance à dire que oui, on ne gagnera pas 5%, sauf que quelques paquets bien spécifiques type multimédia.
[^] # Re: Les optimisations de gcc, ça optimise _vraiment_ !
Posté par Christophe Fergeau . Évalué à 2.
Ca vaut vachement le coup de préciser que t'utilise -pipe dans tes flags de compil... Tu devrais aussi dire quel shell t'utilise pour lancer tes compils, ça doit avoir un impact très important sur la réactivité finale des applis.
[^] # Re: Les optimisations de gcc, ça optimise _vraiment_ !
Posté par nigaiden . Évalué à 2.
Pour info :
_ "-O3" des fois ça fait des trucs bizarres, "-O2" est recommandé.
_ "-pipe" sert à accelérer la compilation
_ "-ffast-math" fait aussi des trucs bizarres
[^] # Re: Les optimisations de gcc, ça optimise _vraiment_ !
Posté par Christophe Merlet (site web personnel) . Évalué à 2.
Maintenant dire que -03 ou -fast-math donne des résultats bizarres, je demande a voir. Je les utilise sur différentes machines, différentes architecture et j'ai jamais eu de problème.
si il y a des trucs "bizarre" a utiliser -03 ou -fast-math, alors c'est un bug de gcc ou de l'appli et ça se corrige.
Maintenant je ne fais que rapporter ma _propre expérience_. Et ce n'est pas quelqu'un qui ne fait que rapporter des on-dit qui me convaincra du contraire.
Juste pour infos, mon dépot de RPMs http://ftp.redfoxcenter.org/pub/RedFox/MyRPMs/(...)
qui n'est hélas pas à complètement à jour...
[^] # Re: Les optimisations de gcc, ça optimise _vraiment_ !
Posté par Calim' Héros (site web personnel) . Évalué à 2.
[^] # Re: Les optimisations de gcc, ça optimise _vraiment_ !
Posté par Stephane Marchesin (site web personnel) . Évalué à 2.
En fait, -ffast-math donne un comportement qui ne respecte pas le standard IEEE sur les calculs flottant, en particulier sur les nombre denormals (dénormaux ?) et infinis. Ce genre d'erreur peut se propager dans tout un calcul et même passer totalement inaperçue et mener à des résultats erronés.
Et il ne s'agit pas là d'un bug dans un programme. L'application attend un certain standard dont elle a besoin pour tourner correctement et il faut que le compilateur le respecte.
[^] # Re: Les optimisations de gcc, ça optimise _vraiment_ !
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
-02 -fomit-frame-pointer -funroll-all-loops -march=athlon-xp -msse2,x87
(je ne suis pas sur du -msse2,x87 mais il existe une option pour l'ui dire d'utiliser du sse2 pour la partie flottante)
"La première sécurité est la liberté"
[^] # Re: Les optimisations de gcc, ça optimise _vraiment_ !
Posté par Christophe Merlet (site web personnel) . Évalué à 2.
-funroll-all-loops me fait un peu peur. Je me demande si il ne vaut pas mieux laisser gcc décider de lui meme si il faut dérouler les boucles ou non. mais bon faut tester pour voir ce que ça donne globalement.
concernant sse2, je ne crois pas que les athlon-xp en soit doté, en tous cas pas le mien :((
Il me semble que sse2 n'est apparu chez amd que sur les Athlon 64.
mais sinon, utiliser mmx ou sse pour les calculs flottants me semble être une idée interessante a creuser si ce n'est pas pris en compte automatiquement par gcc.
[^] # Re: Les optimisations de gcc, ça optimise _vraiment_ !
Posté par Calim' Héros (site web personnel) . Évalué à 3.
[^] # Re: Les optimisations de gcc, ça optimise _vraiment_ !
Posté par Christophe Fergeau . Évalué à 2.
[^] # Re: Les optimisations de gcc, ça optimise _vraiment_ !
Posté par Christophe Merlet (site web personnel) . Évalué à 1.
-mfpmath=387 , -mfpmath=sse ou -mfpmath=sse,387
A ce propos, j'ai trouvé un test particulièrement pointu pour juger de la précision et conformité des calculs mathèmatiques
http://www.netlib.org/paranoia/paranoia.c(...)
et un long threads _serieux_ sur les effets des differentes options de compilation et d'optimisation de gcc. http://gcc.gnu.org/ml/gcc/2004-03/msg01468.html(...)
Apres avoir faits mes propres tests et testé mes propres combinaisons sur un athlon-xp et sur un P4 avec differents compilo, j'ai constaté, tout comme dans le thread, que l'utilisation de -ffast-math n'était pas préjudiciable si il est associé avec d'autres bons flags. De meme que l'utilisation seul de -Ox peut aussi être catastrophique sur la précision des calculs mathèmatiques.
Faites vos propre tests et jugez par vous-même...
[^] # Re: Les optimisations de gcc, ça optimise _vraiment_ !
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Les optimisations de gcc, ça optimise _vraiment_ !
Posté par fabb . Évalué à 0.
Ben pourquoi tu ne donnes pas les résultats d'une bench sur gnome-terminal ?
Ne réponds pas, je sais déjà.
Chez Red Hat (qui s'y connais beaucoup plus en compilateur que Gentoo) recompiler l'ensemple de la distribution au détriment de la compatibilité donne un gain insignifiant (moins de 1 %). Pour les paquets où il y a un gain significatif, ils sont fournis en plusieurs versions (actuellement, le noyau, la libc, et openssl).
La voie où il y a quelques espoirs de gain est l'utilisation de "-Os". Oui, un noyau compilé en optimisant la taille tourne plus vite qu'avec "-O999". Ce qui n'a pas été fait, c'est de faire un test sur l'ensemble de la distribution. Si ce test existe, je suis preneur de toute information.
Je me pique toujours de voir des gentooistes défendre l'intérêt d'optimiser les FLAGS alors qu'ils n'ont rien démontré. Pour les lib particulières où un gain existe, il y a [usr]/lib/tls/cpu.
Gentoo est beaucoup plus intéressante pour d'autres qualités que pour l'effet placébot de choisir son CFLAGS.
[^] # Re: Les optimisations de gcc, ça optimise _vraiment_ !
Posté par Calim' Héros (site web personnel) . Évalué à 2.
Mais globalement [et pour mon utilisation] je trouve cette distribution bien intégré, stable et facile.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.