Les SPE : la force du Cell
Les SPE sont constitués de trois unités :
- une unité de calcul appelée Synergistic Processing Unit (SPU)
- un contrôleur DMA : le Memory Flow Controller (MFC)
- 256Ko de SRAM appelée Local Store (LS)
SPU
Les SPU sont des processeurs SIMD : Single Instruction Multiple Data, ce qui signifie qu’ils appliquent la même instruction à un ensemble de données. En l’occurrence ils sont particulièrement adaptés au traitement vectoriel vu qu’ils opèrent essentiellement sur des vecteurs de 4 éléments de 32 bits chacun stockés dans des registres 128 bits. A ce propos, les SPU disposent d’un très large fichier unifié de 128 registres 128 bits, utilisé aussi bien pour les entiers, les nombres en virgules flottantes ou les opérations conditionnelles. Un aussi grand nombre de registres se révèle particulièrement utile pour le déroulement des boucles.
L’architecture des SPU est de type chargement-rangement, tous les accès mémoire se font entre la Local Store et le fichier de registres ce qui est classique dans les architectures RISC. Le SPU comme nous l’avons dit plus tôt exécute les instructions dans l’ordre du programme mais offre une forme limitée de lancement multiple. Ainsi chaque SPU dispose de deux pipes d’exécution, le premier se charge d’effectuer les chargements, rangements, ainsi que les opérations de manipulation d’octets et les branchements. Le deuxième effectue les opérations flottantes, les opérations arithmétiques et logiques ainsi que quelques opérations de manipulations d’octets. Les SPU sont donc capables d’effectuer au mieux deux instructions par cycle.
Les SPU sont optimisés pour effectuer leurs calculs sur les nombres flottants simple précisions. A chaque cycle ils sont ainsi capables d’effectuer une opération FMAC (Floating Point Multiply-Accumulate) sur quatre nombres flottants simple précision ce qui offre une performance de crête de 32 GFlops par SPU pour un processeur cadencé à 4 GHz. Notons toutefois qu’à l’image des VU de l’Emotion Engine (le processeur de la PS2), les SPU ne sont pas conformes à la norme IEEE 754. Celle-ci défini un comportement bien précis pour l’arrondi, et les exceptions en cas de débordement, division par zéro, etc. En ignorant cette norme, les SPU peuvent offrir de meilleures performances et à un coût moindre. De plus ce n’est pas tellement pénalisant vu le cadre d’application des programmes destinés à être exécutés sur les SPU.
En revanche dans le cadre de calculs scientifiques, qui peuvent être un autre débouché pour le Cell, le respect de la norme IEEE 754 est primordial, aussi lors de calculs double précision les SPU respectent cette norme. En contrepartie les SPU ne sont plus capables d’exécuter qu’une FMAC sur deux nombres double précision par cycle, et une FMAC ne peut être exécutée que tous les 7 cycles. La performance de crête retombe donc dans ce cas à 2.3 GFlops environ par SPU pour un processeur à 4GHz ce qui est nettement moins impressionnant.
Le jeu d’instructions des SPU est dérivé du jeu d’instructions VMX mais n’est pas complètement identique. Rappelons ici que le jeu d’instructions VMX aussi appelé Altivec par Motorola ou encore Velocity Engine par Apple, est une extension du jeu d’instructions PowerPC offrant 162 nouvelles instructions dédiées au traitement vectoriel. Les instructions arithmétiques disponibles sur les SPU sont donc similaires à celles du jeu d’instructions VMX mais certaines ont été retirées. Le jeu d’instructions des SPU inclus en revanche des nouvelles instructions par rapport au VMX pour contrôler les transferts de et vers la mémoire externe par l’intermédiaire de l’unité MFC.
Enfin un VRAI article...
Une révolution ce Cell? rendez-vous dans 10ans pour avoir la réponse...
Moi je dis que c'est l'avenir.
Je suis très content de mon A64 3400+ et de ma 6800GT, mais pour l'avenir, les fondeurs de CPU vont s'inspirer de ce qu'IBM a voulu faire pour ce Cell.
'Enfin un VRAI article ...', des articles tres complets sur le sujet existent depuis plus de 8 mois sur le net. Il faut chercher un peu ...
et encore il parle pas en détail de l'asm du cell
Excellent Articles, peut être y'en a t'il déjà sur internet, mais celui la est suffisament accessible et complet pour defenir une référence
Bravo encore !
'Enfin un VRAI article ...', des articles tres complets sur le sujet existent depuis plus de 8 mois sur le net. Il faut chercher un peu ...
Ce que je voulais dire, c'est un article traitant de technologie informatique tout en restant accessible. Parce que souvent les articles font allusion à des news par toujours pertinente.
Voilà , c'est tout. Je sais que sur le net on peut trouver des articles encore plus poussés, mais par forcément sur presence-pc...
A quelques mois de l'arrivée de la Planystation 3, nous vous proposons de vous plonger dans la technologie et l'architecture de son processeur phare, le Cell.
Kesekça Planystation ?
[...] Planystation 3[...]
Pourquoi tant de "n" ?
Rappelons qu'Apple a qui le Cell avait été présenté, à dit après avoir choisi Intel et sa future roadmap, qu'il aurait été plus difficile de porter le code de Mac OS X et des applications sur Cell que sur x86...
Ça semble surprenant (car le PPE de Cell est un PowerPC) mais ça en dit long sur la complexité de programmation des SPE... En effet, le PPE est tellement simplet que lui laisser traiter la majeure partie des opérations en laissant les SPE tourner à vide aurait abouti à une bouse sans nom. Pour que le Cell soit rapide, il faut donc tout coder pour que les instructions envoyées au PPE soient au maximum dispatchées aux SPE et traitées pas ces derniers.
Certains développeurs prétendaient qu'il suffisait de "pré-coder" les parties multimédias de l'OS les plus gourmandes (et non totalement les applications, alors plus simples à développer), actuellement prévues pour être exécutées par les shaders programmables des cartes graphiques, pour les "câbler" à la place sur les SPE de Cell (ça regroupe Quartz Extreme, Core Image, Core Audio, QuickTime etc...).
Mais comme le gain de temps et de puissance par la carte graphique est déjà énorme actuellement (alors que sur Mac on est toujours en AGP, ce sera encore plus fulgurant en PCIe) et que cela laisse le processeur s'occuper d'autres tâches, à quoi cela aurait servi de tout regrouper à nouveau... sur le processeur central, et ne plus utiliser le GPU ?
Mais qu'on ne s'y trompe pas, avec la gravure des puces de plus en plus fine, ce genre de design à multiples cores asymétriques massivement parallèles est l'avenir. Il n'y a pas qu'IBM qui travaille dessus, même s'ils ont le mérite d'être les premiers à l'avoir sorti avec Sony et Toshiba.
Intel vient heureusement de changer son fusil d'épaule, et avec sa famille Nehalem (qui n'est plus un projet de successeur du P4 NetBurst à ultra haute fréquence) et ses descendants, prépare pour 2007 et au-delà des processeurs massivement multicores et asymétriques, équipés de très nombreux DSP internes qui ressemblent beaucoup aux SPE de Cell. Mais comme ces puces auront un processeur primaire plus musclé que le PPE de Cell, il pourront trouver leur place dans autre chose que les TV, les PDA et les consoles de jeu, si vous voyez ce que je veux dire...
Fedy, toutes mes félicitations
Heu la photo c'est un Cell?
Ca me parait bien petit pour un proc de PS2.
Ca me parait bien petit pour un proc de PS2.
234 millions de transistors sur un die de 221 mm2, c'est quand même assez balèze par rapport à AMD Semptron dont le die fait 144 mm2. Même le gros Pentium D et ses 230 millions de transistors mesure 206 mm2... mais c'est normal vu qu'il y a 9 cores sur Cell et beucoup de transistors.
Pour les consoles, le die du proc de la PS2 fait 240 mm2, mais il a bien moins de transistors ("seulement" 10,5 millions) et il est gravé... le double, en 180 nm.
Comme quoi, tout est relatif !
'Enfin un VRAI article ...', des articles tres complets sur le sujet existent depuis plus de 8 mois sur le net. Il faut chercher un peu ...
Plutôt que de le dire, il vaut mieux le faire :
[*]Google "Cell CPU"
[*]Cell Industries: Introducing The Cell
[*]Wikipedia "Cell (microprocessor)"
[*]PCstats: IBM's CELL Processor: Preview to Greatness?
[*]XbitLabs: IBM’s Cell Will Change the World, Says Report (Jul 2004)
[*]ArsTechnica: Introducing the IBM/Sony/Toshiba Cell Processor
[*]TheRegister: The Cell chip - what it is, and why you should care
[*]THG 30 Aug 2005: « IBM lead architect: Cell CPU could take PS3 beyond gaming, into Linux »
[*]BBC News: PlayStation 3 processor unveiled
[*]et encore beaucoup d'autres...
Paris, Fri 30 Sep 2005 11:16:30 +0200
Assurons-nous bien du fait avant que de nous inquiéter de la cause -- Fontenelle
Félicitation pour un travail très bien réalisé. Une vulgarisation sans complaisance, un jugement personnel discret... bien! Il est vrai qu'il n'y a aucune configuration qui ne sort des labos... donc l'évaluation sur papier doit rester sobre de toute sanction ou de tout enthousiasme.
IBM a annoncé un usage tourné vers le multi-media et l'embarqué. bon!... c'est tout? Sur le terrain de l'informatique je ne vois pas une grande révolution. Et pourtant IBM semble vouloir attirer des communautés Linux sur cette architecture. Des cartes "proto" devraient pouvoir être distribuées en fin d'année si j'ai là encore bien compris.
Honnêtement le vectoriel ne m'émeut pas vraiment... mais c'est parce que culturellement parlant, j'ai une simple orientation informatique de gestion. Dans ce domaine, le graphisme se limite à l'IHM traditionnellement Windows ou encore tout bureau XWindows. Alors le vectoriel... le multi-média... et bien on attend l'IHM 3D avec une interactivité vocale... Vista c'est encore de la gnognote dans ce domaine! Apple, avant-gardiste, aurait pu prendre les devants avec IBM, mais la R&D ça coute cher, et puis quelles sont les exigences d'IBM dans un éventuel partenariat. Apple veut faire du volume maintenant. Alors? IBM? Quelle stratégie au-delà de tirer des bénéfices dans le marché volumineux des consoles de jeux et des équipement multi-média... un ROI rapide pour revenir à bas prix dans le marché des PC et serveurs?
Et dans le domaine des cores dédiés, quand est-ce qu'on intègrera des unités de traitement cryptographique comme Via le fait (génération de nombres aléatoires, algorythme AES)?
Honnêtement je suis favorable à un développement de technologie de type Cell. Cette première monture laisse perplexe pour certains points mais me semble conçue pour le multi-média dédié. Est-ce aussi une approche plus sexy pour attirer une génération de développeurs en vue d'une extension aisée de leur compétence dans les domaines classiques de l'informatique avec Cell-2, Cell-3, ...? On suppose qu'IBM priviligiera Linux! Sauf si d'autres lui font des yeux doux et que ça promet de rapporter (IBM n'a peut-être pas digéré son divorce avec MS). Cela dit, les faiblesses du PPE évoquées ne leur ferment pas la porte au client léger multimédia (ça existe ça???)
bah moi je constate qu'en appli multimédia c'est une claque de puissance, mais qu'en appli demandant des calculs exacts, bah c'est pas la joie; en gros c'est pas sur le Cell qu'il faudra faire tourné des programme scientifique de type Folding@Home... dommage! lol
bah moi je constate qu'en appli multimédia c'est une claque de puissance, mais qu'en appli demandant des calculs exacts, bah c'est pas la joie; en gros c'est pas sur le Cell qu'il faudra faire tourné des programme scientifique de type Folding@Home... dommage! lol
Pourtant F@H etant un parfait exemple de calcul distribué, ca en fait le client ideal des processeurs a plusieurs core comme le CELL...
Imagine que tu puisses dedier chaque sequence de calcul a un SPE différent, tu imagine que tu pourrais en faire tourner huit, et il te resterait encore le core principal pour faire tourner ton OS ... pas mal, non ?!?
fx
edit: je n'avais pas compris que tu faisais allusion au probleme de calcul flotttant des SPE.
Imagine qd meme qu'en flottant, tu peut d'apres l'article atteindre 2.3gflops par SPE.
Avec huit SPE, ca fait 18.4 Gflops, ce qui equivaut qd meme a trois fois les perfs d'un Xeon 3Ghz, donc relativement au calcul entier, c'est moyen, relativement aux autres procs, c'est qd meme pas mal
Y a aussi un truc que tout le monde oublie, et qui effectivement ne sera pas vraiment mis à contribution par les Cell de première génération : cette architecture a été crééé pour tirer parti des réseaux pervasifs très haut débit du futur. En clair, leur but ultime sera de fonctionner tous ensemble et de se distribuer les calculs sur LAN, voire WAN. Vos calculs pourront être pris en charge par un appareil contenant 1, 4, 8, 32 Cell ou plus, mais aussi entre toutes sortes d'appareils AV équipés Cell, reliés sans fil : plusieurs PC, les TV, les set-top-box etc... C'est évidemment pas pour tout de suite mais vous avez l'idée.
Oui, Sony parlait de gonfler les perfs de la Playstation 3612 avec une TV Sony, un microonde sony, un lavelinge sony, une armoire à chaussures Sony, un chauffe-biberon sony, un ampli sony, etc
Pourtant F@H etant un parfait exemple de calcul distribué, ca en fait le client ideal des processeurs a plusieurs core comme le CELL...
Imagine que tu puisses dedier chaque sequence de calcul a un SPE différent, tu imagine que tu pourrais en faire tourner huit, et il te resterait encore le core principal pour faire tourner ton OS ... pas mal, non ?!?
fx
edit: je n'avais pas compris que tu faisais allusion au probleme de calcul flotttant des SPE.
Imagine qd meme qu'en flottant, tu peut d'apres l'article atteindre 2.3gflops par SPE.
Avec huit SPE, ca fait 18.4 Gflops, ce qui equivaut qd meme a trois fois les perfs d'un Xeon 3Ghz, donc relativement au calcul entier, c'est moyen, relativement aux autres procs, c'est qd meme pas mal
bah vu que les arrondis sont pas normalisé, apparemment pour les calculs scientifiques le Cell c'est assez naze... alors que pour ytous ce qui est calcul flottant et travail a la volé mais avec permission d'erreur la ça déchir tout. relis l'article tu verra., il en reparle aussi dans la conclusion si tu est féneant! lol
Pour ma part, je pense qu'une cocotte minute vole très bien en apesenteur, du moment qu'un bon moteur de fusé la propulse hors de l'atmosphère.
Le succès du cell viendra plus des développeurs qui le choisiront, c'est bien à l'homme d'adapter le logiciel au matériel... Le cell a dénorme capacité, aux gens de l'exploiter !
bah vu que les arrondis sont pas normalisé, apparemment pour les calculs scientifiques le Cell c'est assez naze... alors que pour ytous ce qui est calcul flottant et travail a la volé mais avec permission d'erreur la ça déchir tout. relis l'article tu verra., il en reparle aussi dans la conclusion si tu est féneant! lol
relis ce que j'ai marqué ... Assez naze, en calcul avancé ca represente qd meme trois fois un xeon 3ghz ...
Je viens de lire l'article, fort bien ecrit et comprehensible par le commun des mortels
Ce micro-controleur embarquait un CPU ARM (que je vais assimiler au PPE) et un DSP (que je vais assimiler à un SPE). Pareillement, les deux travaillaient dans une memoire separée et il fallait faire des requette memoire pour remplir ou vider la memoire du DSP à partir de, ou vers là memoire centrale.
L'architecture massivement multi-thread est une excellente idée quand elle est bien gerée et ce processeur semble tres bien construit.
Mais...
... je vois dans cette architecture un enorme probleme, et je comprends maintenant beaucoup mieux les reticences de developpeurs a son egard.
Les SPE ne peuvent travailler que dans le Local Store pour eviter un gestionnaire memoire complexe. Et là, le bas blesse, pour plusieurs raisons:
Pour commencer, j'ai travaillé il y a 3 ans sur un micro-controlleur derniere generation d'un des acteurs majeur du secteur dont je ne citerai pas le nom
Ce systeme etait annoncé comme revolutionnaire, et en tant que partenaire, j'avais accés a toute la documentation technique de l'engin. Currieusement, la premiere chose qui m'a frappé etait la totale absence de chiffres concernant les capacité de transfert memoire entre les 2 unités.
Nous avons donc du faire nos propre benchmarks. Et ce fut la catastrophe. En lieu et place des mega-octets de traitement promis par le CPU ou le DSP separement, nous nous somme retrouver à pouvoir transferer 20KO (oui kilo-octets!) par seconde entre les unités, à cause des differents problemes de synchronisation.
Affolé, le constructeur reagit et augmente les fenetres memoire et optimise les systeme de transferts. Resultat, au mieux, nous avons atteint 40ko/s. Le partenariat n'est pas allé plus loin, et à ma connaissance, ce merveilleux micro-controlleur n'a pas eu le succés escompté.
Quelle sera réellement la capacité du Cell à assurer des transfert rapide entre les unités? Si les unités passent leur temps à attendre que la memoire se remplisse ou se vite, leur formidable capacité de calcul ne servira à rien.
Pour finir, je comprends que ce processeur fasse peur au developpeur. Adieu les architechtures traditionelle, adieu l'abstraction hardware, cette fois il faudra tenir compte du chef d'orchestre, de ses musiciens et des moyens de coordonner le tout.
Adieu aussi le portage facile d'une console vers une autre.
J'ai peur qu'au final, le PPE soit majoritairement utilisé et les SPE utilisé de temps à autre pour taches ingrates et/ou repetetives.
Wait & See
Wait & See
'Enfin un VRAI article ...', des articles tres complets sur le sujet existent depuis plus de 8 mois sur le net. Il faut chercher un peu ...
Plutôt que de le dire, il vaut mieux le faire :
[*]Google "Cell CPU"
[*]Cell Industries: Introducing The Cell
[*]Wikipedia "Cell (microprocessor)"
[*]PCstats: IBM's CELL Processor: Preview to Greatness?
[*]XbitLabs: IBM’s Cell Will Change the World, Says Report (Jul 2004)
[*]ArsTechnica: Introducing the IBM/Sony/Toshiba Cell Processor
[*]TheRegister: The Cell chip - what it is, and why you should care
[*]THG 30 Aug 2005: « IBM lead architect: Cell CPU could take PS3 beyond gaming, into Linux »
[*]BBC News: PlayStation 3 processor unveiled
[*]et encore beaucoup d'autres...
Paris, Fri 30 Sep 2005 11:16:30 +0200
Assurons-nous bien du fait avant que de nous inquiéter de la cause -- Fontenelle
super pas un seul papier en francais !
la goute d'or, Fridai 30 Septembeur 2005 à 22:12:41 +0200
BKgk, selon Ars-technica:
Ce qui donne 12 octets/cycles.
Pour arriver à plus de 40ko/s il faudrait une fréquence de 8,534 KHz !!!
Maintenant il faur voir comment sont dispatchés les différents accés à la cache avec les SPE.
Je vais mettre en place le processeur San Gohan et vous allez voir la claque que va ce prendre ce processeur Cell
BKgk, selon Ars-technica:
Ce qui donne 12 octets/cycles.
Pour arriver à plus de 40ko/s il faudrait une fréquence de 8,534 KHz !!!
Maintenant il faur voir comment sont dispatchés les différents accés à la cache avec les SPE.
comme disait Bkg2k, il y a une grande différence entre perf reele, et perf sur le datasheet
ici, 12o/cycle... d'ailleur tu te trompe, c'est 96 BYTE, et non pas bit, donc 96 octet/cycles..
c'est tres bon, mais ca veux dire... merde c'est quoi la fréquence de ce bus de donnée? j'arrive pas a trouver
d'ailleur 96octet utiles? 96 octet eu total ( CRC? bit de sécurité? début de trame fin de trame? bit de controle?)
combien de cycle il faut attendre pour reserver ce bus? peut on se reserver le bus pendant un certain temps ( un peu comme le DMA des disques dur )? comment se reserver le bus? faut il une interruption sur le PPE? il y a t'il un arbitre spécifique?
beaucoup de question complexe, qui risque de limiter ce débit...
d'ailleur est-ce que le compilateur optimisera comme il faut ce bus ( dans un premier temps en tout cas )?vas t'il perdre beaucoup de cycle a changer en pérmanence le SPE maitre du bus ( pour limiter les attentes quand un SPE a un résultat ) ou vas t'il préferer que un SPE soit maitre un maximum de temps?
enfin bon, je m'égare, mais attention, le Bus PCI promet 32bit*133MHz, mais en reel est bien loin de ces performances a cause du genre de défaut que j'ai appuillé...
sinon l'architecture "in-order" de ce processeur en fait un choix particulierement mauvais ( a mon humble avis qui n'engage que moi, et les personne ayant une connaissance plus poussé) pour les OS comme linux, ou macos, ce qui explique le choix d'apple ..
programmer pour un CELL à 7 cores a 3.2GHz, avec 256Ko de mémoire est totalement différent de coder pour un CELL a 21 core avec 1Mo de mémoire, ce qui rend la conception d'un OS pratiquement impossible, ou alors le dédie a un unique processeur, ce qui est totalement différent avec les processeur "out of order", X86 ou PPC
porter macos sur PS3 est possible ( je ne dis pas qu'il serait performant, j'en sais rien), mais le porter sur "architecture CELL" necessiterais une recompilation a chaque modification ...
Jsuis pas ultra-calé en architecture processeurs mais ya pas mal de trucs que je comprends.![[:c3po]](http://img.infos-du-net.com/forum/images/perso/c3po.gif)
Ca n'empeche que cet article me donne des boutons
Pour ma part, je pense qu'une cocotte minute vole très bien en apesenteur, du moment qu'un bon moteur de fusé la propulse hors de l'atmosphère.
Le succès du cell viendra plus des développeurs qui le choisiront, c'est bien à l'homme d'adapter le logiciel au matériel... Le cell a dénorme capacité, aux gens de l'exploiter !
+1. le pb sera encore l'interface chaise clavier chargée d'élaborer le code. aussi bien le code qui interprete et compile du code que le code qui a pour vocation d'interagir avec l'interface chaise clavier. Déjà qu'il y a une sous exploitation des archi actuelles alors vouloir en mettre en place des nouvelles, avec de nouveaux concepts de raisonnement associés, ça va compliquer toute cette histoire...
je trouve vraiment abhérant, mêm sous ironie de comparé l'homme a une interface...
blague d'informaticien, les bugs viennent à 90% de l'interface chaise-clavier