Verständnisfrage zu SMT / Hyperthreading

CoMo

Commander
Registriert
Dez. 2015
Beiträge
2.133
Hallo,

ich mache mir gerade Gedanken, wie SMT eigentlich genau funktioniert. Bisher verstehe ich das so:

Ein CPU-Kern kann grundsätzlich erst mal nur eine einzige Aufgabe auf einmal durchführen, also einen Thread bearbeiten. Möchte ein anderer Thread auf den Kern zugreifen, muss er warten.

Nun besteht ein CPU-Kern ja aber aus mehreren Komponenten, z.B. einer Einheit für Gleitkomma-Berechnungen und einer Einheit für Vektor-Berechnungen.

SMT sorgt nun dafür, dass die Kerne effizienter genutzt werden können. Wenn ein Kern z.B. gerade nur Gleitkomma-Berechnungen durchführt und ein anderer Thread Vektor-Berechnungen benötigt, so sorgt SMT dafür, dass die Vektor-Einheit sich um diesen Thread kümmern kann, währen die Gleitkomma-Einheit weiter am anderen Thread arbeiten kann.

Das erzeugt Latenzen und kostet etwas Leistung, da sich die Kerne ständig über den Status der Threads austauschen müssen und sich Datenleitungen teilen müssen und ist der Grund dafür, dass sich die Leistung auch in diesem Optimalen Szenario nicht verdoppelt.

Habe ich das soweit richtig verstanden?

Dann weiter: Das OS hat keine direkte Kontrolle darüber, wie der Prozessor seine Threads verarbeitet und kann darauf nur bedingt Einfluss nehmen. Für das OS und darauf laufende Anwendungen ist jeder logische Prozessor gleichwertig.

Daraus schlussfolgere ich: Wenn ein Prozessor z.B. 24 Kerne hat und SMT aktiviert ist, und ich führe einen Prozess aus, der genau 24 Threads benötigt (der Einfachheit halber nehme ich an, dass das OS selbst keinen Thread benötigt) und sonst nichts. Dann würde das OS die 24 Threads auf 48 logische Kerne verteilen, ohne die tatsächliche Anzahl an physischen Kernen berücksichtigen zu können. Das bedeutet, Threads würden durch SMT auf Kerne verteilt, welche dann an mehreren Threads arbeiten würden, während tatsächlich physische Kerne in dieser Zeit gar keine Daten verarbeiten würden.

Da das Leistung kostet, wäre die Ausführungsgeschwindigkeit in diesem Fall also geringer als ohne aktiviertes SMT. Denn sonst würde sich je 1 Kern dediziert um einen Thread kümmern können.

Ist das soweit korrekt?

Bei mehr als 24 Threads, sagen wir 48, stünden jedem Thread potentiell 2 logische Kerne zur Verfügung. Das wäre ein Effizienzgewinn. Es sei denn...

Es sei denn, alle 48 Threads nutzen nur eine Einheit der Prozessoren. Z.B. führen alle 48 Threads ausschließlich Vektor-Berechnungen durch. Dann sind die Vektor-Einheiten aller Kerne ausgelastet.

In diesem Fall könnte SMT keinen Vorteil bringen, da sich diese Berechnungen nicht weiter parallelisieren ließen. Die Ausführungsgeschwindigkeit würde sogar massiv sinken, da einzelne Threads ihre Informationen zwischen physischen Kernen synchronisieren müssten.

Ist das soweit korrekt?

Wenn ich andererseits normale Workloads betreibe, also alle Einheiten der Kerne mehr oder weniger in Verwendung sind, dann kann SMT doch nur so lange einen Vorteil bringen, wie die Anzahl meiner Threads die Anzahl der physischen Kerne übersteigt, oder?

Anders ausgedrückt: So lange ich auf einer 24-Kern CPU weniger als 24 Threads ausführe, sinkt meine Performance mit aktiviertem SMT, da die vorhandenen physischen Kerne sich nicht dediziert um die Threads kümmern und somit Leistungspotential brachliegt.

Richtig? Freue mich auf euren fachlichen Input, denn das beschäftigt mich schon sehr lange und so wirklich konnte mir das noch niemand erklären :)
 
  • Gefällt mir
Reaktionen: Anoubis

SMT / Hyperthreading ist nur dafür da um die richtigen Kerne mehr auszulasten, mehr realen 100%. Bei den jetzigen Architekturen ist die Kernauslastung nicht effektiv genug ohne SMT / Hyperthreading.

 
nein, da hast du die Fragestellung völlig falsch verstanden!

als SMT aufkam, wurden die neuen "blauen" CPUs auf Compute-Servern entwickelt, auf denen das SMT explizit AUS geschaltet wurde, weil es mehr Nach- als Vorteile bringt/gebracht hat ;)
 
  • Gefällt mir
Reaktionen: Asghan
du hast nichts von Cache und RAM und Kontextwechseln geschrieben. Das sollten Architekturübergreifend die wichtigsten Stichpunkte sein.
Die ausführenden Einheiten sind da nochmal außen vor, aber auf die hast du dich ja gerade fokussiert. was @UNDERESTIMATED da ansprichtkann gut in die Richtung dessen was du direkt nachfragst gehen

Was HT angeht:

Die Rechenwerke deiner CPU bekommen das was sie tun aus den CPU Caches. Die Caches werden mit Daten aus dem RAM gefüllt (und schreiben Ergebnisse auch wieder in den RAM.
Nun kommt es oft vor, dass alle im Cache vorgehaltenen Instruktionen abgearbeitet sind und jetzt muss zeitaufwändig was "neues aus dem RAM her". Der RAM ist jedoch oft um mehrere Größenordnungen langsamer als der CPU Cache.

ohne HT hatte man bspw. 10 Threads laufen. Das sah dann so aus:
Thread 1 bekommt seine Instruktionen in den cache -> Es wird gerechnet -> Ergebnis in den cache -> Ergebnis in den RAM -> nächsten Intruktionen des nächsten thread laden
Da jedoch gern hunderte Threads aktiv sind, kann keiner seine Instruktionen dauerhaft im Cache halten. Dafür haben die meisten Leute zu wenig Kerne wenig Kerne.
Kontextwechsel kosten jedoch immer Zeit, in der der kern nicht rechnen kann
cs.png

https://mycareerwise.com/content/context-switch-and-dispatcher/content/exam/gate/computer-science

Beim hyperthreading werden die caches pro kern für mehrere Threads befüllt
Das kann man so ganz nett visualisieren:
smp_single.png
hyperthread2.png


links siehst du 2 threads, 2 kerne ohne HT, links threads in einem kern mit HT

CoMo schrieb:
In diesem Fall könnte SMT keinen Vorteil bringen, da sich diese Berechnungen nicht weiter parallelisieren ließen. Die Ausführungsgeschwindigkeit würde sogar massiv sinken, da einzelne Threads ihre Informationen zwischen physischen Kernen synchronisieren müssten.
Es ist sehr sehr unwahrscheinlich, dass du mit einem Normalen auf Endanwender ausgerichteten Betriebssystem weniger als 100 Threads hast.
Je mehr threads du hast, desto mehr kontext wechsel. Desto mehr "verbrannte zeit"
 
  • Gefällt mir
Reaktionen: hans_meiser, iron_monkey, Mickey Mouse und 2 andere
CoMo schrieb:
Dann weiter: Das OS hat keine direkte Kontrolle darüber, wie der Prozessor seine Threads verarbeitet und kann darauf nur bedingt Einfluss nehmen. Für das OS und darauf laufende Anwendungen ist jeder logische Prozessor gleichwertig.
Das OS weiß durchaus, was es da unter sich hat. Das OS selbst sagt: Dieser Thread läuft auf diesem Kern. Das entscheidet nicht die CPU. Deshalb kannst du auch die Prozessoraffinität auswählen.

2023-02-27 22_58_27-Verständnisfrage zu SMT _ Hyperthreading _ ComputerBase Forum – Mozilla Fi...png


2023-02-27 23_03_45-Verständnisfrage zu SMT _ Hyperthreading _ ComputerBase Forum – Mozilla Fi...png



CoMo schrieb:
Dann würde das OS die 24 Threads auf 48 logische Kerne verteilen, ohne die tatsächliche Anzahl an physischen Kernen berücksichtigen zu können. Das bedeutet, Threads würden durch SMT auf Kerne verteilt, welche dann an mehreren Threads arbeiten würden, während tatsächlich physische Kerne in dieser Zeit gar keine Daten verarbeiten würden.
Das ist absolut nicht so. Solange physische Kerne frei sind, werden die bevorzugt. Mindestens bei den Ryzens ist es sogar so, dass bekannt ist, welcher der beste Kern ist. Entsprechend wird auch ausgewählt.

2023-02-27 23_01_17-Verständnisfrage zu SMT _ Hyperthreading _ ComputerBase Forum – Mozilla Fi...png



madmax2010 schrieb:
Je mehr threads du hast, desto mehr kontext wechsel. Desto mehr "verbrannte zeit"
Aber auch nur, solange diese Arbeiten. In der Praxis sind die meisten dieser die allermeiste Zeit im Schlaf und es erfolgen keine Kontextwechsel.


Nachtrag:
Dieser ganze Mechanismus ist ja auch vor allem auch für Hybride CPUs im big.LITTLE Aufbau relevant. Bei Smartphones schon seit Jahren, bei Desktops seit neustem bei Intel an Board. Hier wird Arbeit auch bewusst auf bestimmte Kerne/Threads gepackt.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: CoMo
Zurück
Oben