Nouveaux Processeurs et optimisation (question par pure curiosité)

[urdle]

Bonjour à tous,

Je viens de tomber sur le dossier de PCI sur l'Haswell, et je me posais une question.

Aujourd'hui, comment fait le compilateur pour se dépatouiller des milliards de combinaisons d'optimisation du genre "sur l'intel machin, on peut maintenant faire des multiplications entre les registres E et F", etc. Est-ce qu'il cherche à créer des optimisations et génère un code (les .exe pour windows par exemple) contenant différentes versions pour différents procs ?

Au final, est-ce qu'un programmeur s'embête à prendre en compte ces optimisations ?

Est-ce que des plateformes "pré-compilées" style C# ou Java arrivent à prendre en compte de telles optimisations alors que jamais un programmeur Java, lui, ne va s'amuser à prendre en compte le nombre d'opérations similaires qu'il va regrouper ("oh, j'ai 4 additions et 2 comparaisons, je vais grouper les additions des fois qu'un proc saurai faire les 4 d'un coup"... y'a des gens qui font ça ?)

J'imagine que les seules à pouvoir optimiser quoi que ce soit, ce sont les dev' de drivers ou ceux de moteurs genre l'unreal engine, mais le reste, j'ai un doute.

Merci d'éclairer ma lanterne de mec qu'a arrêté de faire du dev' sérieux y'a 10 ans.

[RaphAstronome]

À moins que tu programme en assembleur c'est le compilateur qui fait ces optimisations.

[foetus]

Oui le compilateur fait des optimalisations: regardes le mot clef volatile en C++

Depuis toujours avec le compilateur gcc tu peux choisir la plateforme finale

Et en faculté, on m'a appris cela: "Toujours faire le code le plus simple, ne faire que les optimisations après que tout fonctionne"

Pourquoi? parce que le compilateur fera de meilleures optimisations (du code) que n'importe quel humain peut faire

Un développeur pourra faire des optimisations, mais ce sera des tâches très compliquées: paralléliser son code, trouver un meilleur algo, réorganiser ses conditions ou ses valeurs, éviter de faire des choses en trop...

[urdle]

Certes mais ça veut dire que de manière générale en fait aucun programme ne sera optimisé pour tel ou tel processeur ? ou bien qu'il choisissent de compiler pour la version qui a le plus de chance d'être optimisée pour le plus de monde ?

Du coup, l'apport de toutes les petites nouveautés qu'intègre Haswell (mais attention, pas tous les Haswell, juste la version truc), quand est-ce qu'on va avoir un programme "du marché" (que ce soit un programme assez répandu chez les pro ou les particuliers) qui exploite ce type d'optimisation ?

[foetus]

Les fonctionnalités d'un processeur peut être utilisées en utilisant "les bons outils": Intel Math Kernel Library, Intel Parallel Studio 2011, Intel Parallel Studio XE, ....

Je pense que lorsque tu touches le grand public, les développeurs s'en fichent des optimisations (*). Ils préfèrent le portage.

Mais lorsqu'on arrive dans des domaines de pointe/ de niche, là effectivement il faut faire les bons choix. Cela peut faire gagner du temps, de l'argent, de l'humain.

* -> Quoique il y a des jeux optimisés NVidia ou AMD

[moomba]

Je me permet de donner mon retour d'expérience car pour le coup c'est mon domaine.

Je parle ici du calcul massif, destiné au domaine de la recherche et du super calcul (> 1000 processeurs simultanément).

Déjà tous les compilateurs ne sont pas capables d'utiliser les jeux d'instructions et d'optimisations des derniers processeurs.

Par exemple, un gcc 4.6.x n'utilise pas correctement les SSE 4.x face au compilateur Intel 11, 12 ou 13. Les branches 4.7 et 4.8 sont plus performantes (nottament la 4.8 avec l'arrivée du mode Graphite par défaut) Il y a donc plusieurs facteurs à prendre en compte :

- La version du compilateur.

- La simplicité du code (comme le dit foetus), car plus le code est simple, mieux le compilateur vas interpréter la ligne de code et l'optimiser. A noter que étrangement, développer certaines boucles aide le compilateur à optimiser le code, il faut savoir les reconnaitre.

- Le language du code (le C, C++ et le Fortran s'optimise très bien, surtout le fortran si les boucles sont écrient au format vectoriel)

- Les options de compilation choisies.

Prenons un programme de base.

Première étape, on purge tous les trucs de base : limiter les divisions, sortir les opérations redondantes des boucles, etc.

Seconde étape, faire attention au stripping, car même le compilateur ne sais pas optimiser ça.

Ensuite, monter en niveau d'optimisations et vérifier la bonne opération du code. Certains codent plantent au dessus d'un certain niveau (souvent O3).

On commence par faire tourner le code en debbug lourd, puis on le passe en -O2, et -O3. Le compilateur optimise déjà pas mal le code.

Ensuite, en fonction du compilateur, il est possible de spécifier certaines instructions précisément (par exemple l'option -xSSE2 force l'utilisation des SSE2 sur le compilateur intel), voir on laisse le système s'optimiser lui même avec -fast qui tune le code pour l'architecture de la mahcine, mais dans ce cas le binaire est moins portable (mais en supercalcul on s'en balance).

Certains code de mécanique des fluides ressemble très fortement niveau opérations aux traitements vidéo/image (dériver un champ revient à appliquer un filtre). Le compilateur repère alors que la boucle concernée peut tirer partie des options type SSE/AVX et optimise les opérations tout seul.

Dans la très grande majorité des cas, le compilateur (surtout celui d'Intel) fait mieux que toi. Autant faire simple et le laisser faire en lui donnant des options de compilation fortes. Ne pas hesiter à confronter plusieurs compilos, il arrive que gcc soit plus rapide que intel.

Après, tu peut aussi utiliser des libs externes type MKL pour intel (déjà compilées) ou BLAS/SCALAPACK etc qui sont optimisées et possèdent des flags de préprocessing pour les tuner sur AVX ou SSE4/2 etc. Les gains peuvent êtres astronomiques car ces libs sont optimisées au rasoir et optimisent la gestion des niveau de cache (qui est le goulet d'étrangement numéro 1).

Après, pour finir, soyons honnète : la plupart des codes qui tournent sur supercalculateurs sont codés avec les pieds, ne sont pas du tout optimisées, et la moitié des utilisateurs ne sait même pas qu'il existe des options de compilations, sans parler des bugs ou des IO en plein milieu des boucles.

Voilà, si ca peut déjà te donner une idée.

("oh, j'ai 4 additions et 2 comparaisons, je vais grouper les additions des fois qu'un proc saurai faire les 4 d'un coup"... y'a des gens qui font ça ?)

Et oui, il y a pas mal de gros utilisateurs qui sont concernés pas les limites des machines (les grosses équippes) qui tunent leur code avec du pre-processing.

Au lieu d'avoir :

do i=1,x   A(i) = B(i) + C(i)*A(i)end do

Il y en a qui déroulent la boucle sous la forme :

do i=1,x,4   A(i) = B(i) + C(i)*A(i)   A(i+1) = B(i+1) + C(i+1)*A(i+1)   A(i+2) = B(i+2) + C(i+2)*A(i+2)   A(i+3) = B(i+3) + C(i+3)*A(i+3)end do

A première vue les additions vont augmenter le nombre d'opérations, mais le compilateur comprend tout de suite qu'il s'agit d'une boucle utilisable avec les AVX, ce qui n'est pas forcément le cas la première fois. Tu prend un facteur 2 à 3 d'un coup en accélération sur la boucle (non négligeable si la dite boucle prend 90% de ton temps de calcul).

[brice.wernet]

Certes mais ça veut dire que de manière générale en fait aucun programme ne sera optimisé pour tel ou tel processeur ? ou bien qu'il choisissent de compiler pour la version qui a le plus de chance d'être optimisée pour le plus de monde ?

Du coup, l'apport de toutes les petites nouveautés qu'intègre Haswell (mais attention, pas tous les Haswell, juste la version truc), quand est-ce qu'on va avoir un programme "du marché" (que ce soit un programme assez répandu chez les pro ou les particuliers) qui exploite ce type d'optimisation ?

En fait, pour les programmes pour lesquels on souaite être optimisé, certaines parties sont compilées plusieurs fois, et au démarrage le programme cherche le chemin qu'il doit prendre (ce qu'il doit exécuter sur la plate-forme) = code path.

Exemple: cod epath "MMX" code path "SSE", code path "SSE3"...

On le trouve aussi dans les codec vidéo.

C'est aussi le problème pour les jeux vidéo et les cartes graphiques qui partagent le même code, mais n'ont pas du tout les mêmes performances.

L'autre solution, c'est les applis compilées pour une machine qui n'existe pas: Java, .Net. Mais là, les machines virtuelles sont si limitées en instructions qu'on n'utilise encore au mieux que le jeu d'instruction SSE du P3/P4. LLVM va (beaucoup) plus loin, mais elle eest plus destinée à être intégrée dans le soft (exemple: couche OpenGL de Apple qui se "recompile" à la volée)

Dernière solution: les compilateurs spécialisés, comme les compilateurs Intel. Mais dans ce cas, exit les AMD.

[lorinc]

Petit retour d'expérience perso aussi :

1°) Java ne vectorise rien du tout. C'est peut-être prévu pour Java 8, mais pour l'instant nada. Les calculs se font avec l'unité SSE, mais en scalar, pas en packed, donc intérêt proche du zéro absolu.

2°) gcc vectorise extrêmement mal (du moins jusqu'à 4.7, pas testé le 4.8 . Même avec un typage fort (i.e. pas de template) pour des opérations assez simple d'algèbre linéaire, il est souvent incapable de vectoriser à cause d'un possible aliasing. On peut rajouter plein d'options et de mots-clefs dans le code mais ça devient tellement illisible et peu portable que ça ne vaut franchement pas le coup.

3°) Les intrisics sont plutôt faciles à manipuler. Ok, il faut se taper la doc d'intel et suer un peu, mais c'est incomparable avec de l'assembleur en terme de rapidité de dev. Et c'est de loin les meilleurs perfs

4°) icc : la rolls, mais si ton code fait plus de 100k lignes, il va falloir prévoir un certain temps pour arriver à le faire compiler, car il est moins gruik friendly que gcc.