Intel et Larrabee

**Alexko** · 18/11/2009, 22h38

À 80 cores c'est pas plutôt Terascale/Polaris ? On a vu un die-shot de Larrabee avec 32 cores...

**fefe** · 18/11/2009, 23h36

Oui ca ressemble a une typo

.

C'est combien le max atteint sur SGEMM sur les GPUs actuels (ou futurs si qq un a acces a un Fermi

)

**Møgluglu** · 19/11/2009, 14h08

Envoyé par fefe

C'est combien le max atteint sur SGEMM sur les GPUs actuels (ou futurs si qq un a acces a un Fermi

)

Chez NV, on est a 60% du peak (MAD seuls) sur GT200, donc 425 Gflops sur GTX 285.

Côté AMD, on aurait des prototypes atteignant 880 Gflops sur 4870 (73% peak). Si ça scalait linéairement, on s'approcherait de 2 Tflops sur 5870, mais les ratio Tex/FPU et débit LDS/FPU fait que l'implémentation "optimale" devra être différente...

Pour Fermi, on aura 1 instruction load 128-bit pour 4 instructions FMA. Si les loads sont gérés par l'unité dédiée, on atteindra maxi 80% du peak (limitation au niveau du dispatch).
Ça doit donner une fourchette de 730 à 1000 Gflops sur Tesla C2050...

**fefe** · 19/11/2009, 16h07

Ok donc pour l'instant c'est la demo la plus "haute" sachant que d'ici quelques mois des produits devraient en arriver la (pas des prototypes).

**newbie06** · 05/12/2009, 12h57

http://www.semiaccurate.com/2009/12/...ture-variants/
http://realworldtech.com/page.cfm?Ar...WT120409180449

**fefe** · 06/12/2009, 02h03

Oh surprise

...

**newbie06** · 06/12/2009, 11h39

Je ne suis vraiment pas surpris, je n'ai jamais cru au modèle cohérent avec plein de coeurs, je trouve l'idée du message passing tellement plus intéressante (au moins ça me rappelle ma jeunesse

).

**Neo_13** · 08/12/2009, 12h00

Larabee ne sortira pas ?
Encore une victoire de canard : http://forum.canardpc.com/showpost.p...2&postcount=30
(Y'avait un autre exemple plus pertinent avec une comparaison avec l'itanium 1 tout pourri fourni aux dev pour passer en itanium 2 performants ensuite, mais j'ai la flemme de chercher)

**Alice** · 09/12/2009, 01h33

Aussi souple soit il, Larrabee ne pouvait clairement pas rivaliser avec la concurrence en terme de performance brute. En allant titiller le marché 3D des API graphiques Intel ne pouvait de toute façon pas espérer bcp mieux qu'un échec cuisant sur le haut de gamme.

Du côté du ray-tracing, leur démo de l'IDF dernier était loin de pouvoir faire la différence avec le ray-tracing sur GPU plus traditionnel. Il leur reste alors le calcul haute performance, ce sur quoi ils n'ont rien à mettre en face d'un NVidia qui fagocite le domaine.

Bref l'annulation du Larrabee n'est clairement pas une surprise.

Un avenir viable pour du graphique haut de gamme Intel? Pourquoi pas si le rendu software réussi à s'imposer à nouveau (fort probable). Plus d'API graphique => plus de standard de "GPU". Dans ce cas de figure, un "CPU"-like peut faire tout aussi bien (mieux?) qu'un GPU sur du code graphique, et ce que ce soit sur un CPU externalisé sur carte (Larrabee 2, Fermi3

) ou sur un CPU classique...

**Lionel33** · 09/12/2009, 13h25

D'après cette news (d'accord c'est Fudzilla

) ,Intel dément stopper Larrabee comme solution graphique et travaille jusqu'au moment ou il sera à niveau de Nvidia/Amd

.

**Alexko** · 09/12/2009, 13h31

Ce n'est pas que Fudzilla, c'est le message officiel d'Intel, et c'est logique : ils ont besoin de Larrabee et ne vont pas abandonner comme ça.

**fefe** · 09/12/2009, 16h34

Ca serait con d'investir autant dans un concept et de s'arreter alors que le premier chip n'est pas satisfaisant (surtout que historiquement aucun chip complexe n'a delivre ce qui etait attendu de lui a la premiere generation). Donc ils continuent, je dirais que jusqu'a present tout va normalement, on saura vraiment ce que vaut Larrabee a la 2 eme ou 3 eme generation, ceux qui ont cru autrement sont ceux qui ecoutent les voix de marketing

.

**newbie06** · 09/12/2009, 17h03

Alors j'espère que les générations 2 et 3 auront le bon goût de ne pas être cohérentes.

**Lionel33** · 09/12/2009, 19h14

Tout à fait d'accord ,ce n'est pas une tentative pour creer un nouveau marché (ce qui permet d'avoir une plus grande marge de manoeuvre) mais essayer de pénétrer un marché très compétitif (et en évolution très rapide) et bipolaire (Amd-Nvidia) .

Donc pour réussir à avoir un produit viable ,ils doivent réussir à concevoir une puce performante ,pas trop complexe à produire et à programmer et sans exploser la dissipation thermique ,ce qui leur demandera quelque génération (le moins possible espérons-le) pour obtenir un résultat probant

**Alice** · 10/12/2009, 23h55

Envoyé par Tim Sweeney

I see the instruction set and mixedscalar/vector programming model of Larrabee as the ultimate computingmodel, delivering GPU-class numeric computing performance and CPU-classprogrammability with an easy-to-use programming model that willultimately crush fixed-function graphics pipelines. The model will berevolutionary whether it's sold as a Express add-in card, an integratedgraphics solution, or part of the CPU die.

To focus on Teraflops misses a larger point about programmability:Today's GPU programming models are too limited to support large-scalesoftware, such as a complete physics engine, or a next-generationgraphics pipeline implemented in software. No quantity of Teraflopscan compensate for a lack of support for dynamic dispatch, a full C++programming model, a coherent memory space, etc.

**fefe** · 11/12/2009, 00h01

whether it's sold as a Express add-in card, an integratedg raphics solution, or part of the CPU die.

Sold is the word

.

**newbie06** · 11/12/2009, 19h17

Bah s'il veut la cohérence à tous les niveaux, j'espère qu'il est prêt à éduquer tous ses programmeurs sur les méfaits de laisser faire ça sur un système avec un ringbus

Je trouve son discours limite fanboy, même si je suis plutôt d'accord avec certains points.

**fefe** · 11/12/2009, 21h30

Tu peux en dire plus sur ces mefaits ? Je ne vois pas de quoi tu veux parler...

**newbie06** · 12/12/2009, 01h38

Hum, je me demande s'il y a un piège

Exemple bête : je génère une texture procédurale sur P0. Cool avec la cohérence, tout le monde voit les données et peut faire ce qu'il veut avec cette texture ; enfin pas tout à fait, si je dois la modifier, chuis pas con je la locke avec un sémaphore, mais tout le monde peut la lire. Voilà j'ai stupidement saturé le ring bus parce que j'ai x processeurs qui vont lire la texture.

OK l'exemple est complètement idiot. Mon point est juste que si le placement de données n'est pas fait correctement (impliquant aussi que le traitement est placé), ça ne marche juste pas avec beaucoup de coeurs. Donc la cohérence ne m'apporte pas tant que ça (sauf peut-être des prises de sémaphore plus rapides).

Idiot ?

**fefe** · 12/12/2009, 02h27

Bien sur que c'etait un piege

, mais bon je n'etais pas sur de ce a quoi tu faisais reference.

Je pense que tu confonds coherence et consistance memoire ou alors oublie le snoop filtering et ce qui est fait de maniere generale pour traiter le trafic de coherence. La coherence est juste le fait de garantir quand tu lis une donnee que tu as la derniere version qui a ete ecrite par qui que ce soit dans le systeme. Tu as des snoop filter qui te permettent de ne snoop que si la donnee a ete demandee pour ecrire par un autre core depuis que tu as obtenu ta derniere copie, donc tu n'emets pas de snoops a chaque lecture, et une fois que ta donnee a ete modifiee il y a plein d'algorithmes intelligents de mise a jour de tes filtres qui reduisent/font disparaitre le risque de passer son temps a snoop pour rien a chaque nouvelle lecture. Qui plus est un snoop est une requete specifique et non un transfert de donnee, ce qui dans la plupart des reseaux d'interconnection transite sur des fils differents geres separement. Bien entendu si tu as une donnee a transferer ca prendra de la bande passante, mais il aurait fallu le faire de toutes facons. Donc oui le traffic de coherence prend de la bande passante, sur le reseau charge de gerer ca qui est optimise pour.

Si pour des raisons de consistance tu passes ton temps a locker/unlocker des donnees tes perfs vont s'effondrer si beaucoup de monde doit y acceder, mais c'est essentiellement un mauvais algorithme de parallelisation et pas un effet de la coherence. Le fait de travailler sur des tiles de memoire a tendance a simplifier cet aspect considerablement.

Les problemes de bande passante des ringbus est plus leur scalabilite qu'autre chose. ATI a abandonne le ringbus quand ils ont du mettre trop d'agents dessus, et ils n'etaient absolument pas coherents.

De maniere generale la simplicite de programmation qu'induit la coherence libere du temps pour reflechir a l'algorithme et au placement des taches

.

**Møgluglu** · 23/12/2009, 16h40

Des nouvelles du Siggraph Asia en VO :
http://pc.watch.impress.co.jp/docs/c...22_338322.html

La roadmap initiale :
À partir de Larrabee 1 en 2010, sortie d'une nouvelle version chaque année (2, 3, 4).
En 2014, intégration du core LRB dans les CPU mainstream.

C'est finalement Larrabee 2 qui introduira une incompatibilité dans le jeu d'instruction, même si ça n'a pas l'air de changer grand-chose pour le programmeur sur les instructions vectorielles. Enfin si jamais il n'est pas annulé entre temps.

Fermi n'est pas l'ennemi de Larrabee, c'est un allié.

Bah ouais, il contribue à faire migrer les moteurs de jeu depuis les API graphiques vers du rendu soft et de la physique, terrain favorable à LRB...
AMD devrait suivre d'ici-là.

**fefe** · 23/12/2009, 18h25

Marrant a chaque fois qu'ils ont annonce une roadmap ils s'en sont mordu les doigts. Par exemple, comparez cette annonce a la rumeur de Charlie: http://www.semiaccurate.com/2009/08/...graphics-cpus/ .

**newbie06** · 23/12/2009, 18h37

Envoyé par Møgluglu

C'est finalement Larrabee 2 qui introduira une incompatibilité dans le jeu d'instruction, même si ça n'a pas l'air de changer grand-chose pour le programmeur sur les instructions vectorielles.

J'ai une question à la con : incompatibilité jusqu'à quel point ? Ne serait-ce pas l'occasion pour Intel de laisser tomber certaines features qu'ils se trainent depuis 30 ans et qui ont un coût astronomique (cf. le post de fefe) ? Après tout, la compatibilité binaire on s'en tape un peu sur LRB, non ?

**fefe** · 23/12/2009, 19h23

Ils parlent d'ncompatibilite sur des instructions qui n'existent pas en x86 mais avaient ete introduites par LRB1. Vu que LRB1 ne sera fourni qu'en samples a quelques developpeurs, c'est comme dire que le jeu d'instruction de LRB1 n'a jamais existe... et que LRB2 a le seul jeu d'instruction LRB... Je doute que le sacrifice de la legacy x86 soit pres d'arriver

.

**newbie06** · 23/12/2009, 19h27

Ha ça ne concerne que les instructions vectorielles. Je suis bien déçu

Quelle est la justification pour conserver les aberrations de l'ISA x86 ? Niveau compilo ce serait facile de changer. J'imagine donc qu'il s'agit de réutiliser des unités existantes ?

**fefe** · 23/12/2009, 19h49

X86 c'est comme une religion, il ne faut pas poser ce genre de questions, sinon tu risques de ne pas aimer la reponse

**Møgluglu** · 23/12/2009, 19h49

Envoyé par newbie06

Ha ça ne concerne que les instructions vectorielles. Je suis bien déçu

Pire que ça, la partie vectorielle n'aurait quasiment pas changé non plus.

Peut-être un changement de l'encodage des instructions pour se rapprocher d'AVX, une mise à la norme IEEE 754-2008 des instructions flottantes ou ce genre de chose...

**fefe** · 23/12/2009, 20h01

Option 1 est plus proche de la realite qu'option 2 a mon avis. Des fois il y a des gens qui ne reflechissent pas au futur quand ils definissent une ISA...

**newbie06** · 23/12/2009, 20h14

Envoyé par fefe

X86 c'est comme une religion, il ne faut pas poser ce genre de questions, sinon tu risques de ne pas aimer la reponse

Beuh je ne vois pas ce que je pourrais moins aimer que le x86 actuel

J'adore les incohérences sur les mise à jour des flags, qui obligent à considérer chaque flag comme un registre. Ca doit être un bonheur pour les designers...

Décidément j'y comprends rien au marketing

**Foudge** · 26/05/2010, 09h40

Bill Kircos à propos du projet Larrabee (et de leur futurs IGP) :
http://blogs.intel.com/technology/20...phics-rela.php

Discussion: Intel et Larrabee

Outils de la discussion

Règles de messages