Déjà, il est bon de noter que du à l’architecture, les OS conventionnels ne peuvent tourner sur les 256 cores (l’interconnect ne le supporterai pas).
C'est vrai. En même temps, je ne vois pas pourquoi je voudrais forcément que l'OS tourne sur l'intégralité des cœurs.
Linux tourne sur seulement 4 cœurs, et les autres sont accessibles via une interface particulière, un peu comme on enverrai des shaders sur un gp-gpu ou un firmware sur un microcontrolleur.
Oui, car les quatre cœurs en question sont les seuls à pouvoir gérer les I/O (entre autres).
Donc déjà ça veut dire que vos applications traditionnelles (erlang, go, openmp...) ne vont pas profiter du cluster sans effort.
Oui, il faut utiliser une sorte de dialecte de C/C++ fournit avec le processeur. De ce qu'on m'a dit, programmer efficacement avec n'est pas sans peine. Cependant pour être honnête, c'est aussi vrai pour Cuda/OpenCL/OpenACC/HMPP/ etc. C'est même vrai pour les processeurs Intel/AMD/etc., où sans qu'on sache vraiment quand ni comment, certains aspects micro-architecturaux font qu'une série d'instructions assembleur vont se révéler très efficaces, mais avec la nouvelle version du Core i7 (par exemple), on se retrouve avec une performance unicœur plus pourrie. Pourtant, sur le papier y'a les mêmes specs : 32Kio de L1D, 256Kio de L2, 8Mio de L3 partagé... Sauf que non, le L3 n'est plus un cache avec une file d'attente, il s'agit désormais d'un cache de type NUCA (Non-Uniform Cache Access), donc segmenté, et que désormais la file d'attente est elle aussi segmentée, et ... Bref. CUDA est encore pire, car même si on a accès au jeu d'instruction assembleur (PTX), il s'agit d'un langage « virtuel », et d'une carte Nvidia à l'autre la performance d'une séquence d'instructions PTX « optimisante » peut se retrouver « pénalisante ».
[^] # Re: Sceptique...
Posté par lasher . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 6.
C'est vrai. En même temps, je ne vois pas pourquoi je voudrais forcément que l'OS tourne sur l'intégralité des cœurs.
Oui, car les quatre cœurs en question sont les seuls à pouvoir gérer les I/O (entre autres).
Oui, il faut utiliser une sorte de dialecte de C/C++ fournit avec le processeur. De ce qu'on m'a dit, programmer efficacement avec n'est pas sans peine. Cependant pour être honnête, c'est aussi vrai pour Cuda/OpenCL/OpenACC/HMPP/ etc. C'est même vrai pour les processeurs Intel/AMD/etc., où sans qu'on sache vraiment quand ni comment, certains aspects micro-architecturaux font qu'une série d'instructions assembleur vont se révéler très efficaces, mais avec la nouvelle version du Core i7 (par exemple), on se retrouve avec une performance unicœur plus pourrie. Pourtant, sur le papier y'a les mêmes specs : 32Kio de L1D, 256Kio de L2, 8Mio de L3 partagé... Sauf que non, le L3 n'est plus un cache avec une file d'attente, il s'agit désormais d'un cache de type NUCA (Non-Uniform Cache Access), donc segmenté, et que désormais la file d'attente est elle aussi segmentée, et ... Bref. CUDA est encore pire, car même si on a accès au jeu d'instruction assembleur (PTX), il s'agit d'un langage « virtuel », et d'une carte Nvidia à l'autre la performance d'une séquence d'instructions PTX « optimisante » peut se retrouver « pénalisante ».