Intel et Larrabee

**Møgluglu** · 25/11/2008, 14h21

Envoyé par newbie06

Le premier transparent, j'ai cru qu'ils avaient pompe un slide du CELL (qui lui-meme avait du etre pompe ailleurs)

Normal, à l'époque du Cell tout le monde repompait les schémas de Hiroshige Goto. Tu as pris ça pour une imitation alors que c'est l'original

On a une idee de la vitesse du ring bus ?

512 bits dans chaque sens à ~1,5 GHz, ça doit "tourner" autour de 2x100Go/s. Le crossbar du GT200 est aussi dans ces eaux-là, probablement celui du RV770 aussi (le ringbus du R600 était déjà en 2x512 bits, mais à 740 MHz).

Il semblerait que les prochaines versions a plus de 16 cores utiliseraient des ring-bus multiples pour scaler (slides du bas).

**newbie06** · 25/11/2008, 14h46

Envoyé par Møgluglu

512 bits dans chaque sens à ~1,5 GHz, ça doit "tourner" autour de 2x100Go/s.

C'est pas un peu leger ? Le CELL avec ses seulement 8 proc (+1 pour le PPC si cher a Fefe) monte sans probleme a 200 GB/s. Est-ce utile, je n'en sais rien, mais c'est atteignable (teste par bibi sur 6 SPU [salete de PS3]). Et la on parle bien de 48 coeurs, non ?

De plus, le CELL utilise des DMA qui permettent de completement masquer les transferts pendant que des calculs se font. Y'a ca sur Larrabee ? Ca me parait assez indispensable (mais je ne suis pas un specialiste, loin de la).

Il semblerait que les prochaines versions a plus de 16 cores utiliseraient des ring-bus multiples pour scaler (slides du bas).

Je ne comprends pas ce slide comme toi (je parle du tout dernier en bas, image de droite). J'ai plutot l'impression qu'il y a toujours un double anneau, mais dont la topologie a change (ca peut aussi etre une simplification du dessin). Un bete changement de topologie reduirait la latence entre les coeurs, mais n'augmenterait pas la bande passant, si ?

**fefe** · 25/11/2008, 15h11

Envoyé par newbie06

C'est pas un peu leger ? Le CELL avec ses seulement 8 proc (+1 pour le PPC si cher a Fefe) monte sans probleme a 200 GB/s. Est-ce utile, je n'en sais rien, mais c'est atteignable (teste par bibi sur 6 SPU [salete de PS3]). Et la on parle bien de 48 coeurs, non ?

Un ring bien fait (pas un bus mais des liens point a point) de 512 bits de large bidirectionnel a 1.5GHz avec on va dire au hasard 32 noeuds peut debiter 32*512*2*1.5G=49Tb/s = 6To/s ... Bien entendu c'est en peak en partant du principe que le load balancing de chaque lien est parfait et tout et tout. Mais au final meme si tu es a 25% d'utilisation ca reste un ordre de grandeur au dessus du cell...

De plus, le CELL utilise des DMA qui permettent de completement masquer les transferts pendant que des calculs se font. Y'a ca sur Larrabee ? Ca me parait assez indispensable (mais je ne suis pas un specialiste, loin de la).

Sur les processeurs OOO x86 c'est pris en charge par les prefetchers et les fill buffers (tant que l'OOO trouve quelque chose a executer). Vu que LRB est in-order (merci le pentium) je suis certain qu'ils ont une methode pour permettre de maintenir suffisament d'acces a la memoire en parallele. Ca peut etre un DMA, mais il y a beaucoup d'autres manieres d'y arriver.

**Møgluglu** · 25/11/2008, 15h28

Envoyé par newbie06

Et la on parle bien de 48 coeurs, non ?

Ça dépend si ta source c'est Fudzilla ou pas

C'est plutôt 16 qui est visé au début...

Je ne comprends pas ce slide comme toi (je parle du tout dernier en bas, image de droite). J'ai plutot l'impression qu'il y a toujours un double anneau, mais dont la topologie a change (ca peut aussi etre une simplification du dessin). Un bete changement de topologie reduirait la latence entre les coeurs, mais n'augmenterait pas la bande passant, si ?

Ah oui j'avais pas vu les flèches.

Mais la slide de droite a 2 coeurs de plus et un anneau de plus, c'est donc qu'il y a plus de coeurs et de bande passante non?

Faudrait voir la slide 24.

Mais la discussion porte surtout sur la difficulté de maintenir la cohérence des caches quand on augmente le nombre de coeurs et quand le trafic de snoop sature le ring bus. D'où les tag directories sur le dessin.

De plus, le CELL utilise des DMA qui permettent de completement masquer les transferts pendant que des calculs se font. Y'a ca sur Larrabee ? Ca me parait assez indispensable (mais je ne suis pas un specialiste, loin de la).

Envoyé par fefe

Sur les processeurs OOO x86 c'est pris en charge par les prefetchers et les fill buffers (tant que l'OOO trouve quelque chose a executer). Vu que LRB est in-order (merci le pentium) je suis certain qu'ils ont une methode pour permettre de maintenir suffisament d'acces a la memoire en parallele. Ca peut etre un DMA, mais il y a beaucoup d'autres manieres d'y arriver.

Le SMT, le SIMD et le multithreading software doivent aider pas mal aussi. (J'imagine que les loads sont asynchrones comme sur GPU, en bloquant seulement au moment de la consommation de la donnée.)
Même si ça reste ridicule par rapport à ce que peut faire un GPU.

**newbie06** · 25/11/2008, 15h43

Envoyé par fefe

Un ring bien fait (pas un bus mais des liens point a point) de 512 bits de large bidirectionnel a 1.5GHz avec on va dire au hasard 32 noeuds peut debiter 32*512*2*1.5G=49Tb/s = 6To/s ... Bien entendu c'est en peak en partant du principe que le load balancing de chaque lien est parfait et tout et tout. Mais au final meme si tu es a 25% d'utilisation ca reste un ordre de grandeur au dessus du cell...

Ca me parait mieux que le chiffre donne par Møgluglu

Ca peut etre un DMA, mais il y a beaucoup d'autres manieres d'y arriver.

Pour moi un DMA c'est juste une facon de dire qu'il y a un bidule qu'on active explicitement pour faire du transfert memoire et qui marche sans bloquer le processeur. Maintenant si tes autres manieres d'y arriver sont automatiques, j'espere pour Intel que c'est bien foutu et pas trop specialise pour un type de charge...

**fefe** · 25/11/2008, 15h57

Envoyé par Møgluglu

Le SMT, le SIMD et le multithreading software doivent aider pas mal aussi. (J'imagine que les loads sont asynchrones comme sur GPU, en bloquant seulement au moment de la consommation de la donnée.)
Même si ça reste ridicule par rapport à ce que peut faire un GPU.

Sur une machine OOO:
Le SMT peut aider, mais si ton application a 1 thread est bien ecrite... ca n'aide pas vraiment vu que les les buffers qui trackent les acces memoire en parallele sont partages (sinon maintenir la coherence serait soit lent soit cauchemardesque). Le SIMD n'aide pas vraiment non plus vu que les buffer dont je parle trackent des lignes de cache, donc que les acces aient ete genere par 1 ou 8 instructions la difference est negligeable (reduire les instructions aide l'OOO a aller plus loin dans sa recherche de parallelisme, donc ca peut aider).

Sur une machine In Order:
Tu ne peux pas avoir plus d'1 load en parallele vu que tu es oblige d'attendre le resultat pour rester dans l'ordre. Si tu procedes avec des instructions independantes il te faut verifier leur independance (ce que font les stations de reservation en general) et stocker leur resultat dans un buffer (ROB en general) pour mettre a jour l'etat de la machine dans l'ordre. Dans ce cas multiplier les threads aide a generer plus d'acces paralleles a la memoire (1 par thread), le SIMD par contre n'aide pas vraiment vu que la taille de la ligne de cache est generalement superieure a la largeur de ton mot SIMD.

Pour les loads asynchrones c'est donc l'antithese d'un processeur in-order. Si tu peux faire des load (en x86 les instructions qui demarrent par mov ou ont une source en memoire) asynchrones tu es OOO sinon tu es in order. Tes prefetcheurs eux peuvent etre asynchrone par contre vu qu'ils ne modifient pas l'etat de ta machine, tu peux avoir un prefetcheur qui travaille mot par mot (software prefetch ala SSE par ex) ou stream par stream et programmable (un DMA, ou un prefetcheur ala AltiVec qui est une forme de DMA).

Pour le nombre de cores, 48 Pentium + unites vectorielles ne tient pas dans le reticule d'une machine de prod en 45nm donc il n'y a aucun doute que le nombre de coeur est inferieur. Dans mes calculs, avec 16 il reste pas mal de place donc il n'est pas impossible qu'il y ait un peu plus de coeurs. Apres pour le nombre d'agents sur le ring, il faut ajouter les controleurs memoires (les connecter tous n 1 seul point est equivalent a creer un bottleneck en cet endroit du ring donc il est plus que probable qu'ils soient repartis histoire de maximiser la bande passante) et autres unites avec des fonctions hardware dediees au graphique qu'ils ne manqueront pas d'ajouter (et de repartir sur le ring). Au final je pense que mon 32 n'est pas une si mauvaise approximation.

Envoyé par newbie06

Pour moi un DMA c'est juste une facon de dire qu'il y a un bidule qu'on active explicitement pour faire du transfert memoire et qui marche sans bloquer le processeur.

On est d'accord.

**Foudge** · 25/11/2008, 16h42

D'après Wikipedia (

) :

Larrabee has a 1024-bit (512-bit each way) ring bus for communication between cores and to memory.[8] This bus can be configured in two modes to support Larrabee products with 16 cores or more, or fewer than 16 cores.[10]

Leur source : http://news.cnet.com/8301-13512_3-10006184-23.html

Je suppose qu'ils font référence au ring bus simple et au Xring (3 rings). Mais cela veut surtout dire qu'Intel prévoit également un LRB de 16 cores ou moins.
Par contre je n'ai pas vu le document sur lequel s'appuie CNet.

Un pari sur le nombre de cores de LRB ? Les différentes rumeurs annoncent 16, 24, 32 voire 48 (on va oublier le 80

). J'vote pour du 24 effectif.

**newbie06** · 25/11/2008, 17h16

Envoyé par Foudge

Je crois qu'on t'as entendu. Voici un supercalculateur basé sur des Atom sous le nom de code "Project Molecule"

http://techon.nikkeibp.co.jp/english...081121/161590/

SGI coiffe sur le poteau : http://www.xtremesystems.org/Forums/...d.php?t=208851

OK, je sors...

**Yasko** · 01/12/2008, 15h37

Microsoft offre WARP à Intel pour Windows 7

On dit Merci qui ?

**newbie06** · 01/12/2008, 16h47

Envoyé par Yasko

Microsoft offre WARP à Intel pour Windows 7

On dit Merci qui ?

On dit f*ck Ballmer, parce que si c'est ca qui finira dans Larrabee, ca veut dire qu'il faudra un temps non negligeable avant de voir un driver OpenGL qui tient la route.

**Foudge** · 01/12/2008, 17h12

Je ne suis pas persuadé que ça exploitera LRB si bien que ça. A mon avis, Intel sortira son driver Direct3D (et OpenGL), comme tout le monde.

**Yasko** · 01/12/2008, 17h25

Envoyé par newbie06

On dit f*ck Ballmer, parce que si c'est ca qui finira dans Larrabee, ca veut dire qu'il faudra un temps non negligeable avant de voir un driver OpenGL qui tient la route.

C'est quoi OpenGL ?

Plutôt qu'un wrapper, un DX directement compilé pour LRB, ca serait envisageable ? C'est à quel moment qu'il sert x86 dans l'histoire ?

**newbie06** · 01/12/2008, 17h33

Envoyé par Yasko

Plutôt qu'un wrapper, un DX directement compilé pour LRB, ca serait envisageable ? C'est à quel moment qu'il sert x86 dans l'histoire ?

Je pense que Doc_TB s'est un peu fourvoye en utilisant le terme "wrapper". Apparemment le bouzin utilise l'API DX10. Va voir l'article de MSDN.

**newbie06** · 06/02/2009, 08h02

Vrai ou pas ? http://www.theinquirer.net/inquirer/...laystation-gpu

Bon ptet pas finalement : http://www.techradar.com/news/gaming...rumours-525563

Mon cote anti monopolistique voudrait que ce soit MS/Intel, Sony/nVidia et Nintendo/AMD. Ca profiterait a tout le monde. Ouai, je suis un hippie

**Alexko** · 06/02/2009, 21h32

Si ma mémoire est bonne, à la base Sony comptait utiliser le Cell pour tout et se passer de GPU dans la PS3. Larrabee étant un ensemble de cores à l'origine généralistes, ça pourrait leur permettre de faire ça.

Je ne sais pas si les performances single-thread seraient handicapantes, mais au pire ça pourrait être 2~4 cores de type Nehalem (enfin Sandy Bridge ou autre d'ici-là) avec plein de cores Larrabee autour.

IBM a réussi à placer un CPU dans chaque console de la génération courante, je me demande s'ils peuvent réitérer l'exploit...

**Foudge** · 09/03/2009, 12h40

PPC vient de sortir un dossier "Larrabee : le nouveau GPU d'Intel" :
http://www.presence-pc.com/tests/int...tecture-22867/

**Møgluglu** · 09/03/2009, 13h26

Merci pour le lien, parce que ça fait du bien de rire un peu de temps en temps.

**newbie06** · 09/03/2009, 13h27

Mouai, ben y'a de sacrees erreurs sur le CELL.

Un exemple :

Le choix d’Intel simplifie grandement la programmation et permet d’éviter d’inclure un cœur plus généraliste comme le PPE. Ce système hétérogène est un des handicaps du Cell vu qu’il complique la vie du programmeur qui outre la gestion explicite de la mémoire doit également concevoir deux exécutables utilisant deux jeux d’instructions différents et donc deux compilateurs distincts.

Sans deconner, le mec il a oublie que le PC a un processeur principal et que celui-ci n'est pas compatible avec les cores de Larrabee ?

Ca devient hallucinant le nombre de personnes qui pensent que puisque c'est du x86, y'a rien a faire. x86 ca ne veut plus rien dire en terme de jeu d'instructions...

Envoyé par Møgluglu

Merci pour le lien, parce que ça fait du bien de rire un peu de temps en temps.

Ouf, j'ai cru que c'etait mon cote primaire qui me faisait trouver l'article un peu limite

**fefe** · 09/03/2009, 13h43

Je rappelle juste Fedy != Fefe

**Foudge** · 09/03/2009, 13h47

Envoyé par fefe

Je rappelle juste Fedy != Fefe

Tu veux pas assumer tes erreurs, avoue

**newbie06** · 09/03/2009, 13h59

C'est marrant j'ai pense exactement la meme chose.

Alors fefe, ca va pas ? Des soucis ? T'en fais pas on a tous nos moments de faiblesse, y'en a meme qui n'ont que des moments de faiblesse.

**Møgluglu** · 09/03/2009, 14h04

Envoyé par newbie06

Mouai, ben y'a de sacrees erreurs sur le CELL.

Sur les GPU c'est pas mal non plus.

Les GPU en s’appropriant les tâches les plus coûteuses en calculs rendaient complètement superflu les processeurs haut de gamme de la firme.

Il pourrait au moins citer sa source : marketing NVidia.

les applications les plus exigeantes en termes de puissance de calcul ont en général un flux d’instructions très linéaire : il y a peu de branchements et peu de dépendances entres les instructions

Oui, c'est pour ça que les GPU ont des coeurs superscalaires très larges pour exploiter le parallélisme d'instruction... ah bah non.

Une autre particularité intéressante de cette unité est sa capacité à effectuer des opérations de scatter/gather qui sont typiquement problématiques sur un GPU.

Manque de bol, les GPU doivent être les seules archi modernes à gérer efficacement le gather voire le scatter, contrairement à Larrabee pour lequel ça risque d'être un problème majeur (ils dépendent beaucoup des caches pour diminuer les latences, et sur un gather la probabilité de cache miss explose).

**newbie06** · 25/03/2009, 09h43

Un petit article qui donne un avant-gout des extensions ISA : http://software.intel.com/en-us/arti...mitives-guide/

**Møgluglu** · 25/03/2009, 13h48

Merci.

Les instructions GATHERPFD et SCATTERPFD me rassurent sur la santé mentale des développeur d'Intel et permettent d'expliquer comment ils peuvent espérer faire du SIMD "sérieux" avec une archi in-order.

Quelqu'un a la moindre idée de à quoi peut servir BITINTERLEAVE21_PI?
Pour un split en 23/9 j'aurai compris, mais 21/11? Fonction câblée pour le raster? Ou juste bidouille pour gagner de la place?

Des "float11", "float10" packés en 11:11:10 dans un 32-bits. Cool, ça fait presque 6 mois que le float16 est normalisé, il était temps d'inventer des nouveaux formats

.

**newbie06** · 02/04/2009, 09h08

Abrash, A First Look at the Larrabee New Instructions
http://www.ddj.com/hpc-high-performa...ting/216402188

Autres liens en vrac:

Rasterization on Larrabee: A First Look at the Larrabee New Instructions (LRBni) in Action

http://software.intel.com/file/15542

SIMD Programming on Larrabee: A Second Look at the Larrabee New Instructions (LRBni) in Action

http://software.intel.com/file/15545

Beyond3D forum discussion of LRBni. Includes some tid-bits like how LRB handles exceptions when storing a vector. (It's pretty clever: the store instruction destructively modifies the write mask to all zeros. When the page fault happens the write mask is only partially cleared, and when the instruction is restarted only the vectors that haven't been written to yet will be written to:

http://forum.beyond3d.com/showthread.php?t=53542

PS - Tout ceci provient de RWT.

**Møgluglu** · 02/04/2009, 19h26

[troll]
J'ai beaucoup de respect envers Abrash, mais là je vois vraiment pas ce qu'il y a de révolutionnaire dans un jeu d'instruction SIMD qui reprend quelques instructions MMX et Altivec et complète avec des trucs qui existent depuis 5 ans sur n'importe quel GPU...

[/troll]

**fefe** · 02/04/2009, 19h38

Tu te trompes, ca ressemble plutot a un bon vieux Cray (gather/Scatter Inside) d'il y a 30 ans plus qu'a un GPU d'il y a 5 ans.

**Møgluglu** · 02/04/2009, 19h53

Exact.

Vu que le GPU d'il y a 5 ans était déjà quasiment un Cray d'il y a 30 ans...
(Le gather s'appelle pas comme ça, mais il y est.)

Mais la vraie originalité de Larrabee est de combiner tout ça dans un jeu d'instructions d'il y a 25 ans et de l'implémenter sur une micro-archi d'il y a 15 ans.

**fefe** · 02/04/2009, 20h03

Le x86 a 30 ans aussi

, et le P55C en a 20

tu es optimiste mais le concept y est !

La difference est que ce n'est pas en AsGa mais dans un process CMOs recent !

**newbie06** · 02/04/2009, 20h21

Il parlait pas d'instruction set mais de micro-archi. Et encore 15 ans il est généreux, comme toi tu l'es avec les 30 ans de l'ISA.

C'était ma contribution mauvaise foi

Discussion: Intel et Larrabee

Outils de la discussion

Règles de messages