Publicité
Articles Processeurs
- 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
Produits populaires
Partenaires
- 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
L’aveu d’un échec (suite)
Avec l’Athlon, AMD s’inspirant au passage de l’architecture Alpha de Digital a misé sur l’accroissement de l’ILP en multipliant décodeurs et unités d’exécution. IBM a suivi la même voie avec son PowerPC 970 en misant également sur l’augmentation de la fréquence par rapport à son prédécesseur. Le Pentium 4 est entièrement dédié à permettre une montée rapide de sa fréquence mais a néanmoins le mérite d’avoir apporté quelques nouveautés, comme le trace cache par exemple qui découple le décodage des instructions de la section critique du pipeline. Pour l’Athlon 64 AMD s’est une fois encore inspiré des idées des ingénieurs de Digital et a intégré le contrôleur mémoire au sein du CPU. Toutes ces petites modifications ont eu indéniablement un effet bénéfique sur les performances mais rien du niveau de l’exécution pipelinée, superscalaire ou dans le désordre.
Enfin, la preuve la plus flagrante nous nous trouvons actuellement au point d’inflexion est le fait qu’AMD et Intel se lancent à corps perdu dans cette voie du multicore alors que pour eux c’est clairement la pire des solutions pour augmenter les performances de leurs processeurs. En effet, et vous avez pu le constater dans nos tests, les performances des architectures multicore dépendent de la façon dont sont codés les logiciels. Pour en tirer parti ces derniers doivent être threadés, ce qui d’une part est rarement le cas, d’autre part est compliqué pour les développeurs. Autrement dit contrairement aux générations précédentes il n’y aura pas de gain de performances immédiat en changeant de processeur. Vous me direz, et vous aurez parfaitement raison, que le passage au Pentium a demandé la recompilation des programmes pour tirer vraiment parti de l’architecture superscalaire et que ce fut aussi le cas pour le Pentium PRO/Pentium II voire pour le Pentium 4. Malheureusement cette fois ci une simple recompilation des logiciels ne pourra pas jouer le rôle de sauveur, et il faudra remanier l’architecture des logiciels pour tirer vraiment parti des processeurs multicore.
Les mauvaises évaluations sur la mort des architectures monoprocesseur auront eu l’heureuse conséquence de pousser très tôt les recherches dans le domaine des machines multiprocesseurs. Deux groupes de machines multiprocesseurs ont émergés de ces recherches :
- les machines à mémoire centralisée
- les machines à mémoire distribuée
Le second groupe s’est principalement imposé dans les machines nécessitant un grand nombre de processeurs. L’observation qui a conduit à cette architecture est que lorsque le nombre de processeurs augmente le sous-système mémoire devient rapidement incapable d’offrir une bande passante suffisante. L’idée consiste donc à fournir à chaque processeur son propre espace mémoire, chaque processeur disposant donc d’un débit maximal vers une partie de la mémoire. En contrepartie un accès vers une autre partie de la mémoire doit se faire par le biais d’un réseau d’interconnexion ce qui a pour effet d’augmenter la latence et de complexifier la communication entre les processeurs.
Ce second groupe peut lui-même se subdiviser en deux sous ensembles. Nous avons d’un côté le sous ensemble des machines à mémoire partagée distribué dans lequel l’espace mémoire est partagé. Ce qui signifie pour être clair que la même adresse physique sur deux processeurs correspond à la même case mémoire. Et d’un autre côté celui des multi-ordinateurs dans lequel l’espace d’adressage est constitué de plusieurs espaces d’adressage privés. Dans ce modèle la même adresse physique pour deux processeurs correspond à deux cases distinctes dans deux mémoires différentes.
- Page précédente L’aveu d’un échec
- Page suivante Les nouveaux enjeux
Annonces Google
- 1 / 2
- Suivante
-
riderinvasion
30/09/2005
02:00
'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 ...
dr-freuderick
30/09/2005
08:38
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 !
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...
blackestmajor
30/09/2005
09:38
| 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 ?
Aiolizator
30/09/2005
09:40
| Djlauby a écrit : [...] 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...
Ç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...
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.
| 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 !
Michel Merlin
30/09/2005
11:16
| 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
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???)
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???)
wrongillusion
30/09/2005
14:40
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
| 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
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 
wrongillusion
30/09/2005
17:57
| 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
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 !
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 ...
Je viens de lire l'article, fort bien ecrit et comprehensible par le commun des mortels
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
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
THE REAL KRYSTOPHE
30/09/2005
22:12
| 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
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.
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.
Je vais mettre en place le processeur San Gohan et vous allez voir la claque que va ce prendre ce processeur Cell
| 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 ...
Jsuis pas ultra-calé en architecture processeurs mais ya pas mal de trucs que je comprends.
Ca n'empeche que cet article me donne des boutons![[:c3po]](http://img.infos-du-net.com/forum/images/perso/c3po.gif "[:c3po]")
Ca n'empeche que cet article me donne des boutons
| 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...
wrongillusion
13/10/2005
13:30
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
Michel Merlin
14/10/2005
09:50
| 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.