Intel et Larrabee

[newbie06]

Rien dans l'immédiat, je pense que pour Intel c'est juste une étape avant quelque chose de plus ambitieux. Il leur faudra bien une archi SIMD éprouvée le jour où ils vont tenter de démocratiser le many-core.

Je ne suis pas convaincu que ce type de machines serve pour le grand public : au final peu de soft ont besoin de faire du flottant, en tout cas à ce niveau de perf. Et s'il y avait un tel besoin de perf flottantes, je pense qu'on aurait vu bien plus d'applications GPGPU grand public.

[fefe]

Je ne suis pas convaincu que ce type de machines serve pour le grand public : au final peu de soft ont besoin de faire du flottant, en tout cas à ce niveau de perf. Et s'il y avait un tel besoin de perf flottantes, je pense qu'on aurait vu bien plus d'applications GPGPU grand public.

/agree.

Je ne suis certainement pas a la page, mais cote grand public en dehors du transcodage video (qui est plus efficace avec un accelerateur dedie inclu dans les 2 dernieres generation de CPU Intel entre autre et qui arrive chez AMD), il y a quoi comme Appli qui fasse du GPGPU. Les applis Adobe comme CS5/6, mais je n'ai pas vraiment vu la difference a l'utilisation (et puis Photoshop c'est pas vraiment grand public), quoi d'autre ?

[Alexko]

De temps en temps, AMD (entre autres) évoque la reconnaissance faciale ou vocale. Mais je ne suis pas entièrement convaincu que ça ait réellement un intérêt pour le grand public non plus.

[Møgluglu]

Je ne suis pas convaincu que ce type de machines serve pour le grand public : au final peu de soft ont besoin de faire du flottant, en tout cas à ce niveau de perf.

Le jeu vidéo ?

[Foudge]

Je ne suis pas convaincu que ce type de machines serve pour le grand public : au final peu de soft ont besoin de faire du flottant, en tout cas à ce niveau de perf. Et s'il y avait un tel besoin de perf flottantes, je pense qu'on aurait vu bien plus d'applications GPGPU grand public.

Tu penses qu'Intel a définitivement abandonné l'idée d'essayer d'en faire un GPU (castré en DP pour ne pas concurrencer les Xeon Phi) ?

[newbie06]

@Møgluglu:

Tu penses qu'Intel a définitivement abandonné l'idée d'essayer d'en faire un GPU (castré en DP pour ne pas concurrencer les Xeon Phi) ?

Aucune idee. Je n'y connais pas grand-chose, mais j'ai quand meme l'impression que sans unites dediees a certaines taches faire un GPU performant est illusoire. J'irais meme un cran plus loin (a prendre avec des pincettes) : il est probable que le parallelisme doive etre bien plus massif pour faire un GPU efficace (les specialistes me corrigeront ).

[Møgluglu]

Moi je ne sais pas. Mais Intel ils ont déjà essayé... et ils ont eu des problèmes.

Pour le parallélisme, ça ne me choque pas plus que ça : 16 (voies SIMD) * 4 (threads SMT) * 8 (threads SoE "fibers") * 50 (cores), ça fait 25600 threads. C'est raisonnable par rapport aux 25000 pour le GF100, 31000 pour le GK110 et 82000 pour GCN. (Je n'ai pas vu de mention explicite du nombre de fibers employés en pratique, sinon que c'est assez pour couvrir la latence de l'unité de texture.)
S'ils arrivent à saturer leur unités de calcul avec moins de threads que les concurrents (grâce à plus d'ILP ou une latence mémoire moyenne plus faible), c'est autant de gagné en localité dans les caches et c'est tout bénef pour eux.

[newbie06]

Pour le parallélisme, ça ne me choque pas plus que ça : 16 (voies SIMD) * 4 (threads SMT) * 8 (threads SoE "fibers") * 50 (cores), ça fait 25600 threads. C'est raisonnable par rapport aux 25000 pour le GF100, 31000 pour le GK110 et 82000 pour GCN. (Je n'ai pas vu de mention explicite du nombre de fibers employés en pratique, sinon que c'est assez pour couvrir la latence de l'unité de texture.)
S'ils arrivent à saturer leur unités de calcul avec moins de threads que les concurrents (grâce à plus d'ILP ou une latence mémoire moyenne plus faible), c'est autant de gagné en localité dans les caches et c'est tout bénef pour eux.

S'quoi le SoE ?

[Møgluglu]

Switch on event. Le modèle d'exécution des shaders de Larrabee prévoyait des basculements de contexte en niveau user entre threads pour couvrir les latences de sampling de texture.
L'idée du scheduling à 2 niveaux n'est pas débile, AMD le fait depuis longtemps et on trouve même des papiers de Nvidia Research qui le réinventent. Le faire en soft a un coût supplémentaire, mais pas forcément délirant.
Ils peuvent donc avoir autant de parallélisme qu'ils veulent. Mais au final, c'est toujours la capacité du cache L1 ou du banc de registres GPU qui va dicter le nombre de threads. Et s'ils sont toujours à 32K de L1D/core, la comparaison n'est pas à l'avantage de Larrabee...

[newbie06]

Et s'ils sont toujours à 32K de L1D/core, la comparaison n'est pas à l'avantage de Larrabee...

S'ils avaient mis autre chose que du x86 ils auraient gagne assez de place pour passer de 32k a 64k. Quoi, je trolle ?

[Møgluglu]

S'ils avaient mis autre chose que du x86 ils n'auraient pas besoin d'autant de cache L1 parce qu'ils auraient un nombre décent de registres et des conventions d'appel potables.

[newbie06]

Bah pour l'ABI c'est du x86_64, y'a pire hein.

Y'a un endroit ou on peut reclamer une carte gratos quand on n'est pas au CERN ?

[Alexko]

De toute façon, il n'y a pas de registres dédiés à LRBni, de la même façon qu'il y a des registres SSE ?

[newbie06]

De toute façon, il n'y a pas de registres dédiés à LRBni, de la même façon qu'il y a des registres SSE ?

Oui, tu as les registres vectoriels, 32 de 512-bit.

[Møgluglu]

Rhôo, moi aussi je peux troller si je veux…

La différence, c'est que sur les GPU les données privées des threads sont allouées de manière statique dans un gros banc de registres partitionné entre les threads (#registres/thread variable) et ne bougent plus, tandis qu'avec Larrabee on passe par le cache L1 à chaque basculement de contexte.

A priori l'approche Larrabee est plus coûteuse, mais le nombre de registres / thread variable a un gros désavantage : la génération de code dépend du contexte. C'est un sacré problème pour la composabilité : on ne peut pas compiler séparément la moindre fonction de bibliothèque, parce que suivant l'endroit où elle est appelée, "l'architecture cible" sera différente. C'est une des raisons qui oblige à avoir du JIT de partout dans les drivers GPU.

En ce sens, le x86 (au sens de jeu d'instruction CPU classique, ça pourrait aussi bien être ARM ou PPC ou Alpha...) peut être vu comme un avantage.

Y'a un endroit ou on peut reclamer une carte gratos quand on bosse pour un concurrent ?

Euh... Tu peux toujours demander.

[newbie06]

On n'est pas concurrents sur le HPC. Enfin pas encore

[Foudge]

Quelques détails sur Xeon Phi
http://www.hardware.fr/news/12577/qu...-xeon-phi.html

[newbie06]

http://communities.intel.com/communi...t-hot-chips-24

Je ne suis toujours pas convaincu.

[Møgluglu]

Je me posais une question sur Xeon Phi. Il n'y a pas de versions scalaires des instructions flottantes SIMD dans le jeu d'instructions comme en SSE/AVX.
Du coup, en quoi est compilé le flottant scalaire (par icc et dans l'idée d'Intel) ?
1) en instructions x87,
2) en instructions SIMD sur des vecteurs de 512 bits,
3) en instructions SIMD prédiquées par le masque 0000000000000001,
4) ça n'existe pas, icc sait tout vectoriser.

La réponse 3) me semble la plus raisonnable. La solution 1) pose des problème de déterminisme des résultats entre le même calcul vectorisé et non-vectorisé (bon, c'était déjà le cas avant), et l'ABI copié-collée sur celle du x86_64 relègue x87 aux calculs en double-étendue. La solution 2) doit poser des soucis avec les traps et les exceptions (ah non pardon, Phi gère pas les exceptions flottantes), en plus d'être pas super efficace en énergie. Pour 4), no comment.

La solution 3 voudrait dire :
- Le compilo doit initialiser un registre de masque à 00…01 dans chaque fonction qui manipule du flottant scalaire. Et le refaire entre chaque appel de fonction, les registres ki étant temporaires d'après l'ABI.
- On a plein d'écritures partielles, et la micro-archi voit des dépendances de partout. Pas trop gênant encore en in-order, mais en out-of-order bon courage…
- A-t-on une voie privilégiée ? Si je décide de choisir plutôt le masque 0000001000000000, je consommerait autant ? Ça voudrait dire que les datapaths et les registres sont clock-gatés et banqués à une granularité de 64 bits, voire 32 bits ?

[newbie06]

Plus de résultats de bench Xeon Phi (mais toujours par Intel) : http://www.intel.co.jp/content/dam/w...ance-brief.pdf

[Møgluglu]

50% du débit crête sur la mémoire, c'est pas terrible ?
Je n'ai pas trouvé de chiffres pour Kepler, mais sur Fermi c'était autour de 80% (ECC on).

[newbie06]

50% du débit crête sur la mémoire, c'est pas terrible ?
Je n'ai pas trouvé de chiffres pour Kepler, mais sur Fermi c'était autour de 80% (ECC on).

Je trouve surtout etrange d'utiliser triad pour mesurer la BP surtout sur un processeur in order, non ?

[Møgluglu]

Bah ils doivent software-prefetcher à fond de toute façon. Plus il y a de loads en vol, mieux c'est. Et le ratio lectures:écritures de 2:1 est probablement plus intéressant.

Sinon au temps pour moi, 80% c'est pour du trafic en lecture uniquement. Sur triad, on doit plutôt tomber à 70% à la louche.

[Møgluglu]

Ça bouge ici aussi.

Xeon Phi premier au top 500.

Lancement des Xeon Phi séries 5100 et 7100 : http://ark.intel.com/products/family/71840


Et surtout on commence à avoir des infos un peu plus précises sur l'animal. Notamment cet article :
http://software.intel.com/en-us/arti...o-architecture

Et... ça fait plutôt peur.

Intel Xeon Phi processors have global stall pipeline architecture; that is, part of the pipeline will stall if one of the stages is stalled for some reason.

Global stall et SMT ? C'est pas censé aller bien ensemble...

The hardware cannot issue instructions back to back from the same thread in the core. To reach full execution unit utilization at least two threads must be running at all times.

En single-thread, on ne schedule des instructions qu'un cycle sur 2... OK, donc sur du code séquentiel on part d'un IPC crête divisé par 2 par rapport au Pentium d'il y a 20 ans...

The Intel Xeon Phi coprocessor uses time-multiplexed multithreading. The PPF thread picker determines the request to be sent to instruction cache and put into the prefetch buffer and the second one selects what entries to read from the prefetch buffer and send them to the decoder. It uses a smart round-robin mechanism to pick only threads that have work to do and avoids threads that are inactive due to various conditions like cache miss. One can control thread scheduling by putting delay loops in the thread that the thread picker will not schedule in the actual hardware(which is useful for optimization)..

Là ça sent l'enfummage. Si le thread qui doit attendre n'est pas schedulé, alors ça ne change rien de mettre des boucles d'attente...
Je comprend plutôt : en fait le "smart" scheduler est juste greedy et sélectionne les instructions qui suivent le load pour le thread qui a eu un miss. Ces instructions se retrouvent bloquées sur la dépendance au load, et à cause du global stall elles bloquent aussi toutes les instructions des autres threads qui sont derrière. Du coup pour contourner le problème le programmeur doit mettre des nops après les loads pour remplir les slots du scheduler et comme ça les autres threads peuvent avancer.

Jespère que j'ai mal compris...

L'article répond aussi à ma question plus haut sur le flottant scalaire.

The figure shows that the single threaded non vectorized run only provided ~0.66 Gflops. However, expected DP flops for a single core run is 2(FMA)x1(DP elements-non vectorized)x1.1 GHz = 2.2 Gflops. However, as described in architecture section, the hardware cannot issue instructions back to back from the same thread in the core. To reach full execution unit utilization at least two threads must be running at all times. So running on 2 threads (OMP_NUM_THREADS=2), we are able to reach 1.45 Gflops per core. As the core still uses vector unit to perform scalar arithmetic, the code for scalar arithmetic is very inefficient. For each fma on a DP element, it has to broadcast the element to all the lanes. Operate on the vector register with a mask and then store the single element back to memory.

C'est bien ce que je craignais. Le code scalaire est quasiment deux fois plus lent que le code vectoriel.

Heureusement, icc n'aura aucun problème à tout vectoriser, surtout que les codes qui tournent sont déjà plein de #pragma vector aligned, de notations Cilk+ propriétaires et de tailles de vecteurs hardcodées comme l'exemple.

[newbie06]

Apparemment Phi est dispo pour le commun des mortels : http://www.sabrepc.com/p-3936-intel-...or-active.aspx
Enfin faut avoir $1700

[newbie06]

A peine sorti, et le jeu d'instructions change : AVX-512 pour Knight Landing

[Møgluglu]

Encore heureux, en même temps. Bon, l'unification des encodages aurait été fait une génération plus tôt, ça n'aurait pas fait de mal non plus...

Il y a des ajouts à part une fusion entre AVX et LRBni ?
Apparemment on récupère les masques, les gather-scatter, la config FPU statique et autres features de "vrai SIMD" de Knight Corner (mais les fonctions exp/log,rcp/rsq restent en option), et les instructions scalaires, les shuffle et autre unpack d'AVX.

Cool, on aura donc des instructions scalaires dans Knight Landing. :monomaniaque:

[Møgluglu]

Apparemment Phi est dispo pour le commun des mortels :

Avec le Phi, il faut revoir ses vieilles habitudes :

$ ssh mic0
$ cat /proc/cpuinfo



$ less /proc/cpuinfo

Les numéros de processeurs à 3 chiffres, ça surprend au début.

Plus sérieusement je vais voir ce que j'arrive à en tirer. Si vous avez des benchmarks ou des tests pas trop compliqués à installer que aviez toujours rêvé de faire tourner sur un Phi, dites toujours...

[newbie06]

Ton cat et ton less sont vides. Autant de substance que le Phi somme toute.

EDIT: Enfoire !

---------- Post added at 17h46 ---------- Previous post was at 17h42 ----------

Ha tiens j'ai une idee d'un truc a faire tourner : POVray...

[fefe]

Je croyais que les PHI ca servait a faire tourner SGEMM . Et j'ai failli suggererer Dhrystone .