Licence CC BY

Des cœurs fantômes dans vos processeurs

Ou comment le SMT (a.k.a HT) vous vends bien plus de puissance qu'exploitable en réalité

Dernière mise à jour :
Auteur :
Catégories :
Temps de lecture estimé : 2 minutes

Beaucoup de processeurs d’ordinateur grand public modernes utilisent le simultaneous multithreading (SMT), une technologie qui date des années 1960 mais qui est apparue dans les processeurs grand public fin 2002, avec le Pentium 4 HT à 3.06 GHz. En simplifiant, elle permet à un cœur d’exécution du processeur de traiter simultanément plusieurs (2 dans les implémentations grand public) programmes en parallèle. Intel a appelé son implémentation cette technologie « HyperThreading ».

Donc si votre processeur affiche « 2 cœurs / 4 threads », votre système d’exploitation va voir 4 processeurs, alors que le processeur ne possède réellement que 2 cœurs d’exécution.

Et on arrive à la grande question :

Quelle est la performance réelle de ce processeur ? (nonobstant les effets de changements de fréquence dus à la différence de charge).

« 4 fois la performance d’un cœur seul », pensera sans doute le lecteur peu averti.

Et c’est là le drame :

Le gain en performances du SMT est de… 0 à 40 %, avec un gain moyen de 25 % (+22,5 % chez Intel, +28 % chez AMD).

Toujours en ignorant les variations de fréquence et autres effets de bord, voici la conversion en cœurs équivalents réels de la performance de différents processeurs « grand public » actuels. La performance idéale serait celle d’un SMT efficace à +100 %, et donc la puissance perçue par l’acheteur moyen. Les cœurs « perdus » sont l’équivalent des cœurs visibles par l’OS mais qui n’apportent rien en terme de performances réelle, comme s’ils n’étaient pas là mais que tous les processeurs virtuels étaient efficaces à 100 %.

Cœurs Threads Idéale Min Moyenne (Intel/AMD) Max Cœurs « perdus » Modèles
2 2 2 2 2,0/- 2,0 0,0/- Pentium (sauf doutes dernières séries), Celeron
2 4 4 2 2,4/- 2,8 1,6/- Pentium (toutes dernières séries), Core i3, Core i5 et Core i7 basse consommation
4 4 4 4 4,0/4,0 4,0 0,0/0,0 Certains Celeron, Core i5, Ryzen 3
4 8 8 4 4,9/5,1 5,6 3,1/2,9 Core i7, Ryzen 5 1400/1500X
6 12 12 6 7,3/7,7 8,4 4,7/4,3 Core i7, Ryzen 5 1600/1600X
8 16 16 8 9,8/10,2 11,2 6,2/5,8 Core i7 Extreme Edition, Ryzen 7, Threadripper 1900X
10 20 20 10 12,2/- 14 7,8/- Core i7 Extreme Edition
12 24 24 12 -/15,4 16,8 -/8,6 Threadripper 1920X
16 32 32 16 -/20,5 22,4 -/11,5 Threadripper 1950X

En prime, ce tableau nous montre que la gamme « Core i7 » d’Intel contient des processeurs qui n’ont absolument rien à voir les uns avec les autres, si ce n’est qu’ils sont tous très chers !

Ajoutons à ça qu’en réalité :

  • Une application ne tirera pas toujours partie correctement des cœurs supplémentaires – même si c’est de moins en mois le cas, les jeux en particuliers sont maintenant capables d’utiliser bien plus de 1 ou 2 cœurs.
  • Plus il y a de cœurs chargés, plus la fréquence du processeur baisse (selon des métriques assez complexes, surtout sur un PC portable où ça dépend beaucoup de la qualité du système de refroidissement).
  • Selon les applications, ajouter un cœur supplémentaire, même s’il est utilisé à 100 % lui aussi, ne va pas forcément faire l’équivalent de +1 cœur en terme de performances. C’est la notion de « scalabilité », je sais que Hardware.fr avait fait un test là-dessus mais je ne retrouve plus de lien.
  • Il existe des cas pathologiques dans lesquels le fait d’avoir le SMT activé diminue les performances d’un programme.

Si vous manquez de puissance, attention avant d’acheter un nouveau processeur, peut-être qu’il ne vous servira à rien. En particulier, passer de X cœurs sans SMT à X cœurs avec SMT n’apportera probablement pas grand-chose.



11 commentaires

Je ne vois pas en quoi cela est surprenant comme résultat. Le grand public n’y voit certes que du feu niveau communication, mais ça se saurait si un cœur logique et physique ce serait pareil (dans ce cas les cœurs ne seraient que logiques car ils sont plus simples).

Après niveau gain, je trouve les benchmarks mal fait. Et ton interprétation également. Des applications massivement parallèles (qui exploitent donc plusieurs cœurs physiques ou logiques) tu en as pas tant que cela. D’ailleurs on le voit que le gain dépend fortement de l’application considérée.

Le gain est sans doute plus pertinent si on considère le système dans son ensemble, avec beaucoup de tâches en parallèle de manière intensive ou pas par ailleurs. Cela est certes complexe à mesurer mais cela représenterait plus le gain réel d’une telle solution que de partir sur le cas d’usage d’une application unique qui doit faire chauffer le processeur tout eul (ce qui est un cas d’usage assez limité des machines d’aujourd’hui).

Amateur de Logiciel Libre et de la distribution GNU/Linux Fedora.

+0 -0

Crois-moi, d’expérience, la différence entre cœur physique et logique est loin d’être aussi évidente pour tout le monde – y compris pour des gens qui bossent dans l’informatique et qui le font bien – que pour toi.

Des applications massivement parallèles (qui exploitent donc plusieurs cœurs physiques ou logiques) tu en as pas tant que cela.

Ben, de plus en plus. Ça va du développement (coucou Android) à pas mal de jeux modernes, pour rester dans les domaines que je maitrise.

Quant à ton troisième cas d’usage, il ne correspond pas à mon point, qui est que justement quant ton application est CPU-limited, les performances réellement gagnées en changeant de processeur peuvent décevoir. Et c’est un vrai cas d’application, aujourd’hui dans mon nouveau boulot par exemple.


PS : Le fait que les applications modernes arrivent de mieux en mieux à tirer partie du parallélisme se vérifie bien en allant voir les tests détaillés : certaines applications ont une performance fortement corrélée au nombre de cœurs, à fréquence égale. D’autres plafonnent arrivées à un certain nombre de cœurs.

Bien évidemment, c’est des tests CPU, donc ce qui est intéressant c’est de vérifier les cas où tu as besoin d’un CPU de manière intensive. Si ton besoin c’est de naviguer sur Internet et de mater des vidéos, tu n’auras jamais besoin de beaucoup de puissance CPU, ou alors ponctuellement sur un petit nombre de cœurs. Ce qui te mets donc hors cas d’usage des tests que je présente et de ma conclusion sur le SMT.

Édité par SpaceFox

Des sources exactes, non, mais je sais que c’est un sujet débattu depuis longtemps et assez peu testé en conditions réelles. De mémoire, on trouve d’autres sources sur les articles qui traitent du SMT et/ou de l’HyperTreading sur Wikipedia (EN au moins).

Édité par SpaceFox

Ben, de plus en plus. Ça va du développement (coucou Android) à pas mal de jeux modernes, pour rester dans les domaines que je maitrise.

C’est sûr que cela va dans ce sens, mais beaucoup ne le sont pas encore (et ne le seront probablement jamais, faute de réel besoin).

Quant à ton troisième cas d’usage, il ne correspond pas à mon point, qui est que justement quant ton application est CPU-limited, les performances réellement gagnées en changeant de processeur peuvent décevoir. Et c’est un vrai cas d’application, aujourd’hui dans mon nouveau boulot par exemple.

Je ne dis pas que cela n’arrive jamais, en fait ton article n’insiste pas vraiment sur le but. Ça explique le problème, mais pas pourquoi tu t’intéresses à ces données telles qu’elles. Car en effet suivant le besoin, tu ne testes pas de la même façon.

Mais s’intéresser justement au cas du système global n’est pas idiot je pense. Ce n’est pas rare de voir quelqu’un jouer avec un navigateur ouvert, un logiciel de discussion voire de streaming en même temps. Cela demande une certaine souplesse du CPU pour que cela reste fluide. Et quand je compile en étant sur le Web et de la vidéo en fond, c’est agréable aussi. :D

Après c’est sûr, pour ma grand mère, ce ne sera pas très pertinent. De toute façon tu n’as pas besoin d’un gros CPU non plus pour ce cas d’usage.

Amateur de Logiciel Libre et de la distribution GNU/Linux Fedora.

+0 -0

Ça reste un billet, pas un article. J’ai écrit ça sur un coin de table parce que j’avais fait le tableau pour le montrer à quelqu’un et que je me suis dit que ce serait intéressant de le partager… donc non, je n’insiste sur aucun but, je n’explique pas pourquoi je m’intéresse à quoi que ce soit.

Quant à tester du multi-tâches avec des tâches lourdes (ce que n’est pas la lecture vidéo : aujourd’hui si elle n’est pas accélérée par le matériel, c’est que ton ordi est mal configuré ou que ton format de vidéo est exotique – lire une vidéo consomme moins que la navigation web sur des sites un peu chargés) l’un des principaux problèmes consiste à avoir un protocole expérimental un minimum crédible et reproductible.

J’ai écrit ça sur un coin de table parce que j’avais fait le tableau pour le montrer à quelqu’un et que je me suis dit que ce serait intéressant de le partager… donc non, je n’insiste sur aucun but, je n’explique pas pourquoi je m’intéresse à quoi que ce soit.

Pas de soucis. ;)

ce que n’est pas la lecture vidéo : aujourd’hui si elle n’est pas accélérée par le matériel, c’est que ton ordi est mal configuré ou que ton format de vidéo est exotique – lire une vidéo consomme moins que la navigation web sur des sites un peu chargés

Dans le cadre de processeurs modernes, en effet ça ne l’est pas, mais des processeurs qui ont quelques années seulement ne sont pas capables de gérer des formats tels que H265, VP8 ou VP9 (sans parler de formats plus exotiques encore) ce qui a un impact bien entendu.

l’un des principaux problèmes consiste à avoir un protocole expérimental un minimum crédible et reproductible.

C’est tout le problème des tests en fait. Si jamais les tests de performances (sous Linux du moins) vous intéressent, il y a un employé de Netflix qui publie beaucoup à ce sujet : http://www.brendangregg.com/linuxperf.html comme les outils, protocoles expérimentaux, outils de visualisation, interprétation de résultats… Très intéressant.

Amateur de Logiciel Libre et de la distribution GNU/Linux Fedora.

+0 -0

Personnellement, j’ai simplement fait l’expérience, et voilà ce que j’en dit, sous Linux, avec des applications gérant plus ou moins le multi-threading :

  • en 2 cores / 2 threads, les application mono et double-processus sont plus performantes.
  • en 2 cores / 4 threads, le système dans sa globalité est plus réactif et rapide, les applications multi-thread utilisant plus de 2 processus ont également un certain gain de célérité. Par contre, les applications simple ou double processus sont plus lentes quand elles ont besoin de beaucoup de ressources.

Au final, je reste dans la seconde configuration, bien plus adaptée à mon usage quotidien.

Édité par Breizh

Breizh zo ma bro, hag ihuel eo ma c’halon geti. Da viken. – L’oiseau imaginaire : ZzxŷxzZ

+0 -0

Un cas où le SMT peut permettre de s’approcher du gain théorique : quand on est limité par les IOs et qu’on a un bon équilibre temps passé sur les IOs VS temps de calcul. En se débrouillant bien (et en forçant la position des threads avec NUMA), on peut être quasi sûr de recouvrir les IO d’un thread avec les calculs de l’autre et vice-versa.

J’ai plus mes benchs sous la main, faudrait que je retrouve ça …

First : Always RTFM - "Tout devrait être rendu aussi simple que possible, mais pas plus." A.Einstein [Tutoriel Frama-C WP]

+1 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte