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.