Optimisation code SSE sous C++

Version imprimable

11/01/2010, 17h08
Charlemagne

Optimisation code SSE sous C++
Salut

J'utilise habituellement les fonctions intrasics d'Intel pour optimiser du code C++ avec des instructions SSE.
Mais en regardant le code généré en mode release par mon compilo (ICL) , j'ai remarqué que ce n'est pas optimal pour la vitesse sur un point particulier:
Quand une constante est utilisée à plusieurs reprises, le compilo la garde dans un registre SSE pour la réutiliser.

Par exemple, pour ce code simple
Code:

1 2 a=_mm_mul_ps(a,_mm_set_ps1(10)) b=_mm_mul_ps(b,_mm_set_ps1(10))
le compilo génère qqch du genre:
Code:

1 2 3 movaps xmm7,xmmword ptr [KERNEL32_NULL_THUNK_DATA+90h (44C220h)] // charge la constante mulps xmm0,xmm7 // xmm0=xmm0*xmm7 mulps xmm1,xmm7 // xmm1=xmm1*xmm7
Je souhaiterais obtenir:
Code:

1 2 mulps xmm0,xmmword ptr [KERNEL32_NULL_THUNK_DATA+90h (44C220h)] mulps xmm1,xmmword ptr [KERNEL32_NULL_THUNK_DATA+90h (44C220h)]
La stratégie du compilo est peut-être généralement payante, mais dans mon cas c'est plus lent. J'en suis sûr, car quand je modifie dans mon code C++ les valeurs des constantes pour n'en avoir aucune identique, le code généré est plus rapide (mais erroné...).
Mon explication: + de place dans les registres => + de résultats temporaires sont gardés dans les registres => - d'aller retour avec la pile => + rapide

Question: comment forcer mon compilo à compiler à ma manière.
Peut-être en insérant de l'assembleur? Mais je n'ai pas réussi! (Je suis nul en assembleur)
Il me faudrait écrire qqch dans le genre:
Code:

1 2 __asm mulps a, 10; __asm mulps b, 10;
J'ai a priori 2 problèmes:
- je crois pas qu'il soit possible d'utiliser des variables directement avec __asm
- je ne vois pas comment aller charger la bonne valeur de constante
12/01/2010, 12h21
Mac LAK

Essaie peut-être une directive #pragma optimize, pour voir si tu peux désactiver ce comportement temporairement ?

Pour l'inclusion d'assembleur, c'est quand même peu pertinent je pense : d'une part, côté portabilité (y compris vers la prochaine version de compilateur), c'est un nid à problèmes. D'autre part, tu vas certes générer exactement le code désiré, mais tu vas également te priver de possibles améliorations du code.

Côté valeur de constante, je n'ai pas la syntaxe exacte en tête mais l'ASM inline peut accéder aux adresses / contenus de variables C++ sans problèmes. Tu pourras donc charger l'adresse de _mm_set_ps1(10) dans une variable / registre, puis l'utiliser. Direction MSDN pour les détails.
12/01/2010, 12h39
Lavock

Citation:

Envoyé par Mac LAK

. Direction MSDN pour les détails.

Je veux pas paraître tatillon, mais ne posait-il pas la question pour ICC oO ?

D'après les dire d'intel, tu devrait même pas avoir à te soucié de ça, le compilateur prenant en charge non-seulement SSE jusqu'à SSE4, mais est surtout sensé disposé d'auto-vectorisation (source Wikipedia) !

"Parce qu'avec ICC, j'ai pas besoin de savoir que le SSE existe pour l'utiliser correctement !" <= Fausse pub. Mais c'est en partie l'esprit du compilateur.
12/01/2010, 13h08
Charlemagne

Citation:

Envoyé par Mac LAK

Essaie peut-être une directive #pragma optimize, pour voir si tu peux désactiver ce comportement temporairement ?

J'ai essayé en désactivant l'optimisation globale (la seule option dans la liste qui aurait pu correspondre...) sur le code en question mais ca n'a rien changé

Citation:

Pour l'inclusion d'assembleur, c'est quand même peu pertinent je pense : d'une part, côté portabilité (y compris vers la prochaine version de compilateur), c'est un nid à problèmes.

C'est clair que c'est pas top. Mais ca serait pas si problématique que ça: j'aurais bien programmé une petite fonction inline. Ca aurait donné l'impression d'utiliser une intrasic.
Mais je bute clairement sur la syntaxe à utiliser...

Citation:

D'après les dire d'intel, tu devrait même pas avoir à te soucié de ça, le compilateur prenant en charge non-seulement SSE jusqu'à SSE4, mais est surtout sensé disposé d'auto-vectorisation (source Wikipedia) !

"Parce qu'avec ICC, j'ai pas besoin de savoir que le SSE existe pour l'utiliser correctement !" <= Fausse pub. Mais c'est en partie l'esprit du compilateur.

Ca c'est clairement exagéré. Aucune chance de faire plus efficace qu'avec les intrasics. Pour des cas simplissimes à la rigueur et encore... car y'a trop de problèmes à considérer pour qu'un compilo puisse en tirer pleinement parti.
Je pense que c'est tout juste un plus pour ceux qui ne veulent pas savoir comment SSE marche: ils ajoutent l'option de compilation et espèrent un petit gain en vitesse.
12/01/2010, 14h26
Mac LAK

Citation:

Envoyé par Lavock

Je veux pas paraître tatillon, mais ne posait-il pas la question pour ICC oO ?

Tu as raison sur le principe, sauf qu'à moins que ça n'aie changé, les deux compilateurs sont interchangeables... ICL.EXE "remplace" CL.EXE, et le code spécifique VS/CL compile sans sourciller avec le compilateur Intel. La différence se situe au niveau des performances obtenues, mais pas au niveau des sources ou des directives de compilation.

Citation:

Envoyé par Charlemagne

J'ai essayé en désactivant l'optimisation globale (la seule option dans la liste qui aurait pu correspondre...) sur le code en question mais ca n'a rien changé

Mouais... Donc, inutile de poursuivre sur la piste d'un #pragma.

Citation:

Envoyé par Lavock

C'est clair que c'est pas top. Mais ca serait pas si problématique que ça: j'aurais bien programmé une petite fonction inline. Ca aurait donné l'impression d'utiliser une intrasic.
Mais je bute clairement sur la syntaxe à utiliser...

Tu as regardé la doc de l'assembleur inline ? Il y a des exemples d'utilisation de variables / fonctions C/C++ dans le code ASM, normalement...
12/01/2010, 14h41
Charlemagne
Citation:

Tu as regardé la doc de l'assembleur inline ? Il y a des exemples d'utilisation de variables / fonctions C/C++ dans le code ASM, normalement...

J'ai trouvé sur internet pas mal d'exemples SSE en assembleur, mais aucun qui ressemble à ce que je voudrais faire.
Dans l'ensemble, ca se borne à implémenter des fonctions prenant des pointeurs d'entrées et des pointeurs de sorties.

Je ne sais toujours pas utiliser une variable locale en assembleur.
Ce code ne compile pas: (error: __asm 'mulps' syntax error: variable reference)
Code:

1 2 3 __m128 x=_m_set_ps1(10); __m128 y=_m_set_ps1(20); __asm mulps x y
Et je vois encore moins quelle valeur de pointeur donner en deuxième opérande pour le chargement de constante. J'ai l'impression que le compilo se crée une table de constantes, ce qui lui permet d'écrire des chose du genre.

Code:

mulps xmm0,xmmword ptr [KERNEL32_NULL_THUNK_DATA+90h (44C220h)] // xmm0=xmm0*10

PS: J'arrive en partie à mes fins en utilisant une constante et son opposé, puis en échangeant les signes + et - dans les calculs. Le compilo est bluffé. mais le code C++ est moche...
12/01/2010, 18h20
Mac LAK

Tu as essayé en tentant de lui donner une adresse (et non pas une valeur) comme argument, c'est à dire un __m128* ?
12/01/2010, 18h38
Charlemagne

Ca ne marche pas non plus.

Ceci dit, je suis en train de me rendre compte que ce genre d'optimisation est un peu hasardeux. Parfois ca fait gagner un peu en vitesse, parfois pas...
Mais ca montre bien que les compilos sont (un peu) améliorables...
12/01/2010, 19h17
RaphaelSP
Pour ce qui est de l'assembleur en ligne:
lorsque tu utilises une variable, ça revient à une référence mémoire. Les registres eux-mêmes doivent être utilisés explicitement.
Si je veux multiplier x et y entre eux, puis stocker le résultat dans "resultat", je dois y aller avec:
Code:

1 2 3 4 5 6 7 __m128 x =_m_set_ps1(10); __m128 y =_m_set_ps1(20); __m128 resultat; __asm movaps xmm0, x __asm mulps xmm0, y __asm movaps resultat, xmm0
edit: Quant aux optimisations du compilateur, elles correspondent à un cas général. Il y a forcément des cas où ça ne sera pas le plus efficace, mais seule une optimisation guidée par profilage pourra les détecter et les traiter (et je ne sais pas si ICC propose un tel niveau d'optimisation - VC++ le fait, et GCC peut-être).

re-edit: et en ce qui concerne le fait de forcer le compilateur à utiliser la forme "op reg, mem" plutôt que "load reg, mem / op reg, reg"...
C'est un combat permanent et souvent vain. En tout cas, je n'ai toujours pas trouvé comment faire avec VC++ 2005.
13/01/2010, 13h00
Charlemagne

Content de voir que je suis pas le seul à avoir remarqué cette subtilité dans le code généré.

J'utilise ICL sous Windows. Je fait la distinction avec ICC sous Linux (que je n'ai jamais utilisé), même si j'imagine que c'est plus ou moins la même chose sous le capot.
J'utilise pas de profiler, je me contente de lancer des benchs pour comparer les vitesses au fur et à mesure que je modifie le code. J'ai bien VTune à ma disposition, mais je sais à peine l'utiliser, et je ne suis pas sûr que ça me serve dans le cas présent.

ICL semble utiliser systématiquement "op reg, mem" quand la constante n'est utilisée qu'une seule fois. Mais dès 2 fois, il la charge au préalable dans un registre.
J'arrive dans une certaine mesure à forcer la main à ICL en utilisant chaque constante et son opposé. (puis en échangeant des opérations + et - dans les calculs); ça me fait gagner quelques % en vitesse.
Mais rien ne me dit qu'un autre compilo (GCC...) en ferait de même...
13/01/2010, 13h47
screetch

essaye avec AMD CodeAnalyst, il peut aussi lancer des simulations et te montrer ce qui se passe dans le processeur.
Je suis très dubitatif des optimisations a l'aveuglette comme ca...
13/01/2010, 16h30
Charlemagne

Citation:

Envoyé par screetch

essaye avec AMD CodeAnalyst, il peut aussi lancer des simulations et te montrer ce qui se passe dans le processeur.
Je suis très dubitatif des optimisations a l'aveuglette comme ca...

Je n'ai pas CodeAnalyst.
Mais VTune doit bien être capable de faire ça aussi...
13/01/2010, 16h37
screetch

CodeAnalyst est gratuit et un peu plus intuitif que VTune, bien que moins puissant je crois.