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 ...
[^] # Re: Le CPU, limité dans son évolution
Posté par Julien . En réponse à la dépêche Les GPU promis à une mort prochaine ?. Évalué à 5.
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 ...