Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 3 sur 5 PremièrePremière 12345 DernièreDernière
Affichage des résultats 61 à 90 sur 132

Discussion: The Cell

  1. #61
    Citation Envoyé par ludoschmitt
    Citation Envoyé par jihef
    Citation Envoyé par EPIC
    Tout est possible cela dit dans le projet il y a IBM on sait déja que le proc tournera sous Linux grâce à l'Archi POWER pour le reste je ne doute pas une seule seconde qu'IBM supportera les dévellopeurs comme le font Intel ou encore AMD...
    Oui mais tourner sur ne veut pas forcement dire tirant parti de l'enorme puissance de calcul. Il faudrat des bons drivers et des soft optimisés spécifiquement ce qui va surement prendre du temps et ce n'est pas juste en recompilant les sources que l'on pourra arriver a utiliser toute la puissance.

    Vive l'assembleur !!
    IBM a de bonne ressources surtout au niveau financier. Pourquoi ne feraient-ils pas un compilateur bien optimisé comme il faut pour le Cell ?
    Il y a des bons compilateurs capables de vectoriser efficacement du code ?
    "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?
    <°)))><

  2. #62
    Citation Envoyé par dandu
    ben face a un processeur plus efficace avec un pipeline plus court, ca tient pas trop la route.

    le long pipeline, c'est efficace por monter en fréquence, mais pas trop au niveau des perfs.
    Tu trouve que sa a beaucoup aidé ?
    En un an de Prescott on a pris 'que' 400MHz.
    Et les modeles 3600 et 3800 sont surement pas les plus vendus.

  3. #63
    Citation Envoyé par jihef
    Il y a des bons compilateurs capables de vectoriser efficacement du code ?
    Pas évident dans un code classique, car souvent beaucoup de dépendances dans les traitements.

    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).

  4. #64
    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?
    <°)))><

  5. #65
    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é...

  6. #66
    bas un pipiline long tres bien optimiser se serai pas possible pour le futur ?

  7. #67
    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.

  8. #68
    Citation Envoyé par Yasko
    Pas évident dans un code classique, car souvent beaucoup de dépendances dans les traitements.

    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).
    D'ou l'intéret des processeurs VLIW et de l'archiecture EPIC de l'Itanium...
    "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

  9. #69
    Dans les suites de l'actualité du Cell, Apple souhaite entrer dans l'arene.

    http://www.silicon.fr/getarticle.asp?ID=8570

    Citation Envoyé par Silicon.fr
    Une technologie, qualifiée de multi processing, qui a incité la presse américaine à affubler le processeur du doux nom de 'supercomputer on a chip', super ordinateur sur une puce. Un surnom qui en revanche est peu indiqué pour le positionnement de Cell sur le marché du digital home !
    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 ?

  10. #70
    Citation Envoyé par The_Mad
    J'ai décortiqué un peu le bébé :

    234 Millions de transistors :

    - 113 (8*14) Millions de transistors pour le cache de chaque DSP
    - 28 (1*28à Millions pour le cache L2 du CPU
    - 28 Millions de transistors pour le core du CPU
    - 56 (8*7) Millions de transistors pour le core des DSP
    - 10 Millions de transistors pour le reste

    Serieux, moi un DSP a 7 millions de transistors pour le core, ca me fait pas trop bander...
    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 !

  11. #71
    Citation Envoyé par Pascal_TTH
    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 !
    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.
    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:

  12. #72
    Citation Envoyé par Yasko
    Les "SPE" du Cell semblent aussi polyvalents dans leurs calculs que les ALU/INT et FPU d'un CPU x86.
    Tu sors ca d'ou ?

  13. #73
    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...)

  14. #74
    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.

  15. #75
    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

  16. #76
    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.

  17. #77
    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...

  18. #78
    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
    4 GHz * 8 (nombre de SPE) * 2 (odd & even pipe) * 4 (4-way simd) = 256 GFlops.
    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.

    GeForce 6800
    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
    quotes de Tridam...

    Nvidia chiffre le NV40 à 1 Tflops en précisant toutefois que c'est la somme de toutes les unités certaines n'étant pas programmables.
    quote de Xellos

    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

  19. #79
    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?
    <°)))><

  20. #80
    ba en tout cas, ils auront réussi à faire un sacré ramdam avec l'annonce

  21. #81
    Citation Envoyé par lechenejb
    ba en tout cas, ils auront réussi à faire un sacré ramdam avec l'annonce
    Il y a des gens qui vont déchanter quand ils apprendront que c'est très loin d'être le x86 killer attendu .

  22. #82
    le ventilateur de l'année
    Mes propos n'engagent personne, même pas moi.

  23. #83
    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...

  24. #84
    Citation Envoyé par paulez
    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...
    d'où les DSPs donc ?

  25. #85
    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 ?

  26. #86
    C'est le nombre de Cells qui est variable je crois.
    La PS3 en aurait 4.

  27. #87

  28. #88
    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)
    Est-ce que vous savez pourquoi cette dépendance entre largeur de la fenêtre d'instruction et fréquence max ?

    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 ?

  29. #89
    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 ;-)).

  30. #90
    Citation Envoyé par The_Mad
    On peut comparer ca a un core de P4 et 8 cores de GeForce 1 inclus dans le meme die.
    pour moi le cell l'a toujours été

    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

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •