Cette version du compilateur du projet GNU, initié par Richard Stallman, est particulièrement importante et a été testée depuis des mois de façon intensive par les distributions car elle sera le compilateur utilisé par Fedora 9, par OpenSuse 11.0 et par Debian Lenny - ce message détaillé donne une bonne idée du travail ayant lieu actuellement chez Debian pour pouvoir utiliser GCC 4.3 dans la future version stable de la distribution.
Ci-dessous, les nouveautés concernant GCC, gfortran, gcj et les optimisations mises en oeuvre.
![[en]](../images/en.png)
GCC (418 hits)-
Les nouveautés de GCC 4.3 (1551 hits)
-
Portage du code vers GCC 4.3 (507 hits)
-
La bibliothèque arithmétique GMPLib (319 hits)
-
La bibliothèque de calcul de précision MPFR (341 hits)
> Lire la dépêche (137 commentaires, moyenne: 3,4).
Vous avez demandé le commentaire #913101.
Run by 
Cette page a été générée par Templeet en 0.065s (dont 0.005 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Auto vectorisation
Comme précisé dans cette news somptueuse, l'autovectorisation est en standard dans Gcc 4.3. On l'attendait avec impatience.
Qu'est-ce que c'est exactement :
Pour pas mal de type de boucle (celle-ci : http://gcc.gnu.org/projects/tree-ssa/vectorization.html#vect(...) ) Gcc va être capable de produire du code MMMX, SSE, ou altivec sur powerPC. Voire, d'après ce que j'ai compris, du SPU du cell.
Ceux qui veulent lire des vidéos HD sur leur linux installé sur la PS3 vont être content (parce que pour avoir passé une après midi à essayer de le faire marcher, faire accéder au codec le spu du cell, c'est mission impossible).
D'après cette note http://gcc.gnu.org/wiki/AutovectBranchOptimizations , la vectorisation est automatique. Gcc détecte ce qui est optimisable dans le code.
Ca veut dire, que ça risque d'être très intéressant de recompiler pas mal de logiciels gourmand en calcul avec cette nouvelle version de gcc.
La 4.2 gérai un peu de vectorisation, mais de manière très limitée et à condition qu'on active le switch correspondant.
Il va y avoir des benchs à refaire...
[^]Re: Auto vectorisation
Et comment est-ce que ça gere les histoires d'alignement ? pour que SSE, Altivec et cie soient efficaces il faut que les données soient correctement alignées en mémoire (sur un multiple de 16 bytes), comment fait -il quand il ne voit qu'un "float*" ou un "double*", par exemple pour vectoriser ce genre de fonction:
void saxpy(float a, float * restrict x, float *restrict y, int n) {
for (int i=0; i < n; ++i) y[i] += a*x[i];
}
?
[^]Re: Auto vectorisation
D'après ce que j'ai compris, il retrouve les données de départ par analyse de flot (du pauvre, parce que SSA, c'est assez limité), et si elles sont pas trop loin, il les alignent.
Je suppose qu'il aligne toutes les données, de toutes façons.
[^]Re: Auto vectorisation
Warning : j'y connais rien, ce ne sont que des suppositions.
En même temps ici il ne voit pas qu'un float * et un double *, il voit que ce sont des tableaux, rien que syntaxiquement ( x[n] ).
Après il faut détecter que chaque tour de boucle ne dépend que de "i", l'indice, et que a est constant, en gros que rien à part l'indice ne dépend d'un tour de boucle précédent.
Du coup tu peux parralelliser le tout sachant que ça doit être un "pattern" dans une boucle, détectée par le compilateur : Rien qui ne dépend du tour de boucle précédent, un indice qui accède à des adresses consécutives en mémoire, une taille constante (n).
Après, pour savoir ce que tu dois aligner, tu dois avoir un moyen déterminer les variables tableau/pointeur à l'appel de la fonction ... par analyse de flot par exemple, pas forcément dans tous les cas, comme le disait Ontologia. Sûr que si c'est de l'allocation dynamique t'as intérêt à ce que ce soit aligné "de base".
[^]Re: Auto vectorisation
> si c'est de l'allocation dynamique t'as intérêt à ce que ce soit aligné "de base".
C'est un bon exemple, puisque ce n'est pas le cas: sous linux, malloc renvoie des addresses alignées sur 8 bytes, pas sur 16, donc on a une chance sur deux d'avoir un buffer mal aligné (sous macos par contre malloc renvoie toujours un buffer bien aligné).
Maintenant il y a des situations où avec la meilleur volonté du monde, le compilateur ne peut pas savoir que les addresses qu'il recevra seront bien alignées. Si par ex. ma fonction saxpy fait partie d'une bibliothèque (qu'on pourrait appeler "blas" pour fixer les idées..), eh bien à ce moment que peut faire le compilateur ? gerer tous les cas ? (x bien aligné , mais pas y, x et y bien alignes, etc). Je crois que c'est ce que fait la lib http://math-atlas.sourceforge.net/ , mais ça me semble difficilement envisageable pour un compilateur sinon bonjour le bloat.
[^]Re: Auto vectorisation
Je ne pense pas que gcc puisse aligner ce qu'il faut. Il va générer une entrée de boucle scalaire et une sortie aussi scalaire. Le milieu seulement sera vectoriel avec les accès aligné.
[^]Re: Auto vectorisation
Le milieu seulement sera vectoriel avec les accès aligné.
Si il n'y a qu'un operande je peux le concevoir, mais quand il y a deux operandes (comme dans saxpy), ou plus, ça devient très compliqué, à moins d'en provilegier une et d'accèder aux autres de façon non alignée.
[^]Re: Auto vectorisation
oui, c'est compliqué. L'autovecorisation de gcc est faite pour ceux qui y font attention sans devoir faire de l'asssembleur à la main. C'est déjà pas mal.
[^]Re: Auto vectorisation
Comme toujours avec les histoires d'alignement: il génère un prologue et un épilogue qui gèrent les parties non-alignées
en début et fin de boucle. C'est pareil si on devait écrire ça à la main. Comme ça fait du code en plus il faut en général du profiling ou des
informations statiques pour décider si c'est vraiment utile ou pas de vectoriser la boucle en question. Les JIT ou compilo super fortiche sont
capables de faire du versioning, i.e en fonction du site d'appel d'utiliser une version vectorisé ou pas de la fonction contenant la boucle, voir
d'inliner tout ça. Mais ça demande soit du profiling soit de faire du JIT.
[^]Re: Auto vectorisation
Tiens c'est marrant je viens de découvrir le mot-clé "restrict".
Justement, j'allais demander comment gcc réglait les problemes d'aliasing, et j'ai ma réponse.
Mais alors, il va falloir apporter quelques modifications au code existant afin qu'il soit automatiquement vectorisé : on le voit meme dans les exemples cités plus haut, il faut mettre du "restrict" assez souvent ...
[^]Re: Auto vectorisation
y'a aussi un #pragma ivdep qui existe sur certains compilos et qui dit explicitement que les iterations de la boucle qui suit sont indépendantes, mais je crois que gcc ne le connait pas