Hyperthreading genau

[ollix]

Hi,

ich bin gerade dabei mich mal in Prozessorarchitektur einzulesen. Dabei ist mir eine Frage zum Hyperthreading untergekommen.

Wie ich es verstanden habe, sind bei Hyperthreading alle (wirklich alle :)) Register doppelt vorhanden. Die logischen CPUs 1 & 2 haben jeweils für sich einen kompletten Registersatz.

Allerdings sind ja die Rechenwerke/ALU etc. wohl nur einmal vorhanden. Ist das richtig?

Ich habe es mir jetzt so zusammenreihmt, daß es ähnlich wie mit dem Scheduler im Betriebssystem die Recheneinheiten der CPU mal auf den einen, mal auf den anderen Registersätzen rechnen.

Also wenn zwei logische CPUs unterstützt werden und sie beide mit Maschinencode angesprochen werden. Läuft auf einem gerade die execute Phase eines Befehls ab, whärend auf dem anderen die fetch Phase für den nächsten Befehl der CPU läuft. Normalerweise laufen diese ja immer hintereinander ab und es werden unserschiedliche Teile der CPU dafür verwendet. So wären dann beides voll ausgelastet (HT CPUs sind ja auch idr heißer).

Als Methapher könnte man ein Koch in einem Studio benutzen, der an zwei Essen gleichzeitig kocht. Während er an dem einen kocht, wird was fürs andere Essen gerade vorbereitet. Dann macht er mit dem anderen Essen und den vorbereiteten Sachen weiter & umgekehrt.

Aber dies passiert nur wirklich wenn zwei logische CPUs unterstützt werden (und überhaupt:))? D.h. die zusätzlichen Register nützen gar nichts, wenn nicht wirklich zwei CPUs angesprochen werden. Z.B. Um die Fetch Phase des kommenden Befehls schon auszuführen.

Ist das in Grundzügen richtig oder ist das völliger Quatsch wie ich mir das überlegt habe? Hat jemand genauere Details dazu?

danke

[Avalox]

Du hast völlig Recht, das die Idee hinter SMT einfach die ist, CPU Aufgaben weiter zu parallelisieren. Da festgestellt wurde, das viel Zeit einfach nur gewartet wird. Ob nun auf einen Fetch oder externen Semaphoren u.s.w

Es wurde versucht mit HT einen höheren Grad von Parallelisierung und damit eine höhere Auslastung einzelner Units zu erreichen.
Da es sich bei SMT um ein konkurrierenden Ansatz handelt ist dabei sehr interessant wie die einzelne SMT Lösung im Detail funktioniert, um einen Schluss auf das tatsächliche Ergebnis zuzulassen.

Es ist im Koch/Küche Vergleich eher so, dass zwei Köche in einer Küche kochen wollen. Da landet schon mal eine Pfanne leer auf dem Herd um diesen zu reservieren. Interessant ist auch, wenn beide Köche ein Gericht zubereiten bei dem die Bereitung einer Sache als Zutat für das gesamt Gericht gilt.

Moderne Software ist Multi Threaded programmiert. Allerdings nicht immer mit dem Hintergrund einer Optimierung für SMP oder gar SMT. Vielmehr sind es praktische Beweggründe, die den Programmierer veranlassen z.B. nicht mit der „vollen“ Rechenzeit in einen Thread zu springen. Viele der neuen BS kommen ebenso mit Multiprozessor-Systemen zu recht.
SMP fähige Software als solches ist kein Garant auf einen performanten Ablauf auf SMT Systemen, obwohl die Software kein Unterschied erkennt. Das OS und auch die Anwendung sollte dabei auf die Eigenheiten von HT eingehen. Sonst kann das Ergebnis schnell negativ werden.


@Thop

Stimmt. Bestimmt dieser http://www.heise.de/ct/02/24/120/default.shtml
Wenn Online leider ein wenig kurz.

[HellHorse]

Original geschrieben von ollix
...
Also wenn zwei logische CPUs unterstützt werden und sie beide mit Maschinencode angesprochen werden. Läuft auf einem gerade die execute Phase eines Befehls ab, whärend auf dem anderen die fetch Phase für den nächsten Befehl der CPU läuft.
...
Sollte eigentlich auch bei normalen CPU's gehen, Stichwort pipelining.

[thop]

Es gibt einen sehr guten mehrseitigen Artikel zu HT in einer älteren c't Ausgabe. Wenn du willst such ich mal die Ausgabe raus.

[Kakarot]

Original geschrieben von thop
Es gibt einen sehr guten mehrseitigen Artikel zu HT in einer älteren c't Ausgabe. Wenn du willst such ich mal die Ausgabe raus.
24/02

der komplette Artikel ist auch auf der c't ROM 2.Halbjahr 2002.

[tatarus]

Hyperthreading hat den Vorteil, dass weniger Threadwechsel beim Multithreading notwenig sind.
Auf einem Prozessor laufen ja gleichzeitig sehr viele Threads ab. Einige für Programme und andere fürs Betriebssystem. Man hat also eine Ausführungseinheit, auf der mehrere "Programme" mit verschiedenen Deadlines ausgeführt werden. Beim Threadwechsel (oft mitten in der Ausführungsphase) müssen nun alle Registerinhalte und die Befehlsadresse etc. in den Speicher geschrieben werden und die des neuen Threads zurückgeholt werden.

Weil man normalerweise immer nur einen Prozessor hat auf dem sehr viele Threads "parallel" laufen, häufen sich diese Threadwechsel.
Beim Hyperthreading benötigt man weniger Threadwechsel und hat dadurch einen Geschwindigkeitsvorteil, weil viele Lese-und Schreiboperationen zwischen den Threads entfallen.

[ollix]

Natürlich - die Threadwechsel hatte ich völlig vergessen (sindja nur im Namen des Marketingbegriffs drin :D) bzw. die Ausbremsung durch Speicherzugriffe beim Sichern des aktuellen Status, neu laden, etc..

Danke auch für den c't Artikel - werde ich gleich mal lesen.

Also durch Hyperthreading lassen sich vorallem Speicherzugriffe sparen, weil man ein komplettes Register set direkt in der CPU auf Halde liegen hat ohne auf den Speicher zuzugreifen? Um jetzt mal den Bogen zum Thema Pipelining zu schlagen, stelle ich mal die These auf, daß der P4 davon besonders profitiert, da er bedingt durch seine lange Pipeline sehr von der langsamen Speicherzugriffen ausgebremst wird.

@HellHorse
Zum Thema Pipeling der fetch/execute Phase frage ich mich, wie das gehen soll? Ich erinnere mich, daß das doch sequentiell ablaufen muß. Oder verstehe ich Pipelining jetzt falsch? Es ist doch so, daß eine Kette von Befehlen gleichzeitig in der Pipeline hängen, die mit jedem Takt jeweils eine weitere Stufe der Pipeline durchschreiten, oder? Wichtig dabei ist AFAIK auch, daß die Daten nicht voneindern abhängig sind.

Aber wie kann gleichzeitig 'fetch/execute' ablaufen bzw. wie kann ein 'execute' ohne ein zuvor fertiges 'fetch' ablaufen?

[HellHorse]

@ollix
Nicht bei einem Befehl, sondern bei aufeinanderfolgenden Befehlen. Wenn also Befehl2 auf Befehl1 folgt, fetch für Befehl1 schon geschehen ist, dann execute von Befehl1 gleichzeitig zu fecht von Befehl2 erfolgen.
(Ich hoffe ich schreibe keinen Müll, ist schon eine Zeit her, seit ich das hatte)

Theoretisch denkbar wären auch so Sachen wie Threadwechsel bei cache-miss.

Dafür musst du mir das erklären:
stelle ich mal die These auf, daß der P4 davon besonders profitiert, da er bedingt durch seine lange Pipeline sehr von der langsamen Speicherzugriffen ausgebremst wird.

[CrazyIvan]

@ HellHorse

Hast keinen Müll geschrieben ;)

Zu Ollix' Statement:
Je länger die Pipeline, desto häufiger können innerhalb dieser Daten- bzw. Steuerabhängigkeiten auftreten. D.h. dass zum Beispiel Befehl2 auf das Ergebnis von Befehl1 angewiesen ist. Somit sind diese beiden nicht parallelisierbar und damit auch net gut für die Pipeline.

Natürlich gibt es den gleichen Effekt auch bei der Pipeline des K8, nur ist diese halt net so lang. Dadurch "dauert" auch das Neuauffüllen net so lange. IMHO profitiert somit der P4 mehr von SMT. Aber da es zu dem Thema schon ellenlange Diskussionen gab, möchte ich hiermit das IMHO zu Beginn meiner Aussage noch einmal deutlich hervorheben.

[HellHorse]

Original geschrieben von CrazyIvan
Zu Ollix' Statement:
Je länger die Pipeline, desto häufiger können innerhalb dieser Daten- bzw. Steuerabhängigkeiten auftreten. D.h. dass zum Beispiel Befehl2 auf das Ergebnis von Befehl1 angewiesen ist. Somit sind diese beiden nicht parallelisierbar und damit auch net gut für die Pipeline.

Ist klar. Und wenn die Sprungvorhesage Mist baut, und die pipeline geflusht werden muss, kommt auch keine Partystimmung auf.
Ich sehe aber nicht, wieso eine längere Pipeline zu mehr Speicherzugriffen führt.

[CrazyIvan]

@ Hellhorse

Weil statistisch gesehen diese Abhängigkeiten umso häufiger auftreten, je länger die Pipeline. Auch müssen meist mehr Daten neu geladen werden, da ja die Pipeline länger ist.
Inwiefern das jetzt unbedingt zu mehr Speicherzugriffen kommt, kann ich auch net sagen. Wird wohl net so wild sein, da heutige L1 + L2 + L3 Cache recht großzügig dimensioniert sind.
Aber selbst dass Holen der Daten aus dem L1 kostet Takte...