- Athlon 64 X2 3800+ / Sempron 3400+
- Duel Turion 64 / Pentium M - Asus A6000
- Test AMD Athlon 64 FX-57
- Apple embrasse Intel : révolution ?
- Duel au sommet : Athlon X2 VS Pentium D
- Athlon 64 Venice et Sempron Palermo
- Le dual-core selon Intel
- Asus CT-479 : Pentium M sur socket 478 !
- Pentium 4 6x0
- Guide d'achat processeurs
- 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
- 7 – Le CELL : une vue d’ensemble
- 8 – Les SPE : la force du Cell
- 9 – Les SPE : la force du Cell (suite)
- 10 – Le PPE : le maître d’œuvre
- 11 – Le PPE : le maître d’œuvre (suite), l'EIB
- 12 – Conclusion
Le PPE : le maître d’œuvre (suite), l'EIB
La technique utilisée par le PPE n’a pas été décrite par IBM aussi nous ne pouvons ici qu’émettre des suppositions, toutefois il semblerait que la méthode utilisée soit nettement moins flexible que celle de l’Hyperthreading d’Intel. Une piste viendrait des déclarations de nombreux programmeurs (dont John Carmack et Gabe Newell) qui se sont plaints des performances du PPE (et du Xenon de la Xbox 360 par la même occasion) dans le cadre de programmes monothreadés. Ils ont en particulier dénoncé le discours de Sony et Microsoft, vantant leur impressionnante fréquence d’horloge à la moindre occasion, en indiquant qu’en pratique il fallait, dans certains cas, la diviser par deux pour obtenir une meilleure estimation des performances de ces CPU.
Encore plus troublant, lors de sa présentation sur le Cell à la dernière GDC, Dean Calver programmeur d’un jeu PS3 appelé Heavenly Sword, a indiqué qu’il conseillait de considérer, d’un point de vue logiciel, le PPE comme deux processeurs distincts fonctionnant à une fréquence deux fois moins élevée. Enfin IBM lui-même a précisé que l’exécution des threads était entrelacée sans donner plus de précision.
Ce que l’on peut déduire de tout cela, mais encore une fois cela reste des spéculations, est que l’implémentation du SMT par le PPE est assez limitée en ce sens qu’un thread ne peut lancer l’exécution d’une instruction que tous les deux cycles, l’autre cycle étant réservé à l’exécution d’une instruction de l’autre thread. Ainsi dans le cadre d’une application monothreadée on se retrouverait effectivement avec l’équivalent d’un processeur de fréquence deux fois moins élevée.
Ceci dit ceci n’est qu’une hypothèse et si l’on en croît l’article de Microprocessor Report elle serait fausse. Ainsi dans le cas où un des threads ne serait pas capable d’exécuter une instruction lors de son cycle, alors l’autre thread pourrait exécuter des instructions tous les cycles et non tous les deux cycles. Il semblerait donc que la situation ne soit pas aussi dramatique, mais l’implémentation du SMT par le PPE reste assez mystérieuse et dans tous les cas plus limitée que l’Hyperthreading car elle ne permet pas, à un cycle donné, d’avoir deux instructions de deux threads différents en cours de traitement dans des unités distinctes.
L’EIB : un anneau pour les gouverner tous
Pour garantir une bonne communication entre ces divers éléments, il fallait un réseau d’interconnexions efficace. IBM a donc développé un bus en anneau appelé EIB. En fait il s’agit plus précisément de quatre anneaux unidirectionnels : deux transférant les données dans un sens, et deux dans l’autre afin de minimiser la latence introduite par la structure en anneau. Ainsi dans le pire des cas la latence n’est que la moitié de la distance totale de l’anneau. Chaque anneau offre une largeur de 16 octets (plus un tag de 8 octets) mais ne fonctionne qu’à la moitié de la fréquence d’horloge.
- Page précédente Le PPE : le maître d’œuvre
- Page suivante Conclusion
- 1 / 2
- Suivante
-
Bravo encore !
| zizou6945 a écrit : '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...
| Djlauby a écrit : 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 ?
| Djlauby a écrit : [...] 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.
| a écrit : Heu la photo c'est un Cell? |
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 !
| zizou6945 a écrit : '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???)
| bib50 a écrit : 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
| jeff2 a écrit : Pourtant F@H etant un parfait exemple de calcul distribué, ca en fait le client ideal des processeurs a plusieurs core comme le CELL... |
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 !
| bib50 a écrit : 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 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.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
| a écrit : J'ai peur qu'au final, le PPE soit majoritairement utilisé et les SPE utilisé de temps à autre pour taches ingrates et/ou repetetives. |
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
| zizou6945 a écrit : '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 ... |
| HASSAN_HADOUMAN a écrit : Plutôt que de le dire, il vaut mieux le faire : |
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.
| chucky@IDN a écrit : BKgk, selon Ars-technica: Citation :These small vector computers are connected to each other and to the 512KB L2 cache via a element interface bus (EIB) that consists of four sixteen-byte data rings with 64-bit tags. This bus can transfer 96 bytes/cycle, and can handle over 100 outstanding requests. 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
![[:c3po]](http://img.infos-du-net.com/forum/images/perso/c3po.gif "[:c3po]")
| Niavlys@IDN a écrit : 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. |
+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...
| figaro@IDN a écrit : 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
- 1 / 2
- Suivante
-
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.