Il y a des bons compilateurs capables de vectoriser efficacement du code ?Envoyé par ludoschmitt
Il y a des bons compilateurs capables de vectoriser efficacement du code ?Envoyé par ludoschmitt
"si tout le monde s'etait dit "pour quoi faire ?" je pense qu'on tournerait encore sur 8086. Si tant est qu'on ait l'electricite ... " Franck@X86
If all goes well will Dell sell Cells?
<°)))><
Tu trouve que sa a beaucoup aidé ?Envoyé par dandu
En un an de Prescott on a pris 'que' 400MHz.
Et les modeles 3600 et 3800 sont surement pas les plus vendus.
Pas évident dans un code classique, car souvent beaucoup de dépendances dans les traitements.Envoyé par jihef
C'est au moment de la conception de l'architecture qu'il faut prendre en compte cet aspect.
Souvent ca complique bien les choses puisque il faut casser le fil logique de l'algorithme conceptuel (celui avec les dépendances), pour une sorte de regroupement thématique (plusieurs opérations/traitements similaires, consécutifs, et indépendants).
Bref un compilateur qui serait capable d'exploiter le Cell n'existe pas encore.
edit : ca oblige le concepteur de programme Cell a aller contre la maniere "naturelle" d'ecrire les choses puisque le compilo. ne peut pas faire ca. Bonjour les coûts de développement.
"si tout le monde s'etait dit "pour quoi faire ?" je pense qu'on tournerait encore sur 8086. Si tant est qu'on ait l'electricite ... " Franck@X86
If all goes well will Dell sell Cells?
<°)))><
Bah, le problème avec la parallèlisation/vectorisation, c'est que c'est pas trop la façon naturelle/intuitive de faire les choses, et le compilateur ne peut pas non plus faire de miracle.
Refaire ce travail de remaniement d'architecture, j'y crois pas trop, ca me semble bien compliqué...
bas un pipiline long tres bien optimiser se serai pas possible pour le futur ?
pour le parallélisme, y a pas trop de problèmes, vu que la PS2 est déja assez dure a programmer. C'est aussi un des avantages de la Xbox (et de feu la dreamcast), ça se base sur directX, donc c'est facile à porter et a programmer pour les prorammeurs PC.
Le long pipeline, c'est pas spécifiquement le prescott, c'est netburst en général, et ça fonctionne, ça monte en fréquences.
Maintenant, que Intel commercialise pas des prescoot très rapide ou que question efficacité ça limite, c'est un autre problème.
pour la parralléisation en codant, en école d'info il y a 4 ans, on apprenait déja a programmer en multi-thread, c'est un peu différent, mais pas vraiment plus compliqué si on s'y connait un peu en programmation.
Bon, evidemment, le codeur qui a fait du PHP ou du basic, il aura un peu de mal, mais c'est pas insurmontable.
le véritable problème, c'est que toutes les formes de codes ne sont pas multi-threadable.
Et pour les retouches en assembleur, c'est souvent que une petite partie de programmes, genre les grosses boucles et/ou gros calcul répétitif, pas tout.
D'ou l'intéret des processeurs VLIW et de l'archiecture EPIC de l'Itanium...Envoyé par Yasko
"We can't wait twenty years to achieve a 1000 fold increase in PlayStation performance : Moore's Law is too slow for us"
Shin'ichi Okamoto-Chief Technical Officer Sony Computer Entertainment Corporation
Dans les suites de l'actualité du Cell, Apple souhaite entrer dans l'arene.
http://www.silicon.fr/getarticle.asp?ID=8570
En lisant ça on peut penser qu'il aura une ambiguité sur la position de ce futur processeur. Serait-ce un chip uniquement destiné au grand public ? Parce que j'avais cru entendre dire qu'ils prévoyaient de l'intégrer dans des stations de travail ?Envoyé par Silicon.fr
Je me posais jutement la question et j'arrivais à décompte comparables. Bref, Cell c'est un Power PC et 8 petits "DSP". Pour le coup des Gflops, ça me fait trop rire : l'unité la plus pitoyable jamais inventée. Ca représente de la puissance FPU sans aucune standardisation... Bref, facile de faire un gros chiffre avec un DSP ! Curieux de savoir quel est la part du Power PC dans le score !Envoyé par The_Mad
Les 8 unités de calcul ne sont pas vraiment des DSP qui sont assez figés dans leurs traitements. Les "SPE" du Cell semblent aussi polyvalents dans leurs calculs que les ALU/INT et FPU d'un CPU x86.Envoyé par Pascal_TTH
Quant au PowerPC, c'est lui le chef, donc ben, il fait pas grand chose et file le boulot aux autres, c'est ça son job... :whistle:
De l'article de Blachford et d'Ars Technica :
.
Mais bon c'est vrai que "semblent aussi polyvalents dans leurs calculs que les ALU/INT et FPU d'un CPU x86.", c'est peut être pousser un peu loin, surtout vu ce qu'on sait actuellement sur ces SPE (c'est à dire, pas grand chose...)
Bah non justement, tu suis pas la :
En haut, on a VALU (Vectoriel ALU) pour faire du SIMD, ALU pour faire le reste et LSU (Load/Store Unit) pour les accés avec l'exterieur : C'est le CPU
Les 8 unités en dessous la, elles n'ont qu'une unité vectorielle, un LSU et un cache. C'est exactement ce qu'on appelle un DSP. Ces unités ne sont capables que de faire du vectoriel, ce n'est en aucun cas des CPUs complets. On peut comparer ca a un core de P4 et 8 cores de GeForce 1 inclus dans le meme die.
Oui, j'avais lu la suite, mais je sais pas, c'est bizarre.
Sur le diagramme que tu as posté, les unités de traitements des SPE se resument à une VALU, alors que sur le diagramme de l'article du jour précédent, il y a également 2 FPU et 2 ALU dans les unités de traitement de chaque SPE.
Euh... bah j'ai compris, c'est parce que c'est le diagramme du PPC et pas celui d'un SPE... :whistle:
Mais euh, c'est la faute au titre ! ("Part I: the SIMD processing units"). :D
on sait faire quoi avec des unités simd en pagaille ?
je vois le traitement video, le traitement des effets sur des textures, et calculer plein plein plein des polygones pour un jeu (le gros point faible des Playstation), mais a part ca ?
une IA ou un moteur physique, c'est pas super prédictible ni facilement parallélisable, il me semble.
et pour les traitement 3D, on a les GPU nvida/ATI qui font ca tres bien.
Bah, on est pas obligé de utiliser les VALU en vectoriel. Qui peut le plus peut le moins.
Pour les entiers, OK, mais par contre, ce qui m'étonne du coup, c'est qu'il n'y a que 2 FPU dans tout le Cell, celles du PPC. En regard de la quantité de GFLOPS annoncée, ca parait assez surprenant...
Ca ne peut pas faire de l'IA ni du moteur physique, ce sont des parties trop conditionnelles qui demandent une unité de prédiction de branchement. Tridam donne comme exemple des traitement de Vertex Shader. De plus les SPE semblent d'une précision très limitée... C'est franchement de plus en plus louche. Je me demande quel est l'intérêt de ces SPE s'ils collent un VPU/GPU dans la consolle. Sans compter que Cell n'est pas 2x plus lent en en double précision mais d'après IBM 10x plus lent.
Cell
Dans les Gflops annoncés, rien ne vient du PPC... D'ailleurs des Gflops ou du n'importe quoi, c'est choux vert et vert choux. On leur fait dire n'importe quoi à ces Gflops.4 GHz * 8 (nombre de SPE) * 2 (odd & even pipe) * 4 (4-way simd) = 256 GFlops.
GeForce 6800
quotes de Tridam...Pour les cg, par exemple une 6800U:
64 (64-way mimd) * 2 (2 alu) * 0.4 GHz = 51.2 GFlops
Maintenant si on compte les modifiers et mad comme 2 instructions :
64 * 5 (instruction1 + modifier1 + mad + modifier2) * 0.4 GHz = 128 GFlops
2 6800U en SLI = 256 GFlops
quote de XellosNvidia chiffre le NV40 à 1 Tflops en précisant toutefois que c'est la somme de toutes les unités certaines n'étant pas programmables.
Ce Cell ressemble de plus en plus à une vaste blague qu'à un processeur... ne parlons même pas de super calculateur vu la précision. Le processeur qui va vite mais calcul à "l'à peu près" :D
Source pour confirmer la perte de 10x la perf en double
http://www.realworldtech.com/page.cf...WT021005084318
voir a "floating point capabilities"
"si tout le monde s'etait dit "pour quoi faire ?" je pense qu'on tournerait encore sur 8086. Si tant est qu'on ait l'electricite ... " Franck@X86
If all goes well will Dell sell Cells?
<°)))><
Il y a des gens qui vont déchanter quand ils apprendront que c'est très loin d'être le x86 killer attendu .Envoyé par lechenejb
C'est surtout qu'il est conçu pour être utilisé dans l'informatique industrielle, pour par exemple aller décoder du HD-TV dans une platine de salon, son architecture me semble plutôt faite pour ça que pour aller concurrencer Intel dans les PCs de bureau...
Je pense oui, et il n'était pas prévu de sortir plusieurs versions avec plus ou moins de DSP selon l'utilisation qu'un constructeur voulait faire du Cell ?
Envoyé par YaskoEst-ce que vous savez pourquoi cette dépendance entre largeur de la fenêtre d'instruction et fréquence max ?The larger you make the instruction window, the more parallelism that can be extracted simply because the CPU is looking at a wider set of instructions from which to select independent ones. At the same time, the larger you make the instruction window, the lower your clock speed can be. (page 7)
La conséquence qui me vient à l'esprit, si on augmente le nombre d'instructions dans cette fenêtre, c'est que potentiellement, on augmente le nombre d'instructions déja traitées (dans le désordre) et qui restent bloquées dans la fenêtre d'instruction, parce qu'une instruction antérieure n'a pas encore été traitée (puisqu'il faut les retirer dans l'ordre).
Mais pourquoi ce rapport avec la fréquence ?
Je pense que c'est juste du a une question de complexité, plus la fenetre d'instruction est grande, plus les dépendance inter-instruction son nombreuse, ça utilise plus de transistor du coup la fréquence diminue.
Enfin, maintenant il est clair que pour faire un x86 killer, faudra un PPE un peu plus balaize que ça (ce qu'anandtech dis d'ailleurs), parce que un cpu in-order avec des complios qui sont pas sensé faire de reordonancement trop poussé ...
En parlant de ça, j'ai regardé en diagonale l'article d'anandtech il parle pas vraiment du SMT du PPE, est-ce qu'il ne serais pas là juste pour compenser l'approche in-order : en cas de defaut cache normalement il devrait attendre que la donné arrive de la mémoire, il ont peut-être une memoire XDR de-la-mort-qui-tue mais avec un cpu à 4 Ghz ça fait beaucoup de cycle de latence, donc je me disais que que leur SMT pourrais juste servir à switcher de tâche pendant un défaut cache, un peu comme le sun niagara (un autre cpu in-order d'ailleurs ;-)).
pour moi le cell l'a toujours étéEnvoyé par The_Mad
a titre de comparaison, un die de r420 fait dans les 180M de tistors, soit 16x11M grosso modo
sachant qu'il y'a du cache, un controleur mémoire complexe et pas mal d'autres trucs, on arrive à quelque chose de comparable aux 7M des dsp annexes du cell