Le processeur Cell

Introduction

IBM nous refait le coup de la révolution RISC ?

Au début des années 90, trois grandes sociétés s’allient pour détrôner Intel qui règne sans partage sur le marché des microprocesseurs équipant les ordinateurs personnels. Pour ça un seul mot d’ordre : simplification ! Les processeurs modernes sont trop complexes ce qui limite leur efficacité. La solution selon ces trois firmes est de repenser l’architecture des microprocesseurs, afin d’offrir des bases solides pour les applications gourmandes de demain.

Retour vers le futur : au début des années 2000 trois grandes sociétés s’allient… Le parallèle est amusant et si beaucoup de choses ont changées en dix ans, le discours lui est étonnement similaire. Et au milieu de ces deux alliances on retrouve un même acteur IBM.

Si Big Blue n’a pas réussi sa première révolution RISC on peut en tout cas dire que son enthousiasme reste intact. Il faut avouer que si l’alliance AIM (Apple-IBM-Motorola) qui a donné naissance au PowerPC n’a pas rencontré le succès escompté ce n’est pas non plus un échec complet même si initialement les ambitions des trois sociétés allaient bien au delà de la niche du marché Macintosh et du monde console.

IBM comptait en effet sur son processeur pour créer une nouvelle révolution, un peu à la manière du PC mais sans répéter les erreurs du passé. Pas question donc cette fois de faire la fortune de fournisseurs externes : IBM a vite compris que le succès du PC avait eu en fait deux principaux bénéficiaires, Intel et Microsoft. Pour l’OS IBM disposait d’OS2 et pour le processeur du PowerPC. Ainsi armé IBM partait en guerre contre ses deux anciens partenaires. Au final ce fut un coup d’épée dans l’eau et les stations PowerPC IBM sont restées très discrètes, surtout face à l’envolée du Pentium.

Il faut dire que les PowerPC n’ont jamais vraiment eu l’occasion d’exposer leur supériorité architecturale dans les benchmarks. Pire encore grâce à la concurrence acharnée entre AMD et Intel ils ont même pris du retard en terme de performance. Mais cette fois ci IBM et ses deux acolytes Sony et Toshiba ont tout fait pour que l’histoire ne se répète pas. Qu’est ce qui différencie le CELL d’un autre processeur ? Regardons d’un peu plus près ce futur processeur qui sera intégré à la déjà très célèbre console de jeu Sony Playstation 3…

La première révolution RISC

Lorsque l’alliance AIM a proposé le premier processeur PowerPC, le concept de RISC (Reduced Instruction Set Computer) n’était pas nouveau. En fait les fondements du design RISC remontent au début des années 1980 avec les travaux de Patterson à l’université de Berkeley qui donneront naissance à deux machines appelées RISC-I et RISC-II. En fait à la fin des années 1970 IBM (déjà lui !) avait commencé des travaux qui allaient dans cette voie.

C’est cependant la première fois avec le PowerMac qu’un processeur RISC est disponible dans une machine grand public. L’idée sous jacente derrière le RISC était de mieux utiliser les ressources disponibles : une part non négligeable des transistors des processeurs de l’époque était dédiée à câbler des instructions de plus en plus complexes ou des modes d’adressages alambiqués, la conséquence malheureuse est que cela se faisait au détriment des instructions les plus fréquemment utilisées. On peut donc résumer le RISC à cette phrase : « rendre le cas courant rapide et le cas rare possible.».

On peut aujourd’hui dire que le concept RISC touche à sa fin lorsque l’on regarde l’implémentation de l’ISA (Instruction Set Architecture : architecture de jeu d’instructions) PowerPC par son dernier représentant : le 970. Celui-ci est en effet un microprocesseur complexe n’exécutant pas nativement les instructions PowerPC mais les décomposant en un format interne. Il les envoie ensuite à un cœur d’exécution Out of order très largement superscalaire, sous forme de groupes répondant à des règles strictes sur l’organisation des instructions qu’ils contiennent. Le pipeline, extrêmement long, s’écarte également du schéma du pipeline RISC classique qui faisait la marque de fabrique des processeurs MIPS ou PowerPC.

La quête d’un meilleur ILP

Toutes ces modifications introduites au fil du temps depuis le premier représentant de l’ISA PowerPC n’ont été faîtes que dans un seul but : augmenter le parallélisme d’instructions (en anglais Instruction Level Parallelism ou ILP). Et tout ceci a bien évidemment eu un coût en terme de ressources. En effet il a fallut implémenter un ordonnanceur capable d’extraire de l’ILP d’une fenêtre d’instructions (on appelle fenêtre d’instructions l’ensemble des instructions examiné pour une exécution simultanée), introduire une unité – le tampon de réordonnancement (ou Reorder Buffer en anglais) capable de conserver l’ordre des instructions en cours de traitement toujours plus nombreuses -, ajouter suffisamment de registres de renommage pour résoudre les dépendances de nom… Ajoutons à cette liste déjà longue que l’allongement du pipeline a rendu les branchements de plus en plus coûteux et a donc conduit les architectes à développer des algorithmes de prédiction de branchement plus évolués.

Si l’on examine les derniers représentants des différentes architectures (Athlon 64 et Pentium4 ou PowerPC970) on constate une certaine constance : tous ont dédié énormément de ressources à essayer d’extraire davantage d’ILP et n’ont pas vue une augmentation significative du nombre de ressources d’exécution par rapport à leurs prédécesseurs. Autrement dit la logique de contrôle prend une part de plus en plus prépondérante au sein d’un microprocesseur et ce au détriment de la logique d’exécution. Mais malgré des ressources dédiées toujours plus importantes, cette voie semble sans issue. Il devient en effet de plus en plus difficile d’extraire encore plus d’ILP d’un seul flux d’instructions. Il convient de noter que l’HyperThreading d’Intel est une réponse à ce constat : puisque certaines unités sont inutilisées du fait de l’impossibilité de trouver suffisamment de parallélisme d’instructions dans un seul thread pourquoi ne pas essayer d’en trouver dans un deuxième thread ? Mais ceci ne fait que repousser l’inévitable : les techniques actuelles vont se heurter à un mur et ce mur s’appelle loi des rendements décroissants. Autrement dit ajouter encore des ressources supplémentaires dédiées à extraire du parallélisme d’instruction apportera des gains de plus en plus faibles. Et comme dans le même temps l’augmentation de la fréquence des processeurs est au ralenti ces derniers temps il faut trouver un nouveau moyen d’augmenter la puissance de nos processeurs adorés.

L’aveu d’un échec

La réponse c’est le multi core dont Intel et AMD ne cessent de nous vanter leurs mérites. IBM de son côté s’est penché sur la situation actuelle et s’est demandé si cette suite logique était la bonne voie à suivre. Et selon les chercheurs de Big Blue la réponse est non. Pour cela IBM a cherché à déterminer quelles étaient les applications actuelles et futures pour lesquelles la puissance était vraiment un facteur déterminant et quels étaient les moyens les plus efficaces pour augmenter les performances de ce type d’applications. La réponse est évidente : les applications les plus intensives sont les applications multimédia : son, vidéo ou encore affichage 3D. Et, tels les chercheurs des années 70 qui n’ont pas hésité à remettre les concepts traditionnels des architectures des microprocesseurs au placard, IBM et ses alliés ont également décidé d’abandonner plusieurs des techniques qui semblent aujourd’hui indissociables des processeurs modernes. Tout ceci dans un seul but : celui d’offrir plus de performance aux applications en ayant réellement besoin.

Avant de continuer j’aimerais me permettre une petite digression. Ce n’est sans doute pas la première fois que l’on vous rabat les oreilles avec la mort des architectures monoprocesseurs traditionnelles. Il est vrai que depuis quelques temps les efforts marketings de la plupart des fabricants de microprocesseurs vont dans ce sens et que l’on pourrait croire que cette tendance est assez récente. Beaucoup d’entre vous j’en suis persuadé pensent en effet que c’est l’échec de la montée en fréquence du Pentium 4 qui a révélé le problème, pourtant cela fait longtemps que les architectes se sont penchés sur cette question. Pour vous en convaincre lisez les citations qui suivent et essayez (sans tricher !) de deviner de quand elles datent :

« La recherche de voies alternatives à la structure classique débuta au milieu des années 60 quand la loi du rendement décroissant commença à prendre effet dans l’effort d’amélioration de vitesse du fonctionnement des ordinateurs… Les circuits électroniques sont limités en dernier ressort en vitesse de fonctionnement par la vitesse de la lumière… et beaucoup de circuits fonctionnaient déjà dans la gamme des nanosecondes. » (Bouknight et al.)

« Les ordinateurs séquentiels approchent une limite physique fondamentale dans leur puissance de traitement potentielle. Une telle limite est la vitesse de la lumière. » (A.L.DeCemaga)

« Les machines d’aujourd’hui… sont proches de l’impasse avec les technologies approchant la vitesse de la lumière. Même si les composants d’un processeur séquentiel pouvaient travailler à cette vitesse, le mieux que l’on puisse espérer est borné par quelques millions d’instructions par seconde. » (Mitchell)

Je vous aide : ces citations font l’ouverture du chapitre 8 de la seconde édition du livre « Architecture des Ordinateurs : une approche quantitative. » qui date de 1996. Inutile de continuer ce petit jeu plus longtemps, vous avez déjà du comprendre où je voulais en venir : la première citation date de 1972 ! Les deux autres de 1989. On peut donc constater que si au niveau industriel cela fait peu de temps que le multiprocesseur focalise l’attention, dans le milieu de la recherche on s’inquiète depuis longtemps des alternatives permettant de poursuivre la montée en performance incroyable que l’on a connue.

Il est aussi amusant de constater que ces prédictions étaient inutilement alarmistes et bien trop en avance sur leur époque : en effet depuis 1989 nous avons connu de nombreuses innovations qui ont permis une augmentation fulgurante des performances parmi lesquelles les processeurs superscalaires (processeurs capables de lancer l’exécution simultanée de plusieurs instructions dans des unités distinctes) ou l’exécution des instructions dans le désordre (possibilité de réagencer les instructions d’un programme pour mieux tirer parti des ressources hardware disponibles), la prédiction de branchement (capacité de déterminer lors d’un branchement s’il a statistiquement plus de chance d’être pris ou non, évitant ainsi une suspension du pipeline), etc. Se pourrait il donc que les oiseaux de mauvaise augure qui prédisent la mort des architectures monoprocesseurs se trompent une fois de plus et que de nouvelles innovations vont relancer la croissance des performance au même rythme que nous l’avons connue jusqu’ici ?

Soyons francs : c’est peu probable. Si les prédictions citées ci-dessus étaient indéniablement prématurées, le raisonnement qui a amené leurs auteurs à de telles conclusions reste malheureusement tout ce qu’il y a de plus correct. Comme nous l’avons vu plus haut l’augmentation de l’ILP est limitée par la loi des rendements décroissants ; quant à l’augmentation de la fréquence elle se heurte à plusieurs phénomènes physiques. Il est aussi peu vraisemblable que de nouvelles techniques apparaissent et augmentent radicalement les performances comme nous avons pu le connaître par le passé. Pour s’en convaincre il suffit de regarder les dernières architectures d’AMD, Intel ou de la gamme PowerPC d’IBM. Un rapide coup d’œil à ces architectures révèle qu’elles n’ont rien apportées de fondamentalement nouveau par rapport aux précédentes.

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 premier groupe de machine est le plus populaire et c’est celui qui s’est imposé notamment dans les stations de travail ou les serveurs de petite et moyenne taille. Dans ce type d’architectures tous les processeurs se partagent une mémoire centralisée unique. Comme il n’y a qu’une mémoire et que son temps d’accès est uniforme pour tous les processeurs on parle aussi de machines UMA pour Uniform Memory Access.

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.

Les nouveaux enjeux

Pour aboutir à leur architecture, IBM, Sony et Toshiba ont donc cherchés le point commun entre toutes les applications qu’ils souhaitaient accélérer. Dans tous les cas qu’il s’agisse de vidéo, de 3D, de calculs physiques il s’agit d’appliquer un même ensemble d’instructions relativement petit (on parle de kernel) à un très large ensemble de données (un flux). Ce code est très facilement parallélisable car il a peu, pour ne pas dire pas, de dépendances. Autrement dit à l’intérieur d’un kernel le résultat du calcul pour un élément donné ne dépend que de ses entrées et pas du résultat des calculs d’un autre élément du flux. De plus contrairement au code des applications bureautiques, il y a peu de branchement : tous les éléments d’un flux sont traités exactement de la même manière.

Encore une fois ces observations n’ont rien de révolutionnaires : ce sont elles qui sont à la base des DSP qui existent depuis des années. Ces DSP qui ont évolué au fil du temps pour devenir de plus en plus programmables comme le montre l’exemple des GPU initialement intimement lié à un sous ensemble du pipeline graphique (la rastérisation) et aujourd’hui utilisés pour toutes sortes de calculs. Ainsi on parle de plus en plus de GPGPU : General Purpose Computation on GPUs mais malgré les progrès effectués dans ce domaine tant du point de vue hardware (avec des GPU supportant un nombre toujours plus important de ressources : instructions, registres etc) que software (HLSL, Brook…) effectuer des calculs généraux sur un GPU reste compliqué.

Le CELL : une vue d’ensemble

Si les programmeurs sont prêts à de tels efforts cela traduit un réel manque de performances dans ce domaine des processeurs traditionnels. La réponse d’IBM à ce constat s’appelle donc le Cell. Ainsi plutôt que de dédier un ensemble toujours plus large de transistors à de la logique de contrôle ou à des caches toujours plus monstrueux, le Cell dévoue une bonne partie de ses 234 millions de transistors à de la logique d’exécution. Puisque les processeurs vectoriels n’ont jamais vraiment rencontré le succès en dehors de certaines niches de marché IBM a opté pour une approche hybride. Le Cell se compose donc de plusieurs éléments. On trouve en premier lieu un core PowerPC classique le PPE (pour Power Processing Element) auquel viennent s’ajouter plusieurs processeurs vectoriels les SPE (Synergistic Processing Element).

Ainsi pour ne pas sombrer dans un cas typique d’application de la loi des rendements décroissants IBM ne cherche pas à augmenter le parallélisme d’instructions bien au contraire mais plutôt à augmenter massivement le parallélisme de threads (Thread Level Parallelism ou TLP) en dotant la première incarnation du Cell de 8 SPE. Il faut ajouter à cela que le PPE peut lui-même opérer sur deux threads simultanément à l’aide d’une technique proche de l’HyperThreading d’Intel.

Et comme cette bête doit être malgré tout possible à produire en grande quantité vu que son marché premier reste la future console de Sony, certaines caractéristiques passent à la trappe. Exit donc l’ordonnancement dynamique des instructions : le Cell qu’il s’agisse du PPE ou des SPE ne traite les instructions que dans l’ordre du programme, il est en effet incapable de les réagencer pour mieux tirer parti des ressources disponibles. Ce choix permet de limiter la logique de contrôle au maximum au détriment des performances.

De plus là où un PPC970 peut exécuter jusqu’à 5 instructions par cycle en crête, le PPE lui est beaucoup plus modeste et ne peut lancer à chaque cycle que deux instructions par cycle. On est ici bien plus proche d’un PowerPC 601 bien qu’il emprunte des idées à plusieurs projets récents d’IBM.

Ne vous inquiétez pas si ce schéma vous semble confus au premier abord nous détaillerons largement ces différents éléments ensuite. Mais d’ores et déjà vous devriez remarquer une chose, cette architecture ne vous en rappelle pas une autre vu précédemment dans cet article ? Celle des machines à mémoire distribuée évidemment ! On retrouve donc les différents processeurs (ici les SPE) avec chacun leur propre espace mémoire (LS pour Local Store), le tout connecté par un réseau d’interconnexion (EIB).

En fait, avec toute l’expérience acquise dans les machines multiprocesseurs IBM positionne le Cell à la croisée des chemins des deux approches d’architecture à mémoire distribuée. Ainsi les SPE reposent sur une architecture à mémoire distribuée avec espaces d’adressage distincts. En revanche lorsque vous rajoutez un deuxième Cell, les PPE eux partagent un même espace d’adressage mais il faut noter que la mémoire elle est physiquement distribuée. Ainsi une machine équipée de plusieurs PPE est de type NUMA (Non-Uniform Memory Access), le contrôleur mémoire étant intégré au Cell l’accès aux diverses parties de la mémoire aura un coût variable.

Après ce rapide survol de l’architecture, intéressons nous maintenant aux divers éléments du Cell et, à tout seigneur tout honneur commençons par ce qui distingue tant le Cell des autres processeurs : les SPE.

Les SPE : la force du Cell

Les SPE sont la principale nouveauté du Cell. Comme IBM se plaît à le répéter dans une métaphore du plus bel effet, les SPE sont l’orchestre et le PPE le chef d’orchestre. Mais trêve de représentations figurées, intéressons nous aux détails techniques de ces fameux SPE.

Les SPE sont constitués de trois unités :

• une unité de calcul appelée Synergistic Processing Unit (SPU)
• un contrôleur DMA : le Memory Flow Controller (MFC)
• 256Ko de SRAM appelée Local Store (LS)

Ces trois unités forment un total de 21 millions de transistors (7 millions de logique et 14 millions de SRAM).

SPU

Les SPU sont des processeurs SIMD : Single Instruction Multiple Data, ce qui signifie qu’ils appliquent la même instruction à un ensemble de données. En l’occurrence ils sont particulièrement adaptés au traitement vectoriel vu qu’ils opèrent essentiellement sur des vecteurs de 4 éléments de 32 bits chacun stockés dans des registres 128 bits. A ce propos, les SPU disposent d’un très large fichier unifié de 128 registres 128 bits, utilisé aussi bien pour les entiers, les nombres en virgules flottantes ou les opérations conditionnelles. Un aussi grand nombre de registres se révèle particulièrement utile pour le déroulement des boucles.

L’architecture des SPU est de type chargement-rangement, tous les accès mémoire se font entre la Local Store et le fichier de registres ce qui est classique dans les architectures RISC. Le SPU comme nous l’avons dit plus tôt exécute les instructions dans l’ordre du programme mais offre une forme limitée de lancement multiple. Ainsi chaque SPU dispose de deux pipes d’exécution, le premier se charge d’effectuer les chargements, rangements, ainsi que les opérations de manipulation d’octets et les branchements. Le deuxième effectue les opérations flottantes, les opérations arithmétiques et logiques ainsi que quelques opérations de manipulations d’octets. Les SPU sont donc capables d’effectuer au mieux deux instructions par cycle.

Les SPU sont optimisés pour effectuer leurs calculs sur les nombres flottants simple précisions. A chaque cycle ils sont ainsi capables d’effectuer une opération FMAC (Floating Point Multiply-Accumulate) sur quatre nombres flottants simple précision ce qui offre une performance de crête de 32 GFlops par SPU pour un processeur cadencé à 4 GHz. Notons toutefois qu’à l’image des VU de l’Emotion Engine (le processeur de la PS2), les SPU ne sont pas conformes à la norme IEEE 754. Celle-ci défini un comportement bien précis pour l’arrondi, et les exceptions en cas de débordement, division par zéro, etc. En ignorant cette norme, les SPU peuvent offrir de meilleures performances et à un coût moindre. De plus ce n’est pas tellement pénalisant vu le cadre d’application des programmes destinés à être exécutés sur les SPU.

En revanche dans le cadre de calculs scientifiques, qui peuvent être un autre débouché pour le Cell, le respect de la norme IEEE 754 est primordial, aussi lors de calculs double précision les SPU respectent cette norme. En contrepartie les SPU ne sont plus capables d’exécuter qu’une FMAC sur deux nombres double précision par cycle, et une FMAC ne peut être exécutée que tous les 7 cycles. La performance de crête retombe donc dans ce cas à 2.3 GFlops environ par SPU pour un processeur à 4GHz ce qui est nettement moins impressionnant.

Le jeu d’instructions des SPU est dérivé du jeu d’instructions VMX mais n’est pas complètement identique. Rappelons ici que le jeu d’instructions VMX aussi appelé Altivec par Motorola ou encore Velocity Engine par Apple, est une extension du jeu d’instructions PowerPC offrant 162 nouvelles instructions dédiées au traitement vectoriel. Les instructions arithmétiques disponibles sur les SPU sont donc similaires à celles du jeu d’instructions VMX mais certaines ont été retirées. Le jeu d’instructions des SPU inclus en revanche des nouvelles instructions par rapport au VMX pour contrôler les transferts de et vers la mémoire externe par l’intermédiaire de l’unité MFC.

Les SPE : la force du Cell (suite)

LS

Plus que des processeurs, les SPE sont de véritables petits ordinateurs vectoriels vu qu’ils disposent également de leur propre mémoire embarquée sous la forme de 256 Ko de SRAM appelée Local Store dans la terminologie Cell. Contrairement à ce que laisse entendre l’utilisation de SRAM, et à ce que vous avez sans doute pu lire ici où là ces 256 Ko ne sont pas de la mémoire cache ! La notion de cache implique invariablement une hiérarchie mémoire, et demande de la logique spécifique pour gérer le remplacement des données en mémoire cache. Tout ceci est absent de la mémoire locale des SPE pour plusieurs raisons.

La première est une raison économique, en effet le cache est plus coûteux en termes de transistors et plus complexe à mettre en place. Les autres raisons sont d’ordre plus technique.

En effet cette fameuse LS offre une latence de seulement 6 cycles ce qui est assez impressionnant. Si cette mémoire avait été du cache, soit sa latence aurait nettement augmentée, soit IBM aurait du consentir à en embarquer une plus faible quantité. A ce propos il semblerait que les premiers prototypes de Cell n’embarquaient que 64 Ko de LS, ce chiffre a ensuite été augmenté à 128 Ko puis à 256 Ko actuellement.

La troisième raison, et la plus importante, est que comme nous l’avons vu les SPE sont destinés à effectuer du stream processing. Comme décrit précédemment le stream processing consiste à appliquer un « noyau » d’instructions à un très large ensemble de données variées. Pour ce genre de situations les caches qui reposent sur les principes de localités (spatiales ou temporelle) ne sont pas adaptées car il y a très peu de chance que les données soient réutilisées. Un petit espace mémoire, dont l’organisation est à la charge du programmeur est donc plus indiqué. Toutes ces raisons expliquent le choix d’IBM.

Notons qu’un des compromis pour une telle taille mémoire embarquée est que la Local Store ne dispose que d’un port en lecture/écriture, ce qui signifie qu’une priorité doit régir l’ordre des accès simultanés à la mémoire. La plus haute priorité est donnée aux transferts DMA provenant du PPE, la seconde priorité est donnée aux transferts DMA du SPE et enfin la troisième, et plus basse, aux chargement des instructions du SPU.

MFC

Si les SPE disposent d’une mémoire extrêmement rapide, ils ne peuvent en revanche adresser que ces maigres 256 Ko. Comme cet espace mémoire est insuffisant pour la majeure partie des programmes, les SPE doivent pouvoir faire transiter des données depuis la mémoire principale en permanence. C’est le rôle du MFC qui est en fait un contrôleur DMA associé à une MMU (Memory Management Unit) pour assurer la cohérence des données en mémoire.

Le MFC gère deux files de commandes DMA : une interne contenant les requêtes du SPE, et l’autre externe contenant les requêtes du PPE ou des autres SPE. La file de requêtes interne peut contenir jusqu’à 16 commandes et chaque requête peut transférer jusqu’à 128 Ko de données, de ou vers la Local Store. Lorsque le SPE demande une donnée en provenance de la mémoire externe la MMU gère la traduction d’adresse avant de la placer sur le bus. Notons également que le MFC peut transférer des données depuis la Local Store directement dans la mémoire cache de niveau 2 du PPE afin de rendre des données critiques accessibles plus rapidement.

Le PPE : le maître d’œuvre

Alors que les SPE constituent la partie exotique du Cell, le PPE est pour sa part beaucoup plus traditionnel. On se retrouve ainsi devant une nouvelle implémentation 64 bits de l’ISA PowerPC qui trouve ses racines dans un projet d’IBM datant de 1997 et qui visait à créer un processeur simple mais capable d’atteindre la fréquence d’horloge de 1 GHz. Huit ans plus tard ce projet a bien changé mais le PPE hérite de la simplicité de son ancêtre.

Le design du PPE rappelle donc celui des premières implémentations de l’ISA PowerPC : exécutant les instructions dans l’ordre (pas de réordonnancement dynamique des instructions) et offrant une forme limitée d’exécution superscalaire. On est donc très loin ici d’un PowerPC 970.

Le PPE dispose d’une hiérarchie mémoire classique avec deux mémoires cache de niveau 1 distinctes pour les instructions et les données de 32 Ko chacune, et une mémoire cache de niveau 2 unifiée de 512 Ko.

A chaque cycle le PPE est capable de lancer l’exécution de deux instructions par cycle pourvu qu’elles ne présentent pas de dépendances entre elles et qu’elles occupent des unités différentes. En effet le PPE ne dispose que d’une FPU, d’une unité vectorielle et d’une ALU. L’absence de réordonnancement dynamique des instructions limite encore plus l’IPC de ce processeur.

Le PPE doit en effet reposer sur l’ordonnancement statique effectué par le compilateur là où les processeurs modernes (à quelques exceptions comme l’Itanium) utilisent l’ordonnancement dynamique afin de réduire les suspensions dans le cas où les dépendances ne sont pas connues à la compilation.

Prenons par exemple la suite d’instructions suivante :

R0 = R1 * 2
R2 = R0 + 2

Ces deux instructions utilisent l’unité de calcul entière du PPE. Toutefois la deuxième instruction ne peut être exécutée tant que le résultat de la première ne sera pas connu. Et plus le pipeline est long plus ce résultat prendra de cycles à être déterminé. Pour contourner le problème, les processeurs à ordonnancement dynamique disposent d’une fenêtre d’instructions à lancer et sélectionnent dans cette fenêtre des instructions ne présentant pas de dépendances avec la première.

Ainsi en attendant que le résultat de la première instruction soit disponible ces CPU peuvent effectuer du travail utile pour la suite. Un CPU à ordonnancement statique pour sa part devra suspendre le pipeline diminuant largement son efficacité. Un autre avantage des processeurs à réordonnancement dynamique est qu’ils peuvent masquer les défauts du cache de niveau 1 en exécutant encore une fois d’autres instructions indépendantes lorsqu’une donnée doit être récupérée depuis la mémoire cache de niveau 2. Evidemment l’exécution dans le désordre à un coût, vu qu’il faut une fenêtre d’instructions et sauvegarder l’ordre des instructions dans une table afin de garantir une exécution ordonnée du programme au final. Des registres de renommage sont également nécessaires pour éliminer les fausses dépendances qui peuvent être introduites.

Le PPE : le maître d’œuvre (suite), l’EIB

IBM a préféré éviter d’ajouter une telle complexité dans son processeur, et le justifie en disant qu’ainsi le comportement est nettement plus prédictif pour le programmeur. Justification pour le moins discutable. En revanche pour limiter les cycles perdus par une architecture de ce type, IBM a rendu le PPE capable d’exécuter des instructions de deux threads en parallèle : lorsqu’un thread est suspendu par une dépendance, l’autre thread prend le relais et occupe ces précieux cycles CPU avec du travail utiles au lieu d’introduire des suspensions dans le pipeline. On parle de SMT pour Simultaneous MultiThreading. Le coût en logique est minime et le gain de performances induit peut être très intéressant. Surtout dans une architecture comme celle du PPE incapable de réordonnancer ses instructions. En revanche l’impact sur la mémoire cache peut parfois s’avérer désastreux.

La technique utilisée par le PPE n’a pas été décrite par IBM aussi nous ne pouvons ici qu’émettre des suppositions, toutefois il semblerait que la méthode utilisée soit nettement moins flexible que celle de l’Hyperthreading d’Intel. Une piste viendrait des déclarations de nombreux programmeurs (dont John Carmack et Gabe Newell) qui se sont plaints des performances du PPE (et du Xenon de la Xbox 360 par la même occasion) dans le cadre de programmes monothreadés. Ils ont en particulier dénoncé le discours de Sony et Microsoft, vantant leur impressionnante fréquence d’horloge à la moindre occasion, en indiquant qu’en pratique il fallait, dans certains cas, la diviser par deux pour obtenir une meilleure estimation des performances de ces CPU.

Encore plus troublant, lors de sa présentation sur le Cell à la dernière GDC, Dean Calver programmeur d’un jeu PS3 appelé Heavenly Sword, a indiqué qu’il conseillait de considérer, d’un point de vue logiciel, le PPE comme deux processeurs distincts fonctionnant à une fréquence deux fois moins élevée. Enfin IBM lui-même a précisé que l’exécution des threads était entrelacée sans donner plus de précision.

Ce que l’on peut déduire de tout cela, mais encore une fois cela reste des spéculations, est que l’implémentation du SMT par le PPE est assez limitée en ce sens qu’un thread ne peut lancer l’exécution d’une instruction que tous les deux cycles, l’autre cycle étant réservé à l’exécution d’une instruction de l’autre thread. Ainsi dans le cadre d’une application monothreadée on se retrouverait effectivement avec l’équivalent d’un processeur de fréquence deux fois moins élevée.

Ceci dit ceci n’est qu’une hypothèse et si l’on en croît l’article de Microprocessor Report elle serait fausse. Ainsi dans le cas où un des threads ne serait pas capable d’exécuter une instruction lors de son cycle, alors l’autre thread pourrait exécuter des instructions tous les cycles et non tous les deux cycles. Il semblerait donc que la situation ne soit pas aussi dramatique, mais l’implémentation du SMT par le PPE reste assez mystérieuse et dans tous les cas plus limitée que l’Hyperthreading car elle ne permet pas, à un cycle donné, d’avoir deux instructions de deux threads différents en cours de traitement dans des unités distinctes.

L’EIB : un anneau pour les gouverner tous

Pour garantir une bonne communication entre ces divers éléments, il fallait un réseau d’interconnexions efficace. IBM a donc développé un bus en anneau appelé EIB. En fait il s’agit plus précisément de quatre anneaux unidirectionnels : deux transférant les données dans un sens, et deux dans l’autre afin de minimiser la latence introduite par la structure en anneau. Ainsi dans le pire des cas la latence n’est que la moitié de la distance totale de l’anneau. Chaque anneau offre une largeur de 16 octets (plus un tag de 8 octets) mais ne fonctionne qu’à la moitié de la fréquence d’horloge.

Conclusion

Alors le Cell une révolution ? N’allons pas si vite en besogne, parler de révolution est un bien grand mot. S’il faut reconnaître que l’approche d’IBM est intéressante sur de nombreux points elle n’est néanmoins pas parfaite. Ainsi l’approche qui vise à simplifier la logique de contrôle pour privilégier la logique d’exécution est assurément la voie à suivre pour les besoins des applications futures. Intel avait d’ailleurs suivi la même voie pour son architecture EPIC. En revanche là où l’Itanium cherchait à accroître l’ILP, le Cell mise tout sur le TLP par l’intermédiaire de multiples processeurs vectoriels. Il y a fort à parier que de nombreux fabricants de microprocesseurs suivront une approche de ce style dans les années qui viennent. Intel l’a d’ailleurs déjà annoncé dans sa roadmap. Après une phase qui consiste à inclure de multiple core généralistes au sein d’un CPU, le fondeur californien a déjà prévu d’ajouter de multiples cores spécialisés à ses processeurs.

S’il n’y a donc pas grand-chose à reprocher aux SPE, on peut en revanche être plus circonspect en ce qui concerne le PPE. IBM a peut être poussé un peu trop loin l’esprit de simplification et un core généraliste plus performant, capable du lancement multiple d’instructions dans le désordre aurait été préférable. Mais les compromis nécessaires pour rendre le processeur relativement peu coûteux à fabriquer dans l’optique de son utilisation dans des appareils grands publics par Sony et Toshiba risque de compromettre son utilisation dans des stations de travail.

Une rumeur qui circule laisserait d’ailleurs entendre que le Cell avait été proposé à Steve Jobs pour les futurs Macintosh mais que celui-ci l’aurait refusé. Ce refus est sans doute la combinaison de choix autant marketings que techniques, mais elle n’incite pas à l’optimisme quant au futur du Cell dans les ordinateurs personnels.

N’oublions toutefois pas que lorsque nous parlons du Cell nous parlons en fait de la première implémentation de l’architecture Cell qui a été présentée récemment par IBM et qui sera utilisée par la PS3 de Sony. D’autres implémentations corrigeront certainement les défauts constatés dans cette première mouture. La question n’est donc pas tant de savoir si l’idée du Cell est bonne, car elle l’est assurément, mais plutôt de se demander si IBM n’est pas un peu trop en avance en tentant de la réaliser dés aujourd’hui.