Journal IBM, Sony, Toshiba : The Cell

Posté par  .
Étiquettes : aucune
0
25
mai
2005
IBM, Sony et Toshiba seraient prets à ouvrir/liberer les specifs du processeur the Cell.

extrait de l'article du eetimes :
""Our intention is to open up the Cell software architecture. The idea is to get the industry to help us evolve the basic software layers," said IBM's Jim Kahle, the Cell team leader.

The three companies are now doing a final review of a Cell architecture specification that could be released to software developers by the end of May. It will include details of more than 200 new instructions used in the specialized cores inside Cell. The group also plans to release open-source software libraries for Cell as early as this fall.

"We're not yet sure about the right licensing terms for the libraries. It can be hard to give stuff away for free," Kahle said in an interview after a presentation at the Spring Processor Forum here.

The trio is almost done with an application binary interface and language extensions for Cell. A system-level simulator is also nearly complete. Yet to come is a full-fledged Linux implementation for the CPU.

"Our plan is to open-source the software for Cell and productize different parts as we go along," said Kahle.
"

En gros : ils veulent ouvrir l'archi pour que toute l'industrie les aide à faire evoluer les "niveaux logiciels basiques". Ils devraient publier les specifs aux developpeurs dans la fin Mai.
Par contre ils ne sont pas encore surs des termes de la licence pour des librairies.
Et une implementation de Linux pour ce cpu serait bientot dispo.

http://www.theregister.co.uk/2005/05/25/ibm_opens_cell/(...)
http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=1631(...)
http://research.scea.com/research/html/CellGDC05/index.html(...)

  • # Utilisable dans GStreamer

    Posté par  . Évalué à 2.

    Sachant que ces SPU ont l'air de descendre de DSP que de CPU pur, on pourrait alors imaginer que les différents filtres GStreamer soit implémenter sur des SPU, ce qui pourrait permettre des traitements temps réel...

    Hummm, Flumotion serait alors beaucoup plus rapide ... (quoi que je ne connais pas ni utilise flumotion, je n'en connait pas la rapidité mais j'y vois une amélioration sensible de la charge et donc des capacités d'encodage...

    • [^] # Re: Utilisable dans GStreamer

      Posté par  . Évalué à 2.

      et idem pour des filtres Gimp...
      Bon faut que j'arrete mes speculations moi...

    • [^] # Re: Utilisable dans GStreamer

      Posté par  . Évalué à 4.

      Si on considére que ces unités de calculs programmable sur 128bit capable de bosser en grid asynchrone directement sur le bus mémoire, oui cela tien du DSP, sinon c'est quand même sacrement révolutionnaire et potentiellement cela permet beaucoup plus de chose que de simple filtre, puisque ce sont des unités programmable ce qui fait toute la différence avec des DSP.

      Potentiellement tu peux faire de la crypto, de la compression-décompression divers, etc etc ...
      Toutes les taches/thread qui peuvent se loger dans la mémoire serte restreinte de l'une de ses unités peuvent étre traité directement par elle et directement dans la mémoire. Apres tu imagine que chaque unités peut travailler en série ou en paralléle avec une autre et je te laisse imaginer l'énorme potentiel que cela peut avoir. Compression vidéo temps réel, cryptographie forte a la volée, traitement 3D, etc etc ...

      Par contre cela doit impliquer une maniére assez radicalement différente de concevoir ses applications.

  • # utilité ?

    Posté par  (site web personnel) . Évalué à 4.

    Si il ne sorte pas une autre machine que la PS3, je ne vois pas l'utilité de la chose :/

    Au moins qu'il ne sorte une sorte de carte PCI avec un cell + 1 Go de RAM. Cela fera un copro pour pas chère et de quoi commencer.

    "La première sécurité est la liberté"

  • # pas simple.

    Posté par  . Évalué à 2.

    Et oui, c' est bien joli de faire des processeurs ultra paralleles avec pleins de tera flops. Le probleme, est que cette archi reporte la complexite dans le software.
    AMHA, cela va mettre pas mal de temps avant de vraiment exploiter les capacite de la bete.
    En gros, tout le code C critique que l'on a est a jeter et a refaire pour le parraleliser. Sachant la complexite du debuggage des algorithmes paralleles, ya du boulot.

    Au lieu de supporter leur materiel en fournissant des bibliotheques, ils essayent de faire travailler la communaute. AMHA, l'industrie a interet a mutualiser ces travaux, mais est ce que les mentalites sont pretes?

    • [^] # Re: pas simple.

      Posté par  . Évalué à 2.

      est-ce pas aussi simple que de faire du code multi-thread sauf que c'est un thread qui se déplace sur un SPE aulieu d'un CPU ?

      Bon ok, le débogage multi-thread c'est chiant, et on en revient au meme point...

      • [^] # Re: pas simple.

        Posté par  . Évalué à 3.

        Le problème c'est que les SPE ne sont pas des CPU classique, ils ont une pile d'exécution assez petite et sont spécialisé dans les traitements sur des valeurs très larges. Donc cela implique une niveau de segmentation des taches très fin afint de tenir dans la mémoire d'un SPE, et cela limite l'interet a certaine tache. Par exemple travailler sur des int de 32bit avec un SPE est assez inutile, maintenant faire des opérations sur des vecteurs 128bits, de la crypto de bloc ou de la compression c'est tous bénéfice.

  • # correction

    Posté par  (site web personnel) . Évalué à 4.

    IBM, Sony et Toshiba seraient prets à ouvrir/liberer les specifs du processeur the Cell.
    ils veulent plutôt développer des libs utilisant le Cell sur un modèle Open Source. Parcque bon libérer les spécifs, quand tu veux faire un proc généraliste sans drivers proprio, ca me paraît un minimum si on veut espérer vendre le proc tout de même :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.