Reprise du message précédent :

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)

J'aurais bien aimé avoir des informations sur l'impact du mode profiling pour la compilation: on compile avec l'option profiling, on execute le programme de test, puis on recompile avec les informations obtenues.
J'avais fait des tests de performances (il y a 2 ou 3 ans) entre visual studio et le compilateur intel, et pour mes tests, le compilateur intel n'etait interessant que si l'option de profiling était activée, autrement le code obtenu etait inutilement trop gros ou pas assez optimisé dans les parties du code frequemment utilisées.
De plus, un developpeur qui veut avoir les meilleurs performances utilisera ce mode là. Si son jeu de test pour le profiling est bien choisi, il peut améliorer les performances de facon importante. Il est donc interessant de voir le comportement du compilateur avec des informations sur le comportement du programme.

Il y a aussi ce compilateur dispo: https://github.com/path64/repositories
http://www.pathscale.com/ekopath-compiler-suite
http://www.silicon.fr/pathscale-li [...] 54053.html

Pour ce rendre facilement compte de l'impact d'icc il suffit d'essayer différentes variantes de linux sur un acer aspire one avec sud "stock" (il est à chier cela dit en passant) dont meego, distrib linux compilée pour atom.
 
Elle est compilée entièrement avec ICC, là ou même sous gentoo en changeant de compilateur on ne peut le faire pour l'intégralité du système ...
 
Forcément sur ce netbook "moyen" cette version de linux est bluffante, surtout si vous avez essayé d'autres distrib ... (temps de boot moyen 7 secondes, alors que le sud d'origine est je le rappelle pourri ...)
Bon après c'est meego donc bon y a pas grand chose mais en tout cas c'est je pense une des meilleures démonstration pratique du compilateur ICC  pour qlq chose de "palpable" par l'utilisateur (car franchement ce netbook, avec quoi que ce soit d'autre dessus, vous le transformez en freesbee au bout d'une heure de lutte/attente d'utilisation

excusez, sud -> ssd, putain d'assistant de frappe

 
C'est non problématique lorsque tu ne te préoccupe pas du load time ... pour nous le load time est primordiale. De plus, doubler ou tripler la grosseur de notre package est tout a fait hors de question, non pas par manque d'espace disque, mais car nous déployons par internet.
 
En plus que Visual studio ne supporte pas nativement le multi target en C++ et rendu la le plus simple serait de compiler 3/4 fois la même chose et avoir un package par target, un x87, un SSE, un SSE2, un SSE3, un AVX etc... mais ça aussi c'est inacceptable.

Comme promis j'ai donc essayé la version -w64, en utilisant toujours les packages TDM ici : http://tdm-gcc.tdragon.net/download
 
Niveau compatibilité effectivement je confirme qu'il y a quelques petits problèmes, le test hmmer ne fonctionne pas par exemple. J'ai testé sur FX-8150 avec le profil bdver1.  
 
J'ai bien quelques petits gains, mais on est loin d'un monde de différence. Peut etre parce que les builds TDM classiques que j'avais utilisées dans le test étaient déjà plus optimisées (elles sont beaucoup plus à jour que les mingw traditionnelles qui sont très en retard, nottament sur la version de GCC). J'ai noté un gain assez variable, qui va jusque 2.8% sous h264ref, sinon on est en moyenne autour du pourcent.

reste la voix royale ===> reste la voie royale

Super article C_Wiz  

justement, c'est bien de penser mais penser sans posséder toutes les données c'est comme calculer (1+x) en déduire que le résultat est 3
alors que hélas la valeur de x était en fait 4 ...
 
en clair, tes conclusions sont erronées par manque d'information !

 
Super. Merci beaucoup. =)  
 
Je note pour la compat et je vais taper sur quelqu'un jusqu'à ce qu'il corrige. ;p  
 
Pour la différence de perf, la plus grosse différence viendrait sans doute des fonctions de maths et donc ça va changer en fonction du bench et de l'utilisation qu'il fait de ces fonctions. Il me semble que mingw.org (la version truc-*pc*-bidule) ne peut pas du tout utiliser la nouvelle lib de maths (truc-*w64*-bidule) (je crois que c'est déterminé par "pc" vs. "w64", ce qui est choisissable à la compile de gcc lui-même).
 
Mais je viens de penser à un truc assez particulier : GCC peut évaluer certains calculs à la compilation, ou simplifier des expressions. Souvent ça dépend de libs externes genre GMP, MPFR, Cloog, PPL (des polyhédrons pour optimiser du code, il fallait y penser )... et c'est activable ou pas à la compilation de GCC justemen. Ça doit pouvoir faire varier pas mal.
 
PS : si les temps de build ne sont pas négligeables, est-ce qu'il serait possible de les avoir (pour le futur). (par contre, là, pour le coup, un proco dont la fréquence diminue peut être _incroyablement_ plus lent comme je l'ai découvert par hasard. ='( [/mylife])

C'est un vil troll, mais bon :
Le langage dansd lequel est codé le compilateur n'influence pas le code compilé. On pourrait imaginé un compilateur en basic, ou javascript : la compilation serait très lente mais le code compilé a priori le même.
 
Un compilateur ne fait que "traduire" un langage en un autre: enfin en vrai il commence par analyser/reconnaitre les mots (mots clés, variables, constantes, fonctions...), puis les instructions, vérifier que les instructions sont grammaticalement correctes (genre si une variable et attendu, on doit pas avoir un mot clé), et enfin procède la compilation.
Un compilateur peut très bien produire un code illisible sur le proc en cours. L'exemple typique et le dev sur des architectures pas performante : Tu compiles ton programme ARM sur ton quad Core i7, tu copies le binaire sur ton pda sous arm et tu tests. Compiler directement sur le PDA faut déjà être motivé...

Article excellent, énorme boulot, merci beaucoup ! ça va rester la référence pendant plusieurs années, tant les discussions sur les optimisations et mérites respectifs des compilateurs ont souvent besoin d'être étayées, super. Quelques tests dans le même genre sont souvent réalisés sur phoronix (sous linux, avec llvm et gcc principalement), mais bien moins complets.

Voilà un dossier "qu'il est bien torché"... non franchement, super ! Ce dossier me rappelle à moi aussi les heures de gloires de x86-secret (quoique son successeur est pas mal aussi ). Très intéressant, et technique aussi. Il faudrait que je le relise !

 
Nope ce sont les algos d'optimisations du compilateur qui joue, pas comment il a été lui-même compilé. (par contre plus il a été compilé bien ciblé pour la machine de compilation, plus la compilation/optimisation est rapide)

est-ce que la mkl (math kernel library de intel) est utilisée dans les benchmark ? Si oui ca peut faire une tres grosse difference si seul icc peut les utiliser. Elle est tres optimisée (assembleur je crois) et peut faire gagner énormément.

Euh je suis le developpement du codec x264 pratiquement depuis le début. Il me semble que si on veux bénéficier des instructions SSE, SSE2, SSE3, SSE4, SSE5 ... il faut que l'algo est un codage adéquat.
 
En somme s'il n'y a pas d'optimisations du code pour les instructions SSE2 et bien l'executable n'utilisera pas correctement les instructions SSE2 du CPU même si celui ci en dispose et le compilateur n'y changera rien. Dans ces conditions je ne vois pas a quoi ça sert de comparer des compilations optimisées manuellement pour telles ou telles intructions si le code n'a pas été écrit pour en bénéficier. C'est visiblement le cas pour plusieurs algo dans votre comparatif.
 
De plus pour bien connaitre le x264, seules certaines parties du code peuvent aussi reellement beneficier de telles ou telles intructions CPU. Par exemple DCT, SSE, SAD, SADT, RDO ... etc ... ne necessiteront pas toute d'être optimisées pour un codage SSE5 car cette intsruction n'apportera pas de gain mesurable par rapport a une optimisation SSE2 ou SSE3. Il sera donc facile de mettre en avant telle ou telle optimisation avec le x264 en fonction des profils d'encodages choisi. Par exemple un bitrate très fort entrainera un calcul sur le CABAC très lourd qui mettra lui-même en évidence les intructions utilisées pour le CABAC. De même si vous voulez mettre en évidence les instructions du nouveau CPU AMD, il vous faudra utiliser un profil x264 particulier pour avoir un gain visible.
 
Pour finir le code peut encore être optimisé pour chaque classe de CPU et ce même s'ils possèdent les mêmes instructions. Ainsi un code pourra être optimisé particulèrement pour Intel et pas pour AMD. Et là encore la compilation ne pourra rien y changer. A mon avis le code pourra aussi être lui-même optimisé pour s'adapter aux différents compilateurs.
 
 
Bon après je ne suis pas un spécialiste et je me trompe peut-être ... ???

Et si vous voulez un exemple pour le x264:
http://x264.nl/x264/changelog.txt
 
commit 2f0384dcd68bb85f98fb566b70b863b40082c83e r2102
Author: Loren Merritt <pengvado@akuvian.org>
Date:   Mon Oct 10 05:42:36 2011 +0000
 
    SSSE3/SSE4/AVX 9-way fully merged i8x8 analysis (sa8d_x9)
    x86_64 only for now, due to register requirements (like sa8d_x3).
     
    i8x8 analysis cycles (per partition):
     penryn sandybridge bulldozer
    616->600  482->374  418->356  preset=faster
    892->632  725->387  598->373  preset=medium
    948->650  789->409  673->383  preset=slower
 
commit 46d1f3ab24e8aead7ccb3f89a382e7c92721ba96 r2101
Author: Jason Garrett-Glaser <jason@x264.com>
Date:   Fri Sep 30 19:09:19 2011 -0700
 
    SSSE3/SSE4/AVX 9-way fully merged i8x8 analysis (sad_x9)
    ~3 times faster than current analysis, plus (like intra_sad_x9_4x4) analyzes all modes without shortcuts.
 
Avant cette revision les fonctions d'analyses des blocs i8x8 ne pouvaient pas utilser les instructions SSSE3/SSE4/AVX (certainement optimisées MMX/SSE/SSE2 précedement). Cette révision à permis un calcul trois fois plus rapide pour la fonction intra_sad_x9_4x4 dans le code x264.

Non elle n'est pas utilisée, nous l'avons volontairement laissée de côté pour éviter d'accentuer les écarts.

Comme nous l'avons expliqué dans l'article, x264 est un cas à part (que nous avons d'ailleurs traité à part) dans le sens où il dispose d'un dispatcher interne et de codepath assembleur pour différentes architectures. L'exemple que vous donnez est issu de cela, il s'agit d'une fonction optimisée en assembleur. Tout le code de x264 n'est cependant pas dispatché.  
 
On peut également compiler x264 en desactivant ces fonctions assembleur. Un code générique en C est alors utilisé.  
 
Nous avons testé dès lors deux choses. D'une, est-ce que la génération de code SSE/AVX (pour le code qui n'est pas écrit en assembleur) peut avoir un impact sur les performances (la réponse étant oui, de légers gains) ? La seconde consistait à regarder, pour la version sans assembleur, ce qu'était capable de produire GCC comme optimisations via ses algorithmes de vectorisation automatique (dans ce cas, une baisse de performance par rapport au code générique).

ça me rappel l"époque de x86 secret, ça fait du bien!!!

Il fait pqrler de lui cet article:
http://www.realworldtech.com/forum [...] 3&roomid=2

L'article donne une idée de ce qu'est l'optimisation sans tomber dans le trop c'est trop. On sent bien qui si on rajoute bientôt la compilation AMR en plus, et les processeurs à dizaines de cores, ça va être sympa.
 
Sur ma calculette (du genre 8bits à 1khz), j'avais une boucle de suite récurrente qui n'allait pas vite.
J'ai commencé par calculer 2 termes de la suite dans la même boucle et avancer de  2 pas-> ça accéléré pas mal. Je suis passé à 3 termes, c'était encore plus rapide. Je suis passé à 4 et là, boom, c'était très lent. J'ai compris que je venais de dépasser le nombre de de variables contenues dans le cache le plus profond du processeur.
 
Quand un programme tourne seul, c'est une chose, mais quand il en en multitâche, c'est plus compliqué (les gros lag des accès disque par exemple).
 
Pour optimiser un programme, les instructions pour charger des variables en cache sont apparues, mais comme pour un rien, tout le monde mettait tout en cache, ça n'accélérait plus rien.  
 
Donc une recette qui marche ne marche n'est pas forcément répétable à l'infini.

Bonjour,
 
Cet article est très intéressant, d'autant plus que le sujet n'est pas traité si couramment...
 
Par contre, une petite question me taraude. MinGW montre de grosses faiblesses côté optimisation en C++, ce qui n'est pas très logique... Voici donc la question :
Avez-vous recompilé TDM-GCC pour chacune des architectures?
 
Je pense que ça pourrait avoir une certaine importance étant donné que les binaires fournis pour TDM-GCC, le sont pour la seule architecture i686, soit pentium pro (pas de SSE, SSE2, ...).
 
Quoiqu'il en soit je trouve que cet article est une excellente initiative!

La seule chose que recompiler TDM-GCC changerait, c'est le temps de compilation. Le code généré resterait strictement identique. Donc non, cela ne présentait pas d'intérêt de le faire.

 
OK, merci pour cette réponse (rapide qui plus est ).

pas mal l'article. Est-ce que les testes sont fait en 32bits? les ABI windows/linux changent pas mal avec x64 et x87 n'est plus utilisé directement.

Il existe un autre compilateur que les 3 grands: PGI capable d'optimisaton poussé...
http://www.pgroup.com/
  y a t'il une raison de ne pas l'avoir inclu? Est-t'il possible de l'inclure?

Article très certainement commandé et payé par intel. Les tests sont bidons. Finalement le message c'est quoi. Récemment Intel a eu des problème quant au fait qu'ils optimisé moins bien les processeur AMD. Cour dur pour leur réputation il fallait réagir. Cet article fait parti de la réaction. Quel est la conclusion ? Intel c'est le meilleure, et Intel c'est même plus performant avec AMD qu'avec leurs propres processeurs, alors qu'ils optimisent moins pour les procs AMD, ils l'ont avoués, reconnu. Comment c'est possible ? Ça c'est ce que l'on appelle de la propagande, c'est de la pub déguisée en information.

L'article ne dis pas le choix à faire sur le compilateur Intel ou Microsoft.
Premier commentaire, et dernier ?
 

déterrage de première par un adepte du complot...
 
et en quoi ces tests seraient bidon? argumente un peu...

 
Tu fais référence à ses commentaires là bas ?
 
http://www.leparisien.fr/reactions [...] 932323.php

 
Multi d'abw spotted

ça veut dire quoi ?

Un très bon article dont je me demandais si une mise à jour est prévue, un de ces quatre matins avec les derniers processeurs Intel et AMD.