HT/SMT kann eure CPU signifikant langsamer machen

Für alle die am PC zocken, die meisten von euch haben vermutlich HT/SMT (Hyper Threading/Simultanious Multi Threading) aktiviert. Aus Marketing Gründen ist das der Standard weil ne 8 Kerne CPU sich so mit 16 Kernen am OS meldet.

HT/SMT wurde erfunden, um die uneffektive nutzung von CPU Kernen zu verringern. Wenn ihr 8 Kerne habt und jeder ist nur zu 70% ausgelastet, sind da 30% Luft. Meldet das System 16 Kernel, lastet das Programm jeden „virtuellen“ Kern zu 70% aus, was zu einer echten Auslastung von 140% sorgt und die löcher sind zugestopft.

Man hat also im endeffekt mehr Performance. Super? Naja fast.

Wenn man eine 8 Kern CPU die sich als 16 Kern CPU meldet zu 100% auslastet, also ohne diese Lücken (was die meisten Anwendungen heutzutage problemlos schaffen), hat man genau das gegenteilige Problem die CPU wird langsamer. Die Ursache (u.a.), der Cache.

Die CPU hat mehrere Cache. L1 (der schnellste und kleinste), L2 (langsamer, aber größer), L3 (am langsamsten, am größten) und am Ende kommt der RAM (Verglichen mit den L-Cache, Schneckentempo).

Hier mal ne Simulation dazu

Jetzt ist das Problem, wenn ihr der CPU 16 Threads zum verarbeiten gebt, müssen sich 16 Threads den Cache teilen.

Wo die Threads also vorher 1/8 vom Cache hatten, haben sie jetzt nurnoch 1/16 vom Cache. In Kombination mit dem Overhead der durch HT/SMT so oder so entsteht, kann das zu einer reduzierten Performance führen. Insbesondere da viele Programme, um die CPU voll zu nutzen, eh schon doppelte Threads verwenden.

Viele Programme/Spiele machen auf einer 8 Kern CPU die sich als 16 Kerner meldet also 32 Threads auf. Dann hat jeder Thread noch 1/32 vom Cache. Ergebnis, das meiste passiert im (relativ) langsamen RAM.

Auf meinem Desktop hab ich SMT sofort deaktiviert und nen Test gemacht, ich bin fast vom Stuhl geflogen. Kernel Bau (Kompilieren von paar Hundert C Dateien) war 28% schneller(!) WTF?

Hab dann mal paar Benchmarks angeschaut und die Ergebnisse decken sich. Insbesondere bei Ray Tracing kommen die meisten Benchmarks so auf 15~30% höhere Performance bei deaktiviertem HT/SMT.

Es gibt aber auch viele Benchmarks die genau das Gegenteil zeigen. Lenovo sagt z.b. bei Video Encoding/Decoding, soll man es auf jeden Fall aktivieren weil man deutlich höhere Performance bekommt

Einen Haken gibt es an der Sache. Manche BIOS erlauben das abschalten nicht. Ich hab hier nen MiniPC mit Ryzen7, der kann das z.b. nicht, ist im BIOS hart aktiviert. Man kann das in Linux/BSD zwar deaktivieren, aber Windows bietet keine möglichkeit HT im OS zu deaktivieren. Wer es also im BIOS nicht abschalten kann und Windows nutzt… der hat einfach Pech^^

Wenn ihr das also abschalten könnt, schaltet es ab. Heutzutage nutzt praktisch jede Anwendung die CPU so gut es geht, HT/SMT ist ein Relikt aus der Vergangenheit das in der jetzt Zeit nichts mehr verloren hat.

1 „Gefällt mir“

Ich bin mir nicht sicher, ob man das so allgemeingültig sagen kann. :thinking:
Es gibt sicher Situationen, die von HT massiv profitieren. Umgekehrt gibt es jedoch auch Fälle, in denen HT kontraproduktiv ist.

Der Grund dafür: Der Prozessor ist kein monolithischer Block mit x Rechenkernen. Ganz grob besteht er aus Frontend, Recheneinheiten und Speichersteuerung (hier ist nicht der RAM gemeint, sondern die unterschiedlichen Register und Caches im Prozessor selbst). Jeder dieser Blöcke besteht wiederum aus dutzenden kleinerer Funktionseinheiten: Branchpredition, Befehlsdecoder, die verschiedenen ALUs (die eigentlichen Rechenwerke), unterschiedliche Scheduler, …

Ein (schon sehr vereinfachtes!) Blockdiagramm eines 10 Jahre alten Skylake-Prozessors:

Damit alle diese dutzenden Funktionseinheiten optimal ausgelastet sind, wurde HT erfunden: Wenn der Befehlsdecoder warten muss, bis die Recheneinheit hinter ihm fertig ist, kann er schonmal den nächsten Befehl bearbeiten. Wenn die Integer ALU rumrechnet, kann die Floatingpoint ALU gleichzeitig einen FP-Befehl eines anderen Threads verarbeiten…

Ob HT nun im Einzelfall hilft oder schadet, hängt von hunderten Faktoren ab. Allgemeingültige Aussagen, die sich auf eine spezifische Situation beziehen, kann man einfach nicht treffen.

Ein Beispiel: Zwei praktisch baugleiche Rechner (Gleiches Motherboard, Prozessor, RAM, …) mit unterschiedlichen Kühlkörpern können sich bereits im HT-Verhalten massiv unterscheiden. HT nutzt die Ressourcen des Prozessors möglichst optimal, sodass alle fleißigen Bienchen im Prozessor pausenlos arbeiten und somit jedes Bienchen Wärme erzeugt. Wenn es nun zu heiß wird, grätscht die Temperaturkontrolle zwischen das fein austarierte HT-System und bringt es komplett durcheinander. In diesem Fall kehrt sich der Vorteil des HT um und Singlethreading wäre schneller, weil es einfach weniger Wärme erzeugt. Das eigentliche Problem ist dann aber nicht das HT, sondern die unzureichende Kühlung.

Ein zweite Beispiel: Es macht einen massiven Unterschied, ob man ein eher rechenlastiges Programm ausführt (viele komplexe Rechenschritte), oder ob es eher IO-lastig arbeitet (viele Daten in kurzer Zeit abarbeitet). Im ersten Fall bringt HT richtig viel, im anderen behindert es den Datenfluss eher.

Funfact am Rande: In der neuesten Arrowlake-Generation hat Intel Hyperthreading über Board geworfen.

Fazit:
Nun mal Butter bei die Fische. Ist HT nun sinnvoll oder nicht? :beanwat:
Meine Antwort: Es kommt drauf an. :stuck_out_tongue: Probiert es einfach mit genau dem Programm aus, das ihr optimieren wollt. Benutzt keine synthetischen Benchmarks. Die sind super, um eine einheitliche Vergleichsbasis zu schaffen, im Endeffekt kommt es jedoch auf die reale Performance an, die in einer ganz konkreten Situation abrufbar ist.

Edit: @Vamp898 Du schreibst, dass das Kompilieren 30% schneller ist, wenn du HT abschaltest. Kannst du mal testen, was passiert, wenn du HT einschaltest, die Threads jedoch mit „make -j< x >“ limitierst? Das Ergebnis würde mich interessieren.

2 „Gefällt mir“

Ich hab das bisschen zu krass vereinfacht, das stimmt schon.

Es gibt fälle, die können von HT profitieren, gerade unter Windows. Also unter Windows ist der Unterschied mit/ohne HT (Laut Phoronix) größer als unter Linux.

Bei der Bulldozer Architektur (Was ja kein HT war, das war ja wieder was ganz anderes/besonderes) war der Unterschied extrem.

Ich hatte damals nen FX 8150 und der war halt gefühlt fast doppelt so schnell wie der Phenom II 1100T den ich vorher hatte.

Aber unter Windows gab es Leute, bei denen war der FX 8150 sogar langsamer.

Der Hauptgrund dass ich SMT deaktiviert (und das überhaupt getestet) hab waren build error. Gerade sehr große Sachen wie LLVM die ja eh schon gefühlt ewig bauen, hatten random build error. Hab nen Bug aufgemacht → wurde analysiert, ist nen CPU Bug. Wenn SMT aktiviert ist und du kompiliert über lange Zeit auf allen (virtuellen) Kernen auf Vollgas, produzeirt die CPU früher oder später Rechenfehler und der build crashed.

Ultra nervig, seit ich SMT aus habe, ist das nicht mehr passiert. Mit -j8 auf 8 Kerne zu limitieren (mit aktiviertem SMT) hat das vorher schon gefixed, aber dann hast du den SMT Overhead ohne die Vorteile.

Also die höchste Performance habe ich mit deaktiviertem SMT und -j16 auf 8 (echten) kernen und LLVM crashed auch nicht mehr beim bauen

1 „Gefällt mir“