Nomenclature et manipulation

Dans le cas du parallélisme de données, Larrabee se comporte comme un GPU classique même si Intel arrive forcément avec sa propre nomenclature.  Ainsi les threads de CUDA sont ici rebaptisés strands, les warps correspondent à ce qu’Intel appelledes fibers quicontiennent de 16 à 64 strands. Enfin les blocs sont ici des threads qui peuvent être composés de 2 à 10 fibers. Un cœur de Larrabee peut exécuter jusqu’à 4 threads. Perdus ? On le serait à moins entre toutes les définitions personnelles de « threads » qui ne désignent pas les mêmes choses ! Avouons tout de même que la définition d’Intel est plus proche de celle qui existe depuis des années alors qu’utiliser ce terme pour désigner un élément d’une unité SIMD, comme le fait NVIDIA, est un peu discutable à notre goût. Mais au fait pourquoi un tel découpage ? Simplement parce qu’alterner entre ces éléments n’a pas le même coût.

Jongler entre plusieurs fibers d’un même threads est un processus très peu coûteux et entièrement logiciel. L’ensemble des données des fibers restant en mémoire cache, l’exécution d’un fiber peut reprendre très rapidement. Ce mécanisme est donc utilisé pour masquer les longues latences comme lors de l’accès à la mémoire centrale. A l’inverse, alterner entre plusieurs threads est une opération matérielle plus coûteuse puisque comme sur un processeur cela demande de sauvegarder le contexte du thread qui va être mis en sommeil et de le restaurer une fois que son exécution sera reprise, il faut toutefois souligner que le SMT permet de limiter ce coût en offrant à chaque thread un ensemble dédié de registres. Les threads sont utilisés pour masquer les latences plus courtes et moins facilement prédictibles.

 Le fonctionnement de Larrabee en parallélisme de tâches met en jeu nettement moins de jargon : une tâche est donc une fonction asynchrone, chaque thread est constitué de plusieurs tâches et chaque cœur alterne l’exécution de jusqu’à 4 threads en parallèle. Un des avantages de Larrabee est que comme tout bon CPU, il peut lancer l’exécution de nouvelles tâches à tout moment alors que sur un GPU c’est impossible ; c’est le CPU qui doit lancer l’invocation d’un nouveau programme. Sur Larrabee on peut donc tout à fait envisager voir une tâche lancer l’exécution d’une autre tâche qui exploitera le parallélisme de données. Il est en effet possible de mixer les deux types de programmation parallèle sur Larrabee, c’est d’ailleurs ce que fait Intel dans son moteur de rendu.

Notons enfin qu’il n’est pas nécessaire d’utiliser des runtimes spécifiques pour programmer Larrabee, Intel offre en effet la possibilité de développer des applications natives pour Larrabee qui s’exécuteront directement sur le hardware. Ces applications natives nécessiteront d’être compilées avec un compilateur C/C++ spécial fourni par Intel qui outre un exécutable Larrabee, génèrera aussi un binaire destiné au processeur central dont le rôle sera de charger le programme Larrabee et de lui passer les données nécessaires. Ces applications sont les plus proches du métal possibles, c’est à ce même niveau qu’est exécuté le moteur de rendu logiciel de Larrabee par exemple, qui n’est d’ailleurs rien d’autres qu’une application native Larrabee comme tout le monde pourra en écrire. Intel ne se réserve aucun accès privé au hardware, tout est exposé au programmeur. Evidemment programmer Larrabee de cette façon est plus contraignant qu’en utilisant les API existantes mais c’est de cette manière qu’il sera possible d’exploiter au mieux la nouvelle puce d’Intel.