- 1 – Introduction
- 2 – La première révolution RISC
- 3 – La quête d’un meilleur ILP
- 4 – L’aveu d’un échec
- 5 – L’aveu d’un échec (suite)
- 6 – Les nouveaux enjeux
Les nouveaux enjeux
Pour aboutir à leur architecture, IBM, Sony et Toshiba ont donc cherchés le point commun entre toutes les applications qu’ils souhaitaient accélérer. Dans tous les cas qu’il s’agisse de vidéo, de 3D, de calculs physiques il s’agit d’appliquer un même ensemble d’instructions relativement petit (on parle de kernel) à un très large ensemble de données (un flux). Ce code est très facilement parallélisable car il a peu, pour ne pas dire pas, de dépendances. Autrement dit à l’intérieur d’un kernel le résultat du calcul pour un élément donné ne dépend que de ses entrées et pas du résultat des calculs d’un autre élément du flux. De plus contrairement au code des applications bureautiques, il y a peu de branchement : tous les éléments d’un flux sont traités exactement de la même manière.
Encore une fois ces observations n’ont rien de révolutionnaires : ce sont elles qui sont à la base des DSP qui existent depuis des années. Ces DSP qui ont évolué au fil du temps pour devenir de plus en plus programmables comme le montre l’exemple des GPU initialement intimement lié à un sous ensemble du pipeline graphique (la rastérisation) et aujourd’hui utilisés pour toutes sortes de calculs. Ainsi on parle de plus en plus de GPGPU : General Purpose Computation on GPUs mais malgré les progrès effectués dans ce domaine tant du point de vue hardware (avec des GPU supportant un nombre toujours plus important de ressources : instructions, registres etc) que software (HLSL, Brook…) effectuer des calculs généraux sur un GPU reste compliqué.
Encore une fois ces observations n’ont rien de révolutionnaires : ce sont elles qui sont à la base des DSP qui existent depuis des années. Ces DSP qui ont évolué au fil du temps pour devenir de plus en plus programmables comme le montre l’exemple des GPU initialement intimement lié à un sous ensemble du pipeline graphique (la rastérisation) et aujourd’hui utilisés pour toutes sortes de calculs. Ainsi on parle de plus en plus de GPGPU : General Purpose Computation on GPUs mais malgré les progrès effectués dans ce domaine tant du point de vue hardware (avec des GPU supportant un nombre toujours plus important de ressources : instructions, registres etc) que software (HLSL, Brook…) effectuer des calculs généraux sur un GPU reste compliqué.
Annonces Google
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.
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" ?
Ç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...
Ca me parait bien petit pour un proc de PS2.
Heu la photo c'est un Cell?
Ca me parait bien petit pour un proc de PS2.
La photo en page 12 est bien un Cell (gravé en 90 nm), et contrairement à ce que tu crois, il est relativement gros comparativement aux processeurs de PC, et encore plus pour un processeur de console...
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
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
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
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
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 ...
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
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
On le verra en 2006 : la PlayStation 3 étant équipée d'un Cell composée donc d'1 PPE et de 8 SPE ; et la Xbox 360 étant équipée d'un PowerPC tricore bien similaire à 3 PPE (beaucoup plus qu'à "3 G5"...) et sans aucun SPE. Beau match en perspective
'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
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.
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 ...
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...
blague d'informaticien, les bugs viennent à 90% de l'interface chaise-clavier
En effet cette blague archi-usée est bien une « blague d'informaticien », càd de personnels trop en dessous de la moyenne des gens pour les comprendre ; comment, sinon, expliquer pareil mépris pour l'utilisateur, que le SI (Service Informatique) est au contraire supposé servir, donc respecter ?
Si vous étiez PDG d'une boîte assez grande, où mettriez-vous les meilleurs : du côté du management et du développement ? ou du côté du SI, du Help Desk et autres administratifs ? Résultat, si un bon SI comprend bien les difficultés de ce métier, il y a en général plutôt dans les SI une majorité qui n'ont pas assez d'intelligence pour comprendre :
[*]que quand on est loin d'un problème on le comprend moins bien que quand on est près - donc que l'utilisateur, aussi ignare qu'il se prétende (car il est en général plus modeste et plus compétent que ce qu'on dit), est a priori celui qui est le plus près de comprendre le problème ;
[*]qu'en plus, un agent de SI est très généralement au dessous (en intelligence, instruction, expérience, ouverture d'esprit) de la moyenne des utilisateurs ;
[*]que lorsqu'on ne comprend pas quelqu'un ce n'est pas forcément qu'il vous est inférieur.
Le résultat est que les plus mauvais des agents des SI, au lieu de faire effort pour se hisser au niveau des usagers, se croient au contraire supérieurs à eux, et se donnent bonne conscience en leur inventant des imbécillités comme celle que vous avez relayée.
Paris, Fri 14 Oct 2005 09:50:00 +0200, édité 10:07:50
Tire de SVM à l'époque : l'ordinateur le + rapide et le - cher du monde.
C'était l'Archimedes.
Une machine révolutionnaire, avec un OS révolutionnaire le RISC OS, dans 2 mo de ROM.
Avec 4 mo de RAM, l'ensemble était stupéfiant.
A l'époque l'ARM2 était cadencé à 8 Mhz.
Un vrai 32 bits au niveau opérande, le Program Counter lui était 26 bits (dans les versions suivantes il sera 32 bits).
Pas de registre dédié, hormis R13 pour pointer la pile, R15 Program Counter et flags et R14 recevait l'adresse de retour après un saut à une sous-procédure (BL : Branch with Link).
Suffisait de sauver R14 pour avoir en permanence 15 registres 32 bits librement utilisables (R0 à R14).
Pour le reste, toute liberté.
Le pied pour n'importe quel programmeur assembleur.
Depuis l'Acorn Risc Machine est devenu l'Advanced Risc Machine et ses nombreuses déclinaisons (STRONGARM, XSCALE) se retrouvent dans de très nombreuses machines.
Puissants, faciles à programmer, et surtout très faible consommation ...
Faites des recherches sur yahoo.co.uk vous en saurez plus c'est passionnant.
Et bonne année 2006
et le PC de l'ARM2 serait pas 16 bits plutot ???
En effet cette blague archi-usée est bien une « blague d'informaticien », càd de personnels trop en dessous de la moyenne des gens pour les comprendre ; comment, sinon, expliquer pareil mépris pour l'utilisateur, que le SI (Service Informatique) est au contraire supposé servir, donc respecter ?
Si vous étiez PDG d'une boîte assez grande, où mettriez-vous les meilleurs : du côté du management et du développement ? ou du côté du SI, du Help Desk et autres administratifs ? Résultat, si un bon SI comprend bien les difficultés de ce métier, il y a en général plutôt dans les SI une majorité qui n'ont pas assez d'intelligence pour comprendre :
[*]que quand on est loin d'un problème on le comprend moins bien que quand on est près - donc que l'utilisateur, aussi ignare qu'il se prétende (car il est en général plus modeste et plus compétent que ce qu'on dit), est a priori celui qui est le plus près de comprendre le problème ;
[*]qu'en plus, un agent de SI est très généralement au dessous (en intelligence, instruction, expérience, ouverture d'esprit) de la moyenne des utilisateurs ;
[*]que lorsqu'on ne comprend pas quelqu'un ce n'est pas forcément qu'il vous est inférieur.
Le résultat est que les plus mauvais des agents des SI, au lieu de faire effort pour se hisser au niveau des usagers, se croient au contraire supérieurs à eux, et se donnent bonne conscience en leur inventant des imbécillités comme celle que vous avez relayée.
Paris, Fri 14 Oct 2005 09:50:00 +0200, édité 10:07:50
D'un autre côté, je me permet quand meme d'emettre un doute.
Dire qu'une majorité des agents du SI ne sont pas capables d'empathie, je n'en suis pas certain.
Je sors d'un centre de formation qui m'a permis justement de connaitre des collégues qui ont le même esprit que moi.
Je ne pense pas être quelqu'un d'unique en mon genre, mon but est d'aider mes collégues de travail tous les jours.
Qu'ils possédent des compétences informatique ou non, que ce soit le pdg ou le manutentionnaire, j'aide ses personnes toujours de la meilleure façon quelque soit leur niveau hierarchique, en résolvant leurs problèmes, et jamais en les accusant de quoi que ce soit, et au grand jamais, en les prenant d'un air supérieur.
La plupart des problèmes informatiques pour lesquels j'ai pu intervenir proviennent plus souvent d'un bug machine.
Les problèmes inhérents aux personnes surviennent souvent suite à une appréhension de la part des utilisateurs, ou d'une manipulation hasardeuse par manque de temps, mais rarement suite à un manque de compétence de leur part (compétence qui de toute facon viendrait d'un manque de formation).
Je suis donc tout a fait d'accord avec toi sur le fait que certaines personnes doivent surement abuser de leurs *pouvoirs* mais de la à generaliser, je suis pas certain.
Je m'intéresse depuis peu aux architectures processeur. Le CELL est donc un sujet d'étude trés enrichissant.
Cependant avec les faibles connaissances que sont les miennes, je me pose encore quelques questions.
- Le CELL est-il vraiment un processeur RISC ?
- S'agit-il d'un SMP classique ou d'un systéme asymétrique ? Le PPE étant annoncé comme le "Chef d'orchestre".
- Il s'agirait donc d'un systéme à couplage lâche ? Dans ce cas quid du goulot d'étranglement que causerait l'utilisation du PPE ? Ce dernier étant le poin faible de l'architecture du Cell ?
- L'article évoque, en parlant des SPE, de processeurs basés sur un systéme SIMD, cependant l'utilisation de ce systéme recquiert un couplage étroit. Il y a donc contradiction ?
- J'ai compris, mais je me trompe peut-être, que les SPE fonctionnent selon un modèle symétrique (architectures identiques entre elles, même fréquence, même capacité des mémoires caches, ...). J'aimerais savoir qu'elles réponses IBM à trouvé pour résoudre le problème de cohérence des caches. A moins que le contrôleur mémoire ne soit dédié à cette tâche ?
Je pense qu'avec les notions que j'ai réussi à comp