Multithreading (architecture informatique)

Dans l'architecture informatique , le multithreading est la capacité d'une unité centrale de traitement (CPU) (ou d'un seul cœur dans un processeur multicœur ) à fournir plusieurs threads d'exécution .

Le paradigme du multithreading est devenu plus populaire à mesure que les efforts visant à exploiter davantage le parallélisme au niveau des instructions ont stagné depuis la fin des années 1990. Cela a permis au concept de calcul de débit de réapparaître dans le domaine plus spécialisé du traitement des transactions . Même s'il est très difficile d'accélérer davantage un seul thread ou un seul programme, la plupart des systèmes informatiques effectuent en fait plusieurs tâches en même temps. Ainsi, les techniques qui améliorent le débit de toutes les tâches entraînent des gains de performances globaux.

Les deux principales techniques de calcul de débit sont le multithreading et le multitraitement .

Si un thread reçoit beaucoup d' échecs de cache , les autres threads peuvent continuer à tirer parti des ressources informatiques inutilisées, ce qui peut conduire à une exécution globale plus rapide, car ces ressources auraient été inactives si un seul thread avait été exécuté. De plus, si un thread ne peut pas utiliser toutes les ressources informatiques du processeur (car les instructions dépendent du résultat de l'autre), l'exécution d'un autre thread peut empêcher ces ressources de devenir inactives.

Plusieurs threads peuvent interférer entre eux lorsqu'ils partagent des ressources matérielles telles que des caches ou des tampons de traduction (TLB). Par conséquent, les temps d'exécution d'un seul thread ne sont pas améliorés et peuvent être dégradés, même lorsqu'un seul thread est en cours d'exécution, en raison de fréquences plus basses ou d'étapes de pipeline supplémentaires nécessaires pour prendre en charge le matériel de commutation de threads.

L'efficacité globale varie ; Intel revendique jusqu'à 30 % d'amélioration avec sa technologie Hyper-Threading , tandis qu'un programme synthétique effectuant simplement une boucle d'opérations à virgule flottante dépendantes non optimisées obtient en réalité une amélioration de vitesse de 100 % lorsqu'il est exécuté en parallèle. D'un autre côté, les programmes en langage assembleur réglés manuellement à l'aide des extensions MMX ou AltiVec et effectuant des pré-extractions de données (comme le ferait un bon encodeur vidéo) ne souffrent pas de ratés de cache ou de ressources informatiques inactives. De tels programmes ne bénéficient donc pas du multithreading matériel et peuvent en effet voir leurs performances dégradées en raison de la contention des ressources partagées.

Du point de vue logiciel, la prise en charge matérielle du multithreading est plus visible pour les logiciels, nécessitant davantage de modifications des programmes d'application et des systèmes d'exploitation que le multitraitement. Les techniques matérielles utilisées pour prendre en charge le multithreading sont souvent parallèles aux techniques logicielles utilisées pour le multitâche informatique . La planification des threads est également un problème majeur du multithreading.

La fusion de données provenant de deux processus peut souvent entraîner des coûts nettement plus élevés que le traitement des mêmes données sur un seul thread, potentiellement de deux ordres de grandeur ou plus en raison de frais généraux tels que la communication interprocessus et la synchronisation.

Le type de multithreading le plus simple se produit lorsqu'un thread s'exécute jusqu'à ce qu'il soit bloqué par un événement qui, normalement, créerait un blocage à longue latence. Un tel blocage peut être dû à un échec de cache qui doit accéder à la mémoire hors puce, ce qui peut prendre des centaines de cycles CPU pour que les données soient renvoyées. Au lieu d'attendre que le blocage soit résolu, un processeur à threads bascule l'exécution vers un autre thread prêt à s'exécuter. Ce n'est que lorsque les données du thread précédent sont arrivées que le thread précédent est replacé dans la liste des threads prêts à s'exécuter .

Par exemple:

1. Cycle i : l'instruction j du thread A est émise.
2. Cycle i + 1 : l'instruction j + 1 du thread A est émise.
3. Cycle i + 2 : l'instruction j + 2 du thread A est émise, ce qui est une instruction de chargement qui manque dans tous les caches.
4. Cycle i + 3 : planificateur de thread invoqué, bascule vers le thread B.
5. Cycle i + 4 : l'instruction k du thread B est émise.
6. Cycle i + 5 : l'instruction k + 1 du thread B est émise.

Sur le plan conceptuel, il est similaire au multitâche coopératif utilisé dans les systèmes d'exploitation en temps réel , dans lesquels les tâches abandonnent volontairement du temps d'exécution lorsqu'elles doivent attendre un certain type d'événement. Ce type de multithreading est connu sous le nom de multithreading par blocs, coopératif ou à gros grain.

L'objectif de la prise en charge matérielle du multithreading est de permettre une commutation rapide entre un thread bloqué et un autre thread prêt à s'exécuter. Le passage d'un thread à un autre signifie que le matériel passe d'un ensemble de registres à un autre. Pour atteindre cet objectif, le matériel des registres visibles du programme, ainsi que certains registres de contrôle du processeur (tels que le compteur de programme), sont répliqués. Par exemple, pour basculer rapidement entre deux threads, le processeur est construit avec deux ensembles de registres.

La prise en charge matérielle supplémentaire du multithreading permet de changer de thread en un seul cycle CPU, ce qui améliore les performances. De plus, le matériel supplémentaire permet à chaque thread de se comporter comme s'il s'exécutait seul et ne partageait aucune ressource matérielle avec d'autres threads, ce qui minimise la quantité de modifications logicielles nécessaires au sein de l'application et du système d'exploitation pour prendre en charge le multithreading.

De nombreuses familles de microcontrôleurs et de processeurs embarqués disposent de plusieurs banques de registres pour permettre un changement rapide de contexte pour les interruptions. De tels schémas peuvent être considérés comme un type de multithreading de blocs entre le thread du programme utilisateur et les threads d'interruption.

L'objectif du multithreading à granularité fine est de supprimer tous les blocages de dépendance de données du pipeline d'exécution . Étant donné qu'un thread est relativement indépendant des autres threads, il y a moins de chances qu'une instruction d'une étape de pipeline ait besoin d'une sortie d'une instruction plus ancienne du pipeline. Sur le plan conceptuel, il est similaire au multitâche préemptif utilisé dans les systèmes d'exploitation ; une analogie serait que la tranche de temps donnée à chaque thread actif correspond à un cycle CPU.

Par exemple:

1. Cycle i + 1 : une instruction du thread B est émise.
2. Cycle i + 2 : une instruction du thread C est émise.

Ce type de multithreading a d'abord été appelé traitement par barils, dans lequel les portées d'un baril représentent les étapes du pipeline et leurs threads d'exécution. Le multithreading entrelacé, préemptif, à granularité fine ou à tranches de temps sont des terminologies plus modernes.

Outre les coûts matériels évoqués dans le type de bloc du multithreading, le multithreading entrelacé a un coût supplémentaire lié au suivi par chaque étape du pipeline de l'ID de thread de l'instruction qu'il traite. De plus, comme il y a davantage de threads exécutés simultanément dans le pipeline, les ressources partagées telles que les caches et les TLB doivent être plus volumineuses pour éviter les échanges entre les différents threads.

Le type de multithreading le plus avancé s'applique aux processeurs superscalaires . Alors qu'un processeur superscalaire normal émet plusieurs instructions à partir d'un seul thread à chaque cycle CPU, dans le multithreading simultané (SMT), un processeur superscalaire peut émettre des instructions à partir de plusieurs threads à chaque cycle CPU. Reconnaissant que chaque thread unique a une quantité limitée de parallélisme au niveau des instructions , ce type de multithreading tente d'exploiter le parallélisme disponible sur plusieurs threads pour réduire le gaspillage associé aux emplacements d'émission inutilisés.

Par exemple:

1. Cycle i : les instructions j et j + 1 du thread A et l'instruction k du thread B sont émises simultanément.
2. Cycle i + 1 : l'instruction j + 2 du thread A , l'instruction k + 1 du thread B et l'instruction m du thread C sont toutes émises simultanément.
3. Cycle i + 2 : l'instruction j + 3 du thread A et les instructions m + 1 et m + 2 du thread C sont toutes émises simultanément.

Pour distinguer les autres types de multithreading du SMT, le terme « multithreading temporel » est utilisé pour désigner le cas où les instructions d'un seul thread peuvent être émises à la fois.

En plus des coûts matériels évoqués pour le multithreading entrelacé, le SMT entraîne un coût supplémentaire : chaque étape du pipeline suit l'ID de thread de chaque instruction en cours de traitement. Là encore, les ressources partagées telles que les caches et les TLB doivent être dimensionnées pour le grand nombre de threads actifs en cours de traitement.

Les implémentations incluent DEC (plus tard Compaq ) EV8 (non terminé), la technologie Intel Hyper-Threading , IBM POWER5 / POWER6 / POWER7 / POWER8 / POWER9 , IBM z13 / z14 / z15 , Sun Microsystems UltraSPARC T2 , Cray XMT et les microarchitectures AMD Bulldozer et Zen .

Un domaine de recherche majeur est le planificateur de threads qui doit rapidement choisir parmi la liste des threads prêts à être exécutés, ainsi que maintenir les listes de threads prêts à être exécutés et bloqués. Un sous-thème important concerne les différents schémas de priorité des threads qui peuvent être utilisés par le planificateur. Le planificateur de threads peut être implémenté entièrement dans le logiciel, entièrement dans le matériel ou sous la forme d'une combinaison matériel/logiciel.

Un autre domaine de recherche concerne le type d'événements qui devraient provoquer un changement de thread : échecs de cache, communication inter-thread, achèvement DMA , etc.

Si le schéma multithread réplique l'intégralité de l'état visible par le logiciel, y compris les registres de contrôle privilégiés et les TLB, il permet de créer des machines virtuelles pour chaque thread. Chaque thread peut ainsi exécuter son propre système d'exploitation sur le même processeur. En revanche, si seul l'état en mode utilisateur est enregistré, moins de matériel est nécessaire, ce qui permettrait à davantage de threads d'être actifs simultanément pour la même surface de puce ou le même coût.