|
[[File:Stream processor.png|centre|vignette|upright=2|Stream processor]]
A première vue, les schémas du dessus ne ressemblent à rien de connu. Et pourtant on peut déjà faire quelques remarques assez intéressantes. Déjà, il n'y a pas de mémoires caches. Ensuite, l'ensemble ressemble fortement à ce qu'on trouve sur les processeurs vectoriels, à part que les registres vectoriels sont scindés en plusieurs exemplaires.
===PasL'absence dedu cache de données===
En théorie, les Streamsprocesseurs de Processorsflux contiennent peu de mémoires caches, comme pour les processeurs vectoriels. Il faut dire que les Streamsprocesseurs de Processorsflux sont, comme les processeurs vectoriels, conçus pour manipuler des tableaux de données, qui ont une faible localité temporelle : quand on accède à une donnée dans un tableau, il est rare qu'on doive la réutiliser plus tard. Dans ces conditions, utiliser des mémoires caches est contre-productif,. vuC'est pour cela que celles-ciles sontpremiers conçuesprocesseurs pourde stockerflux, descomme donnéesl'''Imagine'', n'avaient strictement aucun cache. Au afinlieu de pouvoirchercher lesà réutiliserdiminuer ultérieurement.la C'estlatence pouravec celades quecaches, les premiers processeurs vectorielsde etflux lesvont Streamsplutôt processorschercher ontà peumasquer oucette pasdernière deen cacheexécutant pourdes lesinstructions données.en Lesparallèle premiersdes Streamsaccès Processorsmémoire, commesoit l'Imagineen utilisant un pipeline long, n'avaientsoit strictementavec aucundu cachemultithreading matériel.
Mais attention : si un Streamprocesseur Processorde flux ne contient pas de mémoire cache pour les données, ce n'est pas le cas pour les instructions. Après tout, si l'on doit exécuter ces instructions plusieurs fois de suite sur des données différentes, autant éviter de les charger de la mémoire à chaque fois. Pour éviter cela, les suites d'instructions à exécuter sont stockées dans une petite mémoire une bonne fois pour toute. Il s'agit bel et bien d'une petite mémoire cache.
===Une hiérarchie de bancs de registres===
Les Streamsprocesseurs Processorsde flux ont plusieurs bancs de registres. On trouve d'abord quelques '''Local Register File''', directement connectés aux unités de calcul. Plus bas, ces Local Register Files sont reliés à un Register File plus gros, le '''Global Register File''', lui-même relié à la mémoire. Ce Global Register File sert d'intermédiaire entre la mémoire RAM et le Local Register File. La différence entre ce Global Register File et un cache vient du fait que les caches sont souvent gérés par le matériel, tandis que ces Register Files sont gérés via des instructions machines. Le processeur dispose ainsi d'instructions pour transférer des données entre les Register Files ou entre ceux-ci et la mémoire. Leur gestion peut donc être déléguée au logiciel, qui saura les utiliser au mieux. Outre son rôle d'intermédiaire, le Global Register File sert à transférer des données entre les Local Register Files, où à stocker des données globales utilisées par des Clusters d'ALU différents. Les transferts de données entre la mémoire et le Global Register File ressemblent fortement à ceux qu'on trouve sur les processeurs vectoriels. Un Stream Processor possède quelques instructions capables de transférer des données entre ce Global Register File et la mémoire RAM. Et on trouve des instructions capables de travailler sur un grand nombre de données simultanées, des accès mémoires en Stride, en Scatter-Gather, etc.
[[File:Stream processor registers.png|centre|vignette|upright=2|Stream processor registers]]
On peut se demander pourquoi utiliser plusieurs couches de registres ? Le fait est que les Streams Processors disposent d'une grande quantité d'unités de calcul. Et cela peut facilement aller à plus d'une centaine ou d'un millier d'ALU ! Si on devait relier toutes cas unités de calcul à un gros Register File, celui-ci serait énorme, lent, et qui chaufferait beaucoup trop. Pour garder un Register Files rapide et pratique, on est obligé de limiter le nombre d'unités de calcul connectées dessus, ainsi que le nombre de registres contenus dans le Register File. La solution est donc de casser notre gros Register File en plusieurs plus petits, reliés à un Register File plus gros, capable de communiquer avec la mémoire. Ainsi, nos unités de calcul vont aller lire ou écrire dans un Local Register File très rapide.
La mémoire RAM d'un Streamprocesseur Processorde flux est souvent une mémoire multibanques, comme avec les processeurs vectoriels. Cette mémoire RAM est une mémoire qui possède souvent un gros débit binaire. Je rappelle que le débit binaire d'une mémoire est le nombre de bits qu'elle peut transférer en une seule seconde. Par contre, cela ne signifie pas que cette mémoire est rapide : le temps mit pour lire ou écrire une donnée est assez important. Il ne faut pas faire la confusion entre le débit binaire et le temps d'accès. Pour faire une analogie avec les réseaux, le débit binaire peut être vu comme le débit de la mémoire, alors que le temps d'accès serait similaire au ping. Il est parfaitement possible d'avoir un ping élevé avec une connexion qui télécharge très vite, et inversement. Pour la mémoire, c'est similaire.
===La mitigation de la latence===
Comme je l'ai dit plus haut, la mémoire RAM est très lente. Et quand on n'a pas de mémoires caches pour diminuer la latence des accès mémoire, on doit trouver une autre solution. Au lieu de chercher à diminuer la latence, les Streams Processors vont plutôt chercher à cacher cette dernière. La première solution pour cela consiste à allonger le pipeline : cela permet au Stream Processor de continuer à exécuter des instructions pendant que l'on accède à la mémoire. Un autre solution consiste à utiliser le multithreading matériel.
<noinclude>
|
