Canard PC vous en dit plus sur Larrabee

[Oxygen3]

Dans la microelec, ceux qui vivent sont ceux qui continue la R&D pendant la crise. Car à la sortie de crise, c'est trop tard pour s'y mettre.

Je serai tenté de dire qu'il n'y a pas que dans la micro elec

[Neo_13]

Non, mais dans la microelec, ils le savent et l'appliquent... dans les autres domaines... Voilà quoi.

[Vladtepes]

Il faut bien également qu'Intel profite de sa position dominante!

La dernière fois qu'ils ont essayé de faire avancer les spécification hardware des PC (en passant à un vrai 64 bits complètement différent), ils se sont fait devancer par AMD qui en a sorti un pseudo-rétro-compatible vite fait (et plus ou moins bien fait) tout en vérouillant un peu plus l'architecture des pc (comme quoi concurrence ne rime pas nécessairement avec diversité)

ça pourrait vraiment être une bonne nouvelle si les développeurs (et en particulier micro$oft, puisqu'on parle plutôt de PC) s'y mettent... mais bon il ne faut pas trop y compter, vu le nombre d'évolutions techniques partiellement, ou complètement, inexploitées dans les divers domaines informatiques... ça risque surtout de venir grossir les rangs des évolutions tout justes bonnes à exciter les services marketing

Disons que si les devs avaient ne serais-ce que la moitié de l'enthousiasme des fabriquants de hard, au lieu d'avoir un poil dans la main (un baobab pour ma part...) et de se limiter pour des causes diverses (donc beaucoup sont certes louables) à ce qu'ils connaissent déjà bien ou à ce qui a déjà été fait (par soit ou par les autres), le monde du PC serait bien meilleur.

On en viens à louer les mérites des plates-formes plus fermées comme les stations de travail, les macs ou les consoles... et à rêver d'un monde ou tout sera programmé dans un java-like indépendant de la plateforme et du hard, et supra optimisé à l'aide des fabricants de hard... AMEN

[lordpatou]

Ouais c'est bien beau tous ca , mais on ne me la fais pas a moi, Larrabee ne fais pas le moine , non de non.

[bjone]

Il faut bien également qu'Intel profite de sa position dominante!

La dernière fois qu'ils ont essayé de faire avancer les spécification hardware des PC (en passant à un vrai 64 bits complètement différent), ils se sont fait devancer par AMD qui en a sorti un pseudo-rétro-compatible vite fait (et plus ou moins bien fait) tout en vérouillant un peu plus l'architecture des pc (comme quoi concurrence ne rime pas nécessairement avec diversité)

ça pourrait vraiment être une bonne nouvelle si les développeurs (et en particulier micro$oft, puisqu'on parle plutôt de PC) s'y mettent... mais bon il ne faut pas trop y compter, vu le nombre d'évolutions techniques partiellement, ou complètement, inexploitées dans les divers domaines informatiques... ça risque surtout de venir grossir les rangs des évolutions tout justes bonnes à exciter les services marketing

Disons que si les devs avaient ne serais-ce que la moitié de l'enthousiasme des fabriquants de hard, au lieu d'avoir un poil dans la main (un baobab pour ma part...) et de se limiter pour des causes diverses (donc beaucoup sont certes louables) à ce qu'ils connaissent déjà bien ou à ce qui a déjà été fait (par soit ou par les autres), le monde du PC serait bien meilleur.

On en viens à louer les mérites des plates-formes plus fermées comme les stations de travail, les macs ou les consoles... et à rêver d'un monde ou tout sera programmé dans un java-like indépendant de la plateforme et du hard, et supra optimisé à l'aide des fabricants de hard... AMEN

Effectivement l'Itanium avait des spécifications élégantes (registres de predicats binaires, instructions avec predicat, etc....).

Mais le fait est que l'échec de l'Itanium est de la pure faute d'Intel et non d'AMD.

Intel avait la fenêtre pour en faire une version low-cost pour remplacer l'archi x86, mais ils n'ont jamais osés tués la poule aux oeufs d'or.

Cette hésitation a donnée la fenêtre de tir pour Amd et leur extension x64, et le non-investissement massif autour de l'Itanium pour lui créer un écosystème large l'a tué.

Pour le Larrabee qui a des specs alléchantes, on verra si Intel va mettre le paquet ou pas

[Tromzy]

Dans la microelec, ceux qui vivent sont ceux qui continue la R&D pendant la crise. Car à la sortie de crise, c'est trop tard pour s'y mettre.

Je vois vraiment pas ce que Sport-Elec vient faire dans cette histoire.

[bjone]

Parceque avec Sport-Elec tu deviens balèze BALEEEEEEEZEEE

[Erokh]

C'est ma façon de me moquer gentillement d'un mec qui demande si on va connecter un CPU sur un bus point à point. Parce qu'en l'état, t'as question a autant de sens que "le prochain core i9, ce sera sur PCI-e ou totalement autre chose ?"

SI c'est mis sur une carte fille comme une carte graphique, je vois vraiment pas ce que ça pourrait être d'autre que du PCI-e.
SI c'est mis en copro, ça pourrait se planter sur un socket dédié lié au cpu via CSI qui servirait enfin à quelque chose.
SI c'est utilisé en CPU, ben ce sera sur une CM avec un socket spécial.

Si j'en crois le schéma qui illustre la news, ce sera très certainement en PCI-e

[Neo_13]

Si j'en crois le schéma qui illustre la news, ce sera très certainement en PCI-e

Ben si ça sort en carte fille, oui (point 1). Mais vu qu'on sait toujours comment ça sortira (hors SDK, je veux dire...), le system interface pourrait finalement être un CSI et Larabee devenir un copro pour serveur (par contre, en GPU, a moins de lui greffer le NB, ça restera PCI-e)

(Et puis je regarde pas les images, moi je lis les news dans le forum)

[Doc TB]

Larrabee = PCI Express.

[dredd]

Bon, je sais pas si elle a déjà été faite dans ce thread, mais on a tellement peu l'occasion que je la fait quand même:

-Larrabee, c'est où dites?
Par là, mec.

[Neo_13]

Larrabee = PCI Express.

Ou alors, Pat t'as parlé d'un autre projet secret, pendant qu'il prenait la pose avec son wafer, pour un copro à base de larabee like avec des zone fpga le tout connecté sur CSI pour faire un truc qui envoie du bois et en plus puisse se customiser pour des besoin encore plus spécifique. :chinoisdufbi:

[Gérard le Canard]

Larrabee, c est une blague en lui-meme (L ara be(e)). Desole, je ne peux faire accents ni apostrophe.

Reste a voir s il sera accepte par l industrie (je me dis qu il doit bien avoir des entreprises/studios qui vont dire non a l a chose, ou alors c est pour les ecoles partenaires ?)

[DaBoB]

Au pire vous vous en servirez de plateau repas ou freesbee en été

[Arcanum-XIII]

C'est pour ça qu'ils ne la vendront pas...

Tu veux dire comme leurs autres chipset graphique ? Ou tu parles de la première génération pour les développeurs ?

Dans le second cas, tu imagines bien que la version pour le publique va aussi souffrir d'erreur de jeunesse, vu que c'est la que commencera le beta test grandeur nature !

[Neo_13]

Parfois les gens sortent un produit fini... Tout le monde n'est pas Asus ou MS (quoique sur Seven, ils ont l'air d'avoir fini le produit )

[Yasko]

32 coeurs en 65 nm ?!
Et cette histoire de réticule, et de taille max de chip ? (16~24 coeurs en 45 nm)
Le coeur de Pentium a été allégé depuis les derniers calculs ?
What's wrong ?

[fefe]

Tu peux s/65nm/45nm/g dans la news .

[cbo]

Sur ?

Parce que là on y comprend plus rien.

Non pas que ça ait une importance dramatique mais quand on essaye de suivre vos échanges sur votre forum et que dans les articles on lit autre chose c'est embêtant.

Merci à Doc TB de confirmer/infirmer

[Alexko]

La news a été éditée, donc visiblement c'est sûr.

N.B. : l'estimation de 16~24 cores était (notamment) basée sur le principe voulant que Larrabee suive la "tradition" d'Intel et ait 50 % de cache. Or, avec 32 x 256 ko = 8 Mo de L2 + 8 Mo de L3 (soit 16 Mo de cache) on est encore très loin des 50 %.

Sur Nehalem (en 45 nm lui aussi) on a grosso-modo 6 mm² / MB de cache, donc 16 Mo => 96, disons 100 mm². En supposant un die de 600 mm² (max réticule) on est donc à 17 % de cache, environ. C'est peu pour un CPU, mais pas spécialement étonnant pour un GPU, et ça permet de mettre bien plus de cores.

Même en supposant qu'Intel utilise du cache 8T sur le L2 (comme sur Nehalem) et en comptant un peu plus large pour les tags/write buffers, ça reste en-dessous de 25 %.