Des cœurs fantômes dans vos processeurs

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).

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.

Salut,

Merci pour ce petit billet.
Est-ce que tu aurais quelques sources à fournir à ce sujet en plus du lien vers hardware.fr ?

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).

Je me coucherais moins bête ce soir, merci pour l’explication !

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.

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.

Ç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.

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.

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 …