Architecture MILL : discussion

Les grosses innovations sont devenues relativement rares en architectures des ordinateurs, et rares sont les nouvelles architectures réellement novatrices. La majorité des architectures assez innovantes visent soit des marchés relativement restreints (architectures neuromorphiques), et peu essayent de viser le marché de processeurs généralistes.

Il y a quelques mois, une nouvelle architecture généraliste a vu le jour : l'architecture MILL. Beaucoup pensent qu'on a pas vu quelque chose de semblable depuis les processeurs EPIC (Itanium). Une description de cette architecture est disponible sur le site Mill Computing, à cette adresse : Architecture du MILL.

Le but de ce post est de faire connaitre cette future architecture, et si possible d'en discuter en profondeur. Est-ce que les compilateurs pourront faire du bon travail avec (problématique bien connue depuis l'échec de l'Itanium), quelles sont les bonnes idées de l'architecture, etc.

Messieurs, à vos claviers !

Intéressant je vais allez lire ça.

Plus généralement, est ce vraiment un problème de compilateur qui empêche les architectures d’émerger ou de façon plus complet tout "l'historique". Il semble très dur de faire percer une archi. Même les ARM qui n'ont pas vraiment de problèmes d'outils me semble t'il ont bien du mal à s'imposer où le x86 domine et c'est surtout ces capacités énergétique meilleurs qui semble permettre de le faire arriver chez nous. Bref comme pour tout, cela me semble surtout l'inertie qui semble bloquer, non ?

Ah, mais les ARM, MIPS, et autres architectures n'ont pas trop de problèmes. Évidemment, sur les PC c'est loin d'être le cas : on est tellement dépendant du X86 qu'utiliser d'autres jeux d'instruction est impossible (pour le moment). Mais pour les tablettes, téléphones, consoles de jeu et autres dispositifs généralistes courants, pas de problèmes pour ces architectures. Sincèrement, les ARM ont fait leur place dans le marché généraliste (hors PC).

C'est pas comme les architectures EPIC (Itanium en tête, qui étaient formidables sur le papier, mais qui avaient des performances limitées dans leur domaine d’utilisation (haute performance). Là, on avait vraiment un gros problème de compilateur, qui ne pouvait pas vraiment profiter des fonctionnalités de ces architectures (branchements spéculatifs, load anticipés à grand coup d'ALAT, VLIW de longueur variable, etc).

Idem pour les processeurs VLIW généralistes (le transmetta Crusoe en tête) : problème de compilateur, qui n'arrive pas à extraire suffisamment d'ILP lors de la compilation. Ce qui fait que de nos jours, les VLIW sont relativement limités à l'embarqué ou aux GPU, mais n'ont pas percés dans le computing généraliste.

D'ailleurs, si tu regarde bien, les processeurs généralistes (SPARC, POWER PC, MIPS, ARM, etc) sont tous des RISC. Cela vient du fait que le RISC est une forme d'architecture avec laquelle les compilateurs arrivent facilement à faire du code rapide. Seul l'X86 fait exception, mais au prix de micro-architectures particulièrement bourrines et agressives en terme d' (micro-)optimisations matérielles.

Question de béotien (je n'y connais pas grand-chose en architecture des ordinateurs) : pourquoi les gens qui sortent une nouvelle architecture ne sortent pas le compilo (disons C) qui va avec, en même temps ? Je veux dire par là que la conception du compilateur se ferait en même temps (et interagirait avec) la conception de la nouvelle architecture.

Autrement, j'aimerais vérifier que j'ai bien compris : l'organisation des « registres » en ceinture (belt) implique que le code machine est sous forme SSA ? Étant donné que la plupart des compilateurs modernes (à commencer par LLVM) passent par une représentation intermédiaire en forme SSA, cet aspect-là de la compilation devrait être simple à traiter.

Logiquement, le compilateur sort en même que l'architecture, et les deux sont souvent conçus ensemble. Mais cela ne signifie pas pour autant que les compilateurs arrivent facilement à extraire du parallélisme d'instruction efficacement. Quand on voit que l'on arrive pas à utiliser correctement les instructions SIMD alors que ça fait depuis les années 60/70 que ces instructions existent…

Ensuite, l'organisation des "registres" en Belt ressemble très fortement à du SSA à quelques détails prêt : un graphe dataflow "applati" donne une belt de taille infinie. La taille finie de la Belt fait que ce n'est donc pas tout à fait un graphe Dataflow parfait, mais c'est tout de même assez simple de convertir un graphe dataflow en code pour une belt. On peut trouver des processeurs capables d’exécuter directement des graphes SSA : ce sont les architectures Dataflow, et c'est assez différent d'une Belt.

En fait, même les X86 contiennent des cœurs RISC, avec une intelligence indépendante pour découper les instructions CISC. L'intérêt n'est pas que lié à la facilité de faire un compilo, mais aussi à la simplicité des combinatoires. Des instructions plus simple, c'est moins de transistors, et donc moins d'échauffement, ce qui permet de baisser la conso chez ARM, où de monter en fréquence chez AMD. Le fait de gérer les instructions CISC à part simplifie beaucoup le cœur (ce qui permet donc de rajouter de la complexité ailleurs, sur la gestion des caches par exemple).