Forum |  HardWare.fr | News | Articles | PC | Prix | S'identifier | S'inscrire | Aide | Shop Recherche
2024 connectés 

  FORUM HardWare.fr
  Hardware
  HFR

  [HFR] Dossier : Impact des compilateurs sur les architectures CPU x86/x64

 



 Mot :   Pseudo :  
 
 Page :   1  2
Page Précédente
Auteur Sujet :

[HFR] Dossier : Impact des compilateurs sur les architectures CPU x86/x64

n°8229387
C_Wiz
Super Administrateur
Profil : Equipe HardWare.fr
Posté le 28-02-2012 à 01:55:01  profilanswer
0Votes positifs
 

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 ...

mood
Publicité
Posté le 28-02-2012 à 01:55:01  profilanswer
 

n°8229391
Vampyrstar
Tite vipère
Posté le 28-02-2012 à 02:13:33  profilanswer
4Votes positifs
 

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

n°8229395
hahahafr
Machete don't text
Posté le 28-02-2012 à 02:37:02  profilanswer
3Votes positifs
 

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

n°8229408
Haddock200​4
Posté le 28-02-2012 à 04:06:36  profilanswer
1Votes positifs
 

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

n°8229411
HumanRAGE
Rage d'être un Humain...LIBRE!
Posté le 28-02-2012 à 05:41:13  profilanswer
1Votes positifs
 

Un article technique qui fait plaisir a lire !

n°8229423
BlueScreen​Junky
Posté le 28-02-2012 à 08:03:28  profilanswer
1Votes positifs
 

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.

n°8229464
ulukai08
Posté le 28-02-2012 à 09:29:09  profilanswer
2Votes positifs
 

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

n°8229478
MasterSam
Paster of Muppets
Posté le 28-02-2012 à 09:41:30  profilanswer
1Votes positifs
 

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


Message édité par MasterSam le 28-02-2012 à 09:41:50
n°8229504
ad
Posté le 28-02-2012 à 10:10:47  profilanswer
2Votes positifs
 

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

n°8229548
camarade_t​ux
Posté le 28-02-2012 à 10:54:02  profilanswer
0Votes positifs
 

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

mood
Publicité
Posté le 28-02-2012 à 10:54:02  profilanswer
 

n°8229628
UpFrag
Posté le 28-02-2012 à 11:55:03  profilanswer
0Votes positifs
 

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 ?


Message édité par UpFrag le 28-02-2012 à 12:17:38
n°8229649
Lorenzo77
Posté le 28-02-2012 à 12:08:13  profilanswer
0Votes positifs
 

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

n°8229658
meskale
Posté le 28-02-2012 à 12:16:38  profilanswer
1Votes positifs
 

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

n°8229662
bjone
Insert booze to continue
Posté le 28-02-2012 à 12:20:34  profilanswer
0Votes positifs
 

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


Message édité par bjone le 28-02-2012 à 12:25:59
n°8229667
Bourla
Posté le 28-02-2012 à 12:23:04  profilanswer
0Votes positifs
 

Très bon article.

n°8229674
C_Wiz
Super Administrateur
Profil : Equipe HardWare.fr
Posté le 28-02-2012 à 12:29:57  profilanswer
2Votes positifs
 

Merci pour les commentaires.
 

UpFrag a écrit :

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.

Très vrai.  
 

UpFrag a écrit :

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) ...

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

ad a écrit :

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

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
 

camarade_tux a écrit :

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.

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.

bjone a écrit :

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

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).

Message cité 1 fois
Message édité par C_Wiz le 28-02-2012 à 12:36:00
n°8229693
bjone
Insert booze to continue
Posté le 28-02-2012 à 12:47:14  profilanswer
0Votes positifs
 

C_Wiz a écrit :

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 :whistle: )
 
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.


Message édité par bjone le 28-02-2012 à 13:18:44
n°8229702
Singman
The Exiled
Posté le 28-02-2012 à 12:57:28  profilanswer
1Votes positifs
 

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.

n°8229710
hahahafr
Machete don't text
Posté le 28-02-2012 à 13:05:57  profilanswer
0Votes positifs
 

meskale a écrit :

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

On est d'accord lol.

n°8229711
Gazkero
Posté le 28-02-2012 à 13:06:49  profilanswer
0Votes positifs
 

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


Message édité par Gazkero le 28-02-2012 à 13:08:57
n°8229729
C_Wiz
Super Administrateur
Profil : Equipe HardWare.fr
Posté le 28-02-2012 à 13:21:09  profilanswer
0Votes positifs
 

bjone a écrit :

Effectivement dans le cas d'un dispatcher, les stats seront foirées dans le cas où le binaire PGO tourne sur un autre CPU.

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.
 

bjone a écrit :

Mais il y a aura quand même des gains communs à mon avis.

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%.


Message édité par C_Wiz le 28-02-2012 à 13:21:34
n°8229834
3dcSkeeder
Skeeder.studio
Posté le 28-02-2012 à 14:54:59  profilanswer
0Votes positifs
 

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 :)

n°8229839
C_Wiz
Super Administrateur
Profil : Equipe HardWare.fr
Posté le 28-02-2012 à 14:57:52  profilanswer
0Votes positifs
 

3dcSkeeder a écrit :

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.

n°8229923
ragondin
Un pote ragondin c'est cool
Posté le 28-02-2012 à 16:28:29  profilanswer
0Votes positifs
 

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...

n°8229939
mum1989
Posté le 28-02-2012 à 16:37:57  profilanswer
0Votes positifs
 

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

n°8229952
C_Wiz
Super Administrateur
Profil : Equipe HardWare.fr
Posté le 28-02-2012 à 16:57:25  profilanswer
0Votes positifs
 

mum1989 a écrit :

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.

n°8229955
meneldal
Posté le 28-02-2012 à 17:00:39  profilanswer
0Votes positifs
 

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é.

n°8229975
smaraux
Soufflez pas sur les breizh
Posté le 28-02-2012 à 17:21:55  profilanswer
1Votes positifs
 

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.

n°8230093
hyksos_sow​o
Posté le 28-02-2012 à 19:02:47  profilanswer
0Votes positifs
 

3dcSkeeder a écrit :

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 :)


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....

n°8230335
CyberDenix
Posté le 28-02-2012 à 22:42:31  profilanswer
0Votes positifs
 

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.


Message édité par CyberDenix le 28-02-2012 à 22:46:24

---------------
Directeur Technique (CTO)
n°8230407
camarade_t​ux
Posté le 28-02-2012 à 23:34:52  profilanswer
0Votes positifs
 

C_Wiz a écrit :

mum1989 a écrit :

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.


 
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)

n°8230415
camarade_t​ux
Posté le 28-02-2012 à 23:37:45  profilanswer
0Votes positifs
 

smaraux a écrit :

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.


 
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. :-)

n°8230418
slanith
Posté le 28-02-2012 à 23:38:56  profilanswer
0Votes positifs
 

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).


Message édité par slanith le 28-02-2012 à 23:40:13
n°8230437
guybrush_t​hreepwood
Glandeur
Posté le 28-02-2012 à 23:56:32  profilanswer
1Votes positifs
 

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.

n°8230443
C_Wiz
Super Administrateur
Profil : Equipe HardWare.fr
Posté le 29-02-2012 à 00:04:19  profilanswer
0Votes positifs
 

slanith a écrit :

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 ?

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.

n°8230455
C_Wiz
Super Administrateur
Profil : Equipe HardWare.fr
Posté le 29-02-2012 à 00:31:12  profilanswer
0Votes positifs
 

guybrush_threepwood a écrit :

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.


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.

n°8230462
RONIN 512
Posté le 29-02-2012 à 00:44:21  profilanswer
0Votes positifs
 

excellent article

n°8230492
hyksos_sow​o
Posté le 29-02-2012 à 02:42:55  profilanswer
0Votes positifs
 

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...

n°8230711
Zanskar03
www.whitewavedesign.fr
Posté le 29-02-2012 à 11:31:17  profilanswer
0Votes positifs
 

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


---------------
Mods home made "Wasp","White Wave", "Armored Gamer Box","Open Air","Open Air 2"
n°8230798
Gigathlon
Quad-neurones natif
Posté le 29-02-2012 à 12:49:27  profilanswer
0Votes positifs
 

hyksos_sowo a écrit :

Il y a une forte réticence à enlever le support sur le vieux hardware....


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)

mood
Publicité
Posté le   profilanswer
 

 Page :   1  2
Page Précédente

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Hardware
  HFR

  [HFR] Dossier : Impact des compilateurs sur les architectures CPU x86/x64

 

Sujets relatifs
[HFR] Actu : Asus HD 7950 DirectCU II : défaut, attention !Recherche Benchmark CPU et uniquement CPU Gratuit
[HFR] Actu : Z7K500 : 500 Go et 7200 tpm en 7mm chez Hitachi[HFR] Actu : Un nouveau ventirad Noctua, le NH-L12
[HFR] Actu : Pilotes Nvidia GeForce 295.73 WHQL[HFR] Actu : Cyclos aide AMD à réduire la consommation
Un problème de ventilation CPU...Ventilateur du CPU ne fonctionne plus.
[HFR] Actu : AMD Catalyst 12.2 Pre-certifiés[HFR] Actu : Trois nouveaux AMD FX 95W
Plus de sujets relatifs à : [HFR] Dossier : Impact des compilateurs sur les architectures CPU x86/x64


Copyright © 1997-2018 Hardware.fr SARL (Signaler un contenu illicite) / Groupe LDLC / Shop HFR