Quel rôle jouent véritablement les compilateurs dans les performances relatives de nos processeurs ? C'est la question à laquelle nous avons souhaité répondre dans ce dossier !
Lire la suite ...

Gros taff sur ce dossier.
Mais trop compliqué pour moi
Mais j'admire le taff effectué

Non vraiment très intéressant. Ça c'est de la presse! Mis en favoris quand on demandera des bench entre différents compilateurs.

Excellent article !! Un vrai document de référence pour tous les programmeurs.

Un article technique qui fait plaisir a lire !

J'ai pas tout compris ni tout lu dans le détail, mais je pense que les résultats n'indiquent pas forcément un gain de performance "partisan" avec les optimisations du compilateur Intel : Dans la mesure où il est le compilateur le plus performant avec les processeurs AMD, rien ne prouve qu'il aurait été possible de faire mieux, même si les ingénieurs d'Inter avaient bossé spécifiquement pour optimiser les perfs sur AMD.

Très bon article, dommage qu'il soit orienté windows !

En lisant le titre je me suis dit "tiens, me revoilà sur x86-secret".
Gros boulot apparemment, pas trop le temps de lire ça ce matin, mais ça m'a l'air passionnant

Si on voulait pinailler, on pourrait dire qu'il manque PGI et LLVM.

Vous avez essayé mingw-w64 ? En mode i686-w64-mingw32 ou x86_64-w64-mingw32 (je sais, les noms sont à chier ; mingw-w64 fait 32bit et 64bit). Ça inclut une énorme amélioration au niveau des fonctions de maths et globalement, c'est un monde avec mingw.org.
 
Y'a des binaires précompilées sur mingw-w64.sf.net

très bon article !  
 
je tiens juste à rajouter que les Intel Performance Primitive (IPPs) proposent des fonctions qui ne sont pas TOUTES optimisées. Pour certaines le code C/C++ASM que l'on peut écrire est tout aussi rapide (voir plus rapide) que le code dit "optimisé" par les IPPs.
 
enfin je ne comprends pas pourquoi la "manipulation des  intrinsics" différe d'un compilateur à l'autre ? je m'en sers justement pour avoir du code MMX/SSE/AVX portable cross plateform (VSC/GCC) ...
 
 
si faire du code AVX/SSE/MMX semble une bonne idée elle nécessite une bonne connaissance des modèles d'alignement pour réellement exploiter ces fonctionnalités ! quel est le role des compilos sur ce point ?

ca c'est du dossier  !
un bon gros bien couillu et velu, merci H.FR

"...une généralisation de .NET", *HARA-KIRI*

Faudrait refaire les tests avec l'optimisation guidée par profil  

Très bon article.

Merci pour les commentaires.
 

Très vrai.  
 

Je sous entendais qu'il faut souvent passer par une couche suppplémentaire pour ICC : http://software.intel.com/en-us/ar [...] ader-file/
 

Pour PGI, on en reparlera probablement sur un sujet sur l'accélération. Pour LLVM on le mentionne, malheureusement sous Windows le support est encore un peu limité/en retard par rapport aux autres plateformes http://llvm.org/docs/GettingStarted.html
 

J'avais essayé lors de l'établissement du protocole de test avant d'être revenu à la version classique, mais très honnêtement je ne me souviens plus pourquoi. Je pense que j'avais eu quelques problèmes de compatibilité avec SPEC, mais ce n'était peut être pas lié a -w64 (il a fallu pas mal de temps pour faire marcher SPEC avec une version de mingw). Je vais jeter un oeil pour voir.

Une build PGO biaiserait encore plus les résultats en fonction de la plateforme sur laquelle on la compile (en plus de la plus ou moins représentativité du sample d'execution).

 
Effectivement dans le cas d'un dispatcher, les stats seront foirées dans le cas où le binaire PGO tourne sur un autre CPU.
Mais il y a aura quand même des gains communs à mon avis.
Le sample d’exécution n'est pas critique (dans le sens biais d'optimisation) du moment qu'il est typique ^^.
 
Le PGO peut changer pas mal de choses à mon avis.
Donc faudrait vraiment faire quelques essais, quitte à avoir un build par paire compilo/cpu (dans le cas où l'on sait qu'il y'a un dispatcher).
Bon OK, je suis pête-couilles, mais autant tout faire. (surtout que c'est pas moi qui doit le faire )
 
Alors après si c'est pour montrer que l'optimisation c'est un bins aux gens lambda, et que y'a un aléas de perfs suivant le compilo/stratégie d'optimisation, c'est sûr pas besoin de faire des benchs PGO.

Cela illustre bien la guerre que ce livre en coulisses Intel et AMD. Quand un compilateur arrive a prendre des parts de marché substantielles sur le marché, son avantage grandit de jour en jour au fur et à mesure des benchmarks (comme ceux des jeux sur ce site). Ce qui encourage d'autant les clients a choisir cette marque.  
Ayant travaillé dans un studio de développement, quand le commercial Intel (par exemple) venait pour placer ses outils chez nous, c'était la foire aux cadeaux : T-shirts, gadgets, offre sur des stations complètes, suite de développement a prix dérisoires, etc...
Pour eux, c'est un moyen très important de gagner en "performances", bien plus rentable que d'optimiser un processeur.

On est d'accord lol.

résultat: ils faut que les pingouins compilent leur noyau linux sur du M$soft  
 
Ps: si on me cherche , je suis par là ------> []
cela dit , troll à part, c'est un très bon article merci HFR

Même sans, les stats relevées seront différentes sur un FX de sur un Core i7. Ici, nous utilisons des exe identiques sur les trois plateformes pour chaque test.
 

Complètement, mais on sort un peu du cadre de notre article ou l'on essaye justement de voir les impacts variables que peuvent avoir les compilateurs sur les architectures.
 
En rajoutant PGO on rajoute une variable de plus qui complexifie significativement la comparaison si le code produit en PGO sur un FX diffère de sur un Core i7 par exemple.  
 
Pour être complet j'avais quand même fait quelques tests avec PGO activé sous Visual Studio avec SPEC (la norme base interdit PGO, mais en peak c'est autorisé) que je n'ai pas ajouté dans les graphs. Dans ce cas, on recompile/train à chaque fois sur la plateforme.  
 
Sur 473.astar, j'ai respectivement +7,6, +10.4 et +7.1% pour Phenom II, FX et Core i7. Sur 444.namd 3.0, 1.8 et 0% et sur 482.sphinx3, 1.6, 2 et 3%.

Dans le fond, si je suis développeur, je me dis que pour satisfaire tous le monde, je peut utiliser le ICC optimisé pour le SSE3

D'un point de vue de l'équité c'est le meilleur mode oui, et il passe relativement partout.

Quel compilateur compile le compilateur qui compilera les programmes en question ?
Cela a t-il un impact car un compilateur compilé avec certaines optims compilera t-il mieux certains programmes ?
OK je suis déhors...

Pourquoi n'avoir pas inclu un test de GCC sous Linux, puis le fork d'open64 à coté des test Windows ?

Autre OS, autres problématiques, on l'évoque, particulièrement au niveau de la libstd. D'autres sites dédiés à Linux ont en plus déjà traité le sujet, étant donné que nous réalisons nos tests de processeurs sous Windows, nous nous sommes concentrés sur Windows comme plateforme.

Encore je peux comprendre que certains se plaignent que intel fait pas beaucoup d'efforts pour les optimisations sur les processeurs AMD, on peut pas non plus leur repprocher de chercher l'optimisation sur leur processeurs plutôt que sur les AMD. Il y a quand même des différences d'architecture qui changent les optimisations à faire. Donc il pourraient peut-être faire des optimisations plus efficaces pour AMD mais ça serait certainement au détriment des performances sur les processeurs intel. Dans la mesure où il reste plus performant que les autres compilateurs AMD, on pas pas lui reprocher grand chose.
Et puis aussi intel sait déjà les spécificités de l'architecture qui sera lancée dans deux ans chez eux mais n'a aucune idée de comment optimiser la future architecture d'AMD. C'est bien plus facile d'optimiser quand on connaît les détails de l'architecture.
D'ailleurs tout cela me rappelle que certains jeux sont optimisés pour les cartes ATI ou NVidia, souvent avec l'utilisation parfois abusive d'instructions faites à pleine vitesse sur l'un et à demi-vitesse sur l'autre. Sinon il faudrait proposer une version différente par couple processeur/carte graphique mais ça serait bien trop compliqué.

Très sceptique sur les résultats de 456.hmmer, lbm et consorts. A mon avis doit y avoir une sacrée marge d'optimisation pour avoir des perfs 3x meilleurs sur compilo intel... Allocation mémoire fragmentée mieux gérée par l'allocateur Intel ou autre. Si c'est logique que le gain SSE soit assez minime en calculs entiers, avoir des gains de perfs x2 ou x3 sur les versions de base me laisse dubitatif. Au pire une meilelure gestion mémoire ou quelques bouts d'ASM devraient réduire grandement l'écart sur les versions base.

et encore... nous on a réussit de peine et de misère a passer nos logiciels à SSE (premier du nom) ... pourtant sortie il y a 13 ans...
 
Il y a une forte réticence à enlever le support sur le vieux hardware....

Hey, ya moyen de tester le gain de perf sur PHP et MySQL ?
 
Sur certains blogs, on parle d'un gain de 10% à 150% en perf.
J'aimerai beaucoup avoir l'avis d'un professionnel.

 
Y'a un autre point : le scheduler. Comme ça, genre l'année dernière, la vitesse d'x264 sous linux a été améliorée de 60% sur un certain proco. Y'avait clairement un problème à la base mais ça montre surtout que ça fait beaucoup de variables.
 
(bon, mais avec mingw-w64 sous windows, les fonctions des libs sont modernes donc ça devrait aller pour ça)

 
Ou alors le compilo d'intel trouve un bout de code pas "utile". C'est assez dur parfois avec les benchmarks : j'avais GCC qui me dégageait simplement tout le code que je voulais benchmarker parce qu'évidemment le code n'avait pas d'effet de bord et je n'utilisais pas sa valeur de retour (belle fonction pure). Si ICC "voit" mieux, ça peut expliquer.
 
Enfin, y'a aussi beaucoup d'autres explications. Ce serait pas forcément inintéressant de voir le code ASM généré par chaque compilo. :-)

Je suis très étonné de la différence entre les compilateurs sur certain benchmark. Vous avez vérifié que les résultats des algos étaient les mêmes, ou du moins cohérent entre les différentes compilations ?
 
J'ai déjà eu le cas sur certain code source où l'activation de certaines optimisations améliorait grandement les performances, au détriment des résultats qui pouvaient alors diverger (surtout en virgule flottante sur des algos itératifs).

Article super intéressant bravo !  
Par contre je ne suis pas tellement d'accord sur la conclusion sur l'équité. Le code généré par un compilateur Intel a beaucoup de chances de mieux tourner sur les CPU Intel tout simplement car les concepteurs du compilateur peuvent avoir accès à toute l'architecture CPU et à toutes les documentations. Rien n'empêche AMD de faire son propre compilateur.

Pour les benchs SPEC l'output de chaque bench est vérifiée automatiquement oui. Je l'ai également fait manuellement pour x264 et C-Ray.

En théorie je serais d'accord mais lors que l'on a analysé le code assembleur produit, nous avons noté que beaucoup des optimisations qui font la différence de performances, comme des memcpy différents ou l'activation sélective du dépliage de boucle n'ont strictement rien a voir avec le CPU sur lequel tourne l'exe. Et donc pas réellement grand chose a voir avec l'accès a une documentation.  
 
Rien n'empêche AMD de produire un compilateur Windows par contre - qui reste le gros du marché - c'est une certitude.

excellent article

Moi dans toute les boites où j'ai travaillé on a systématiquement refusé de travailler avec les compilateurs Intel car ils désavantagent les processeur AMD, le code exécuté était pas le même selon si c'était un processeur Intel ou AMD qui était détecté... c'est p-e moins pire aujourd'hui, mais à l'époque du P4 c'était flagrant, le memcpy version 'AMD' était fait de la pire façon possible (copy de un byte à la fois), nos bench montrait quelque chose comme 8 fois moins rapide que la version Intel.... pourtant le code du memcpy version Intel pouvait rouler sur un processeur AMD sans problème...
 
Dans un sens ça enlève beaucoup de client potentiel à Intel...

Pas tout compris mais ca change de Closer et autres bouzes, la y'a du taff  

T'as aussi le droit de compiler pour plusieurs cibles, que ça soit de façon automatique ou manuelle.
 
Ca se faisait déjà il y a 20 ans, notamment à cause de la segmentation qui imposait d'avoir du code x86/x87.
 
A une autre époque ça aurait pu être problématique de gonfler l'exe, mais de nos jours c'est dérisoire, surtout si ça apporte un gain de perfs (sachant que pour les cas où la perf a assez peu d'importance, C#.NET est très clairement à privilégier, pour la propreté du code)