Vladimir Makarov, qui bosse sur les compilateurs pour Red Hat, vient de poster le résultat de son évaluation entre les dernières versions de GCC et LLVM.
Le mail d'annonce est ici, les tableaux pour x86-64 et ARM (32 bits) sont postés sur son site tandis que la page de conclusion est là.
Résumé du duel opposant GCC 4.9 et LLVM 3.4 :
- LLVM est bien plus rapide que GCC lors de la compilation.
- GCC génère du code plus rapide que LLVM. Pour les benchs portant sur les entiers l'écart est de 6% environ (sur x86-64) et de 10% environ (sur ARMv7).
- Pas de tests sur les flottants (SPECFP2000) parce que LLVM ne supporte pas FORTRAN.
# Oui…
Posté par Zylabon . Évalué à 6.
Comme depuis 5 ans quoi… Rien de neuf.
Please do not feed the trolls
[^] # Re: Oui…
Posté par deasy . Évalué à 0.
Pareil même si je me suis abstenu de le dire.
Je m'attendais à un "voyez les améliorations du temps de compilation avec gcc"
pétard mouillé :p
[^] # Re: Oui…
Posté par claudex . Évalué à 10.
C'est aussi une information intéressante de savoir que ça n'a pas changé. Après, ça ne vaut pas le coup de l'annoncer tous les jours mais mettre à jour l'information de temps en temps a son intérêt.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Oui…
Posté par patrick_g (site web personnel) . Évalué à 10.
j'ai trouvé ça intéressant parce que :
[^] # Re: Oui…
Posté par freem . Évalué à 8.
Euh, non, on apprend dans les bench que GCC est plus lent qu'avant en compilation sans LTO alors qu'il est vachement plus rapide avec LTO qu'avant. Autrement dit, que GCC s'améliore face à son concurrent.
J'ai aussi dénoté une amélioration non négligeable du score de LLVM sur 181.mcf sans LTO.
Je n'ai pas regardé plus que ça les graphiques basés sur les pourcentages, il faudrait que j'arrive à comprendre ce qu'il signifient pour ça :/
Sinon, personnellement, je trouve les conclusions intéressantes, déjà parce qu'il mets bien dans le contexte, mais aussi parce que j'y ai appris entres autres que LLVM utilise systématiquement les regisres SSE pour des opérations de mouvement mémoire vers mémoire, alors que GCC utilise des registres généraux.
J'admets ne pas être sûr de tout comprendre, hein, et je comprend que certains trouvent ce genre d'info inutiles (peut-être parce qu'ils le savent déjà, ou parce que c'est écrit dans le FM, ou …) mais ça me donne des pointeurs vers de futures recherches.
Mais bon, j'imagine que je suis de ceux qui voient le verre à moitié pleins, et je rejoins le commentaire précédent qui dit que c'est toujours mieux que les bench de phoronix, que je trouve soit moins pertinents, soit moins clairs (dans tous les cas je ne comprend pas l'ensemble, mais dans le cas de ceux de phoronix, j'ai l'impression de nager dans une confusion assez générale à la fin).
[^] # Re: Oui…
Posté par JGO . Évalué à 10. Dernière modification le 01 juillet 2014 à 16:16.
Les tests de Phoronix pourraient être résumés par une table à double entrée avec un nombre et un code de couleurs de façon à montrer d'un coup d'œil les points forts et faibles de chaque configuration. L'auteur préfère cependant générer des pages et des pages d'histogrammes qui, pris individuellement, sont peu intéressants et qui noient le lecteur par leur grand nombre. Mais peut-être qu'il gagne sa vie en fonction du nombre de pages vues, du coup il préfère séparer les résultats en n pages.
[^] # Re: Oui…
Posté par claudex . Évalué à 10.
C'est ça, et il ne s'en cache pas. Si tu prends un abonnement, tu as droit aux articles en une seule page.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Oui…
Posté par oinkoink_daotter . Évalué à 10.
C'est plus que probable, mais de mémoire, il est tout seul et n'a d'autres ressources que la publicité, a pas mal de frais fixes (serveurs et la myriade de machines dont il a besoin pour ses tests) et je n'ai pas l'impression qu'il roule sur l'or et il faut bien vivre. En plus le gars sort des trucs de temps en temps : par exemple, c'est lui qui avait tiré le premier la dessus http://www.phoronix.com/scan.php?page=article&item=linux_mobile_uffda&num=4 .
Donc au delà de la forme qui est toujours perfectible, je ne comprends pas vraiment le Larabel bashing en vigueur ici car son boulot est utile.
[^] # Re: Oui…
Posté par navaati . Évalué à 5.
En fait je pense que ce bashing vient d'une frustration : j'aimerais bien payer (tout comme je paye lwn) pour avoir un phoronix de bonne qualité parce que oui, dans le fond ce qu'il écrit est intéressant.
Sauf que payer ne me donnera pas un phoronix sans les titres accrocheurs moisis, sans l'absence de synthèse dans la rédaction pour pouvoir découper en pages (payer permet d'avoir tout sur une page mais le texte reste rédigé pour plusieurs, avec tous les procédés d'écriture et de dispersion de l'info que ça implique), sans les liens internes à gogo vers de bêtes pages de recherches et démerde toi pour trouver le lien de l'article dont il parle, etc.
C'est très dommage.
[^] # Re: Oui…
Posté par tao popus . Évalué à 1.
Il n'y a pas que le titre qui est de la pure accroche creuse, le pire à mon sens, c'est vraiment le fil RSS, les entêtes qu'il laisse sont aussi creux que nombreux de ses articles. Dommage, il y a des choses intéressantes dans l'ensemble de ses bench. Enfin, le creux à 99% m'a fait personnellement éviter cette source après 1 ou 2 ans de suivit approximative, lorsque quelque chose sort du lot, quelqu'un d'autre le reportera de façon plus pertinente de toute façon. Une recherche yacy ou seeks est plus efficace dans certains cas…
En gros on peut résumer la majorité de ces article en : Un changement sur XXX le rend beaucoup mieux et beaucoup plus rapide… (je comprend pas pourquoi toutes la communauté du libre ne travaille pas avec acharnement à empirer les performances franchement ? ^
[^] # Re: Oui…
Posté par claudex . Évalué à 2.
Vu que c'est le seul qui publie ce genre de bench fréquemment, c'est le seul moyen de le savoir, parfois aussi pour le dev qui commit des trucs qui ont des effets de bords que personne n'avait anticipé. D'ailleurs on voit régulièrement dans les bench avec les version alpha/rc des régressions de performances sur un cas particulier.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Oui…
Posté par Renault (site web personnel) . Évalué à 8.
Oui il peut vivre de son activité mais il faudrait qu'il arrive à fournir du contenu de qualité avec des procédés sympa pour sa clientèle s'il veut que ça fonctionne.
La volonté d'avoir des clients ne nécessite pas de supprimer la qualité du contenu, la pertinence des mesures et le respect de ses lecteurs et de la communauté.
[^] # Re: Oui…
Posté par freem . Évalué à 1.
Perso mon but est pas de basher un type en particulier, je ne savais même pas que c'était un gars seul.
Je n'ai fait que dire le fait que je sois en général confus après la lecture d'un des benchmark, et il est possible que cette confusion vienne de mon manque de connaissance des sujets.
[^] # Re: Oui…
Posté par Sylvestre Ledru (site web personnel) . Évalué à 7.
gcc et clang évoluent tous les deux. C'est deux bonnes nouvelles!
# Le FORTRAN c'est bon mangez en
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 3.
"Pas de tests sur les flottants (SPECFP2000) parce que LLVM ne supporte pas FORTRAN."
Et pourquoi pas un test du genre LINPACK_BENCH ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.