Bericht: Was ist Hyper-Threading?

Vorwort

Intel hat es lange dementiert und die Einführung der „Hyper-Threading Technologie“ im Heimbereich immer wieder auf den Prescott hinaus geschoben. Doch seit ein paar Wochen ist es amtlich: Schon der Northwood wird in den kommenden Modellen über dieses Feature verfügen. Was bei Intels Server-Prozessoren mit Prestonia-Kern, den Xeons, schon seit Anfang des Jahres möglich ist, hält nun also auch bei den Desktop-Prozessoren Einzug. Der neue Intel Pentium 4 mit 3066MHz wird diese Technologie zum ersten Mal in die Rechner des Privatanwenders tragen. Dass der weltweit größte Halbleiterhersteller einzig und allein dafür ein leicht modifiziertes Prozessorlogo entworfen hat, macht deutlich, welche Bedeutung Hyper-Threading für Intel besitzt. Sie scheint vom Marketing her schon fast mit der MMX-Erweiterung gleichzuziehen. Deshalb ist es höchste Zeit, dass auch wir uns etwas mit der Funktionsweise von Hyper-Threading beschäftigen.

Wieso Hyper-Threading?

In der Vergangenheit wurden Leistungssteigerungen vor allem durch höhere Taktraten, größere Caches und andere Optimierungen (Prefetch) in der Microarchitektur eines Prozessors ermöglicht. Ein höherer Prozessortakt bedeutet zwar die Berechnung von mehr Instruktionen pro Zeiteinheit, als Takt bezeichnet, bringt jedoch auch immer eine Zunahme in der Leistungsaufnahme mit sich. Darüberhinaus steigt die Systemleistung nicht linear mit dem Prozessortakt. So eignet sich die 20-stufige Pipeline der Netburst Architektur des Pentium 4 zwar ausgezeichnet für hohe Taktraten, doch kommt es zu Unterbrechungen des „Instruktions-Flusses“ in der Pipeline durch Cache Misses, Interrupts oder falsche Sprung-Vorhersagen, sind die Vorteile schnell wieder dahin. So sind Zugriffe auf den Arbeitsspeicher, die bei einem Cache Miss zum Nachladen benötigter Daten erforderlich sind, schneckenlangsam, wenn man sie mit den Transaktionen im internen Prozessor-Cache vergleicht.

Eine Möglichkeit, die Prozessorgeschwindigkeit zu steigern, wäre z.B. die Vergrößerung der L1 und L2 Caches. Allerdings macht gerade dies einen Prozessor noch komplexer, noch größer und noch teurer und selbst dann sind Cache Misses nicht auszuschließen. Weiterhin steigen mit größeren Caches auch die Schwierigkeiten entsprechende Taktraten und Latenzzeiten zu erreichen. Die Caches können also nur dann wirklich schnell sein, wenn sie klein sind. Verbesserte Fertigungstechnologien werden jedoch auch in Zukunft die Caches weiter anwachsen lassen.

Eine andere Möglichkeit, die Geschwindigkeit eines Prozessors zu steigern, ist das sogenannte Instruction-Level Parallelism (ILP). Hierbei versucht man die pro Taktzyklus ausgeführten Instruktionen zu erhöhen. So verfügen aktuelle Prozessoren beispielsweise über mehrere Ausführungseinheiten, die Instruktionen parallel verarbeiten können. Je mehr unabhängige Befehle der CPU gleichzeitg zur Verfügung stehen, umso effektiver fällt die Nutzung der Taktrate aus. Doch solange die Daten in der Programmreihenfolge ausgeführt ('In-Order Execution') werden, bleibt ein großes Stück Effektivität auf der Strecke. Mit Hilfe der 'Out-of-Order Execution', bei dem die Instruktionen zur Verarbeitung vorher sortiert werden, kann die CPU zwar wesentlich effektiver zur Sache zu gehen, doch wird auch hier Thread für Thread (engl. Pfad), also Programmteil für Programmteil, nacheinander bearbeitet. Wird eine Prozessor-Ressource für einen Thread nicht gebraucht, so liegt sie brach, da nur selten genügend Instruktionen zur Verfügung stehen, um alle Ressourcen voll auszunutzen.

Zitat

Def. Thread: Kleinster ausführbarer Teil eines Tasks. Beim Task handelt es sich um jenen meist sehr kleinen Teil eines Programms, den ein Prozessor auf einmal bearbeiten kann. Ein Prozessor ist sogar in der Lage, Programmbruchstücke zu bearbeiten, die deutlich kleiner als Tasks sind. Allerdings funktioniert dies nur bis zu einer Untergrenze, die man als Thread bezeichnet. (Wissen.de)

Heutzutage kommt darüber hinaus noch ein weiteres Problem dazu. So haben bereits aktuelle Prozessoren eine Leistungsaufnahme, die nicht mehr ohne weiteres einem Desktop-System im Arbeitszimmer zugemutet werden kann. Allmählich sind die Grenzen erreicht. Einzig und allein mit der kontinuierlichen Erhöhung der Taktrate ist es also nicht getan. Vielmehr müssen die bestehenden Ressourcen des Prozessors effektiver ausgenutzt werden, um auf diese Art und Weise die Leistung des gesamten Computers zu steigern. Das ist der Punkt, an dem die Hyper-Threading Technologie ansetzt.

Was ist Hyper-Threading?

Die Idee von Hyper-Threading kommt eigentlich aus dem Serverbereich, wo häufig Rechnersysteme mit mehr als nur einem Prozessor zum Einsatz kommen. Mit zwei Prozessoren ist es z.B. möglich, zwei Threads pro Taktzyklus zu verarbeiten, da jede CPU unabhängig mit Aufgaben beschäftigt werden kann. Wenn eine Anwendung vom Programmierer in mehrere Threads aufgeteilt wurde, lässt sich so die Geschwindigkeit deutlich steigern, wenn nicht sogar nahezu verdoppeln. Insbesondere bei Webserver-Applikation kann man nahezu von einer Verdoppelung der Leistung sprechen.

Die Hyper-Threading Technologie ist hierbei nichts anderes, als die Technik, die dieses simultane Multi-Threading in einem einzigen physikalischen Prozessor (mit Einschränkungen) ermöglicht. Dieser eine Prozessor spaltet sich somit in zwei logische Prozessoren auf, wobei sich die beiden logischen/virtuellen Prozessoren einen Teil der physischen Ausführungs-Ressourcen teilen, wobei die Umsetz-Logik (Architecture State) für jeden Prozessor einzeln und somit doppelt vorhanden ist. Ziel ist es, die vorhanden Ressourcen effektiver auszunutzen.

Was ist neu am Kern?

In der Theorie klingt Hyper-Threading eigentlich recht simpel. Doch was musste Intel nun wirklich dem bisherigen Pentium 4 Prozessorkern hinzufügen, um aus einem physischen Prozessor zwei logische machen zu können? So überraschend die Antwort auch sein mag, aber „hinzufügen“ ist in diesem Zusammenhang eigentlich nicht das richtige Wort. Viel besser wäre die Frage, welche schon immer vorhandenen Ressourcen nun endlich mal aktiviert werden. So verfügt jeder ausgelieferte Pentium 4 mit Northwood-Kern (und vermutlich auch mit Willamette-Kern) über alle nötigen Transistoren, die für Hyper-Threading gebraucht werden. Intel spricht davon, dass 5 Prozent bzw. 2 bis 3 Millionen Transistoren der relativen CPU Bestandteil von Hyper-Threading sind. An der Größe und den Transistoren ändert sich zu den bisherigen Pentium 4 somit nichts.

Eine Übersicht über den Pentium 4 Prozessor-Kern (Northwood) offenbart uns die Regionen, die nun mit Hyper-Threading vom Staub befreit werden und endlich zeigen können, was in ihnen steckt.

Darüber hinaus besitzt jeder virtuelle Prozessor seinen eigenen Interrupt-Controller (APIC), die Ressourcen wie Trace Cache (TC) / L1-Cache, L2-Cache, Queues und Key-Buffers werden geteilt.

Beim Trace Cache, der decodierte Instuktionen (micro-operations oder µops) enthält, wird, wenn beide virtuellen Prozessoren Zugriff auf den Cache haben möchten, jedem Prozessor abwechselnd mit jedem Takt Zugriff gewährt. Sollte ein virtueller Prozessor aufgrund eines Cache-Miss auf weitere Daten vom Hauptspeicher warten und somit quasi „blockiert“ (stalled) sein, so steht der gesamte Trace Cache dem jeweils 'anderen Prozessor' zur Verfügung. Ähnlich wird auch mit den internen Caches des Prozessors verfahren. Wenn ein virtueller Prozessor also gar nicht genutzt wird, ergibt sich durch die Teilung dieser beiden Ressourcen kein Nachteil.

Anders sieht das jedoch in der Out-Of-Order Execution Engine, hier speziell beim Allocator, aus. So verfügt die Out-of-Order Execution Engine über mehrere Zwischenspeicher zum Wieder-Ordnen (Reorder), Nachverfolgen (Tracing) und Aufteilen (Sequencing) von Operationen. Der Allocator hat die Aufgabe, diesen Zwischenspeicher zu füllen. Der Pentium 4 Northwood-Kern verfügt über 126 Re-Order Buffer Einträge, 128 Integer und 128 Floating-point Physical Register sowie 48 Load und 25 Store Buffer Entries. Ein Teil dieser Buffer wird bei aktivem Hyper-Threading geteilt, so dass jeder virtuelle Prozessor genau die Hälfte der Buffer füllen darf. Dies betrifft die Re-Order, Load uns Store Buffers. Jeder virtuelle Prozessor darf hier maximal 63, 24 bzw. 12 Einträge hinterlassen. Ist das Limit erreicht, wird der Allocator die Ressourcen dem anderen virtuellen Prozessor zuweisen. Sollten sich im Aufgabentopf (µop queue) nur decodierte Instuktionen für einen Prozessor befinden, so wird der Allocator versuchen, für diesen jedem Takt Ressourcen zuzuweisen, die Teilung bleibt jedoch bestehen.

Wenn der Allocator seine Arbeit vollendet hat, landen die µops in zwei weiteren Queues. Diese sind ebenfalls partitioniert und zwar so, dass jeder Prozessor maximal die Hälfte aller Einträge für sich verbuchen kann. Aus diesen beiden Queues (Memory Operation Queue und Genereal Instruction Queue) bedienen sich anschließend die fünf µop Scheduler abwechselnd aus den Topf jedes virtuellen Prozessors, um den Ausführungseinheiten Aufgaben zur Verarbeitung zuzuteilen.

Wie funktioniert's?

Da die Umsetzungs-Einheiten beim neuen Pentium 4 nun doppelt vorhanden sind, bzw. mit den neuen Hyper-Threading Prozessoren auch erstmals im Desktop-Bereich genutzt werden, und die üblichen Ressourcen geteilt werden, sind alle Voraussetzungen erfüllt, um zwei Threads parallel auszuführen. Da wir uns an dieser Stelle nicht in den Tiefen der komplizierten Prozessor-Theorie verlieren wollen, soll eine kleine Grafik an dieser Stelle verdeutlichen, wie bei ein- und demselben Prozessortakt ohne Hyper-Threading ein bzw. mit Hyper-Threading zwei Threads verarbeitet werden.

Beide CPUs haben dieselbe Aufgabe: Thread 1 (blau) und Thread 2 (ocker) sollen berechnet werden. Während eine CPU ohne Hyper-Threading in der angegebenen Anzahl an Arbeitschritten nur einen Thread abarbeiten kann, ist der Prozessor mit Hyper-Threading in der Lage, einen zweiten Thread durch die von Thread 1 nicht ausgelasteten Bauteile der CPU zu jagen. Beide Threads werden (in diesem optimalen) Beispiel somit exakt genauso schnell berechnet, wie der erste auf dem herkömmlichen Prozessor.

Was profitiert?

Da sich die virtuellen Prozessoren die Ausführungseinheiten teilen, dürften auch die Grenzen von Hyper-Threading ganz schnell klar werden. Sollte eine Anwendung tatsächlich einmal 100 Prozent einer Einheit (z.B. FPU) belegen, so würde eine zweite Anwendung, die ähnliche Ressourcen bevorzugt, dennoch warten müssen oder abwechselnd und somit im Endeffekt nicht schneller berechnet werden. Doch nicht einmal Seti@Home belastet eine Einheit so stark, dass zwei Seti-Instanzen nicht doch gewaltig von Hyper-Threading profitieren können. Als besonders reizvoll dürfte sich sicherlich die Tatsache heraus stellen, dass es Hyper-Threading ermöglicht, Floatingpoint- und Integerrechnung parallel laufen zu lassen.

Auch dürfte klar sein, dass Hyper-Threading nur dann Sinn hat, wenn beide Prozessoren mit Arbeit belastet werden. Und dies ist die Aufgabe des Betriebssystems. Sowohl Windows XP Home und Professional sowie Windows 2000 (nicht empfohlen, da nicht validiert) als auch Linux 2.4.18 sind hierfür geeignet. Was jetzt nur noch fehlt, sind geeignete Anwendungen, die in Threads programmiert wurden. Alternativ können die beiden Prozessoren auch durch mehrere Anwendungen zum Entfalten ihrer Kraft gebracht werden. Somit muss also zwischen Multitasking und Multithreading unterschieden werden. Bei Multitasking sollen sich durch Hyper-Threading vor allem die Reaktionszeiten merklich verringern. Wichtig ist hierbei, dass beide Anwendung auch wirklich parallel etwas tun - von Taskswitching erziehlt man in der Regel keinen großen Geschwindigkeitsvorteile.

Anders sieht das natürlich aus, wenn man mit Office-Anwendungen arbeitet und der berühmte Virenscanner im Hintergrund läuft. Hier haben wir echtes Multitasking. Das Gleiche gilt auch für das Musikhören beim Spielen sowie Seti@Home oder FlaskMPEG als Hintergrundprozess beim Arbeiten. Hier liegen die wahren Vorteile von Hyper-Threading.

Fazit

Nein, eine CPU mit Hyper-Threading besteht weder aus zwei physischen Prozessoren noch werden Anwendungen nun doppelt so schnell ablaufen. Und auch der Nutzen für einer einzeln ablaufenden Anwendung wird sich wohl in den meisten Fällen auf den etwas angehobenen Takt belaufen. Die Grenze zwischen einem PC mit HT-CPU und einem Dualsystem wird auch in der Zukunft klar und deutlich verlaufen. Während ein PC mit zwei CPUs identische Threads parallel laufen lassen kann und somit rein theoretisch einzelne Programme um die 100 Prozent beschleunigen kann, wählt Hyper-Threading einen anderen Ansatzpunkt und zwar die effektive Ausnutzung des Prozessorkernes.

Allerdings ist es Aufgabe des Betriebssystems, die anfallenden Arbeiten sinnvoll auf die beiden virtuellen Prozessoren zu verteilen. Da Spiele aber in den seltensten Fällen für Multi-Prozessor-Systeme programmiert wurden und somit nicht „threaded“ sind, kann hier auch das Betriebssystem die Rechenlast nicht sinnvoll verteilen. Insofern bleibt die Arbeit wieder an einem Prozessor hängen. Dafür dürfte es rein theoretisch möglich sein, eine parallel zum Spiel laufende Anwendung nun mit nahezu unveränderten Speed weiter laufen zu lassen und nicht in den „Idle-Modus“ schicken zu müssen.

Zumindest in der Theorie erscheint die Idee 'Hyper-Threading' als einleuchtend und genial. Wenn man bedenkt, dass in einer heutigen CPU oftmals ganze Bereiche blockiert werden, weil der aktuell bearbeitete Thread z.B. hauptsächlich die Floating-Point-Unit (FPU) und/oder ein paar andere Units des Prozessors belegt, dann kann einem ob der verschenkten Leistung nur flau im Magen werden. Hyper-Threading versucht dieser Entwicklung entgegen zu wirken, indem ein damit bestückter Prozessor durch seine zweite Allocator Unit zwei Threads parallel laufen lassen kann und somit den Kern zwar nicht optimal, aber in den meisten Fällen effektiver ausnutzt.

Glaubt man den durch das Netz geisternden Meldungen, dann wird es Donnerstag, am 14.11.2002, so weit sein und wir werden mehr zu diesem Thema wissen.

Ihr wollt über den Artikel diskutieren, habt Fragen, Lob oder Kritik auf dem Herzen? Am besten tut ihr all dies auf ForumBase.de [1] oder in unserem IRC-Channel [2] #computerbase im QuakeNet.