Articles : Les GPU promis à une mort prochaine ?
Posté par Ontologia (page perso, ). Modéré le 20 mai 2008.
De simples afficheurs de triangles texturés en 1995, les cartes graphiques munies de GPU sont devenues des sortes d'énormes DSP bientôt composées d'un milliard de transistors, délivrant des performances approchant bientôt le téraFLOPS. La répartition des tâches semblait jusqu'ici bien déterminée entre le CPU, dévolu aux tâches de gestion et de décision, et le GPU se chargeant du calcul brut, en particulier graphique. Mais les quelques acteurs du marché ont récemment amorcé des mouvements les préparant à dépasser leurs frontières traditionnelles.
![[en]](../images/en.png)
L'annonce de Larrabee par Intel (697 hits)-
Le guide de référence d'AVX (201 hits)
![[fr]](../images/fr.png)
Une description du fonctionnement des derniers GPU NVidia (718 hits)-
Un tutoriel expliquant comment optimiser avec SSE (304 hits)
-
Une fractale de mandelbrot en shading language (693 hits)
> Lire la dépêche (66 commentaires, moyenne: 3,6).
Vous avez demandé le commentaire #932832.
Run by 
Cette page a été générée par Templeet en 0.0648s (dont 0.0059 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Le CPU, limité dans son évolution
Je suppose que déjà le système de parallélisation automatique du x86 doit prendre une certaine place sur la puce...
Si on l'enlevait et qu'on passait à du VLIW on devrait gagner une place non négligeable. Mais bon, Intel a essayé (Itanium), et le marché n'a pas suivi.
Le problème finalement, c'est surtout le support logiciel. Les cartes graphiques sont essentiellement utilisées par les pilotes pour les jeux fournis par leurs constructeurs, donc ce n'est pas vraiment problématique si leur assembleur est tellement complexe que seul le constructeur sait l'exploiter. Ce qui compte, c'est la performance.
Surtout qu'il n'y a pas de problème de compatibilité, puisque ça passe par une couche d'abstraction (OpenGL, DirectX...)
Les CPUs font face à un tout autre problème. Il y a à la fois le problème de compatibilité et celui de la simplicité. Les divers OS, compilateurs, etc. doivent être à même d'exploiter le matériel sans dépenser des milliers en recherche dessus, et les utilisateurs veulent que le travail qu'ils ont effectués jusqu'à présent fonctionne.
Pour toutes ces raisons, malheureusement, on ne peut pas se débarasser de x86 si facilement pour le remplacer par un jeu d'instruction mieux fait et qui permettrait de gagner des performances non négligeables. C'est triste quand on voit que les GPU peuvent tout se permettre puisqu'ils n'ont pas à conserver la moindre usabilité ou compatibilité avec quiconque, ce qui leur permet d'évoluer et de s'améliorer beaucoup plus.
Idéalement, on pourrait se dire qu'un GPU devrait fusionner avec le CPU pour devenir son unité de calcul vectoriel. Sauf que pour les raisons citées ci-dessus, le GPU a bien plus de potentiel, donc ce n'est pas réellement envisageable.
Le seul moyen pour que ce le soit, ce serait que le constructeur maintienne une implémentation libre d'une abstraction. Un peu comme ce que fait nvidia avec CUDA, qui permet justement d'utiliser un GPU comme un CPU limité.
(Désolé si je me répète un peu, il est tard)
[^]Re: Le CPU, limité dans son évolution
>Je suppose que déjà le système de parallélisation automatique du x86 doit prendre une certaine place sur la puce...
Bof, pas tant que ça maintenant (en pourcentage), c'est pour ça que les x86 ont finis par rattrapper les RISCs..
Je pense que les scientifiques vont être très, très satisfait d'avoir l'AVX, les calculs scientifiques se faisant sur 64bit de précision en général.
>Si on l'enlevait et qu'on passait à du VLIW on devrait gagner une place non négligeable
Pour les VLIW, il reste le probleme du compilateur, a part pour du code tres regulier un VLIW n'est pas exploité au mieux donc ce n'est pas du tout évident que le VLIW soit la bonne voie: le POWER est tout à fait compétitif par rapport a l'Itanium.
[^]Re: Le CPU, limité dans son évolution
Bof, pas tant que ça maintenant (en pourcentage), c'est pour ça que les x86 ont finis par rattrapper les RISCs..
En réalité (en ce qui concerne AMD en tout cas) les processeurs X86 SONT des RISC, avec une couche de ré écriture du code au mileu.
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: Le CPU, limité dans son évolution
RISC/CISC définisse le jeu d'instruction.
Au début, le RISC correspondait à une architecture load/store (load/store clairement séparer des opérations ALU, avec donc moins de mode d'adressage et un pipeline plus court). En général, le RISC a une taille d'instruction fixe (32 bits en général) pour simplifier le décodage et le pipeline.
Donc le x86 est du vrai CISC bien complexe et ne sera jamais du RISC quelques soit la micro architecture en dessous.
D'ailleurs, ARM avec son thumb2 est entrain de devenir de plus en plus CISC avec des instructions de tailles 16 ou 32 bits.
[^]Re: Le CPU, limité dans son évolution
on est tous d'accord que le x86 c'est un jeu d'instruction CISC.
Mais les processeurs AMD x86 reposent sur un coeur RISC. C'est tout ce que je voulais dire.
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: Le CPU, limité dans son évolution
Sauf que dire "coeur risc" n'a strictement aucun sens.
Je sais que les x86 transforme les instructions en µinstructions voire en suite de µinstructions mais on est plus proche du vliw que du risc. Pour le pentium 4, on parlait de 118 bits ce qui réduisait de beaucoup le cache L1 instructions.
[^]Re: Le CPU, limité dans son évolution
Pour le pentium 4, on parlait de 118 bits ce qui réduisait de beaucoup le cache L1 instructions.
Ah ben oui mais vu qu'on a besoin de moins d'instructions pour effectuer une tache ca compense :) (En réalité je n'en sais rien et je pense que non, il y'a probablement des papiers tres pointus sur ce sujet quelque part sur l'ieee).
[^]Re: Le CPU, limité dans son évolution
Mais bon, Intel a essayé (Itanium), et le marché n'a pas suivi.
Ce ne serait pas plutôt un problème de compilateurs, au niveau de l'ILP que ces derniers arrivent à extraire, ou pire, de l'ILP intrinsèquement présent dans la plupart des programmes (HPC exclu...) ?
[^]Re: Le CPU, limité dans son évolution
C'est pas faux.
[^]Re: Le CPU, limité dans son évolution
c'est intrinsèquement que tu n'as pas compris ? ;-)
[^]Re: Le CPU, limité dans son évolution
Je pense de mon côté que la révolution (si révolution il y a) viendra des langages interprétés et JITés. Je ne serais pas étonné qu'on nous refasse le coup du Out-of-order_execution avec le bytecode dans le rôle de l'assembleur et l'assembleur dans le rôle du microcode.
Je m'explique : le OoO revient à transformer l'assembleur du binaire en un code plus finement découpé : le microcode. Ce microcode est stocké dans un "pool" dans le processeur et chaque instruction est exécutée dans le désordre (out of order) dès que ses dépendances sont satisfaites.
Une partie du processeur est donc destinée à la gestion de ce mécanisme : traduction, gestion des dépendances, etc ...
Dans le cas du bytecode, on ajoute une étape de transformation. Le bytecode est soit interprété, soit transformé en code assembleur pendant l'exécution (JIT). Il me semble que cette étape ressemble fortement à ce qui se fait pour le OoO, mais à une échelle plus large.
On pourrait donc imaginer une architecture où un coeur est destiné à la gestion de ce bytecode (exécution de la VM) et où les autres coeurs exécutent le résultat. Cette solution permettrait de tirer partie de coeurs hétérogènes : 1CPU OoO classique pour l'interprétation, un GPU pour ce qui se parallélise facilement, un VLIW pour ce qui a été JITé, un FPGA pour les tâches très répétitives, etc ...
Enfin, je divague ...
[^]Re: Le CPU, limité dans son évolution
de façon plus générale, on peut même imaginer un système où chaque coeur (ou sous-groupe de qq coeurs) est spécialisé dans une tâche :
* compatibilité x86 (ce qui permettrait de s'en affranchir dans les autres coeurs)
* opérations graphiques
* ...
enfin, je n'y connais pas grand chose :)
[^]Re: Le CPU, limité dans son évolution
* répartition des processus vers les autres coeurs pour la parallélisation
* traitement vectoriel
etc
on peut tout imaginer