Tous les développeurs de la terre (dans l'espace, c'est parfois différent, surtout dans l'espace intersidéral, mais ce n'est le sujet de ce journal), ou presque, aime les performances.
Or, gcc permet beaucoup, même si il est parfois difficile de choisir quel type d'optimisation utiliser. Et c'est ainsi que le site [http://www.linux-mag.com/id/7574/1/] nous propose un beau comparatif de systèmes compilés utilisant des degrés d'optimisations divers pour identifier leurs performances.
Par forcement représentatif de la réalité, ce test grandeur nature nous permet de voir quelques petites choses assez intéressantes.
Ainsi, nous avons 3 systèmes gentoo tournant avec les mêmes logiciels, ainsi que sur le même matériel, mais compilé avec les options -Os (O2 + size optimisation), -O2 et -O3. A titre de comparaison pas forcement pertinent, nous avons un système Ubuntu 9.04 avec un kernel plus vieux (2.28 vs 2.30), un java différent, et X.org différent, et des drivers nvidia différents, mais utilisant gcc 4.3.3 comme gentoo.
Si certains résultats sont très proche, quelque soit le système ou l'optimisation, il est intéressant de noter que certains écarts sont véritablement important et significatif. Les résultats proche semblent (je n'en sait rien) être plus limité au niveau disque dur (les I/O sont plus importantes) que calculs.
mencoder par exemple, est presque deux fois plus rapide avec les optimisations core2 et le nouveau kernel alors que les optimisations de gcc ne lui apporte pas grand chose.
Ce qui, de mon coté, m'a le plus étonné, c'est que -O3 est souvent plus lent que -O2, et que ce même -O2, même si c'est le plus efficace, est parfois battu par un -Os, alors que ce dernier n'utilise pas toutes les optimisations (C'est un -O2 sans -falign-functions -falign-jumps -falign-loops -falign-labels -freorder-blocks -freorder-blocks-and-partition -fprefetch-loop-arrays -ftree-vect-loop-version).
Donc dans ce cas, est-ce le cache qui joue un rôle important? (Les différences sont en effet assez importante, lorsque -Os est efficace. D'ailleurs, dans ce cas, les optimisations en -O3 sont souvent les pire.
Bonne lecture à tous.
Journal Linux, Gentoo, et gcc dans un bateau...
5
nov.
2009
# Question
Posté par nyarla . Évalué à 10.
Désolé.
[^] # Re: Question
Posté par Tiwaz . Évalué à 0.
On remarque donc que gcc n'arrive pas à faire correctement son travail d'analyse de code, et se rendre compte que ce dernier, trop gros, amputera les performances.
Ce n'est que mon avis.
[^] # Re: Question
Posté par Snarky . Évalué à 7.
[^] # Re: Question
Posté par M . Évalué à 2.
Ben le pb, c'est que gcc a tendance a inline a fond en -O3 et qui est nefaste pour les caches.
[^] # Re: Question
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
# A chaud.
Posté par hocwp (site web personnel) . Évalué à 2.
> un kernel plus vieux (2.28 vs 2.30), un java différent, et X.org différent, et des drivers
> nvidia différents, mais utilisant gcc 4.3.3 comme gentoo.
>
C'est fait sur la même machine au moins ? :)
[^] # Re: A chaud.
Posté par Mathieu Schroeter (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: A chaud.
Posté par M . Évalué à 5.
Tu as des sources ?
Au dernière nouvelle -g n'ajoute que des symboles de debug, et ne modifie pas les optimisation.
Par contre ubuntu on tendance a compiler avec -fstack-protector qui n'est pas transparent.
[^] # Re: A chaud.
Posté par Mathieu Schroeter (site web personnel, Mastodon) . Évalué à 2.
Quand je parle de temps c'est des ordres de grandeur dans les centaines de millisecondes. Ça date de longtemps (quelques années) je n'ai plus trop les valeurs en tête.
Mais je n'ai pas de documents pour appuyer mes dires.
# dbench
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
+100% !
http://s.linux-mag.com/i/articles/7574/14-gentoo-optimizatio(...)
Ici, c'est 10% + rapide en -Os:
http://s.linux-mag.com/i/articles/7574/31-gentoo-optimizatio(...)
"La première sécurité est la liberté"
[^] # Re: dbench
Posté par Ontologia (site web personnel) . Évalué à 6.
Le débat porte donc sur le fait que code plus court = code tenant mieux dans le cache code du processeur, donc meilleur exécution...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: dbench
Posté par Ontologia (site web personnel) . Évalué à 5.
Si la boucle critique tiens dans le cache, alors -O3 peut être meilleur
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: dbench
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Des générations entières de programmeurs Fortran à la belle époque te remercie d'avoir rappelé le lien fort entre optimisations et matériel, notamment taille des caches du processeur.
--
Axioplase, qui avait eu un TP sur l'optimisation de code fortran dans un cours orienté compilation et matériel ^^
[^] # Re: dbench
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
C'est un peu évident, non ?
"La première sécurité est la liberté"
[^] # Re: dbench
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
Évidemment, ça dépend de l'industrie dans laquelle tu travailles (et pour avoir lu ton parcours, je me doute bien qu'à toi, ça te parait évident), mais c'est à mon avis une évidence et un critère de développement pour moins de la moité des programmeurs.
D'autant plus que ce sont des optimisations qui ne sont pas forcément algorithmiques et qui ne sont valides que dans certains langages bas-niveau…
[^] # Re: dbench
Posté par lasher . Évalué à 4.
[^] # Re: dbench
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Une fois que tu as le bon algo, tu peux optimiser. L'implémentation doit permettre un gain de x10 maximum, c'est moins que l'algo mais c'est tout de même à prendre :)
"La première sécurité est la liberté"
[^] # Re: dbench
Posté par khivapia . Évalué à 7.
Pour illustrer ça, voici deux codes qui calculent exactement la même chose (un crible d'Eratosthene, un des plus anciens algorithmes s'il en est :-) D'un point de vue algorithmique tout se passe de la même façon, d'un point de vue calculs ils sont très différents.
crible basique :
http://www.joux.biz/algcrypt/PROGRAMS/Sieve_4-1.html
crible par petits morceaux de 16ko tenant largement dans le cache L1
http://www.joux.biz/algcrypt/PROGRAMS/Sieve_4-2.html
Sur un intel atom N270 (1.6GHz), la différence est flagrante pour les tailles les plus grosses : (tous deux sont compilés avec gcc 4.3.4 -O3 ; avec gcc-4.4.2 on gagne à peu près 5 à 8 % dans les deux cas)
time ./cache_sieve > result
1234567890
real 0m53.146s
user 0m48.663s
sys 0m0.164
time ././basic_sieve > result
1234567890
real 2m43.930s
user 2m29.473s
sys 0m3.760s
(je vous recommande de rediriger la sortie vers un fichier pour bien mesurer le temps de calcul, sinon tout sera pollué par le temps d'affichage dans la console).
Notons que les accès mémoire du crible d'Eratosthene basique sont relativement simples, et sans doutes faciles à prédire et donc à optimiser par le compilateur et les mécanismes de prefetch du processeur. Dans des applications plus complexes, le gain d'une implémentation optimisée serait certainement encore plus important.
[^] # Re: dbench
Posté par Sylvain Sauvage . Évalué à 5.
Comme fichier, /dev/null est une bonne idée (élimine les aléas des E/S).
# Interface graphique
Posté par phoenix (site web personnel) . Évalué à -2.
Y-a-t-il des benchs d'interface graphique?
[^] # Re: Interface graphique
Posté par Guillaume T . Évalué à 1.
# Le noyau fausse tout
Posté par YLD . Évalué à 9.
Pour ne prendre que le noyau 2.6.31 comme exemple, les patchs de Mel Gorman (concernant l'allocation mémoire) ajouté au aurait amélioré les performances de 3 à 30%.
Voir http://linuxfr.org/2009/09/10/25848.html
Enfin, sur Gentoo, mencoder (distribué avec mplayer) bénéficie de plusieurs optimisation liées au CPU (MMX, SSE2 notamment) ou au GPU qu'Ubuntu ne propose probablement pas pour rester compatible avec la famille i386.
P.S. : je n'ai pas vu passer la news sur Gentoo 10 (et 10.1), les dix ans de la distribution et la sortie d'un nouveau live DVD.
[^] # Re: Le noyau fausse tout
Posté par Tiwaz . Évalué à 6.
C'est étrange tous ces commentaires sur ubuntu et cie alors que ce n'est pas le sujet.
Là, c'est juste "pour comparaison", mais le vrai test/bench est dans les 3 versions de gentoo. Et c'est là qu'on voit des grosses disparités. Donc c'est bien le même noyau. C'est très bien précisé dans le journal.
[^] # Re: Le noyau fausse tout
Posté par YLD . Évalué à 1.
Ils auraient mieux fait de ne pas inclure Ubuntu dans leurs tests pour empêcher l'ouverture de la boïte à trolls dans laquelle j'ai plongé à pieds joints.
Un beau sac d' -Os, tout ça.
[^] # Re: Le noyau fausse tout
Posté par khivapia . Évalué à 3.
Il me semblait que mplayer détectait justement le processeur à l'exécution et d'activer les opérations MMC SSE & Co à l'exécution ?
[^] # Re: Le noyau fausse tout
Posté par YLD . Évalué à 2.
L'option « custom-cpuopts », quant à elle permet d'outrepasser la détection des caractéristiques du CPU lors de la compilation.
# Cela confirme ce que je pense
Posté par Mr Kapouik (site web personnel) . Évalué à 10.
Bref si un jour je veux monter un cluster d'encodage vidéo je regarderai un peu mieux gentoo mais en attendant je reste avec mes bons vieux paquets binaire.
[^] # Re: Cela confirme ce que je pense
Posté par Olivier Serve (site web personnel) . Évalué à 2.
[^] # Re: Cela confirme ce que je pense
Posté par Mr Kapouik (site web personnel) . Évalué à 4.
[^] # Re: Cela confirme ce que je pense
Posté par Tiwaz . Évalué à 5.
Pour la lecture du x264, on passe d'une utilisation en pointe de 26% à 18%. C'est loin d'être négligeable pour l'utilisateur lambda.
Sur un rendu PovRay, on passe de 1400 secondes (1/2 heures) à 900 secondes (20 minutes). La différence est énorme.
Sur Graphic Magic, on passe de 79 itérations à 88 itérations par minutes. Si je veux redimensionner 500 images en déchargeant mon appareil photo, je gagne une petite minute.
Avec gtkPerf, qui dessine un certains nombre de widget et calcul le temps total, on passe 600 secondes à 350 secondes, c'est énorme (plus de 1100 pour ubuntu). Donc c'est plus rapide à l'écran.
De plus, comme expliqué plus bas (et plus haut), gentoo, ce n'est pas pour les performances qu'on l'utilise, mais pour sa souplesse. Et le sujet du journal n'était pas gentoo VS ubuntu, ou plus généralement, compilation contre binaire, mais les possibilités d'optimisations en utilisant uniquement le compilateur. Et c'est assez énorme.
Il suffit de regarder les temps de compilation également. Passer de 34 secondes à 41 pour compiler le même programme, c'est une belle amélioration très visible.
[^] # Re: Cela confirme ce que je pense
Posté par Mr Kapouik (site web personnel) . Évalué à 1.
Je suis plus qu'un utilisateur type Madame Michou et pourtant j'ai jamais utilisé povray.
Graphic Magic, je ne sais pas si ça a un rapport avec ImageMagik que j'utilise mais je suis sur que madame michou ne l'utilisera jamais.
GTKPerf, pour avec des rendu de 600s, ils ont du en lancé des widget car sur un rendu classique la différence est négligeable encore une fois.
Je ne doute pas des qualités de souplesse de gentoo : je fais juste un constat comme quoi une distribution binaire pour des besoins simple n'a finalement pas des performances trop ridicule en détournant un peu les résultat donné dans cette étude basé sur les gains de performance fait avec des optimisation gcc.
[^] # Re: Cela confirme ce que je pense
Posté par khivapia . Évalué à 4.
Pas sûr qu'elle ne l'utilisera pas sans s'en rendre compte : les logiciels de gestion de photos à la Gwenview sous Kde permettent des traitements par lot d'opérations simples (comme le redimensionement justement) avec une interface clickodrome sympa et tout. Ça n'utilise sans doutes pas graphic magic ni imagemagik, mais des programmes similaires. On peut donc s'attendre à ce qu'elle bénéficie du même genre d'amélioration des performances.
[^] # Re: Cela confirme ce que je pense
Posté par Sylvain Sauvage . Évalué à 8.
Hum, tu as des heures de 2750 secondes ?
Les rapports sont les mêmes (36 % de moins) mais c’est quand même mieux avec des heures de 3600 secondes, et des minutes de 60 secondes ; ça donne 1400 s = 23 min, 900 s = 15 min.
[^] # Re: Cela confirme ce que je pense
Posté par Dr BG . Évalué à 5.
Mais je ne suis pas certain que compiler toute la distribution avec les mêmes options soit très pertinent. Je ne connais absolument rien aux options des compilateurs. Je peux néanmoins m'imaginer que certaines options seront plus efficaces que d'autres sur un code donné et que ça sera l'inverse sur un autre. Il faudrait connaître les options logiciel par logiciel.
[^] # Re: Cela confirme ce que je pense
Posté par khivapia . Évalué à 3.
Selon le manuel de gcc lui-même (si jamais vous l'avez installé à partir des sources), ils annoncent tout de go une augmentation de la vitesse de compilation de 7% rien qu'en activant ce switch.
Par contre ça a l"inconvénient de nécessiter une passe de compilation supplémentaire dans le cas de gcc, et des tests représentatifs dans les autres cas.
Quand on développe un code on réalise toujours quelques tests pour s'assurer des gains de performance quand on optimise une partie critique, il ne doit pas falloir beaucoup de travail pour les fournir proprement et ainsi être en mesure d'optimiser à fond grâce à gcov les parties du code les plus sensibles.
[^] # Re: Cela confirme ce que je pense
Posté par Snarky . Évalué à 2.
Dommage qu'on ne puisse pas avoir une estimation de la consommation électrique moyenne annuelle de chaque distro.
[^] # Re: Cela confirme ce que je pense
Posté par liberforce (site web personnel) . Évalué à 3.
[^] # Re: Cela confirme ce que je pense
Posté par beleys (site web personnel) . Évalué à 2.
Nos machines passent leurs temps à nous attendre ... et donc, le niveau d'optimisation ne change pas grand chose ...
Une chose et dommage, c'est qu'ils n'ont testé que gcc. Je sais bien que c'est le compilateur libre mais je me dis que cela pourrait être intéressant de voir si un compilateur comme Icc ne permet pas de gagné un peu plus de performance. Après je dis cela comme cela, je n'ai jamais essayé de compiler un kernel avec Icc ...
++ Beleys
[^] # Re: Cela confirme ce que je pense
Posté par Antoine . Évalué à 6.
Ben si, parce qu'elles consomment moins quand elles attendent.
[^] # Re: Cela confirme ce que je pense
Posté par Sylvain Sauvage . Évalué à 2.
Après, il faut voir si c’est vraiment le cas ; p.ex. si le CPU est utilisé trop régulièrement à fond et qu’il n’a pas le temps de vraiment descendre en mode économique, ça ne sert à rien.
[^] # Re: Cela confirme ce que je pense
Posté par lasher . Évalué à 2.
[^] # Re: Cela confirme ce que je pense
Posté par khivapia . Évalué à 3.
En plus ça doit être extrèmement difficile de désactiver certaines unités pendant un calcul, car les transitions entre activité et inactivité donc réduction d'énergie possible sont très très courtes ! Quand on voit qu'un CPU met selon powertop quelques centaines de µs à changer d'état, on se dit que ce n'est pas gagné : en 100 µs un CPU a calculé 100 000 instructions, ce qui est énorme.
[^] # Re: Cela confirme ce que je pense
Posté par liberforce (site web personnel) . Évalué à 5.
http://mjg59.livejournal.com/88608.html
[^] # Re: Cela confirme ce que je pense
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
En gros, un code optimisé pourra demander une puissance crête plus forte, mais la consommation pour une opération donnée sera plus faible (énergie total).
De toute façon sur les process modernes, la conso statique est la plus forte. Donc, la consommation est directement proportionnel à la taille du chip x tension d'alim.
Donc, le but est d'aller le plus vite possible pour diminuer la tension et couper l'horloge.
"La première sécurité est la liberté"
# « gentoo is not about performance »
Posté par JGO . Évalué à 10.
http://lwn.net/Articles/359617/
Voir les commentaires sur cette même nouvelle sur lwn. Les utilisateurs de gentoo ne cherchent pas à gagner un demi-pourcent en vitesse. On rappelle que le système de gestion de paquets de gentoo est basé sur celui de BSD et personne ne se moque des gens de BSD en disant qu'ils cherchent à gagner en vitesse.
L'objectif d'un utilisateur de gentoo au hasard (ceux qui commentent sur lwn ; moi...) :
* contrôler les dépendances, ce qu'on installe ou pas. P.ex. mon back-end pour phonon est xine, alors qu'une autre distribution aurait pu m'« imposer » gstreamer ; j'utilise uniquement mysql, je n'ai pas besoin que mes logiciels supportent postgres, etc.
* contrôler les versions des bibliothèques installées ; possibilités d'upgrade et downgrade de n'importe quelle bibliothèque si une fonctionnalité manque ou un problème se présente
* avoir un outil pour résoudre les bugs : j'ai la source de mon système, je peux trivialement le modifier et le recompiler [oui, c'est aussi très facile sous Debian, mais Debian me limite aux versions des bibliothèques livrées avec la distribution.]
* une ligne et un framework d'administration sans comparaison ;
* documentation web excellente. Vraiment.
Certaines personnes ont suggéré qu'il n'y avait pas de valeur ajoutée par rapport à d'autres distributions déjà existantes :
* Slackware : « sa politique est de n'inclure que des applications stables. » (WIkipédia). Bon, pas pour moi.
* Fedora Rawhide : Je ne veux pas être victime des expérimentations de Red Hat
* Debian : soit distribution versionée soit une branche instable. Gentoo permet de choisir son dosage entre les deux : combiner les avantages d'une distribution rolling et d'une distribution stable (90 de ma machine est sur la branche stable, les 10 % restant sont les versions les plus récentes des logiciels et bibliothèques dont je veux profiter des nouvelles fonctionnalités)
[^] # Re: « gentoo is not about performance »
Posté par Hojo . Évalué à 5.
J'ai utilisé Gentoo comme distrib principale pendant plusieurs années. C'est pas le fait d'avoir une distrib optimisé (sous entendu "pour la vitesse") qui me l'a fait essayer ou y rester, mais :
1. Mieux comprendre comment fonctionne Linux (GNU/Linux), cay bien
2. Avoir une distrib optimisé, pas pour la vitesse, mais pour mes besoins (viva portage)
3. L'efficacité des outils d'administration
4. La documentation
5. Si on oubli les Roxx0r, la communauté
6. La création d'ebuild perso, vraiment simple
Je pense que la majorité des utilisateurs de Gentoo le sont pour ces raisons, pas pour la fausse idée des Kevin/Rebelz/Haxx0r/etc... que Gentoo==Distrib de "l33t qui kiff trop la vitesse"
[^] # Re: « gentoo is not about performance »
Posté par Mr Kapouik (site web personnel) . Évalué à 0.
Emerge basé sur pkgsrc ? Tu es bien sur de ce que tu avances ?
pkgsrc est codé en C et emerge en python. Déjà deux bonnes grosses différences. Ensuite les ebuild sont 100% incompatible avec pkgsrc et les makefiles sont 100% incompatible avec emerge.
Et pour finir il suffit de voir la FAQ d'OpenBSD qui conseil d'utiliser les paquet binaire via les pkg_tools ou NetBSD qui intègre pkgin qui est un apt-like version pkg_tools.
Emerge est une écriture from scratch s'inspirant de concept venant du pkgsrc forké par FreeBSD (oui FreeBSD tout comme OpenBSD maintiennent leur propre version de pkgsrc avec quelques différences dans le fonctionnement de l'outils). Personnellement je préfère pkgsrc pour sa simplicité mais d'autre préfère Emerge qui embarque plein d'option permettant aussi de faire le café.
[^] # Re: « gentoo is not about performance »
Posté par JGO . Évalué à 5.
[^] # Re: « gentoo is not about performance »
Posté par houra . Évalué à 1.
en occurrence , portage est basé sur l'arbre des ports de FreeBSD . :D
Sedullus dux et princeps Lemovicum occiditur
[^] # Re: « gentoo is not about performance »
Posté par Bapt (site web personnel) . Évalué à 3.
[^] # Re: « gentoo is not about performance »
Posté par houra . Évalué à 1.
Sedullus dux et princeps Lemovicum occiditur
[^] # Re: « gentoo is not about performance »
Posté par Mr Kapouik (site web personnel) . Évalué à 2.
L'ebuild gentoo :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/x11-wm/openb(...)
Le makefile NetBSD :
http://cvsweb.se.netbsd.org/cgi-bin/bsdweb.cgi/pkgsrc/wm/ope(...)
Désolé je n'ai pas trouvé le makefile FreeBSD mais ça doit être sensiblement la même chose.
[^] # Re: « gentoo is not about performance »
Posté par houra . Évalué à 1.
celui-ci ?
Sedullus dux et princeps Lemovicum occiditur
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.