JetBrains sont d'imbatables caмarades

Lionel Debroux (./5011) :
L'implémentation de HT s'est améliorée depuis les débuts où il avait été montré que des workloads comme MySQL détestaient l'hyperthreading, avec des pertes de performance significatives. Il reste cependant qu'en l'absence d'informations d'affinité, si le scheduler trouve malin de mettre deux threads qui utilisent les mêmes blocs du processeur sur les 2 hyperthreads du même coeur, plutôt que sur 2 coeurs séparés du même socket, la performance peut être inférieure, et surtout, non répétable.
Sur certaines micro-architectures, la performance inférieure peut aussi être remarquée quand on utilise tous les threads du CPU: la performance de memtest86+ (scheduler statique trivial) avec tous les threads est inférieure à la performance avec 1 seul thread par coeur, malgré une consommation électrique et un dégagement de chaleur habituellement supérieurs. `rep stosl / rep stosq`, ou de courtes boucles similaires, ne s'exécutent pas toujours (voire pas souvent ?) efficacement en parallèle sur 2 hyperthreads du même coeur. La pénalité de l'utilisation du SMT est certes inférieure à celle qu'on rencontre sur certaines machines quand on ne tient pas compte du NUMA (j'ai vu un facteur 15-20 sur une machine Ivy Bridge EP quad socket !), mais elle existe.
Je pense que sur certains workloads, pour avoir des benchmarks fiables, il est encore plus simple de désactiver le SMT que de programmer d'une façon ou d'une autre l'affinité de manière à éviter le SMT.

Et côté vulnérabilités des processeurs, désactiver SMT fait partie des mitigations de L1TF ("Foreshadow-NG"), MSBDS ("Fallout"), MFBDS ("Zombieload"), MLPDS et MDSUM ("RIDL"). Un certain nombre de mes machines tournent sans HT depuis 2018.

Merci pour l'info. Je comprends mais je suis quand-même étonné que le HT puisse être moins performant que sans, il faut des cas où les composants partagés comme l'ALU et le cache local (je crois) soient starvés constamment pour que ça se passe, et même dans ce cas ça ne devrait pas augmenter en chaleur (on perd juste l'overhead du multithread). Mais il doit y avoir quelque chose d'autre avec l'architecture Core, parce que deux "threads" consomment en effet assez proche de deux cores distincts pour des gains largement inférieurs, ce qui n'a pas beaucoup de sens pour moi. Mon PC ne tape pas dans la limite de TDP donc je ne peux pas tester, mais il se pourrait qu'un scheduleur mettant par erreur quelque chose sur un deuxième thread puisse faire consommer plus que s'il l'avait mis sur un core non utilisé, rapporté au bénéfice de performance. Mais je crois que Windows ne fait pas ça, il remplit d'abord tous les cores avant de balancer sur les threads. L'exception, c'est pour la performance single core, mais là aussi c'est un "bug" d'Intel, qui fait que si tu bouges souvent un seul thread d'un core à l'autre comme Windows le fait, le processeur va limiter le turboboost, pensant que plusieurs cores sont utilisés (et la fréquence maximale n'est atteignable qu'avec un seul core à la fois). À l'époque j'avais désactivé le HT pour augmenter un petit peu la performance single core, au prix d'environ 30% en multicore. J'imagine qu'il peut y avoir pas mal de problèmes de ce type avec le big.LITTLE, en pire.

Quoi qu'il en soit, c'est sûr que c'est malhonnête d'Intel de faire du HT, vaut mieux vendre ses proços TTC