Evidemment un des marchés qui intéresse le plus Intel avec Larrabee est celui du GPGPU. Pour cela Intel a mis le paquet : Larrabee devrait supporter l’ensemble des API non propriétaires. OpenCL, Compute Shader et bien évidemment l’API maison Ct seront donc de la partie, pour les programmes offrant un parallélisme de données comme on le trouve sur les GPU. Mais Intel souhaite aussi offrir la possibilité de gérer le parallélisme de tâches comme on le trouve sur les processeurs modernes, pour cela Larrabee supportera des API de type pthreads, OpenMP ou encore Intel TBB.
Intéressons nous tout d’abord à ces deux modèles de programmation parallèle. Le parallélisme de données est celui qui est exploité par les GPU, il consiste comme nous l’avons vu à exécuter un même code (appelé kernel ou noyau en français) sur un ensemble suffisamment large de données différentes (appelé stream ou flux). Il n’a pas de dépendance entre les éléments d’un flux ce qui permet d’exploiter efficacement le parallélisme. Un autre avantage est que cela permet d’utiliser de façon implicite les unités SIMD, la largeur des vecteurs traités par le hardware est transparente pour le programmeur, c’est le compilateur qui se charge de réorganiser les données pour exploiter de façon automatique toutes les unités. Enfin le dernier atout est que si le nombre de données est suffisamment grand il est facile de masquer la latence des opérations mémoires. En contrepartie certains algorithmes se prêtent difficilement à ce modèle de programmation, il faut en effet plusieurs centaines voire même plusieurs milliers d’éléments de préférence, pour pouvoir exploiter correctement toutes les unités.
Le deuxième mode de programmation parallèle, le parallélisme de tâches est celui qu’on observe sur les CPU multi-cœurs comme le Cell ou le Xenon sur consoles et tous les processeurs récents sur PC. Plutôt que d’appliquer une même fonction sur un ensemble de données, il s’agit ici d’identifier quelques tâches indépendantes qui peuvent être exécutées en parallèle, de façon asynchrone. On retrouve cependant les problèmes classiques qui sont désormais familiers des programmeurs : pour utiliser les unités SIMD le programmeur doit le faire de façon explicite. De la même façon le parallélisme de tâches est moins évolutif que le parallélisme de données : une fois que le découpage a été fait pour bien utiliser les ressources d’une architecture donnée, une nouvelle architecture pourra en revanche être sous exploitée si le nombre de tâches n’est pas suffisant. Le programmeur a aussi la charge de gérer la synchronisation des tâches notamment dans le cas d’accès à des ressources partagées. En contrepartie certains algorithmes sont plus adaptés à un découpage de ce type vu qu’il nécessite une granularité moins fine que le parallélisme de données.