Intel et Larrabee

[Alexko]

~3x2cm

cf les dies de Montecito: http://en.wikipedia.org/wiki/Montecito_(processor)

OK. Donc environ 50% de plus qu'un R600 avec ses 420mm², le tout avec un meilleur process, ça laisse effectivement de la marge.
Bon, après faut voir où en seront le SLI/Crossfire, à la fois sous forme de deux cartes et sous forme de cartes dual-GPU. Si les rendements atteints sont de 75~80%, ça pourrait annuler l'avantage d'Intel.

[newbie06]

OK. Donc environ 50% de plus qu'un R600 avec ses 420mm², le tout avec un meilleur process, ça laisse effectivement de la marge.
Bon, après faut voir où en seront le SLI/Crossfire, à la fois sous forme de deux cartes et sous forme de cartes dual-GPU. Si les rendements atteints sont de 75~80%, ça pourrait annuler l'avantage d'Intel.

Intel sortira alors des SLI/Crossfire

Quant à savoir si Intel peut sortir un produit raté et rattraper le coup, ça me fait penser à l'Itanium qui doit être leur plus gros ratage commercial (hum y'a ptet l'iAPX432 mais c'est trop vieux, y'a prescription ). Il n'empêche que l'Itanium a trouvé sa niche, même si je ne pense pas qu'elle couvre les frais initiaux de R&D (quoique... on peut se demander si ce n'est pas HP qui a payé...).

Oui, enfin, on parle d'une architecture multicore et du language X86. Deux éléments parfaitement maitrisés par Intel...
Oui, je suis optimiste. Mais ça manque de concurrence en ce moment dans les GPU.

On parle de multicore massif, pas de coller 8 coeurs
Mais je suis d'accord qu'il faut remuer les GPU, y'en a marre du G92 collé sur 6 ou 7 cartes graphiques soi-disant différentes.

[fefe]

Je doute qu'Itanium perde de l'argent aujourd'hui, mais je doute que les 12-13 premieres annees de recherche aient jamais ete repayees (le projet a demarre au debut des annees 90). Donc je ne pense pas qu'Itanium ait jamais repaye l'investissement. Et Intel avait commis l'erreur? de s'engager vis a vis de ses clients a fournir des updates pendant un long moment a ses clients ce qui l'a empeche d'enterrer le chip. Je n'ai aucune idee si les memes risques ont ete pris avec Larrabee, mais vu a quel point ils font du bruit autour, il y a de bonnes chance que l'histoire se reproduise.

La comparaison avec Itanium est bonne imo, un chip que l'on fait enorme (surface) pour rendre concurrentiel malgre une architecture inapropriee et un manque d'experience dans le domaine. Un chip qui perd de l'argent. Le chip en soi n'a reussi qu'une seule chose mais il l'a bien fait: annihiler la supremacie de Dec puis Sun dans le marche des serveurs (x86 a bien aide, mais itanium s'est occupe du haut de gamme).

Je suppose qu'il y en a qui se souviennent d'Itanium chez Intel...

Multicore massif, massif, mouais, meme dans 600mm2 il n'y a pas de place pour en mettre tant que ca .

[Alexko]

Intel sortira alors des SLI/Crossfire

Sauf qu'actuellement, après déjà quelques années d'expérience, le rendement du SLI/Crossfire est encore médiocre. Si Intel sort une solution similaire dès le début avec des drivers dans leur genèse, ça sera encore plus foireux.

[newbie06]

Je n'ai aucune idee si les memes risques ont ete pris avec Larrabee, mais vu a quel point ils font du bruit autour, il y a de bonnes chance que l'histoire se reproduise.

Oula, vu de l'exterieur le tapage est au moins un ordre de grandeur inferieur sur Larrabee. A l'epoque, le bordel genere par le marketing d'Intel et HP sur l'Itanium etait incroyable. En plus Internet n'etait pas aussi developpe que maintenant.
D'un autre cote je suis sans doute aussi moins naif, et les discours racontant a quel point le nouveau machin-bidule va tout revolutionner me glissent dessus
Intel tient un tel discours sur Larrabee ?

Je suppose qu'il y en a qui se souviennent d'Itanium chez Intel...

J'espere que ceux qui se souviennent de cette epoque sont des inges et pas des marketeux qui ont (auraient?) du etre vires

Multicore massif, massif, mouais, meme dans 600mm2 il n'y a pas de place pour en mettre tant que ca .

Oui mais entre 8 et 20 ou 40, ca change la donne. J'imagine qu'il va y avoir un interconnect specifique qui n'a rien a avoir avec ce que tu fais dans un multicoeur x86 actuel. Et si cet interconnect est foireux, ca va chier...

Le ring bus du Cell est assez interessant a ce propos et permet des performances reelles assez impressionnantes, j'ai atteint 150 GO/s agreges sur une PS3

[Oxygen3]

Je me demande surtout si les Atom qui sont en train de sortir ne sont pas un dérivé du Larabee:
En clair, l'Atom serait l'extract d'un core d'execution du Larabee, et en multipliant ca par 128, on arrive à un chip qui ferait du 90W avec un peu d'opti coté consomation, et qui aurait ses 128 cores x86

[newbie06]

Je me demande surtout si les Atom qui sont en train de sortir ne sont pas un dérivé du Larabee:
En clair, l'Atom serait l'extract d'un core d'execution du Larabee, et en multipliant ca par 128, on arrive à un chip qui ferait du 90W avec un peu d'opti coté consomation, et qui aurait ses 128 cores x86

Meuh non :
1. si j'ai bien compris les cores Larabee ont un subset du jeu d'instruction x86, pas les Atom
2. où t'as vu qu'un Atom consomme 0,7 W à une fréquence acceptable avec "un peu d'opti" ?

[Møgluglu]

Meuh non :
1. si j'ai bien compris les cores Larabee ont un subset du jeu d'instruction x86, pas les Atom

Probablement ni un subset ni un superset, plutôt un autre ensemble avec intersection non-nulle (avec AVX ou autre jeu d'instruction SIMD en plus?).

2. où t'as vu qu'un Atom consomme 0,7 W à une fréquence acceptable avec "un peu d'opti" ?

Ça ne me parait pas totalement absurde. En soustrayant la conso du FSB et des PLL, on ne doit pas en être bien loin, pour des fréquences typiques d'un GPU.

Après un core Atom n'a largement pas assez de puissance FPU en SIMD pour faire un GPU potable. Il faut aussi que le SMT gère un peu plus de threads que 2 pour masquer les latences mémoires (ex. 24 sur le G80).
Sachant que les threads exécutés en même temps ont de fortes chances de suivre le même chemin, d'où l'intérêt d'utiliser une forme de trace cache. Les choix microarchitecturaux sont très différents entre un CPU mobile et un GPU...

[newbie06]

Légèrement hors-sujet, s'il y a des fans de CUDA, nVidia organise un concours :
http://www.nvidia.fr/object/cuda_con...il2008_fr.html

Dommage, je n'ai pas de CG qui supporte CUDA

[Neo_13]

moi j'en ai plusieurs, mais je suis une hypertanche en coding... Donc je ne peux pas gagner, et je me demande bien ce que je pourrais foutre des lots... le dual xeon, je vois, mais le reste et notamment tesla, je sais vraiment pas.

[fefe]

Je me demande surtout si les Atom qui sont en train de sortir ne sont pas un dérivé du Larabee:
En clair, l'Atom serait l'extract d'un core d'execution du Larabee, et en multipliant ca par 128, on arrive à un chip qui ferait du 90W avec un peu d'opti coté consomation, et qui aurait ses 128 cores x86

Mmm maths elementaires: Atom =25mm2, si tu enleves le cache et les IO (je ne suis aps sur que d'enlever le cache soit une bonne idee, il reste a peu pres la moitie soit 13mm2. 600mm2/13mm2 ~= 45 a supposer que tu fasses un layout parfait et que tu ne mettes aucun hardware dedie a la 3D, ne mette pas de controleur memoire, pas d'IO, et utilise le meme process entre Larrabee et Atom.

Si tu commences a garder le cache, mettre des IO, mettre un controleur memoire et mettre l'equivalent de 1 ou 2 cores en hardware dedie... Tu vas vite te retrouver en dessous de 20 cores. Donc 128 est on ne peux plus optimiste. Ceci en supposant que Larrabee serait base sur Atom.

La rumeur la plus credible que j'aie vu passer sur le net annoncait l'utilisation de P55C avec une mise a jour de x86 a SSEx ou AVX. Pour faire des calculs du nombre de core a partir de ca, sachant que P55C avait a peu pres 1/3 des transistors d'Atom (sur les 45M d'Atom si on enleve les 512k de cache L2 on tombe aux environs de 14M vs 4.5M pour P55C) et que le passage de MMX a SSE1 a coute aux alentours de 2M de transistors (passage P2 a P3, le passage de P6 a P2 en ayant coute a peu pres le meme nombre) on peut supposer qu'un P5 avec SSE2 full width ferait probablement lplus de a moitie de la taille d'un atom, ou 3/4 si un peu booste (AVX?) en calcul flottant.

Si tu pars de 2/3, et ne met pas de cache tu arriveras peut etre a la 50 aine de cores (en comptant IO/MC/hardware dedie), et si tu mets du cache probablement la moitie (la tendance chez Intel semble etre a mettre +-50% du die en cache ces dernieres annees).

Voila l'essentiel de mon raisonnement quand j'entends multicore "massif" ou des reves eveilles de 128 CPUs sur un die. Avec mes calculs a la noix j'arrive a la conclusion que c'est a peu pres impossible d'en avoir 32 meme si Larrabee est de la taille du reticule d'une machine de prod (je dirais entre 16 et 24 semble beaucoup plus credible).

[newbie06]

@Fefe: intéressante analyse

Du coup on se demande pourquoi Intel a initialement parlé de 80 coeurs sur leur bidule Terascale (http://www.pcper.com/article.php?aid=363). Ca n'aurait donc aucun lien avec Larrabee ?

Je me pose aussi beaucoup de questions sur la sélection de l'ISA :

1. je ne comprends pas bien l'intérêt de se baser sur du x86 si on ne met pas l'ensemble du jeu d'instructions ou si l'on ajoute des trucs non standard ; parce que du coup il faut de toute façon des outils de compilation dédiés, et je ne suis pas certain que le x86 facilite la tâche. Question : quel est le pourcentage de code partagé entre les compilos Intel x86 et Itanium ? Je parie sur plus de 90%, même en excluant le front end d'Edison Design Group.

2. pourquoi se taper la complexité d'un decodeur x86, même réduit ? Tout ce qu'on veut c'est un coeur ayant les fonctionalités d'un CPU (bah oui sinon on reste sur nos GPU nVidia/AMD qui de toute façon prennent la direction des CPU). Quand je vois avec quelle facilité on peut écrire un decodeur pour un jeu d'instructions simple...

A l'arrivée je me demande si Intel ne colle pas du x86 dans ces coeurs uniquement pour ne pas faire peur aux dév, ils ne veulent pas refaire le coup de l'Itanium
Sauf que là on parle d'un autre domaine d'applications.

[fefe]

La question du x86 est a mon avis independante du probleme de savoir si c'est bien ou non pour un CPU ou un GPU.
-Il y a une quantite enorme d'applis qui tournent sur du x86, si tu le supportes, potentiellement tu peux faire tourner tout ca sans le moindre probleme. Si tes GPUs actuels supportaient x86, qui irait utiliser CUDA et autres pour faire du GPGPU ?
-Cote developpement les outils x86 sont plus utilises que tout le reste, ca ne les rend pas meilleurs, il y a juste plus de developpeurs potentiels.
-Le x86 c'est difficile a copier/concurrencer. A cause du support de toute la legacy, faire un CPU x86 est devenu tres difficile (cf Montalvo qui a coule la semaine derniere malgre des investissements massifs). A supposer que Larrabee reussisse, le fait qu'il soit x86 permettrait un avantage indeniable a Intel dans tout ce qui n'est pas du pur DirectX car fournir quelque chose de compatible serait difficile et tres couteux pour la plupart des concurrents (les rumeurs sur nvidia+x86 prennent tout leur sens).
-le decodage x86 est complexe et lourd, et sur un die avec beaucoup de cores il represente peut etre une surface negligeable, mais avec l'amelioration des process cet inconvenient tend a disparaitre (sur les "gros" CPUs il a disparu depuis un bon moment). L'amelioration du process est LE domaine ou Intel a excelle pendant les dernieres decennies, il semble normal qu'ils tentent de capitaliser sur cet avantage.
-Qui plus est Intel a le savoir faire x86 et ca coute moins d'investissement d'utiliser du x86 que quoi que ce soit d'autre (tous les outils de verification existent deja en interne).

Beaucoup des items listes cis-dessus peuvent etre vus comme des conclusions tirees de l'experience Itanium mais a mon avis sont bien reelles.

[newbie06]

Ce que tu dis n'a de sens que si Larrabee a des coeurs qui supportent l'ISA standard du x86 (on peut éventuellement exclure MMX, SSE et autres SIMD). J'étais parti du principe du subset strict.

J'aime bien cette photo : http://www.chip-architect.com/news/N..._1600x1200.jpg

Bon c'est sûr Hans de Vries a probablement fait du "wild guessing" en mettant les boiboites, mais si on suppose qu'il ne s'est pas trop vautré, l'ensemble decode / I-side est assez gros comparé à l'unité FP/SIMD par example. C'est encore plus flagrant si on enlève les unités spécifiques liées à l'OoO.
Enfin c'est à prendre avec des pincettes, j'imagine assez bien qu'Intel et son custom flow doit arriver à éparpiller de la fonctionnalité un peu partout sur le circuit pour optimiser les timings

[fefe]

Si tu regardes bien le dessin, tu te rends compte que c'est 2 a 3% du cpu (excluant le cache) qui est consacre aux specificites du x86. Effectivement beaucoup est consacre au traitement de l'instruction et une partie non negligeable est lie a l'execution OOO avec un pipeline long et "tres" speculatif qui etait la particularite du P4. Sur un P6-like la proportion est moins extreme.

Apres il y a probablement des effets de bords de simplification du jeu d'instruction interne si en externe tu supportes un jeu d'instructions simple et orthogonal, mais c'est difficile a evaluer en regardant juste un floorplan.

Sur ce floorplan c'est visible que:
- le trace cache+sa gestion c'est pas petit
- toute la prediction de branchement est un bon gros bloc
- le middle-end (Allocation/scheduling/dispatch) prend un bon quart du CPU et est specifique au OOO

Decodeurs+ALU+2xFPU (pour le full width SSE2)+DCU+un eventuel cache d'instruction+juste une BTB font aux alentours 25% de la surface du core, en rajoutant un middle end in order qui est probablement 4 ou 5 fois plus petit que celui du P4 tu arrives a ~30% de la surface d'un coeur de P4.

Northwood 55M -31M pour le cache L2 = 24M /3.3 ~=7.3M de transistors. Si on regarde l'analyse que j'ai fait cis-dessus j'arrivais dans les >7M de transistors pour un core de P5 avec un support SSE2 full width...

Il y a beaucoup d'approximations dans mes calculs, mais les ordres de grandeurs sont bons a mon avis. Partir du P5 ou defeaturer un P4 amene a peu pres aux memes resultats: pas moyen de mettre 64 CPUs encore moins 128CPUs classiques Intel dans 600mm2 dans le meme process qu'Atom.

Le "80 cores" etait 80 FPUs connectees a un reseau en matrice et des minis routeurs. Si tu regardes bien c'etait 80xSingle precision FPU, si tu passes a SSE2 full width il y a un facteur 4 de difference, donc tu retombes a 20 cores. Bien sur le chip a 80 cores faisait presque 1/2 du reticule donc en theorie tu peux en mettre ~20xSSE2 full width en reservant la moitie pour du cache, 40 sans cache. Si tu ajoutes 25% a chaque "core" pour avoir un frontend un peu plus independant et du calcul entier je retombes sur mes pieds avec raisonablement 16-24 cores (hop, hop encore un saut perilleux).

Edit: je sais que pour le 80 cores mes calculs sont un peu abuses car les routeurs sont proportionnels au nombre de cores alors que en passant a du SIMD j'ai considere que leur ratio restait constant. Le resultat est que mon 16-24 est un peu pessimiste en partant du "80 cores"...

[newbie06]

Si tu regardes bien le dessin, tu te rends compte que c'est 2 a 3% du cpu (excluant le cache) qui est consacre aux specificites du x86.

Pas d'accord : le ucode sequencer doit être pris en compte, je dirais donc plutôt 5% en comptant les caches (à vue de pif hein) ; en plus, je me demande si les unités de prédiction de branchement ne sont pas obligées de faire du pré-décodage pour identifier les instructions de saut (OK ça doit pas être trop gros ça).

Si on regarde ucode sequencer + instruction decoder sur le schéma, on arrive quasiment à la taille du l'unité FP/SIMD.

Je me demande à quoi ressemblent les floorplan des Intel/AMD actuels (au niveau de détail donné pas Hans)

[Alice]

Les premières rumeurs sur le Larabee laissaient entendre entre 16 et 24 coeurs, 16-way SIMD (SSE 512-bits) (cf premier post). A première vue rien n'est venu contredire ces premiers chiffres et d'après ce qu'Intel communique aux développeurs ces chiffres semblent assez cohérents.

[fefe]

Pas d'accord : le ucode sequencer doit être pris en compte, je dirais donc plutôt 5% en comptant les caches (à vue de pif hein) ; en plus, je me demande si les unités de prédiction de branchement ne sont pas obligées de faire du pré-décodage pour identifier les instructions de saut (OK ça doit pas être trop gros ça).

Si on regarde ucode sequencer + instruction decoder sur le schéma, on arrive quasiment à la taille du l'unité FP/SIMD.

Oui mais:
- La moitie du bloc du shema tagge ucode+sequencer est du stockage/traitement d'instruction independant de x86 en soi (cote gauche)
- la SRAM employee pour stocker le code est 2x plus petite pour du x86 compare a du RISC 32 bits donc ton Icache ou autre structure de stockage se doit d'etre a peu pres 2x plus gros pour arriver au meme resultat (je suis d'accord avec un trace cache la validite de cet argument est discutable).
- Meme chose pour les "Raw instructions bytes in" pour le ratio avec du RISC.

Au final en ajoutant les blocs "x86" j'arrive a peine a la surface du FP add+FP mul, sans compter l'impact si le CPU avait eu un ICache a la place d'un trace cache. Ca fait a peu pres la moitie de ce que tu disais . Ca reste non negligeable comme cout je suis d'accord, surtout quand tu as beaucoup de cores, mais ce n'est plus un inconvenient majeur en soit. Et dans une machine a ICache qui ne stocke pas des instructions decodees le cout est a peu pres divise par 2 par rapport a notre decompte (je compte 16k ICache en x86).

Edit: L'argument de compacite du code est moindre sur du code employant les denieres generations de SSE pour cause de prefixes a ralonge btw.

[DJ_DaMS]

http://www.presence-pc.com/actualite/Cray-Intel-29090/
La guerre entre Intel et Nvidia de plus en plus concrete...

[newbie06]

Les premières rumeurs sur le Larabee laissaient entendre entre 16 et 24 coeurs, 16-way SIMD (SSE 512-bits) (cf premier post). A première vue rien n'est venu contredire ces premiers chiffres et d'après ce qu'Intel communique aux développeurs ces chiffres semblent assez cohérents.

Prenons 24 coeurs et 16 way, ca donne en marketing FLOP 24*16*2 (le * 2 vient du MAC) / cycle = 768 FLOP / cycle. Les rumeurs concernant le G200 de nVidia font etat de 1 a 2 TFLOPS. Faudrait donc une frequence de 1.5 a 3 GHz pour Larrabee.

Bien sur, tout ca est calcule sur du vent, et il reste a voir quelles FLOP sont comptees

[DJ_DaMS]

Ca dépend... si ça marche pas ça fera seulement un flop...

Je sors...

[Møgluglu]

Prenons 24 coeurs et 16 way, ca donne en marketing FLOP 24*16*2 (le * 2 vient du MAC) / cycle = 768 FLOP / cycle. Les rumeurs concernant le G200 de nVidia font etat de 1 a 2 TFLOPS. Faudrait donc une frequence de 1.5 a 3 GHz pour Larrabee.

La rumeur actuelle pour le GT200 est 48*8*2 à 1,625 GHz, soit 1,25 GFlops, donc ça parait cohérent...

[fefe]

Vu les frequences actuelles des produits power efficient dans les process Intel 1.5-2GHz semble etre une fourchette raisonable pour Larrabee (je ne les vois pas vraiment pousser trop loin a moins de vouloir avoir recours aux ventilations "seche cheveux").

[newbie06]

Donc on reste dans le meme ordre de grandeur. J'etais vraiment parti sur l'idee que Larrabee etait un bon cran au-dessus (idee pre-concues fort naive, je le concede, mais j'aime bien rever ). Il faut donc vraiment chercher l'interet ailleurs, comme le cote vrai CPU.

[fefe]

Intel a probablement un leger avantage en terme de process: Larrabee n'etant pas prevu dans leur process le plus moderne mais dans un process bien teste cela donne a peu pres une demie generation, donc en gros 20% de surface et un peu de power et de frequence. Nvidia n'ira probablement pas jusqu'a la taille du reticule mais les G80 n'etaient pas loin de 500mm2 donc a supposer qu'ils y remettent la meme surface ca donne encore 20%.

40% de surface en plus a supposer qu'Intel soit aussi experimente que Nvidia ca ne donne pas 40% de debit en plus (les IO et la memoire ne scalent pas bien) mais probablement 30%.
Quand on voit les ameliorations d'efficacite que Nvidia a reussi ces dernieres annees il est evident qu'une partie significative de cet avantage va etre absorbe par le manque d'experience de Intel. X86 absorbera une petite part de cet avantage, le fait que le hardware soit plus generique que dedie, une autre portion. Mais au final, pour moi il est evident qu'il est absolument impossible que Larrabee ait un avantage impressionant sur la concurrence (jusqu'a 20-30% ce n'est pas impossible, mais 2x me semble totalement impossible...)

[newbie06]

"Discussion" interessante sur les tailles de decodeur :
http://realworldtech.com/forums/inde...89001&roomid=2

[fefe]

I disagree . Le seul moyen de faire la comparaison serait d'implementer un frontend dans un autre jeu d'instruction qui offre les memes fonctionnalites/caracteristiques que le frontend actuel.
Pour ce qui est du power, c'est evident qu'il y a un desavantage non negligeable la logique en question ayant bcp de chemins critiques et ayant de gros facteurs d'activite, ca dissipe dur. Pour la surface ce n'est pas si simple que mesurer la surface d un bloc du chip et de dire on peut l'enlever ca doit etre le decodeur x86 (rien que la necessite d'accroitre la taille du cache d'instruction pour contenir le meme nombre d'instructions devrait etre un indice sur l'inexactitude des commentaires en question). Sur un petit die "simple" il est certain que les decodeurs prendront relativement plus d'espace que sur un gros core "complexe" (donc changerait le ratio decodeur/reste de la logique entre un atom et un P4).
En revanche pour ce qui est de l'effort necessaire pour implementer du x86 plutot qu un autre jeu d instruction clean, a mon avis la difference est bien au dela de 15%. X86 ce n'est pas que des decodeurs a la c... c'est beaucoup d'emm...

Quant a P.G. son boulot est de dire ce que la presse veut entendre pour etre convaincue, et il suffit de lire ses declarations relatives a ce topic et les comparer par ex a des blogs d'autres employes d'Intel pour s'en rendre compte.

[DJ_DaMS]

Voilà qui est interessant :
http://www.pcper.com/comments.php?nid=5674
Larrabee fait peur à Nvidia?

[newbie06]

nVidia a deja rachete Mental Images, fin 2007.

D'ailleurs c'est interessant : nVidia maitrise deja le GPU et rachete des boites qui font du RT.
Intel ne maitrise rien et rachete de tout ; ils devraient ptet racheter Tungsten Graphics pour leur faire les drivers

[DJ_DaMS]

[HS ON]
Perso, j'ai un peu du mal à comprendre la politique de Nvidia actuellement, quand on voit le
rapprochement avec VIA pour les CPUs...
[HS OFF]