- Présentée à Hot Chips 2023, cette puce de recherche vise le traitement de données ultra-éparses de DARPA HIVE et offre un total de 528 threads matériels sur 8 cœurs
- L’analyse des charges de travail a montré une forte parallélisation, mais une utilisation des lignes de cache et une efficacité des longs pipelines out-of-order faibles, ce qui a nécessité une conception différente d’un CPU serveur classique
- Le processeur repose non pas sur x86 mais sur une ISA RISC, avec 66 threads par cœur et un pipeline multithread pour gérer une concurrence massive
- La communication inter-puces s’appuie sur une fabric optique directe mesh-to-mesh basée sur la photonique sur silicium, permettant une communication directe même avec des cœurs situés hors du châssis, sans switch ni NIC
- L’implémentation est un CPU 8 cœurs 75 W en TSMC 7 nm et, plus de la moitié de la puissance étant consacrée aux liaisons optiques, il s’agit encore d’une conception expérimentale au stade du laboratoire
Un CPU de 528 threads pensé pour DARPA HIVE
- À Hot Chips 2023, Intel a présenté, en parallèle de ses puces serveur classiques, une technologie de direct mesh-to-mesh optical fabric
- L’objectif central de la conception est le traitement de données ultra-éparses requis par le programme DARPA HIVE
- Le profilage des charges de travail par Intel a révélé des caractéristiques peu compatibles avec une conception CPU générale
- Une parallélisation massive existe
- L’utilisation des lignes de cache est faible
- Les longs pipelines out-of-order ne sont pas exploités efficacement
- En réponse, le processeur a été conçu autour d’une configuration en socket à 8 cœurs
- 66 threads matériels par cœur
- 528 threads au total
- ISA RISC plutôt que x86
- Chaque cœur utilise un pipeline multithread
Relier directement les puces grâce à la photonique sur silicium
- Cette puce utilise une configuration plaçant 16 sockets dans un unique plateau de calcul OCP et les reliant par un réseau optique
- Une puce d’E/S haut débit assure l’interface entre signaux électriques et fonctions optiques
- Des routeurs sont placés sur le réseau on-die, et parmi les 16 routeurs, la moitié a pour rôle de fournir davantage de bande passante aux E/S haut débit
- EMIB est utilisé pour la couche de liaison physique à l’intérieur du package
- Pour les liaisons off-die, chaque puce pilote un réseau optique via la photonique sur silicium
- Les connexions entre cœurs peuvent se faire directement d’une puce à l’autre
- La connexion reste possible sans switch ni NIC, même hors d’un même châssis
- L’ensemble de la puce est constitué d’un package multi-puce basé sur EMIB
- L’intégration du moteur de photonique sur silicium ajoute des défis supplémentaires à la jonction entre le package et les brins de fibre optique
- Côté consommation, l’implémentation correspond à un CPU 8 cœurs 75 W, dont plus de la moitié de la puissance est absorbée par la photonique sur silicium
- Une photo réelle du die a confirmé l’usage du procédé TSMC 7 nm, et les travaux se poursuivent en laboratoire
- La partie des liaisons optiques a bénéficié de l’aide d’Ayar Labs
- Le connecteur enfichable présenté par Intel à Innovation 2022 n’a pas été utilisé dans cette implémentation
1 commentaires
Avis de Hacker News
Avec 66 threads par cœur, cela ressemble plus à un processeur barrel qu’à autre chose.
Il est difficile de s’attendre à ce que chaque thread soit rapide, mais si le processeur a suffisamment de travail, on peut penser qu’il pourra effectuer une tâche utile la plupart du temps au lieu d’attendre la mémoire.
La principale faiblesse des processeurs barrel se situe du côté humain. Très peu de gens savent concevoir du code qui en exploite correctement le potentiel. Le code généraliste tourne à peu près, donc au niveau du code cela paraît familier, mais les performances ne sont bonnes que si l’on écrit d’une manière très étrange pour quelqu’un qui n’a écrit que du code pour CPU.
C’est une architecture particulière pour concevoir des structures de données et des algorithmes, et il n’existe pas beaucoup de littérature sur la conception d’algorithmes pour processeurs barrel.
J’ai conçu du code pour plusieurs architectures de processeurs barrel depuis les anciens systèmes Tera, et je suis devenu assez bon dans ce domaine ; je pense que, lorsqu’ils sont utilisés par quelqu’un qui s’y connaît vraiment, ils peuvent offrir une efficacité de calcul supérieure à presque toutes les architectures pour le calcul généraliste à budget silicium comparable.
Cela dit, pour écrire du code efficace, il faut garder en tête un modèle beaucoup plus complexe que pour un code équivalent sur CPU. L’économie favorise les architectures de type CPU, où un ingénieur moyen peut aussi obtenir une efficacité correcte.
Malgré leurs avantages en matière d’efficacité de calcul pure, j’ai désormais renoncé à l’idée que nous verrons des processeurs barrel devenir grand public.
Cette partie du cœur ressemble beaucoup aux GPU existants.
Ce qui est différent dans ce CPU expérimental d’Intel, c’est qu’en plus de la partie de type GPU, chaque cœur inclut aussi 2 threads très rapides. Ces deux-là exécutent les instructions dans le désordre, fonctionnent à une fréquence bien plus élevée que les threads lents et disposent chacun d’unités d’exécution non partagées.
Les 2 threads rapides et les 64 threads lents, pris séparément, ressemblent à d’anciens CPU ou GPU, mais la nouveauté est de les combiner dans un seul cœur doté d’une mémoire scratchpad et d’un cache partagés.
https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&d...
Je parierais que le projet DARPA qui a financé cette recherche relève de la même lignée d’intérêt pour cet acronyme en trois lettres qui a permis à Tera de recevoir assez d’argent pour racheter Cray.
Si l’on remplace « attendre la mémoire » par « attendre les entrées-sorties », on obtient presque le même tableau.
Pendant qu’un fetch lent a lieu, le système peut exécuter davantage d’instructions d’autres threads en parallèle.
Marvell a conçu un CPU ARM SMT8 mettant en avant 768 threads par nœud.
https://www.servethehome.com/marvell-thunderx3-arm-server-cp...
Si je me souviens bien, il visait les charges de travail de bases de données, et la logique de fond était la même : si un cœur passe généralement son temps à attendre la RAM, autant traiter un autre thread entre-temps.
IBM et Zen4C répondent en partie à ce besoin, mais j’aimerais voir davantage d’instances cloud SMT16 visant explicitement ce type de charges de travail à faible débit d’instructions.
Pour ce type de conception façon processeur barrel, CMT8/SMT8 semble être un bon compromis.
L’idée semble être que, si l’on peut amortir le coût en surface de die et la perte de vitesse liés à la conversion des signaux électriques en signaux optiques, on peut obtenir, avec des interconnexions optiques, une vitesse pratiquement indépendante de la distance avec une bonne efficacité.
Bien sûr, ce ne sera pas totalement le cas, mais si l’on se limite aux distances entre supports de puces dans un même châssis, il y a peu d’interférences et le routage est aussi libre que le permet le rayon de courbure des guides optiques.
J’ai peut-être mal lu. Les composants optiques peuvent aussi servir à un autre objectif, comme l’empilement de dies, ou bien il peut s’agir de créer une grille de puces sur un super-support et de les relier par interconnexions optiques.
Des photos réelles du die et la confirmation que c’est fabriqué en 7 nm chez TSMC : pour Intel, c’est une scène assez douloureuse
Si l’entreprise doit utiliser la fab d’un concurrent pour ce genre de chose, c’est probablement un moment assez bas pour un fabricant de puces
Cela dit, le nœud 10 nm a été une catastrophe pour Intel et a fait prendre à l’entreprise 5 à 10 ans de retard dans la fabrication de puces
Pour un projet de recherche, on imagine facilement qu’ils préfèrent TSMC
Cela explique pourquoi ces objets atypiques partent chez TSMC. Par exemple, Silicon Photonics lui-même se fait à Albuquerque, un site qui était en train de dépérir
En cherchant sur Google avec une période limitée à 2001–2010, on peut trouver des articles à ce sujet
Il doit bien y avoir une raison pour laquelle les utilisateurs de HN connaissent si mal les semi-conducteurs. Sans doute parce que le lectorat est surtout côté logiciel. Sur ce site, c’est probablement le domaine où le rapport confiance/qualité des explications est le plus élevé
AMD a fait la même chose lorsqu’elle a abandonné GlobalFoundries, et on peut aussi considérer que c’est l’une des principales raisons pour lesquelles elle a dépassé Intel
De toute façon, tout le monde utilise les équipements de lithographie d’ASML, donc qui met les wafers dans la machine est relativement secondaire
Cela ressemble davantage à un CPU de preuve de concept qu’à un produit vendable
Il est très spécialisé, et il reste encore à trouver les problèmes et les charges de travail qu’il permettra de résoudre
Je m’attends à ce que les photons arrivent aussi dans le calcul généraliste à l’avenir. Ne serait-ce que pour gérer le problème croissant de chaleur excédentaire. Ce qui est particulièrement frappant ici, c’est le passage d’un procédé 10 nm à 7 nm
Sun avait fait quelque chose de similaire il y a longtemps, mais l’a ensuite abandonné dans les CPU UltraSPARC
Les threads étaient-ils affamés ? Ont-ils jugé préférable de réduire le nombre de cœurs et de les rendre plus rapides ? Il est difficile de trouver des détails
Ce serait bien que bcantrill, sur HN, nous donne le contexte interne
Pour obtenir de bonnes performances, il fallait souvent ajuster beaucoup plus de paramètres ou recompiler
Pour moi, cela a aussi coïncidé avec une période où le besoin d’utiliser SSL augmentait fortement : SSL était bien optimisé pour x86, mais pas pour Sparc. Il fallait donc gérer toute la complexité supplémentaire des cartes d’offload SSL ou des reverse proxies
Au final, en dehors de quelques niches, il était trop difficile de le faire bien fonctionner
Ce n’était peut-être pas un facteur majeur, mais c’était aussi pénible du point de vue des administrateurs système. Une grande partie de nos tâches était séquentielle et centrée sur un seul cœur. Autrement dit, il montrait son pire visage précisément au groupe qui valide généralement les achats fournisseurs
Cela semble parfait pour la réduction de graphes et la programmation par flux de données
Si ça arrive réellement en production, on pourrait construire des choses assez impressionnantes avec ce type de matériel
528 threads pour 8 cœurs, comment le calcul tombe-t-il ? J’ai d’abord pensé à 512 avant de relire
En raison de la charge de travail, le cache ne semble pas très bien exploité, et ce n’est pas du x86 mais un jeu d’instructions RISC
Ici, 2 correspond au nombre de threads lents comme sur les CPU actuels, et 64 se rapproche davantage de threads GPU
Cette architecture pourrait être la prochaine étape de l’intégration GPU. Espérons qu’ils écriront de bonnes implémentations efficaces des bibliothèques mathématiques standard. Cela pourrait être plus rapide qu’un CPU+GPU séparés dans un même package
Pourquoi 66, ce n’est pas expliqué
Il est temps d’en finir avec la réécriture de tout le code en événementiel, avec io_uring, etc.
Le Tera MTA mentionné par d’autres avait, ou a, pour cela une synchronisation matérielle dans le système mémoire
Il n’y avait pas d’interruptions, seulement des threads en attente que quelqu’un les réveille
Ai-je bien lu l’article ? Cela veut-il dire qu’il y a 32 Go de DRAM sur la puce, ou bien qu’ils utilisent simplement des DIMM standard ?
Ce qui est intéressant, c’est qu’ils utilisent des DIMM personnalisés et un contrôleur mémoire permettant des accès par blocs de 8 octets. En plus, comme on le voit sur la photo du die, chaque cœur a son propre contrôleur mémoire
Si chaque contrôleur mémoire gère 4 Go de DRAM, cela explique les 32 Go par puce
Il existe aussi des ressources qui l’expliquent plus en détail, et Nvidia semble faire cela avec Grace Hopper, tandis qu’Apple fait quelque chose de similaire avec les puces série M
Mise à jour : dans ce cas, il semble que ce soit simplement de la DDR5, plus précisément de la « custom DDR5-4400 DRAM »