Bonjour,
 
   Comme indiqué dans les news HFR, intel viens de sortir une nouvelle version de ses compilers dédiés pour ses processeurs.  
 
Ma question : Est ce que ça vaut le coup d'installer ce compiler pour recompiler quelques services et le noyau, ou alors est ce que GCC est déjà presqu'aussi performant que les compilos Intel ?

Ben je pense pas que gcc sache optimiser le code pour l'hyperthreading par exemple.
Mais si tu n'as pas ce type de processeur, je ne suis pas sur que tu gagnes grand chose.

Si tu ne fais pas de la simulation, c'est ptet pas la peine de se faire chier

G un bipro, donc c le meme principe que l'hyperthreading. HFR parle quand meme de 40% (au maximum) de perfs en plus
si j'ai bien compris, il transforme le code mono-threadé en code multi-threadé, mais lorsque l'on active le support smp du noyau, est ce cela ne reviens pas un peu au meme (en ce qui concerne le noyau uniquement biensur) ? Pour les services comme apache, vu qu'il y a des fork() d'effectués, je ne pense pas qu'il soit nécessaire de l'optimiser pour le smp.

Si tu as un bipro (ce n'est pas tout à fait pareil que le HT qui ne fait que "simuler" 2 procos->c'est pour ça qu'il nécessite un compilo un peu spécial), il vaut mieux compiler avec gcc en mode multipros (smp) à mon avis.

quand je disais que c'était le meme principe, je parlais "virtuellement" biensur, l'hyperthreading fait voir 2 proc à l'os alors qu'il n'y en a qu'un, et le bipro, l'os en voit 2 alors qu'il y en a 2 . Mais le principe d'optimisation du code reste le meme, : paralleliser au maximum les différentes fonctions d'un meme programme.

tu devrais tester!  
moi ça m'interesse bien de savoir ce que tu gagnes.
je l'ai dl c'est assez rapide et ça à pas l'air chiant à instaler. (ici j'ai qu'un mono amd donc je ne l'ai pas fait...)
 
c'est un bipro intel ton pc ?
 
je savais pas qu'ils faisaient des compilos (surtout gratos pour les trucs non commerciaux), mais ça m'a donné envie d'acheter intel pour ma prochaine config perso rien que pouir avoir le compilo qui va bien avec....    
 
essaie !!!!!

notre bon vieu gcc 3.2 est quand meme tres honorable
 
et a mon avis, il va l'etre de plus en plus !

bah ouais mais justement ça ferait une bonne comparaison.
je pense qu'intel connait bien ces procs et ce compilo c'est un peu pour montrer qu'ils vont plus vite que les autres donc il doit y avoir pas mal d'optimisations...
 
edit : totograf

G un bipro amd : mais là le compilo intel n'y pourra rien
G aussi un bipro intel, mais c'est pas un truc de tueur : 2 PII 350, je peux essayer en compilant le meme noyau avec plusieurs compilos, mais comment mesurer les différences de perfs ?

j'avais pas vu que c'était le noyau que tu voulais recompiler....
je sais pas trop comment mesurer les différences de perfs là.
 
Tu peux déjà tester sur un de tes programmes si tu codes, pour voir.
sinoin moi je pense que je testerais sur un trucs à moi qui est bien long d'habitude, mais pas aujourd'hui.

Bon ben je crois qu'il n'y a pas besoin de faire des tests :
 
trouvé sur le site intel :

 
gcc 3.2 avec les flags "-O3 -mcpu=pentiumX -march=pentiumX -mfpmath=sse -msse" ?
 
Parce que s'ils comparent à une compilation gcc sans optimisation pour Intel, ça n'est pas très intéressant...
 
Sinon je suis intéressé si quelqu'un fait un test, pour le SMP je ne suis pas convaincu par contre, faudra que j'essaye un jour voir...

on voit souvent le fram_omit_pointer ou un truc comme ça aussi
ainsi que le inline_function mais là ça dépend du prog, ça peut prendre bcp de place du coup

ouais, c'est ça justement qui me turlupine (si je puis me permlettre) un tel ecart parait impressionant, soit leur test est truqué, soit c'est vraiment de la balle.
 
En gros : qui a une idée pour tester la performance de son noyau ?

-fomit-frame-pointer

euh c koi : -fomit-frame-pointer ?

 
et pkoi y'a pas d'amd compiler ?

ayé ! j'ai retrouvé :
http://forum.hardware.fr/forum2.ph [...] h=&subcat=
http://casteyde.christian.free.fr/cpp/benchmarks/

Ils font déjà les meilleurs proc, ils vont pas en plus faire les meilleurs compilos  
 
PS : pas de troll Intel vs AMD svp

  Il a des soucis le rechercher du forum, j'avais fais une recherche sur intel et il m'a dit : que d'alle !!!

 
moi j'ai mis "compil*"
mais le rechercher est pas toujours très précis, çai sur

 
C'est peut être au moment où la table de recherche était cassée

 
Merci, excellent
 
Hum, les résultats ne sont pas vraiment du même ordre que ce qu'annonce Intel ( en fait ça m'étonne pas du tout )

 
si y a gcc qui optimise deja tres bien  ( tres bien dans la version 3.2)  
 
gcc -march=athlon-tbird/xp ...  ( au passage les flags -mmmx / -msse sont inutiles , ils sont implicites , gcc les deduits de l argument -march= )

 
athlon-mp aussi
 
Par contre y'a des benchs pour voir la différence entre avec et sans ces optis ?

A noter que le comparatif présenté plus haut est réalisé avec la version 6 de icc alors que c'est de la version 7 dont parle le gars du cern plus haut. Toutefois, la différence ne doit pas etre énorme.
 
A priori le seul inconvénient que l'auteur du test trouve a icc c'est de ne supporter que les proc intel ( ). Dans notre cas (le mien tout du moins) ce n'est pas un inconvénient puisque l'on souhaite optimiser le code pour une machine donnée (la notre en l'occurence). Malheureusement le test porte sur des fonctions particulieres et comme je ne suis pas suffisament expert en la matiere (voir pas expert du tout ), je ne saurait pas interpreter le resultat par rapport au fonctionnement du noyau. Il faut donc trouver une methode de test du noyau pour avoir une mesure en cituation réele.
 
S'il y en a parmis vous qui font de l'encodage divx sur du linux et qui peuvent faire le test : encodeur compilé avec gcc et icc, et voir la durée d'encodage pour les 2, je pense que nous aurions une bonne idée de l'affaire...

pour le divx, pour la version 6/7 ou en général ?
 
le probleme c'est qu'on a pas de données précises...

Au contraire, il faudrait rechercher sur Ace's Hardware, mais j'ai déjà vu que le compilo Intel améliorait aussi les performances des Athlons par rapport à un autre compilo ('me souviens, ça devait êter un gcc 2.95, mais je n'en suis pas sûr).

juste une question :
 
Il est en quelle licence le compilo Intel ? Il est libre ???
Et quel est l'impact réél en performance pour du code pas optimisé ?
 
Nan parce que j'aile souvenir d'echos assez negatifs sur les anciennes version de compilos Intel, et il me semblait qu'ils n'etaient pas du tout libres, mais je peux me tromper
 
Enfin dans ce cas, hors de question pour moi de compiler du code GPL avec un compilo non libre, ca serait un non-sens, et pour qqchose d'aussi "sensible" qu'un compilateur, je ne veux pas dependre du bon vouloir d'une societe comme intel pour les eventuels patchs

Ben je pense pas (libre dans le sens open-source).

C'est justement ce qu'on cherche a savoir...

Rassure moi, le code de ton bios, et ceux des firmwares de tes différents périphériques sont GPL...

voir ça pour les pentium4 et les optimisations avec gcc
http://www.andrew.cmu.edu/~komarek [...] yPerf.html
 
j'avais testé et une faisait une grande différence mais là je me rappelle plus

 
 
C'est pas la même chose !
Pour ceux ci, je n'ai pas le choix, ils sont dans 99% des cas fermés, je suis d'accord...
 
Mais compiler un noyau linux avec un compilateur non-libre par exemple, je trouve qu'il y a dans cette phrase un truc qui ne va pas

OK, mais là c'est purement phylosophique

Comme le disait je sais plus qui sur un autre topic, compile un code GPL avec le compilo intel fermé et remonte un bug sur une mailing-liste, tu vas voir comment tu vas etre reçu
 
Sinon, c'est pas que philosophique : quel interet de payer 400$ pour un outil dont on a un equivalent libre et gratuit avec un historique et un suivi excellent pour passer a une version fermée dont les bénéfices rééls restent encore à demontrer ?
 
Mais c'est vrai que compiler du GPL avec ICC, moi ca me fait bizarre... c'est comme si tu compilais du GPL sous Visual C++, c'est antinomique et tu ne peux pas prevoir quels bugs vont venir du compilo et quels bugs viennent du source...

Tiens, justement, il y a une dépêche sur Linuxfr.org qui compare Gcc 3.2.1 et Icc 7.0. En fait, allez lire les commentaires, il y a quelques tests intéressants, dedans.

 
dans le test il utilise ça le gars :
-funroll-all-loops
mais dans le man ils disent que ça ralentit le prog final !!?
ça sert à quoi, j'ai pas compris l'explication
 
EDIT : il est chiant le test, on sait pas si c'est mieux quand c'est plus élevé ou pas. et ça fournit des résultat étrange.
ça par exemple :
 

 
 
le dernier qui est censé être bien est le seul à avoir un nombre plus grand pour le résultat en c++

Ben, dans l'idée, le -funroll-all-loops, c'est ça :

Là, la boucle demande 1 première affectation (i=0), une comparaison à chaque itération (i est-il inférieur à 4 ? ), une incrémentation à chaque itération (i++), une opération par itération (i+1), une autre affectation par itération, et un saut pour faire une boucle, ce qui, à la louche, fais une vingtaine d'opérations.
Si maintenant j'écris ce code ainsi :

Il fait exactement la même chose, or, il ne fait que 4 affectations, ce qui est nettement plus optimal, non ?
 
Après, le problème, c'est que si au lieu d'affecter un tableau à 4 entrées, je dois affecter un tableau à 1 million d'entrée, le fait de dérouler la boucle va me générer un code tellement gros qu'il ne tiendra plus en cache, et l'on risque de perdre en performance. Et il n'y a pas que ce cas qui pose problème. Donc, c'est à voir de manière empirique au cas par cas (ça dépend aussi du nombre de registres disponibles, donc ça change selon l'architecture, à savir 8 sur x86, c'est riducule, et le fait de dérouler les boucles sera moins optimum que de dérouler les boucles sur un PowerPC disposant de 32 registres ...)

pour le nombre de registres ca devrait s'arranger avec le hammer
 
je sens que quand on aura un beau gcc optimise hammer, ca va tracer !

 
ah condition qui nous crame pas entre les doigt !
hors de question que j'achete une nouvelle fois un proco qui nécessite un turbine d'avion pour se faire refroidir
le silence passe avant les perf chez moi, donc ils ont interet d'y prendre garde pq avec le cpu que je me trimballe en ce moment, c'est pas la joie...