Dans le passé, il existait un système appelé hyperthreading, qui permettait à un seul cœur de processeur de se comporter comme deux cœurs.
Mais est-il possible de fusionner deux cœurs de processeur en un seul pour améliorer les performances des programmes qui n'utilisent pas décemment plusieurs cœurs ? (des vieux jeux au X Plane 11)
Réponse courte : Non.
Réponse un peu plus longue : Les cœurs d'une puce multicœur sont en fait des processeurs physiques distincts. L'Hyperthreading vous permet de diviser un cœur physique en deux threads, par exemple. L'avantage est que le cœur unique peut échanger entre les threads de sorte que lorsqu'un thread est en attente (pour les E/S, par exemple), l'autre thread peut être repris. Deux threads sur un noyau hyperthreadé partagent les ressources, ce qui permet un changement de contexte très efficace entre les threads.
Alors pourquoi ne pouvez-vous pas faire le contraire ? Eh bien, imaginez un peu. Vous avez deux cœurs physiques mais un seul processus. Il y a deux scénarios possibles :
Le code d'exécution peut être exécuté en parallèle. Dans ce cas, il suffit d'avoir deux threads, un pour chaque cœur. De cette façon, les deux threads peuvent fonctionner en même temps.
Le code en cours d'exécution ne peut pas être exécuté en parallèle. C'est ce que vous voulez savoir. Dans ce cas, vous avez un seul thread. Comme le code ne peut pas être exécuté en parallèle, vous ne pouvez pas l'exécuter sur deux processeurs distincts en même temps. Pour exécuter un seul thread sur les deux cœurs, il vous suffirait de basculer le thread entre les deux cœurs. Cela n'apporterait aucun gain de performance, et en fait, cela nuirait aux performances en raison des commutations de contexte inutiles.
Il s'agit d'un inconvénient malheureux des systèmes multicœurs ; vous ne constatez un gain de performance que lorsque l'application peut effectuer plusieurs tâches en parallèle et qu'elle est écrite pour le faire. Même dans ce cas, le gain n'est pas directement proportionnel au nombre de cœurs (cf. La loi d'Amdahl ).
Non, pas vraiment.
Il faudrait paralléliser les instructions de quelque manière que ce soit et beaucoup d'entre elles dépendent des résultats d'autres instructions [1]. En outre, l'unité arithmétique (le cerveau, qui calcule réellement) n'est généralement pas le goulot d'étranglement.
Pour accéder aux données et les calculer, il faut les stocker. Pour que cela soit rapide, il existe plusieurs couches de mémoire (registres, cache (niveau 1, 2, 3), RAM). Deux cœurs (dans un processeur x86) ne partagent généralement que la RAM (et peut-être un cache L3). Vous ne pouvez donc pas simplement diviser un programme, car l'autre moitié aurait les données dont elle a besoin.
L'hyperthreading profite du temps, l'unité de calcul attend autre chose.
Le chargement d'une valeur à partir de la RAM, par exemple, prend beaucoup de temps (environ 500 cycles de CPU). Pendant ce temps, alors que l'unité arithmétique ne ferait normalement rien, l'Hyperthreading exécute le second processus sur le même cœur.
[C'est également sur ce point que l'exécution spéculative tente d'intervenir. Et peut-être créer quelques failles de sécurité (Spectre et Meltdown).
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
