Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Affichage des résultats 1 à 15 sur 15

Discussion: Montalvo

  1. #1
    'Jour,

    Y a-t-il ici, parmi les dieux et les demi-dieux vivants, des personnes ayant un peu plus d'infos sur cette boîte ?
    Mysterious chip start-up to take on Intel in mobile space
    Et aussi une intuition sur l'éventualité que ses processeurs aient une chance de dépasser le stade du vaporware...

    Merci d'avance,


    AiZ

  2. #2
    Il y a probablement exageration dans l'article, mais il y a des experts en archi SoC/processeurs reseaux de ma connaissance qui y bossent depuis qq annees. Donc ils font forcement quelque chose. Et non je ne sais pas ce qu'ils font, et je doute qu'ils me repondent si je demande.
    fefe - Dillon Y'Bon

  3. #3
    Avec de vrais morceaux de MLX1 pour les coeurs "légers"?

    Note: je ne vois pas vraiment le rapport avec le CELL, à part le fait que cela fasse très hype/buzz de dire qu'un truc ressemble au CELL. Les gens n'ont toujours pas compris ce que c'est qu'un CELL ?

  4. #4
    rapport avec le Cell (lointain) c'est que c'est une archi avec un core "puissant" et des autres "cores" (même si le Cell, c'est pas si simple) moins puissants

  5. #5
    le cell c'est plutot un core anemique et des cores inutilisables
    Suite à une suggestion, je vais utiliser cette signature pour des canards en manque de ranking pro. Ou des quotes idiots.

  6. #6
    Ha tiens on dirait que je peux poster

    Citation Envoyé par Neo_13 Voir le message
    le cell c'est plutot un core anemique et des cores inutilisables
    C'est vrai que le PPU paraît plutôt limité, mais il cadre bien avec la vision actuelle d'IBM (cf le POWER6).
    Quant aux SPU je ne les trouve pas inutilisables, loin de là. Disons que c'est une façon particulière de penser, qui peut être rédhibitoire.

    Bon c'est hors-sujet là.

    Pour recadrer, si le Montalvo est effectivement constitué de cores asymétriques on retombera sur le même problème que le CELL, on ne sait pas programmer efficacement ces bêtes-là, en tout cas pas facilement. On a déjà du mal avec des coeurs symétriques SMP qui gèrent la cohérence tout seuls

  7. #7
    Citation Envoyé par Neo_13
    le cell c'est plutot un core anemique et des cores inutilisables
    En utilisant uniquement 30% (c'est déjà pas si mal) de la puissance théorique d'un CELL, Uncharted à démontrer que le CELL ça pouvait se coder... et bien se coder d'ailleurs... . Uncharted2 devrait être un bon gros cran au dessus. Le problème du CELL c'est que ça ne se code pas comme un CPU (même mutli-core).
    Dernière modification par Alice ; 21/02/2008 à 10h10.

  8. #8
    Du coup, la difficulté repose essentiellement sur le compilateur du Cell, pas vraiment sur les développeurs (d'autre chose que de compilo pour cell) ?

    Enfin, je suppose qu'IBM a publié son optimization guide où il parle de parallel loop, serialisation (pas dans le sens langage objet, mais l'exemple de l'encodage ou les étapes étaient pipelinées sur les différents SPU) et compagnie à chaque page.

    Edit :
    http://www-01.ibm.com/chips/techlib/...oadband_Engine
    Dernière modification par Yasko ; 21/02/2008 à 10h24.

  9. #9
    Citation Envoyé par Alice Voir le message
    En utilisant uniquement 30% (c'est déjà pas si mal) de la puissance théorique d'un CELL, Uncharted à démontrer que le CELL ça pouvait se coder... et bien se coder d'ailleurs... . Uncharted2 devrait être un bon gros cran au dessus. Le problème du CELL c'est que ça ne se code pas comme un CPU (même mutli-core).
    Relis ce que j'ai ecrit : je n'ai jamais dit que l'on ne pouvait pas atteindre la puissance theorique (je l'ai fait sur le systeme memoire), j'ai juste dit qu'en l'absence d'un langage adequat c'est difficile, tres difficile.

    Citation Envoyé par Yasko Voir le message
    Du coup, la difficulté repose essentiellement sur le compilateur du Cell, pas vraiment sur les développeurs (d'autre chose que de compilo pour cell) ?
    Pas vraiment.

    Un petit exemple : chaque SPU peut executer un programme different ; mais chaque SPU n'a que 256 Ko de memoire, et n'a pas d'acces direct a la memoire principale (il faut passer par le DMA) ; par consequent, si tu ne veux pas que tes SPU passent leur temps a ne rien faire, il faut pouvoir les abreuver en donnees et recuperer les donnees traitees qu'ils produisent ; il faut donc pouvoir initier des transferts DMA. Rien n'automatise completement ca.

    En plus tu as deux ecoles :

    1. chaque SPU est un etage de pipeline sur le traitement des donnees ; le PPU envoie des donnees au SPU 1, qui fait une partie du traitement ; le SPU 1 envoie les donnees traitees au SPU 2 qui fait une autre partie du traitement ; etc.
    2. chaque SPU est capable de faire l'ensemble du traitement ; le PPU decoupe les donnees en paquets et envoie chaque paquet a un SPU.

    Le choix entre ces deux ecoles va dependre de ce que tu as a faire. Et tu vas devoir tester les deux methodes pour savoir laquelle est vraiment la meilleure (en terme de perf, de coup de dev, voire en terme de faisabilite).

    AMHA du fait de ces difficultes, le developpement sur PS3 s'oriente tout droit vers une utilisation de librairies toutes faites (middleware) et deja optimisees. C'etait deja largement le cas sur la PS2.

    Comme je disais, les programmeurs ont deja du mal a utiliser efficacement des systemes simples comme les quadri-coeurs symetriques coherents. C'est encore bien pire sur des systemes asymetriques qui en plus demandent a ce que la memoire soit geree explicitement.
    Dernière modification par newbie06 ; 21/02/2008 à 10h35. Motif: Fusion automatique

  10. #10
    La difficulté n'est pas forcément déporté sur le compilo. J'ai vu du code qui te déroule des boucles de calculs critiques et qui génére du code asm pour les SPU qui maximise le dual-issue des ALU. Une boucherie sans nom qui n'est pas laissé à la charge du compile (incapable de générer un tel code à l'heure actuelle)

    Newbie06, mon post précédent était en réponse à Neo13 ... Quant à ton dernier post je suis assez mitigé sur la difficulté de coder le CELL. Le problème c'est le sentiment de simplicité des autres archie qui leure le jugement. Coder un GPU à travers CUDA beaucoup de monde te dira que c'est facile. Effectivement c'est du C de base et en 1 jour tu as déjà codé ton premier prog CUDA. Le coder efficacement c'est par contre une toute autre tâche. Tu parlais des accés mémoire d'un CELL avec les accès DMA qu'il faut se cogner, le double buffering à implenter pour masquer les accés etc. On a plus l'habitude de se cogner ce genre de tâche mais au moins le programmeur garde le contrôle. Sur un CPU la hierarchie mémoire, les caches...etc te simplifie la vie mais il est bien plus difficile de savoir à quel moment une donnée sera effectivement accessible. Bref le CELL est sans aucun doute difficile à coder mais pas forcément plus difficle à optimiser qu'une archie classique.

    Quant au modèle de programmation des SPU c'est en fait un problème d'algorithmique parallèle commun à n'importe quelle archie: Quel modèle de programmation parallèle est le mieux adapté à mon problème sur une archie donnée? Producteur/Consommateur, problème pipeliné, donnée streamée etc. Et là effectivement le compilo est d'une aide toute relative qt au choix technique de la parallélisation à utiliser sur un problème donné mais tout cela est commun à n'importe quelle archie. Le CELL n'a pas la paternité de cette difficulté

    Pour conclure sur l'utilisation de Lib optimisé pour le CELL, c'est déjà en train de se démocratiser et comme tu le disais c'est sans doute ce qui sera utilisé par la masse des développeurs de jeu
    Dernière modification par Alice ; 21/02/2008 à 11h52.

  11. #11
    The SPEs access main storage with direct memory access (DMA) commands that go between main storage and a private local memory used to store both instructions and data. SPE instruction-fetches and load and store instructions access this private local store, rather than shared main storage. This 3-level organization of storage (register file, local store, main storage), with asynchronous DMA transfers between local store and main storage, is a radical break with conventional architecture and programming models, because it explicitly parallelizes computation and the transfers of data and instructions.
    The reason for this radical change is that memory latency, measured in processor cycles, has gone up several hundredfold in the last 20 years. The result is that application performance is, in most cases, limited by memory latency rather than by peak compute capability or peak bandwidth. When a sequential program on a conventional architecture performs a load instruction that misses in the caches, program execution now comes to a halt for several hundred cycles. Compared to this penalty, the few cycles it takes to set up a DMA transfer for an SPE is quite small. Conventional processors, even with deep and costly speculation, manage to get, at best, a handful of independent memory accesses in flight. The result can be compared to a bucket brigade in which a hundred people are required to cover the distance to the water needed to put the fire out, but only a few buckets are available. In contrast, the explicit DMA model allows each SPE to have many concurrent memory accesses in flight, without the need for speculation.
    PDF (6 Mo)

    Ah ah, Intel, les pompiers sans seau d'eau !
    Comment ils sont mesquins chez IBM, ils balancent sur les autres, mais planqués au milieu de leur doc technique incompréhensible.


    Plus sérieusement, y a tout le chapitre d'introduction qui justifie des choix fait sur Cell qui a l'air assez interessant (pas le temps de tout lire, faut que je bosse un peu quand même, et puis même si je prends le temps, je vais probablement rien comprendre ou me choper une migraine ou le scorbut).

    Our compiler, referred to as a 'single source' compiler, is a parallelizing, simdizing compiler, which generates from a single C or Fortran input source file, multiple binaries targetting the PPE and SPE processing elements. Our goal in this compiler is to generate highly optimized code for the multiple levels of parallelism while providing an abstraction of the underlying architectural intricacies, thus allowing the user to develop applications for a parallel architecture with a single shared memory image.
    At the core of our compilation strategy is our technique for abstracting the small local memories of the SPE.Each SPE has a 256k local memory which is used for both data and instructions. An SPE can directly access only its local store, requiring a DMA transfer whenever it reads or writes locations in the shared system memory. This imposes significant burden on the programmer, especially for large programs accessing significant amounts of data. Our compiler-controlled software-cache, memory hierarchy optimizations and code partitioning techniques assume all data resides in shared system memory, and enables automatic transfer of code and data while preserving coherence across all the local SPE memories and system memory. This infrastructure provides the underpinning for enabling parallelism across the Cell processing elements. Our current compiler enables this via OpenMP Pragmas, but our techniques will easily support the existing auto-parallelization techniques in the compiler framework. Other parallelization paradigms such as UPC could be developed on this framework.
    Dernière modification par Yasko ; 21/02/2008 à 10h49.

  12. #12
    On est vraiment hors sujet (et c'est de ma faute), mais...

    Un cell c'est, de mon point de vue, un ou deux processeurs riscs avec un paquet de DSP. La difficulté est donc bien au niveau des programmeurs, vu q'en général on obtient de bien mauvais résultats en utilisant un code "classique" sur un DSP, sans tenir de ses forces et faiblesses.
    Mais bon, des gens qui ont l'habitude de programmer des DSPs, il y en a plein. C'est juste que ce ne sont en général pas les programmeurs de jeux ni ceux d'applis desktop.

  13. #13
    /agree Gabriel, et ils ont profite de l'integration sur un SoC pour rendre le systeme un peu plus "homogene" qu'un systeme avec un cpu RISC, et un bus avec plein de DSP.
    fefe - Dillon Y'Bon

  14. #14
    Citation Envoyé par Gabriel Voir le message
    C'est juste que ce ne sont en général pas les programmeurs de jeux ni ceux d'applis desktop.
    Ouais et aussi qu'un jeu c'est pas un codec video hein.
    Y'a quand même pas mal de code versatile de glu, scripting et autre qui profite bien d'un processeur généraliste efficace sur les branchements et les accès mémoires, pour te laisser te consacrer à l'optimisation de ce qui est brutal. Toute l'équipe peut pas être au taquet sur la microopti.
    Deja le PowerPC tricore de la 360 qui est une bénédiction pour porter du code PC multithreadé est bien à la ramasse si tu lui files du code qui fait du store-load ou des comparaisons/branchements sur les flottants qui passent comme un charme chez Intel...
    Je te dis pas le moteur de script blindé de branchements comment il souffre. Au moins on est content qu'il soit pas sur le main thread.
    J'ai pas encore fait de PS3 (mais de la PS2) mais je sens que ça va grave saigner...
    Par contre c'est vrai que le modèle mémoire explicite est pas forcément un problème pour optimiser puisque sur 360 on passe son temps à prefetcher, clearer des lignes de D$, les flusher pour maximiser la bande passante.
    Dernière modification par Tramb ; 22/02/2008 à 19h55. Motif: Grammaire sait faire un bon café.
    Sleeping all day, sitting up all night
    Poncing fags that's all right
    We're on the dole and we're proud of it
    We're ready for 5 More Years

  15. #15
    Citation Envoyé par Tramb Voir le message
    Par contre c'est vrai que le modèle mémoire explicite est pas forcément un problème pour optimiser puisque sur 360 on passe son temps à prefetcher, clearer des lignes de D$, les flusher pour maximiser la bande passante.
    100% d'accord. Au moins on a le contrôle de ce qu'on fait, parce que maîtriser les d-side est devenu impossible vu leur complexité et l'absence de doc technique précise.

    D'un autre côté les développeurs consoles ne comptent pas, ils savent ce qu'ils font en général, ils ont moins le droit d'être flemmards sur les optims que leurs confrères dev PC

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
  •