La chose vous aura peut-être échappé, pourtant l’enjeu est de taille : selon certaines sources (et commentaires), Intel pourrait (et il faut bien noter le conditionnel !) abandonner l’HyperThreading sur sa future gamme Arrow Lake, c’est-à-dire au second semestre 2024. Pour une technologie lancée en 2002 chez Intel sur la gamme Xeon, mais dont la paternité revient à IBM en 1968, le changement serait de taille ! Comment expliquer un tel changement de paradigme ? Qu’est-ce qui pourrait bien remplacer cet HyperThreading ? Hardware & Co vous fait le point.
Vous l’aurez remarqué au titre, cette brève est un article d’opinion. Il n’a ainsi pas que vocation à décoder le pourquoi et le comment de la naissance de la rumeur, mais également de prendre position quant à sa plausibilité, un exercice hautement subjectif. Sentez-vous donc libre d’en débattre en commentaire !
L’origine du crime, nous vous en causions il y a quelques jours à peine : une fuite provenant vraisemblablement du manuel d’une carte mère pré-alpha Arrow Lake. Partiellement effacée et contenant quelques typos (le lien DMI se transforme par exemple d’une gen 3 peu probable sur le diagramme en bloc à un gen4 plus logique sur le tableau de spécifications), il est cependant clairement écrit dans une note que les 8 P-Core sont désactivés par le BIOS du fait d’un problème hardware. Plus loin, la mention est faite de « 8+16+1, 8 IA Cores/8 threads (Disabled in BIOS), 16 Atom Cores, GT1, <contenu effacé> 125 W, Efficient Core: <re-contenu effacé>, 3,4 GHz Max ». Un charabia proche de certains rapports de la fondation SCP, mais qui peut être analysé en fonction deux interprétations différentes :
- Soit les 8 IA Cores/8 Threads sont une référence à un nouveau composant, typiquement un dérivé de l’Intel IA Boost intégré dans le Chipset Tile de Meteor Lake. Dans un souci d’homogénéisation des nomenclatures, cet accélérateur serait décomposé en cœurs/threads, permettant aux utilisateurs de repérer ces indicateurs de performances auxquels ils sont habitués. Ce serait loin d’être une première, Apple marketant par exemple une partie GPU à 8 cœurs lors du lancement de son Apple M1, un terme qui ne correspond ni aux cœurs CPU, ni aux cœurs GPU (CUDA de NVIDIA/SP chez AMD) pré-existant. Étant donné le peu de communication des bleus autour de la microarchitecture Lion Cove censé tenir place au cœur de ces Arrow Lake (alors que nous avions été abreuvé de précisions concernant Sunny Cove et Raptor Cove avant même leur sortie), nous penchons pour cette hypothèse, ce pourquoi nous ne relevions rien au sujet de l’HyperThreading dans notre brève précédente.
- Soit les IA Cores sont un renommage des P-Core (un changement de nom qui serait dans l’air du temps, il faut l’avouer), et passeraient de 2 à 1 thread par cœur, abandonnant de fait l’HyperThreading. Caramba ! Cette hypothèse est appuyée par la mention des 8 threads désactivés dans le BIOS, qui fait écho à la note indiquant que les P-Core sont désactivés via le BIOS.
L’extrait responsable de tout ce barda !
L’HyperThreading, mais pourquoi faire ?
Puisque la première hypothèse, plus simple, ne nous entraîne pas dans (trop) de débats architecturaux, immergeons-nous dans la seconde option : adios l’HyperThreading, et voyons les contraintes que cela entraîne. Initialement, l’hyperthreading part d’un constat simple : les cœurs des CPU sont majoritairement sous-utilisés, dans le sens que les processus qui y tournent ne sont pas capable d’utiliser l’intégralité du pipeline de calcul. Par exemple, un processus peut rester bloqué à cause d’un chargement mémoire depuis la RAM, ou n’effectuer que du calcul entier (laissant les unités flottantes libre), ou encore être perdus dans une suite de branchements conditionnels entraînant des blocages du fait de la méconnaissance des instructions suivantes à exécuter. La solution ? Mutualiser la majeure partie des composants du processeur pour y faire cohabiter deux processus, et toc ! On croise les doigts pour que cela mène à une utilisation plus efficace des ressources. Dans le cas où les deux processus utilisent la même ressource, chou blanc : il faut attendre patiemment son tour, et aucune accélération n’est au rendez-vous. Pire, deux processus doivent, à un moment, se causer afin de se synchroniser, ce qui prend du temps. Ainsi, selon la tâche, l’HyperThreading peut dégrader les performances, ce qui a entraîné à ses débuts sa désactivation dans divers domaines tel le jeu vidéo (qui faisait de toute manière peu usage de plusieurs cœurs à l’époque !).
Un P-Core Meteor Lake, c’est 12 voies permettant d’exécuter des calculs en parallèle, avec une limite « dure » de 5 voies actives par cycle. Pas facile de nourrir tout le monde avec un unique processus !
Cependant, les processeurs devenant de plus en plus complexes (et donc intégrant de plus en plus d’unités de traitement, capables de bosser en parallèle), l’HyperThreading a retrouvé ses lettres de noblesse. En effet, s’il est possible de trouver « facilement » un calcul et une opération mémoire à réaliser en parallèle dans un programme, en trouver respectivement 3 et 2 sera bien plus complexe du fait de la présence courante de dépendances entre les instructions. En un mot : plus le pipeline est large (= fourni en unités de calcul), plus il est difficile de l’exploiter avec un processus (et plus il est facile de mieux l’exploiter à 2 processus). Cela a mené à la règle empirique qu’un hyper-thread apporte environ 30 % de performances supplémentaire, une sous-performance qui s’explique en partie par le cache : les deux hyperthreads partagent le même cache L1 et L2 (privé par cœur !), ce qui est redoutablement efficace si les processus réutilisent les mêmes données… mais relativement inefficace dans le cas contraire ! Il a donc fallu un travail logiciel au niveau de l’ordonnanceur des OS afin d’éviter au maximum les contre-performances. Ainsi, avec l’émergence des E-Core dans lequel le maître mot est l’économie d’énergie, et où les caches sont partagés, l’HyperThreading n’a pas été retenu, similairement aux processeurs mobile Arm. Entre la performances plus faible de ces E-Core et le gain limité des hyperthreads, le marketing a eu tôt fait de tout grouper en vrac, et ainsi vendre des 8 P-Core + 16 E-Core comme des 32 threads tout courts, plutôt que des 2*8 + 16 threads… peu importe le manque de cohérence d'une telle appellation.
L’HyperThreading, mais pourquoi s’en débarrasser ?
Selon Intel, à la douce époque du Pentium 4, l’HyperThreading se traduisait par 5 % de consommation de surface en plus (essentiellement histoire de garder trace de quelle instruction correspond à quel thread, et de pouvoir décoder les instructions depuis deux processus différents) pour 30 % de performances supplémentaires. Bien que daté, aucun nouvel élément des CPU actuel ne vient bouleverser ces chiffres… alors pourquoi vouloir changer une recette qui fonctionne ? « Hé bien, on sait pas. C’est ça qui est terrible ! », comme dirait Jean-Pierre Coffe. Ou plutôt, nous n’avons que quelques pistes. D’une part, la proximité des hyperthreads met à mal le cloisonnement théorique entre processus, ce qui ouvre la porte à une palanquée d’attaques type Spectre/Meltdown, où un processus mal intentionné peut voler les données du second : pas top ! D’autre part, l’HyperThreading à 2 threads/cœur n’est pas forcément le plus efficace. La Gen11 des bleus (oui oui, l’architecture graphique) utilise par exemple 7 threads par unité de calcul, et les CPU POWER-9 de chez IBM offrent 4 cœurs logiques par cœur physique (jusque 8 sur certains modèles !) : selon l’utilisation, la recette magique n’est donc pas unique, mais doit pourtant être gravée en dur dans le processeur. De quoi donner quelques rides à notre HyperThreading ! De plus, certaines unités de calcul gagneraient à être partagées entre cœurs physiques, typiquement lorsqu’elles effectuent des opérations complexes — et donc coûteuses en énergie. En mutualisant, le CPU limite la chauffe et donc les baisses de fréquence, tout en diminuant la taille des cœurs… voilà qui tombe bien, des opérations matricielles devraient arriver avec les extensions AMX dans de futurs Xeon bleus ! Rajoutez également l’effondrement des fréquences des mêmes Xeon pros lors de l’utilisation continue d’instructions vectorielles, et vous comprenez que le partage d’unités, ça n'est pas dénudé d'intérêt, bien au contraire.
Quoi qu’on mettrait à la place ?
Vous l’avez peut-être vu venir, cette histoire de mutualisation rappelle sérieusement une micro-architecture de processeurs… Bulldozer, chez AMD (une micro -archi remplacée par Zen, qui fait usage… de l’HyperThreading, renommée SMT. C’est dire l’intérêt de la technologie !). Avant-gardistes, les rouges ! Dans cette version, deux modules se partageaient un front-end et une unité de calcul flottant, le marketing ayant, ici aussi, tôt fait de nommer ces modules "cœurs", ce qui... a entraîné une class-action aux États-Unis et une défaite de rouges, les modules n'étant pas véritablement des coeurs.
Chez les bleus, c’est un brevet déposé en juin dernier qui a mis la puce à l’oreille de nos confrères. À la fois très générale dans son application, mais très spécifique sur le matériel applicable (comme souvent pour les brevets !), il y est question d’une technique de répartition des tâches directement en hardware afin de choisir de manière efficace le cœur sur lequel exécuter les processus. Dans un premier temps, les instructions provenant de différent processus sont décodées par un « Instruction Processing Circuit », que ElChapuzasInformatico renomme « Renting Units », avant d’être redistribuées en « Compositable Task » et renvoyées à nos cœurs (P ou E) habituels. Au besoin, le brevet parle aussi d'un back-end FPGA, c'est dire à quel point l'applicabilité est vaste...
Les deux tâches 1 et 2 (300) sont recomposées en taches composées 1 et 2 (302) permettant un temps d’exécution plus rapide tout en conservant leur séquentialité.
Cela vous rappelle quelque chose ? Oui, c’est exactement ce que promettait NVIDIA avec l’arrivée du « Out-of-Order » sur Lovelace via son ordonnanceur intelligent. Une promesse qui s’est révélée bien plus difficile à utiliser en pratique, car imposant des contraintes strictes sur la programmation des processeurs réordonnables. Vous le voyez venir : le problème risque d’être le même sur CPU ! Avec Intel Thread Director, les bleus ont déjà de quoi remonter à l’ordonnanceur de l’OS (logiciel) des informations sur le placement conseillé des processus : en court-circuitant ce dernier et en passant par un ordonnanceur matériel, Intel pourrait éliminer la contrainte d’uniformité du jeu d’instruction, et proposer un CPU supportant l’AVX-512 et autres AMX sur les P-Cores seulement, laissant les E-Core en AVX, voire en SSE. Chouette ? Pas tout à fait. Un switch de contexte, c’est-à-dire un changement du processus exécuté par un thread est une opération coûteuse, qu’elle soit effectuée en logicielle comme en matérielle, et n’est pas sans conséquence sur les performances du processus une fois migré. Il faut notamment migrer le contenu des registres ; sans compter que les caches non partagés entrent, le cœur source et le cœur destinataire deviennent froids (c’est-à-dire qu’ils ne contiennent plus les données utiles, puisque le processus vient de bouger). Ainsi, l’exécution d’une Compositable Task se révélera in fine plus lente qu’un bon vieux processus rassemblant des instructions identiques, sans compter le surcoût du passage par la Renting Unit. Enfin, cela ne corrigerait pas tous les soucis de l’HyperThreading, puisque les instructions de plusieurs processus étant toujours possiblement mélangées… À y regarder de plus loin, l’idée se résume à exposer un unique cœur hyperthreadé selon n threads, puis ré-ordonnancer ces n threads sur les cœurs disponibles. Vous notez alors que rien n’interdit à ce n de valoir (au hasard) deux fois le nombre de cœurs physiques, et ta-daaaa, revoilà notre bon vielle HyperThreading à deux voix, toutefois étendu à plusieurs cœurs.
La conclusion
Historiquement, les communautés système et hardware ont toujours été deux mondes interdépendants, mais pourtant ne se comprenant pas l’un l’autre. Difficile de ne pas voir dans ce concept de tâches composées et d’ordonnanceur matériel autre chose que la volonté du matériel de coloniser le domaine système de la gestion des processus. Si, dans la théorie, le concept peut être porteur de gains importants en matière de performances, cela ne s’effectuera pas sans changements majeurs au sein des OS, voire des compilateurs ; ce qui n’a pas été observé dans les patchs de support d’Arrow Lake. De là, il semble peu probable qu’Intel mette aussi tôt son concept d’HyperThreading à la corbeille. Cependant, une révision micro-architecturale est bien au programme pour la prochaine génération, nous ne pouvons donc pas totalement écarter les prémisses d’un ordonnanceur matériel sur ces processeurs… Rendez-vous dans une grosse poignée de mois pour vérifier !
Il y a bien des "register files" (fichiers de registres) dans les coeurs, pour permettre le renommage à la volée des registres (évitant ainsi de coûteuses copies de registres à registre, ou le préchargement d'une seconde valeur dans un "même" registre alors qu'il est déjà en cours d'utilisation, sans pour autant multiplier les registres "visibles" par le programmeur/compilateur).
Alors, avec la multiplication des "coeurs" (ou plutôt des unités d'exécution: calculs entiers, vectoriels, matriciels, calculs d'adresse, etc), pourquoi ne pas implémenter le concept de "registres d'unités de calculs" ?... On pourrait imaginer pour une façade (front end) de 8 coeurs (virtuels, à part pour les unités du pipeline d'instructions qui seraient bien physiquement liées à chaque coeur), piocher dans les registres d'unités de calcul (communes à tous le coeurs) pour exécuter une micro-instruction donnée, en fonction des disponibilités. On aurait alors, par exemple, 16 unités de calcul entier, 16 de calcul d'adresse, 8 d'AVX, 4 d'AMX, etc).
Bien sûr, l'interconnexion de toutes ces unités à tous les coeurs, risque de donner un sacré mal de tête aux architectes de ces CPU...
Tout à fait, c'est la direction qui semble découler naturellement du brevet. Le souci, ce n'est pas que l'interconnexion entre unités de calculs (les GPU y arrivent par exemple, certes au prix de restrictions sur les performances et le modèle de calcul), mais surtout la hiérarchie de cache. Avec un modèle de threads mobiles et d'unités totalement partagées, la notion même de cache privé est remise en cause. Il faudrait un cache L1 capable de supporter un chargement de 8 vecteurs et 4 matrices en parallèle selon ton exemple pour être comparable aux perfs actuelles : compliqué sans exploser la complexité du bousin, même en imposants des conditions. Dans un i9 Raptor Lake, on cause de 2 unités AVX par P-Core + 1 par E-Core, donc 32 unités en tout : ca va en faire du monde à nourir !
En fait, cette notion de "registre d'unité de calcul" est déjà présente dans les CPU Out-of-Order avec le Reorder Buffer (ROB), qui sert à exposer du parallélisme entre instructions alors que le programme les exposes en séquence. C'est au scheduler du CPU de repartir au mieux sur les unités logiques d'un cœur, donnant l'illusion au programme d'une exécution dans l'ordre :-)... Et l'HyperThreading c'est justement déjà la solution pour les partager entre 2 processus !
Dans mon idée, les caches resteraient affectés aux "coeurs", en façade, liés aux pipelines d'instruction et de données, au cache de branchement, etc... Seules les unités de calcul (qui n'ont pas besoin de cache, puisqu'elles ne font que recevoir des données en provenance des registres ou des tampons du bus interne, et retourne le résultat à d'autres registres ou tampons) seraient mises en commun entre tous les coeurs.
Ah, je vois ! Effectivement, c'est plus raisonnable, mais effectivement le routage risque de poser souci, tout comme la gestion de la fréquence qui ne peut plus être indépendante par cœur... un vrai casse-tête !
Le Simultaneous MultiThreading (SMT), c'est le nom neutre, générique de la technique. L'HyperThreading, c'est la marque déposé par Intel sur sa techno.
Excellente vulgarisation de cette optimisation en tout cas 👍
Bizarre qu'ils s'assoient comme ça sur +30% quasi gratis.
Pour la sécurité, vu les nombreuses failles et vole de données qu'on ne cesse de découvrir, ça aurait du sens de la retirer sur des cœurs spécialisé sécu, à condition que les OS soient adapté pour aiguiller les tâches sensibles sur ces cœurs-là. Mais pour les perfs pures, ça serait bizarre de partir comme ça avec un tel handicap.
Merci 👍 je n'ai pas souhaité parler de SMT pour éviter l'overdose (déjà existante 😅) de termes techniques !
Je pencherai plus pour un mode sécurisé (un peu comme le mode virtualisé ou le SGX, mais en plus léger) pour exécuter les tâches critiques, mais avoir des coeurs dédiés est une autre possibilité.
Vous l'aviez dit pour AMD (les Zen), et du coup on avait un peu l'impression que c'était leur petit nom à eux, donné par les rouges. Mais non, IBM aussi utilisent cette terminologie, il me semble.
Un mode spécial, vu les brèches farfelue qu'ils arrivent à nous déniché (comme la dernière d'AMD, zenbleed, et son astuce d'optimisation détourner pour voler des données d'un processus étranger, même pas forcément SMT mais juste avant), je me dis qu'ils arriveront toujours à les contourner.
Non, pour régler le problème (du moins autant que faire se peut), faudrait vraiment des cœurs spécialisé, designé dès la base pour la sécurité, çàd sans SMT ni astuces d'ingénieurs pour optimiser les performances.
Les informations disent désactiver pas absent
Donc pour moi c'est désactivé pour tester et ça sera activé dans les version commerciale
Désactivé quoi? Le HT? Ou les P-Cores? Pour moi c'est pas claire et le doute est permis.
Seul les p core ont l ht donc que ce soit ht désactivé ou carrément p core dans les 2 cas elle est pas la