Intel et Larrabee

[fefe]

Et c'est moi qui comprends rien, ou ca veut quand même dire qu'une puce à 24 coeurs de ce type serait quand même notoirement sous performante par rapport à un double quad core2/nehalem ?

En comparaison de transistors, on doit arriver à un truc similaire, et en dissipation aussi, par contre en perfs, le core2/nehalem semble un gros cran au dessus non ?

On compare sur du code compile la, pas sur un driver graphique ou une appli parallelisee aux petits oignons. Ce qui est omis est le comportement en multithread. Atom par exemple une fois que le multithread est active devient seulement 2x plus lent qu'un C2D (grace a un "super" scaling du SMT du au fait qu'ils aprtent d'un IPC si bas).

Les GPUs tout comme Atom, utilisent un nombre important (surtout pour les GPUs) de threads pour masquer les latences dues aux pipelines in order. Dans ce contexte l'avantage en IPC sur une appli sinmple thread disparait assez rapidement.

plusieurs manieres de faire l'estimation:
Un Larrabee suppose a pic 2T flops
Un Penryn Quad core a pic 4*2*4*3x10^9=~50GFlops

Si tu suppose que le core du Larrabee est 4x moins efficace en terme d'utilisation de ses ressources, tu arrives tout de meme a 10x plus de Flops en SP. Si tu as du multi thread pour recuperer une partie de ce que tu as perdu a etre in order, tu te retrouves a 15-20x. Bien sur, ton Quad core Penryn utilise 214mm^2 soit 1/3 du reticule donc si on utilise la taille du reticule pour estimer Larrabee (j'arrivais a 24 cores en partant de la) on tombe a 3-4x si les P54 de Larrabee ne sont pas multithread et 5 a 8x si ils le sont.

[fefe]

http://biz.yahoo.com/ap/080708/dream...ntel.html?.v=6

Tiens Dreamworks vient de promettre d'acheter un chip qui n'existe pas encore (Larrabee)

[Alexko]

Oui j'ai vu ça... curieux. Enfin peut-être qu'ils ne le paient pas, voire qu'Intel leur file un chèque avec les chips.

Sinon quand tu parles de SMT pour Larrabee, tu penses à du 2-way/core, ou plus ? J'imagine que c'est loin d'être trivial d'adapter une base de P54C pour gérer plein de threads mais en même temps, s'ils ne le font pas le rendement risque d'être assez mauvais.

[Neo_13]

ya que moi que P54C en MMX ça étonne ?

[DJ_DaMS]

ya que moi que P54C en MMX ça étonne ?

non...

[Alice]

Tiens Dreamworks vient de promettre d'acheter un chip qui n'existe pas encore (Larrabee)

Ce n'est pas vraiment étonnant vu l'exitation générale des développeurs autour de cette puce. C'est simple, malgrès le marketing catastrophique de Galsinger sur le Larrabee, les années d'incompétence d'Intel à fournir des drivers potables pour leur GPU low end, et le manque d'info concrète sur les performances de la bête les codeurs graphiques veulent du Larrabee. La raison est pourtant loin de l'aspect GPU classique: le lancer de rayon ou plus généralement un vrai co-processeur qui peut faire du calcul généraliste qui ne se limite pas aux 2/3 applications spécifiques qui rangent leur données indépendantes dans des grilles de taille donnée.

En graphique le Lancer de rayons c'est le st-graal mais ca demande de la grosse puissance de calcul. Prenez un des plus grand monsieurs du domaine qui a tapé du point sur la table pour dire: "Le lancer de rayons en interactif c'est possible". Faite le débaucher par Intel (de gros moyens donc) pour le faire bosser sur un GPU high end. Accompagnez ce GPU de rumeurs parlant de SSE puissant, de cache etc. bref de fonctionnalités justement très intéressant pour le RTRT. Tout ca fait bouilloner le petit monde du rendu autour d'Intel et de ce Larrabee annoncé comme l'arme absolue du RT. Avec ça il suffit de rajouter une armée de gros noms au projet pour contenter tout le mode (Michael Abrash pour le raster) de surfer sur la vague du RTRT (Id-software en parle au Siggraph par exemple) d'exhiber que les GPU actuels sont juste nul à chier pour le RT, et de faire parler des développeurs connus (Tim Sweeney, Carmack etc) qui annonce un changement majeurs dans le rendu tel qu'on le connait et bam bam bam... Larrabee fait rêver.

Qt à Dreamworks, trouver une archie des plus prometteuse/souple pour accélérer leur algo de rendu est des plus intéressant. Mais je me doute surtout qu'ils ont du en voir "juste" un peu plus que ce que ce que tout le monde en a vue (çad rien?) <_<

[fefe]

Qt à Dreamworks, trouver une archie des plus prometteuse/souple pour accélérer leur algo de rendu est des plus intéressant. Mais je me doute surtout qu'ils ont du en voir "juste" un peu plus que ce que ce que tout le monde en a vue (çad rien?) <_<

Ben acheter le premier chip d'une ligne de produits qui debute, alors qu'il n'a pas tape out, ca me semble mmm.... fishy.

[Alice]

Le 16way SIMD du larrabee est (encore) confirmé par Intel ici.

[newbie06]

Ca confirme donc bien les 2 Tflops @ 2GHz.

Autre point intéressant : l'article est de juillet et il y est fait mention de l'absence de silicium, ce qui confirme bien ce que disait Fefe sur le tape out (OK, ça ne veut pas dire qu'il n'existe pas maintenant, jusqu'il n'existait pas il y a quelques semaines ).

[Møgluglu]

Le 16way SIMD du larrabee est (encore) confirmé par Intel ici.

Ca confirme donc bien les 2 Tflops @ 2GHz.

En même temps, ça m'étonne qu'ils aient un SIMD full-width, alors que les GPU actuels sont en 1/4-width. Ça voudrait dire qu'ils ont du multithreading massif par core pour masquer les latences (minimum 4 à 8 threads pour les latences FPU, bien plus pour les latences mémoire).
Ou alors ils s'appuient sur des gros caches et du prefetching agressif?
Edit: et un compilateur efficace?

Autre point intéressant : l'article est de juillet et il y est fait mention de l'absence de silicium, ce qui confirme bien ce que disait Fefe sur le tape out (OK, ça ne veut pas dire qu'il n'existe pas maintenant, jusqu'il n'existait pas il y a quelques semaines ).

(Plutôt mai pour la date de soumission du papier, mais oui, il n'existait pas il y a quelques mois.)

[Møgluglu]

PC-Watch (日本語で) :
http://pc.watch.impress.co.jp/docs/2.../kaigai457.htm

[newbie06]

Y'a ca aussi (pas encore lu) : http://www.pcper.com/article.php?aid=602

[fefe]

Apparament les 2 proviennent de la meme campagne de PR (je ne lis pas le japonais, mais au vu des graphes...)

[Alice]

On trouve aussi tout ça chez Anand

[Yasko]

Y'a ca aussi (pas encore lu) : http://www.pcper.com/article.php?aid=602

Page 3 :
The one overwhelming theme that Intel presented us with was scalable performance using more and more cores. Theoretically Intel is showing us that it can simply throw more cores at the problem, and with this architecture it will continue to scale without hitting any point of diminishing returns. So while NVIDIA and AMD have thrown more stream processors at the problem with their latest GTX 200 series and Radeon 4800 parts, their return on performance is not scaling as well as many would have imagined.
The Radeon 3800 series had 320 stream processors, but the Radeon 4800 series with 800 SPs does not give 2.5X the performance of the older architecture.

Mouais... Y a pas mal de choses qui ont changé entre les Radeon 3k et 4k, du coup,son calcul est un peu bancal. Il aurait plutôt dû le rapporter au nombre de transistors plutôt qu'au nombre de streams.
Pour rappel :
Le RV770 ainsi développé ne mesure que 260 mm², mais embarque malgré tout la bagatelle de 956 millions de transistors. Le Radeon HD 3800, ou RV670 se contentait, lui, de 190 mm² et de 666 millions de transistors. Avec 40% de plus, qu'à pu faire AMD ?

Ben, quasiment un +100% (avec AA). Qui a dit que ca scalait mal ?

[Møgluglu]

On trouve aussi tout ça chez Anand

C'est pour quoi le die de Penryn sur la première page? (pour faire zoli, d'accord)

NVIDIA's SPs work on a single operation, AMD's can work on five, and Larrabee's vector unit can work on sixteen.

C'est moi ou le niveau baisse chez Anand?

Bon, en recollant les morceaux on a :
- 16/24/32 cores
- SIMD logique 16-way, SIMD physique 16-way
- SMT 4-way
- Instructions 64-bit, FMA (pas d'info sur les fct élémentaires)
- Multitâche non préemptif?
- 32 K L1I&D
- 256K L2/core
- Ring bus 2x256-bit
- Unité de texturage monolithique
- Algo de rendu "tilé"

Mouais, ça fait pas beaucoup plus que ce qu'on savait déjà ou dont on pouvait se douter.
Leur méthode de tiling parait intéressante...

[fefe]

Ils n'ont pas peur de faire des slides avec un scaling lineaire jusqu'a 48 cores... 8|
En general j'ai tendance a associer bon scaling avec mauvaise perf initiale (ca scale bien parce que le systeme n'est pas vraiment stresse a la base).
Bien sur leur ring bus marche peut etre bien, mais je rigolerais bien si l'equipe de Larrabee croyait a ces scalings lineaires...

Et la seule "news" est le SMT 4 ways. Le reste est la confirmations de rumeurs lancees par un CTO un peu enthousiaste.

[fefe]

Sinon la comparaison 2 cores vs 10 me semble un peu exageree.
2 core de Penryn = >110mm^2 dont plus de la moitie en caches. Si on prend 256k de cache par cpu on doit arriver a ~28mm^2/core, disons 30 en arrondissant.

Si on considere que 32 cores de Larrabee tiennent dans le reticule d'une machine de prod et font 600mm^2 (dans le meme process que Penryn), on trouve 19mm^2 par core avec son cache. C'est une approximation, je sais qu'il n y aura pas que des cores, donc on prend a la louche 15mm^2. Je ne vois pas comment 10 cores de Larrabee serait equivalent a 2 cores de C2D. C'est plutot 4 vs 2.

Qui plus est si Intel veut mettre des unites vectorielles 512bits dans un C2D ou successeur rien ne les en empeche (et ils ont deja annonce AVX). En y allant a la louche, un C2D avec ses 512 bits d'unites vectorielles serait dans les 40mm^2 avec son cache de 256K (j'arrondis).

Au final apres ces calculs on arrive a une densite de calcul par unite de surface 2.5x plus importante dans Larrabee que dans un eventuel successeur de C2D adapte pour avoir des unites vectorielles larges. Dans l'exemple donne par tous ces articles dans leur intro ils essayent de te faire croire que la densite est 20x meilleure.

2.5x c'est bien, tres bien meme, si l'IPC et la frequence suivent. A IPC equivalent en considerant la frequence 33-50% plus faible pour les core a base de P54 vs des C2D (vu les profondeurs de pipeline 5 etages contre 14, meme si j'en ajoute quelques uns au P54 ca fait toujours ~2X). Ca fait 1.66x la performance a surface egale. Est ce que l'IPC d'un core in order reussit a etre plus eleve que 3/5 de l'IPC d'un C2D ca va etre limite a comment le code est optimise. L'exemple d'atom sur des codes classiques suggere que ce ne sera pas facile du tout sur du code compile classique (l'ipc a frequence egale etant plutot 3x plus faible en ST, 2X plus faible en comptant SMT).

Les 4 threads vont probablement aider a s'approcher en terme d'IPC et le reste dependra de la qualite du code pour exploiter le pipeline in order de Larrabee. En tout cas on est tres loin du 20x suggere...

Bien sur je n'ai pas parle de l'argument power, et c'est la que d'employer un core simple devrait changer les choses. Justifier le choix apr le power serait plus honnete a mon gout que par la performance.

[newbie06]

L'exemple d'atom sur des codes classiques suggere que ce ne sera pas facile du tout sur du code compile classique

Je n'imagine meme pas une seconde qu'Intel aurait oublie d'avoir une variante d'icc pour Larrabee qui s'occuperait de faire un scheduling statique correct.

Par ailleurs, si on se restreint aux drivers, il est probable que ceux-ci genereront du code a la volee, et c'est surtout la qu'Intel n'a pas droit a l'erreur. Cet aspect est a la fois plus simple et plus complique qu'un compilo classique : l'espace d'entree est plus restreint (DX/OpenGL + leurs langages de shading), mais il y a une forte contrainte de temps de generation de code.

EDIT : quand je parle de "scheduling" dans ce post, je fais reference au scheduling d'instructions, pas au multithreading

[Neo_13]

le fait que les 32 cores soient in order pourait il masquer discretement que larabee 2 soit pareil mais avec un speculative multithreading pour homme en entrée ?

[Foudge]

C'est pour quoi le die de Penryn sur la première page? (pour faire zoli, d'accord)


C'est moi ou le niveau baisse chez Anand?

Bon, en recollant les morceaux on a :
- 16/24/32 cores
- SIMD logique 16-way, SIMD physique 16-way
- SMT 4-way
- Instructions 64-bit, FMA (pas d'info sur les fct élémentaires)
- Multitâche non préemptif?
- 32 K L1I&D
- 256K L2/core
- Ring bus 2x256-bit
- Unité de texturage monolithique
- Algo de rendu "tilé"

Mouais, ça fait pas beaucoup plus que ce qu'on savait déjà ou dont on pouvait se douter.
Leur méthode de tiling parait intéressante...

2*512bit

All of the cores are connected via a bi-directional ring bus (512-bits in each direction)

edit: ça me fait penser au ringbus des HD3xxx mis en avant par AMD... puis abandonné

[fefe]

Je n'imagine meme pas une seconde qu'Intel aurait oublie d'avoir une variante d'icc pour Larrabee qui s'occuperait de faire un scheduling statique correct.

Bien sur qu'ils ont du bosser sur la compilation, mais je pense que tu dois savoir a quel point il est difficile d'arriver a 3/5 de l'IPC d'un core deep OOO avec un cpu in order (et quasiment scalaire).

2*512bit


edit: ça me fait penser au ringbus des HD3xxx mis en avant par AMD... puis abandonné

L'interet d'un ring bus est sa scalabilite, vu qu'ils n'en profitaient pas son interet semblait effectivement assez faible (combien de variantes y a t'il eu de produit avec ringbus en fonction du nombre de shaders, j'en voit tres peu).
A partir du moment ou on n'a que 2-3 variantes ca coute moins cher de ne pas avoir un reseau d'interconnection qui scale, tu designe juste 2-3 crossbar differents aux petits oignons, et ca coute moins cher.
Si tu veux 10 produits differents, la il y a un avantage certain...

[Oxygen3]

Page 3 :
The one overwhelming theme that Intel presented us with was scalable performance using more and more cores. Theoretically Intel is showing us that it can simply throw more cores at the problem, and with this architecture it will continue to scale without hitting any point of diminishing returns. So while NVIDIA and AMD have thrown more stream processors at the problem with their latest GTX 200 series and Radeon 4800 parts, their return on performance is not scaling as well as many would have imagined.
The Radeon 3800 series had 320 stream processors, but the Radeon 4800 series with 800 SPs does not give 2.5X the performance of the older architecture.

Mouais... Y a pas mal de choses qui ont changé entre les Radeon 3k et 4k, du coup,son calcul est un peu bancal. Il aurait plutôt dû le rapporter au nombre de transistors plutôt qu'au nombre de streams.
Pour rappel :
Le RV770 ainsi développé ne mesure que 260 mm², mais embarque malgré tout la bagatelle de 956 millions de transistors. Le Radeon HD 3800, ou RV670 se contentait, lui, de 190 mm² et de 666 millions de transistors. Avec 40% de plus, qu'à pu faire AMD ?

Ben, quasiment un +100% (avec AA). Qui a dit que ca scalait mal ?

Y'a surtout un élément qui est oublié dans ces calculs c'est que la scalabilité des accès mémoires est pas identique à celle de la puissance de calcul.

Si y'a eu un x2.5 sur les HD3xxx vers HD4xxx, la mémoire n'a pas fait un x2.5 mais est restée assez similaire entre les deux.

Pour en revenir sur Larabee, je me demande si Intel espère pas que sa puce se verra avoir une meilleure scalabilité grace à sa mémoire cache locale plus importante et son ring bus qui pourrait apporter de l'air aux cores surchargés en accès mémoire ?

Reste à voir après l'unité mémoire et ROP qui sera branchée dessus si Intel veut vraiment utiliser sa puce comme render graphique

[Møgluglu]

2*512bit

Merci, un jour j'apprendrai à lire.

Reste à voir après l'unité mémoire et ROP qui sera branchée dessus si Intel veut vraiment utiliser sa puce comme render graphique

En tout cas s'ils ont vraiment une seule unité de texture c'est mal parti.
Même si on suppose que le ring bus tourne à 2GHz avec 0 overhead, et que l'unité de texture arrive à saturer le bus, on obtient un fillrate de texture de 8 GTexel/s. Un peu léger face aux 47 GTexel/s d'une 9800GTX+...

Certes plus personne n'utilise de textures 8-bit, mais même en 32-bit non-compressé ça resterait en dessous du fillrate de NVidia et à peine au dessus de celui d'AMD.

Si j'ai bien compris la slide recopiée 4 fois, les ROP seraient en software uniquement.

[newbie06]

Bien sur qu'ils ont du bosser sur la compilation, mais je pense que tu dois savoir a quel point il est difficile d'arriver a 3/5 de l'IPC d'un core deep OOO avec un cpu in order (et quasiment scalaire).

Il va quand même exécuter du code très spécifique par sa régularité ce coeur. N'est-il donc pas envisageable que la perte par rapport à un coeur OoO soit bien moins faible que sur du code traditionnel ?

[Yasko]

Il va quand même exécuter du code très spécifique par sa régularité ce coeur. N'est-il donc pas envisageable que la perte par rapport à un coeur OoO soit bien moins faible que sur du code traditionnel ?

La régularité d'un code doit plutôt jouer sur toute la partie spéculations/prédictions que sur l'ordonnancement des instructions (ou plutôt leur capacité à être dispatchées efficacement). On doit pouvoir trouver du code très régulier qui n'occupe que peu d'unités d'exécution si il n'est pas ré-ordonné (voire même si il l'est).
C'est donc bien au niveau du compilo que ca va se jouer.

D'ailleurs, c'est quoi (et donc par qui) qui sera compilé avec Larrabee comme cible ? Un driver, une API (DX, OGL ?), voire même une application directement ? Larrabee étant capable d'exécuter directement du x86, comment ca va se passer ? En mode carte additionnelle (PCI-E), je suppose qu'il faudra passer par un driver et le CPU ?
En mode CPU par contre (pour blade de calcul, console de jeu , ... ?), il faudra (ou faudrait plutôt) un OS recompilé pour cette cible ?

[newbie06]

Le papier du SIGGRAPH est dispo : http://portal.acm.org/citation.cfm?doid=1360612.1360617

Comme je ne suis pas certain que ce soit gratuit sur l'acm : http://softwarecommunity.intel.com/U...e_manycore.pdf

[fefe]

Au vu du papier, tout ce qui a ete publie hier venait d'une presentation du papier Siggraph. Pour les flemmards lire anandtech and co est suffisant .

Et je crie "BS" quand je vois la table 1 de la section 3 introduite par "roughly same area and power" (cf mes approximations cis dessus).

[Childerik]

Test

[Foudge]

C'est pas très "advanced" comme info, mais Intel semblerait vouloir proposer son Larrabee dans la prochaine console de Microsoft :
http://www.theinquirer.net/gb/inquir...ole-deal-intel