Discussion :

[Nanoc]

Bonjour,

Je travaille actuellement sur un projet de physique numérique assez important. Le codage arrivant à sa fin, la périodes des tests et optimisations arrive. C'est ce dernier point qui m'intéresse.

J'ai vu à plusieurs endroits sur le web que le compilateur Intel était meilleur sur les plateformes utilisant ce type de processeurs (Ce qui est mon cas).

- Est-ce que cela veut dire qu'il optimisera mieux le code au niveau rapidité d'exécution que si je le compile avec GCC ?

- Si oui, dans quelle proportion ?

Merci d'avance !

[neismarspra]

http://www.google.com/search?q=gcc+v...ient=firefox-a

apparemment c'est pas des différence énorme, bien sur la plus par des testes son fait sous linux, et en physique ce serra probablement equoitions sur equoitions, et alors la????

mois perso quand j'ai un algorithme long et pas trop chian, je me le tape en asm

[wiztricks]

Essayer de profiler votre code avec gprof par exemple histoire de voir la où vous passez le plus de temps.
Puis si vous pensez que çà en vaudra la peine, essayer de voir s'il n'est pas possible de faire la même chose, plus vite.
En dernier ressort, incriminez le compilo.
- W

[PRomu@ld]

Tout à fait d'accord, il faut profiler le code avant de chercher la petite bête avec le compilateur.

Concernant le comparatif icc/gcc il peut partir en troll attention. Pour avoir personnellement testé les deux, je peux dire d'une part que le compilateur intel compile plus vite (c'est pas négligeable sur des gros projets), et qu'ensuite, le code généré était dans bien des cas plus rapide. Néanmoins, il n'est pas toujours possible de l'avoir sur sa plate-forme de manière gratuite, et nos tests n'ont pas été très étendus, alors pas de conclusion hâtive. Mais ne serait-ce que pour le temps de compilation, j'aurai tendance à le préférer à gcc.

[wiztricks]

Je dirais qu'a cette étape du projet vous commencez a avoir un code qu'on peut commencer à secouer un peu. Un outil comme gprof va vous donner des pistes pour prioriser les routines à améliorer.

Les gains potentiels en retouchant l'algorithmique peuvent être assez importants surtout si vous êtes passés à côté de certaines aspects de la dynamique de votre programme: pas possible de le vérifier autrement.

Si ce n'est pas le cas, ou si les seules améliorations de ce côté sont des chantiers longs (et donc risqués et coûteux), il sera sans doute plus rapide d'augmenter la capacité de traitement, d'acheter un compilo plus performant.

Mais si vous passez votre temps a attendre les retours d'IO (je caricature), çà ne servira à rien... C'est d'abord pour avoir ce type d'infos que le profiling est intéressant.
- W

[JolyLoic]

En dernier ressort, incriminez le compilo.

Bof, le tout est de faire un bilan coût/gain/risque. Si le code est propre, le coût d'un changement de compilateur est à peu près nul (pour une entreprise, bien entendu), et donc même si le gain est faible, je ne vois pas pourquoi s'en priver.

[Charlemagne]

J'utilise le compilateur Intel sous Windows (ICL) depuis pas mal d'années (depuis la version 4). A l'origine je voulais surtout avoir un compilo qui puisse compiler toutes les subtilités des templates, parce que VC6 ou VC7 étaient très loin du compte.

Sur du code C pur, je ne pense pas que ICL fasse vraiment beaucoup mieux que Visual ou GCC. Par contre sur du code C++ générique et des intrinsics SIMD, ICL laisse GCC et Visual sur place... Il n'est pas rare que le code d'Intel soit 2x plus rapide dans les cas les plus complexes.

[wiztricks]

Bof, le tout est de faire un bilan coût/gain/risque. Si le code est propre, le coût d'un changement de compilateur est à peu près nul (pour une entreprise, bien entendu), et donc même si le gain est faible, je ne vois pas pourquoi s'en priver.

Effectivement "si le code est propre"....
Pour l'instant, il n'est même pas encore sec alors pour ce qui est de propre, il va falloir encore bosser un peu pour savoir.
- W

[Nanoc]

Merci pour vos réponses.

Nous sommes justement dans la phase "gprof". La question serait quand même de savoir si le profilage donne le même résultat selon le compilateur. Je pense que oui, mais c'est à confirmer.

Le code contient effectivement une grande part de calculs bruts et très peu de "C++", c'est quasiment un copié-collé de code Fortran au niveau des opérations réalisées.

[Alp]

J'avais lu un comparatif sur les optimisations que faisaient les compilos... Et il me semble que le compilo d'Intel se débrouillait très bien, à vérfier.

[Nanoc]

Je suis tombé là-dessus :

http://www.luxrender.net/forum/viewt...d=a&view=print

mais le problème, c'est que je pense pas pouvoir faire usage des options -ffast-maths et autres du même type. Je dois conserver la précision.

La possibilité de compiler une deuxième fois en utilisant le "feed-back" d'une première exécution en vue d'améliorer le tout semble également intéressante. Je n'en avais jamais entendu parler. Est-ce que ça marche réelement aussi bien que l'auteur de l'article ci-dessus le dit ?

[NairodDorian]

Sur du code C pur, je ne pense pas que ICL fasse vraiment beaucoup mieux que Visual ou GCC.

Bien sur que si ICL fait beaucoup mieux que GCC et même Visual.
GCC est une daube en ce qui concerne l'optimisation du code.
Avec VC++ il est indiqué que le code généré essaye d'être optimal pour toutes les puces. Autrement dit le compilo fait en sorte que le code tourne sur un PII comme sur un PIV, Dual core et compagnie de manière optimal.
ICL génère lui en code Excellent / Parfait si on spécifie que l'optimisation doit se faire sur une puce particulière.

Exemple :

Code C,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
int __fastcall demo(int n) {
  return n < 10 ? 1 : 50;
}

Rien de plus simple...
Voyons la différence en VC++ et ICL.

VC++ :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
; ecx = n
xor eax, eax
cmp ecx, 10
setge al
dec eax
and eax, -49
add eax, 50
ret

ICL :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
; ecx = n
mov edx, 1
mov eax, 50
cmp ecx, 10
cmovl eax, edx
ret

Le code généré par ICL (option puce PIV) est beaucoup plus performant que celui généré par MSC++. (voir remarque plus haut)

En résumé :
GCC : Optimisation bof, bof...
MSC++ : Bon / Très bon pour tourner sur toutes les puces.
ICL : Excellent / Parfait pour une puce en particulier. Si on ne spécifie pas de puce en particulier le code est en généralement aussi bon que celui généré par MSC++.

[Charlemagne]

Je suis d'accord avec toi que ICL compile bien mieux que VC ou GCC.
Moi, j'ai remarqué par exemple que les boucles "for" sur des itérateurs sont codées différemment par ICL que par VC. Le code VC est compliqué au possible, le code ICL est limpide et plus rapide...

Mais il faut voir en pratique. Y'a qqs années j'avais lu un article dans un magazine informatique allemand qui comparait ICL8.0 avec d'autres compilateurs. Les gains de performance était de l'ordre de 10%. Conclusion du magasine: ça vaut le coup d'essayer et c'est éventuellement bon à prendre pour une entreprise si ça lui évite de passer du temps pour optimiser du code.

Maintenant ça dépend beaucoup du code source, qu'on lui donne.
Le C ne m'intéresse pas.
Mais je le répète: je remarque que ICL laisse VC et GCC sur place avec du code C++ générique (instructions SIMD, nombreux templates, iterateurs, foncteurs, etc ...).
Effectivement le code généré par ICL me paraît parfait (et clair!)

[Klaim]

Heu... sous VC9 je n'arrive pas a avoir le même code assembleur que toi?

J'ai ce petit programme :

#include <iostream>

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
int __fastcall demo(int n) {
	return n < 10 ? 1 : 50;
}
 
 
int main()
{
 
	int u = 0;
 
	std::cout<< "enter a number > ";
	std::cin >> u ;
	std::cout<< std::endl;
 
	int k = 0;
 
	k = demo( u );
 
	//std::cout << "result = " << k << std::endl;
 
	std::system( "pause" );
	return k;
}

Je me retrouve avec ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
--- e:\tests\test_compile\test_compile\main.cpp --------------------------------
00401002  pop         esp  
00401003  and         byte ptr [eax],al 
00401006  push        esi  
00401007  push        eax  
00401008  mov         dword ptr [esp+8],0 
00401010  call        std::operator<<<std::char_traits<char> > (4011A0h) 
00401015  add         esp,4 
	std::cin >> u ;
00401018  lea         ecx,[esp+4] 
0040101C  push        ecx  
0040101D  mov         ecx,dword ptr [__imp_std::cin (402068h)] 
00401023  call        dword ptr [__imp_std::basic_istream<char,std::char_traits<char> >::operator>> (402048h)] 
	std::cout<< std::endl;
00401029  mov         edx,dword ptr [__imp_std::endl (40203Ch)] 
0040102F  mov         ecx,dword ptr [__imp_std::cout (40205Ch)] 
00401035  push        edx  
00401036  call        dword ptr [__imp_std::basic_ostream<char,std::char_traits<char> >::operator<< (402040h)] 
 
	int k = 0;
 
	k = demo( u );
0040103C  xor         eax,eax 
0040103E  cmp         dword ptr [esp+4],0Ah 
 
	//std::cout << "result = " << k << std::endl;
 
	std::system( "pause" );
00401043  push        offset string "pause" (402148h) 
00401048  setge       al   
0040104B  dec         eax  
0040104C  and         eax,0FFFFFFCFh 
0040104F  add         eax,32h 
00401052  mov         esi,eax 
00401054  call        dword ptr [__imp__system (4020D4h)] 
0040105A  add         esp,4 
	return k;
0040105D  mov         eax,esi 
0040105F  pop         esi  
}
00401060  pop         ecx  
00401061  ret              
--- No source file -------------------------------------------------------------

Je m'y prends peut être mal, j'utilise pour l'instant rarement la vue assembleur sous VS, plus sous Codewarrior, et je suis novice en assembleur, mais a ce que je vois le code de demo est résumé par

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
0040103C  xor         eax,eax 
0040103E  cmp         dword ptr [esp+4],0Ah

C'est bien ça?


Bon en tout cas le compilo d'intel serait effectivement le plus optimizé d'après d'autres spécialistes, je sais pas a quel point c'est vrai mais je n'en doute pas même si apparamment VC et GCC tentent depuis récemment de s'en rapprocher niveau perfs.

[loufoque]

Les gens qui se plaignent de GCC sont généralement des gens qui utilisent des versions obsolètes avec les mauvaises options.

[Charlemagne]

Les gens qui se plaignent de GCC sont généralement des gens qui utilisent des versions obsolètes avec les mauvaises options.

Et il existe des inconditionnels de GCC, sans même comparer...

L'avis de NairodDorian est un peu excessif, mais je le confirme.
J'ai actuellement GCC 4.3.1 sous MinGW.
Sous Windows, GCC est plus lent que VC, lui même plus lent que ICL.

Les points forts de GCC, à mon avis, sont sa rigueur syntaxique et des messages d'erreurs clairs (très important pour la programmation générique), mais certainement pas l'optimisation du code. Mais bon, il est gratuit...

[Klaim]

Sous Windows, GCC est plus lent que VC, lui même plus lent que ICL.

Est-ce que ce n'est pas précisément le fait que ce soit le portage sous windows qui est moins "travaillé" que la version originale?

[three minute hero]

J'ai actuellement GCC 4.3.1 sous MinGW.

La dernière version portée par MinGW est la 4.3.0. De plus, celle-ci est estampillée alpha…
Un peu fragile, comme base de test, non ?

[Charlemagne]

La dernière version portée par MinGW est la 4.3.0. De plus, celle-ci est estampillée alpha…
Un peu fragile, comme base de test, non ?

Non, car j'ai toujours essayé également avec des versions antérieures de GCC et ICL. Rien à faire, GCC est lent par rapport à ICL.
Et toi, tu as quelle version d'ICL, si on peut savoir?

Et je ne pense pas que ce soit dû a un manque de finition sous Windows, car j'avais comparé les perfs sur mon projet mathématique entre GCC sous Linux et Windows y'a environ 3 ans avec les version actuelles de l'époque. Les temps d'exécution étaient sensiblement identiques.

[HanLee]

Sinon, moi niveau performance, je trouve VC++ 2005 aussi rapide que MinGW 3.4.5, sur un algorithme de subdivision de maillage 3D basique.

Je sais pas dans quels cas t'as pu les constater.