Diskussion:Hyper-Threading

Automatische Archivierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 21 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind. Die Archivübersicht befindet sich unter Archiv.

Unlogisch und daher zwangsläufig inhaltlich falsch

In der Einleitung steht:

Es ist also keine Anpassung der Software nötig, das Betriebssystem muss nur (S)MP-fähig sein und sollte Multitasking und Kernel-Level-Threads unterstützen, um Hyper-Threading auszunutzen.

Dagegen steht im Abschnitt "Unterstützung":

Windows 2000 ist zwar kompatibel mit Hyper-Threading, profitiert aber selten davon, weil es nicht zwischen physikalischen und logischen Prozessoren unterscheidet (keine SMT-Awareness). Die Leistung kann sogar durch Effekte wie Cache-Thrashing sinken.

und

Compiler, die Code mit Hyper-Threading-Unterstützung erzeugen können, sind die Intel-Compiler und die GCC.

Während die die Einleitung, die das grundsätzliche vermitteln soll, also behauptet, dass der Sinn des Ganzen ein Funktionieren ohne zusätzliche Anpassung (gewöhnliche SMP-Fähigkeit reicht) sein soll, scheint es dagegen weiter unten notwendig zu sein, nicht nur Betriebssysteme, sondern auch noch Compiler mit besonderer HTT-Unterstützung aufzuzählen, bzw. scheint das Problem von Windows2000, dass SMP-Unterstützung nicht genügt, um von HTT zu profitieren, allgemeiner Natur zu sein (der Begriff SMT-Awareness wird extra eingeführt).

Nur eines von beiden kann stimmen.

Die Behauptung, dass die Leistung von HTT durch Cache-Thrashing sinken kann, liegt (an dieser Stelle) im Widerspruch zur gesamten Erklärung der Funktionsweise. Wenn es sich in Wahrheit nur um einen Kern handelt, der mithin auch nur einen Cache besitzt, wie kann es da zu mehr Cache-Thrashing kommen, wenn des Betriebssystem SMP-fähig aber nicht "SMT-aware" ist?

84.189.45.78

Nja, ein "echter" Kern und ein HT-Kern sehen für das SMP-OS erst mal gleich aus, für das "SMT-aware" aber nicht, weil: Der HT-Kern darf nur rechnen, wenn der "echte" Funktionseinheiten übrig lässt. Der "echte" ist also immer (deutlich!) bevorzugt, er bringt ca. 3-10 Mal soviel Rechenleistung. (Bei ungünstiger Software bringt der HT-Kern meist ca. 10%, bei günstiger bis über 30% der Leistung eines echten Kerns.)

Ein SMT-aware OS kann nun Prozesse/Threads, die bisher v.a. Rechenarbeit geleistet haben und wenig auf I/O warten, den leistungsfähigen Kernen zuteilen, und jene Threads, die v.a. auf User-Input warten, den schwachen HT-Kernen zuordnen. Wenn Win2K stattdessen auch die Rechenthreads immer mal wieder auf die HT-Kerne schiebt, dann wird's u.U. insgesamt sogar langsamer.

Zu den Compilern, siehe oben "Compilerunterstützung für HT"

--arilou 14:48, 26. Mai 2011 (CEST)

Muss mich selbst korrigieren; die beiden Threads sind gleichwertig. Dennoch bringt es Vorteile, ggf. einen Thread abzuschalten, und in einem Prozessorkern nur 1 Thread laufen zu lassen:

Annahme: Es gibt 4 CPU-Kerne, +4 aufgrund HT, also insgesamt 8 logische Kerne.

Es stehen 4 Threads zum Rechnen an.

Dann sollte ein SMT-Aware -OS diese 4 Threads jeweils einem ("echten") CPU-Kern zuordnen und pro "echtem Kern" die jeweils zweite Ausführungseinheit abschalten. So können alle 4 Threads rechnen, ohne CPU-Einheiten mit irgend jemandem teilen zu müssen.

Ein Nicht-SMT-Aware -OS würde die 4 Threads den CPU-Kernen 1 (+HT) und 2 (+HT) zuteilen, wo sie sich jeweils "ins Gehege" kommen.

--arilou (Diskussion) 15:13, 18. Apr. 2017 (CEST)

Was bedeutet Hyperthreading genau?

Haltet mich bitte nicht für spitzfindig aber mir ist die genaue Feststellung ab wann ein Prozessor Hyperthreadingfähig ist nicht genau klar denn, wenn man sich einmal anschaut wieviele Threads gleichzeitig in einem Computer laufen, müßte sogar ein 486er Hyperthreadingfähig sein. Denn in jedem Prozessor laufen immer mehrere Threads ab und auch bei den Prozessen ist das der Fall. Im Programm Processexplorer ist kaum zu erkennen warum der Prozessor Hyperthreadingfähig sein soll. Woran erkenne ich den nun, in dem Programm Processexplorer wann ein Processor Hyperthreading fähig ist? Doch nur daran, das ein Prozessor mehrere Prozesse innerhalb eines Programmes ausführt. Nicht etwa Threads, denn das tut jeder Prozessor sondern Prozesse innerhalb eines Programmes.

Diesen Aspekt müßt Ihr unbedingt in euerem Artikel noch hinzufügen. (nicht signierter Beitrag von 85.178.39.154 (Diskussion | Beiträge) 21:04, 17. Jun. 2009 (CEST))

Du wirst die Begriffe ein bisschen durcheinander. :) Vielleicht erstmal, was Thread und Prozess eigentlich sind: Verwaltungseinheiten des Betriebssystems, die Informationen und Code beinhalten. Dabei steht der Thread in der Hierarchie unter dem Prozess:

• Ein Prozess enthält alle Laufzeitinformationen, hat seinen eigenen Speicherbereich etc. und hat mindestens einen Thread.
• Threads sind nicht unabhängig, sondern unterstehen immer (genau) einem Prozess. Alle Threads eines Prozesses teilen sich denselben Speicherbereich (nämlich den des Prozesses).

Der Process Explorer listet erst einmal nur die Prozesse auf. Wie viele bzw. welche Threads jeder dieser Prozesse tatsächlich benutzt, zeigt die Detailansicht („Lower Pane“ anzeigen lassen und Strg-H drücken, Typ „Thread“).

Ein klassisches Single-Core-Prozessor-System weist sich als solcher aus, woraufhin der Scheduler im Betriebssystem weiß, dass es nur einen Thread gleichzeitig bearbeiten kann. Multitasking wird hier also durch einen sehr schnellen Threadwechsel erreicht: Alle x Millisekunden bricht der Scheduler die Ausführung des aktuell laufenden Threads ab, speichert dessen Zustand weg, lädt den nächsten Thread und führt diesen für x Millisekunden aus, und so weiter.

In einem klassisches Multi-Core-System (mehr als ein CPU-Kern bzw. mehr als eine CPU) weiß der Scheduler, dass er zwei/drei/vier/… Threads gleichzeitig abarbeiten kann. Also schickt er Thread A an Kern 1, Thread B an Kern 2 etc., bis alle Kerne eine Thread haben – und dann läuft dasselbe Spielchen wie oben: Er lässt allen Threads jeweils x Millisekunden Zeit und wechselt dann überall den Thread.

In einem Hyper-Threading-System läuft nun fast das Gleiche ab wie beim Multi-Core-System: Der Prozessor mag zwar nur einen Kern besitzen, aber er gibt vor, zwei zu haben und stellt entsprechend auch einige Verwaltungsfunktionalität zur Verfügung, die man für zwei Kerne bräuchte – die Recheneinheiten sind aber nicht doppelt vorhanden, das ist der wichtige Unterschied zu einem Dual-Core-Prozessor. Der Scheduler sieht nun die zwei Kerne und weist beiden jeweils einen Thread zu. Und jetzt muss der Prozessor beide auf denselben Recheneinheiten ausführen, so dass sie sich dabei nicht in die Quere kommen. Das ist Simultaneous Multithreading (SMT) bzw. Hyper-Threading (HT).

Was du oben schriebst, klang, als hättest du Multitasking mit SMT/HT verwechselt. Klar kann jeder 386er Multitasking – aber er arbeitet immer nur einen Thread echt gleichzeitig ab, das ist kein SMT. Für den User sieht das aber durch die schnellen Threadwechsel des Schedulers nach Gleichzeitigkeit aller Threads aus. Ein HT-Prozessor hingegen versucht, zwei Threads echt gleichzeitig auszuführen, indem er Wartezyklen eines Threads für den jeweils anderen ausnutzt. Im Idealfall kann damit ein HT-Prozessor etwa doppelt so schnell sein wie einer ohne HT (der ansonsten identisch ist), im schlimmsten Fall ist er nur etwa genauso schnell.

Ich hoffe, ich habe jetzt nicht den ganzen Artikel wiedergegeben. :) --Uncle Pain 12:42, 18. Jun. 2009 (CEST)

Danke das Du mir so genau die Unterschiede erklärst hast. Nur das war gar nicht meine Frage! Also: Worin sieht man beim Processexplorer das man es hier mit einem hyperthreadingfähigen Prozessor und nicht mit einem normalen Prozessor zu tun hat? (nicht signierter Beitrag von 92.225.34.9 (Diskussion | Beiträge) 22:01, 5. Jul 2009 (CEST))

Gar nicht, weil das mit den Prozessen und Threads direkt nichts zu tun hat. Das erfährst du besser über CPU-Z. --Uncle Pain 14:31, 13. Jul. 2009 (CEST)

Überschneidung - Das heißt doch SMT

Hyperthreading ist doch soweit ich weiss nur der Marketingbegriff von Intel. Das Fachwort dazu sollte Symmetric Multi Threading (SMT) sein. --Tali 17:09, 14. Jul 2003 (CEST)

Genau, es heißt SMT und SMT ist die Abkürzung für Simultaneous Multithreading, wozu bereits ein Artikel existiert. Warum wird nicht einfach auf den Artikel redirektet? Sogar Intel selbst nennt sein Hyper Threading inzwischen einfach nur SMT, siehe Vorstellung der Core-i7-Prozessoren für den Sockel 1366. --Juri S. 13:26, 21. Mai 2011 (CEST)

Nja, bei Intel sind "echter" Kern und HT-Kern alles andere als gleichberechtigt, das kommt bei x86 wohl erst mit AMDs Bulldozer. Trotzdem habt ihr weitgehend recht, dass eigentlich nicht sooo arg viel dahinter steckt. --arilou 14:52, 26. Mai 2011 (CEST)

Mit echten oder unechten Kernen hat dieser Abschnitt der Diskussion nichts zu tun. Es geht hier darum, dass HTT lediglich ein Marketingbegriff für SMT ist, so dass zwei Artikel völlig unnötig sind und eigentlich das selbe beschreiben. SMT setzt keine "echten" zusätzlichen Kerne voraus, ganz im Gegenteil und deswegen nennt AMD seine Technik der Buldozermodulle ja auch CMT und nicht SMT... --Juri S. 18:18, 26. Mai 2011 (CEST)

Hm, ich gebe zu, dass ich evtl. SMT mit "Hardwareseitiges Multithreading" verwechselt habe. Soweit ich mich erinnere, zielt selbiges v.a. auf den schnellen Task-(oder Thread-)wechsel, v.a. bei RISC-Chips; es geht dabei eher nicht darum, mehr als 1 Thread echt-gleichzeitig auszuführen (also nicht "simultaneous"), sondern ums schnelle Umschalten, mit fertig bereitstehendem Registersatz für die neue Task usw.

--arilou 22:21, 26. Mai 2011 (CEST)

Siehe auch oben unter #Unlogisch und daher zwangsläufig inhaltlich falsch - ein HT-Kern ist nicht gleichwertig zu einem "echten" Kern und liefert daher auch nur ca. 25% von dessen Leistung. Also "asymmetric multi-processing". --arilou (Diskussion) 14:23, 21. Okt. 2013 (CEST)

Da möchte ich mich selbst korrigieren: Die beiden HT-Siblings sind identisch, es sind nicht "ein Haupt- und ein Nebenkern". Sind beide aktiv, so behindern sie sich gegenseitig, sodass statt 200% Rechenleistung bzgl. eines "einzelnen vollständigen Kerns" deutlich weniger erreicht wird; bei Ersteinführung waren das ca. 125% Leistung.

Schaltet man HT ab, so dass jeweils nur 1 Sibling arbeitet - und nicht mehr gestört wird - , so erhält man 100% der 1-Kern-Leistung. Für die Einzel-Thread-Lesitung bedeutet das eine Steigerung von (125% / 2 ~) 62,5% auf 100% .

Daher stimme ich zu: HT war und ist praktisch 2-fach SMT.

--arilou (Diskussion) 10:13, 27. Nov. 2018 (CET)

HT im Bezug auf Spiele?

Der Titel zeigt hier eindeutig was HT aus sicht der Gamer bedeutet und lässt vollkommen jegliche Software außer acht, welche HT wirklich nutzen kann und da auch mehr rausholen kann.

Ob ein Intel Xeon E7 10-Kerner mit oder Ohne Hyper-Threading läuft macht bei Datenbank oder stark-abgefragten Webservern teilweise einen Welten unterschied aus.

Da sprechen wir locker von Unterschieden im Bereich von 30% mehr Geschwindigkeit mit aktiviertem HT und das sind nur die ersten 2 dinge die mir einfallen.

Ich denke nicht jeder kauft sich eine CPU mit 4 Kernen wo durch Hyper-Threading dann 8 Threads draus werden um eine Software auszuführen die zu 90% die GPU auslastet und nebenher ein bisschen auf der CPU rechnet wo dann HT vielleicht 3-5 Frames im Spiel ausmacht (was ja anscheinend für manche das höchste der Gefühle ist).

Ebenfalls spielt die Skalierbarkeit eine große Rolle, auf z.b. 20 ""Virtuelle"" Kerne kann ich Auslastungen wesentlich besser verteilen als auf 10 Kerne.

Zudem Optimieren die Spiele Entwickler auf den der am meisten Zahlt, und nicht auf den der den besten Prozessor herstellt. Ich denke das schlechteste was man nehmen kann um Vorteile-/Nachteile und Beispiele von HT-Nutzung zu Zeigen sind PC-Spiele.

Wenn man nur alleine daran denkt wie viele Standards von den Entwicklern gebrochen werde und wie dreckig da rum-programmiert wird um mit so wenig Arbeit wie möglich ein möglichst großes Ergebnis abzuliefern dann sollte man "solch" eine Software nicht als Beispiel dafür nutzen was eine CPU mit/ohne HT Leisten kann.

Ebenfalls wird hier nicht eindrucksvoll gezeigt das HT kontra-produktiv bei High-Performance Single-Threading Berechnungen ist da ein Prozess, der sonst einen Kern komplett für sich alleine bekommen würde, sich den Kern mit irgend einem anderen Schrott der gerade gesheduled wird, teilen muss.

Es gibt Single-Threading Berechnungen die sogar massiv einbrechen wenn HT aktiviert ist, nicht aber wenn man 8 ""echte"" kerne wie zum Beispiel einem AMD hat weil dort der Prozess den Kern alleine bekommt und ihn nicht teilen muss (bei AMD nur solange es sich um Integer Berechnungen handelt).

Der Artikel erklärt kurz was HT ist und bringt als Beispiele dann nurnoch PC Spiele und die sind mit Abstand die Software die am wenigsten nutzen von HT haben. Vamp898 (Diskussion) 23:00, 17. Okt. 2013 (CEST)

Ist von deinem ganzen Blabla außer WP:TF auch irgend etwas belegbar?

Und dass dein "Welten unterschied" dann maximal 30% sind, tja, da lebst du wohl in einer anderen Welt als ich.

--arilou (Diskussion) 15:41, 18. Okt. 2013 (CEST)

Bezogen auf HT bzw. allgemein für eine Performancesteigerung, die man durch eine einfache BIOS-Setup-Einstellung erreichen kann, sind 30% tatsächlich Welten. Bei den meisten Anwendungen bringt HT 0-10% und HT ist noch eine der Einstellungen, die (abgesehen von FSB-Takt (oder das mikroarchiteturabhängige Äquivalent) und Multiplikator) am meisten bringt (allerdings kann HT bei bestimmten Anwendungen, z,B. bei manchen Spielen, sogar einen leichten Performancerückgang bewirken). --MrBurns (Diskussion) 17:00, 18. Okt. 2013 (CEST)

Wie gesagt, was "Welten" sind, ist Ansichtssache. Einem Datenbank-Techniker, der tagein, tagaus Abläufe optimiert, um Verbesserungen im unteren Prozentbereich zu erreichen, erscheinen 30% natürlich viel. Andere arbeiten eher an Faktoren. Wenn man in seiner tagtäglichen Arbeit Abläufe durch bessere Algorithmen um Faktor 10, 100 oder 1000 beschleunigt, sind +- 30% irgendwo im Peanuts-Bereich.

Und "Performancesteigerung, die man durch eine einfache BIOS-Setup-Einstellung erreichen kann" ist Anweder-Sicht. Frag' mal die Intel-Prozessor-Entwickler, ob sie HT auch als "einfache Einstellung" betrachten... Viele Server-Betreiber haben auch lieber lauter gleichwertige Kerne, als andauernd unterscheiden zu müssen, ob ein Kern jetzt volle Leistung bringt oder ein HT-Kern mit 25% Rechenleistung ist.

Insgesamt sehe ich nicht, wie aus dieser Diskussion eine Verbesserung des Artikels entstehen könnte?

--arilou (Diskussion) 10:33, 21. Okt. 2013 (CEST)

Für den Anwender ist es eine einfache BIOS-Einstellung. Wie viel Auwand Intel dafür betreiben muss ist eigentlich nur für Intel bzw. Intel-Mitarbeiter interessant. --MrBurns (Diskussion) 13:43, 21. Okt. 2013 (CEST)

HT-kompatibler Maschinencode

Bei folgendem Absatz frage ich mich, in wie fern ein Compiler extra Binärcode für Hyperthreading erzeugen soll?

„Compiler, die Code mit Hyper-Threading-Unterstützung erzeugen können, sind die Intel-Compiler und die GNU Compiler Collection. Hyper-Threading bringt jedoch nur für Anwendungen einen Geschwindigkeitsvorteil, deren Berechnungen parallelisierbar sind, das heißt die Berechnung eines Threads ist nicht abhängig vom Ergebnis eines anderen.“

Oder inwiefern er sich von "Nicht-HT Code" unterscheiden soll, schließlich ist es ein Feature des Prozessors mit Unterstützung des Betriebssystems. In wie fern spielt da der Binärcode einer Software eine Rolle? Meiner Meinung nach gar keine. Mir ist auch nicht bekannt, dass es bei GCC eine Möglichkeit gibt, extra für HT-Prozessoren Code zu erzeugen bzw. das es einen Kommandozeilen-Schalter dafür gibt. Es existiert auch keine Quellenangabe für diese Behauptung.

--Sebi2020 (Diskussion) 13:48, 2. Jun. 2017 (CEST)

Soviel ich weiß muss ein Code nur mehr Threads haben, als der Prozessor Kerne hat, damit die CPU Hyperthreading nutzen kann, also bei einem Einkernprozesor mindestens 2, bei einem Zweikernporzesor mindestens 3, bei einem Vierkernprozessor min. 5, usw. Optimal wären doppelt so viele Threads wie Kerne. außerdem ist tatsächlich eine Optimierung möglich, damit Hyperthreading auch einen Leistungsvorteil bringt, bei nicht optimierten Anwendungen führt HT eher zu einem leichten Leistungseinbruch, was man z.B. bei frühen Spielebenchmarks gesehen hat. --MrBurns (Diskussion) 04:03, 3. Jun. 2017 (CEST)

Die Frage ist ja, was hier optimiert heißt, schließlich entscheidet ja nicht die Anwendung sondern das System und der Prozessor, wie geteilte Ressourcen vergeben werden. Weiterhin ist ja vorher nicht bekannt welcher Teil welche Ressourcen wann zugeteilt bekommt. Daher könnte die Optimierung ja höchstens dahingehend funktionieren, dass möglichst nicht Speicherintensiv gearbeitet wird um konkurrierende Cache-Zugriffe zu vermeiden. Das wäre aber auch eine Optimierung auf die eher der Programmierer als ein Compiler Einfluss nehmen kann. --Sebi2020 (Diskussion) 21:01, 3. Jun. 2017 (CEST)

Das ist eine Möglichkeit, man kann aber auch statistische Analysen verwenden. --MrBurns (Diskussion) 00:10, 4. Jun. 2017 (CEST)

Wie auch immer, nichtsdestotrotz fehlt für diese Behauptung eine Quellenangabe --Sebi2020 (Diskussion) 17:49, 8. Jun. 2017 (CEST)

Das Besondere an HT-geeignetem Maschinencode gegenüber einfachem Multi-Threaded-Code ist, dass in HT-Code der Compiler darauf achtet, dass ein Thread nicht eine CPU-Ressource (z.B. die FPU) dauerhaft (viele Befehle lang) belegt, sondern dazwischen Befehle eingeschoben werden, die andere Ressourcen belegen (und die FPU zwischendurch auch mal wieder freigeben).

Ansonsten könnte ein Thread einen anderen erheblich blockieren; außerdem hat der CPU-Kern dann ausreichend verschiedenartige Befehle, um per Out-of-order execution noch weiter zu optimieren - wenn beide (non-HT-)Threads nur FPU-Befehle "anbieten", hat die OoO-Unit keine Chance, da noch irgend etwas im Ablauf günstiger zu gestalten.

--arilou (Diskussion) 11:39, 3. Jul. 2017 (CEST)

PS: Es geht natürlich immer um die gemeinsam verwendeten Ressourcen; daher sind Cache-Probleme nichts HT-spezifisches, sondern gelten stets für Mehrkern-CPUs, ab dem Cache-Level, ab dem sich die Kerne den Cache teilen.

PPS: Da das Mischen verschiedener Befehlstypen nicht nur für HT, sondern auch für OoO-Ex. vorteilhaft ist, und auch bei 'normalem' Mehrkernbetrieb zumindest keinen Nachteil darstellt, kann ich mir gut vorstellen, dass es beim Compiler keinen Parameter gibt, der speziell mit "Hyperthreading-Optimierung" gekennzeichnet ist. Vielleicht steht ja bei OoO-spezifischen Flags was zu HT?

Nachteile und Sicherheitsprobleme

Im Artkel fehlt eine Information über Sicherheitsprobleme, speziell im Zusammenhang mit Meltdown/Spectre. In einigen Linux Distries wird HTT sogar abgeschaltet (nur bei Intel?) aufgrund der entdeckten Sicherheitsprobleme/Bugs in den Prozessoren. --Denniss (Diskussion) 08:10, 27. Nov. 2018 (CET)

Nunja, im Prinzip stimme ich zu - wenn sich Informationen bzgl. Spectre- und Meltdown-Varianten finden lassen, die speziell auf HT bezogen sind.

Allerdings sind diese Sicherheitslücken für Privatpersonen sowieso ziemlich uninteressant, und betreffen vor allem Profis wie z.B. (Web-)Hosting-Betreiber. Wer Server-Dienste für Fremde/Dritte in virtuellen Maschinen betreibt, wird wohl Fachzeitschriften lesen und kaum hier nachschlagen.

Also: Ja, gerne, aber ich seh' das nicht als dringliches Artikel-Problem.

--arilou (Diskussion) 10:01, 27. Nov. 2018 (CET)

Hast du eventuell Hyperthreading mit out-of-order execution verwechselt? Das sind unterschiedliche Dinge. --MrBurns (Diskussion) 11:31, 27. Nov. 2018 (CET)

HTT macht durch die Implementierung seitens Intel die Seitenkanalattacken (Spectre/TLBleed) wohl einfacher ausnutzbar bzw überhaupt möglich Bericht bei Bleepingcomputer. --Denniss (Diskussion) 18:44, 27. Nov. 2018 (CET)

Ja, aber. Der gesamte Komplex "Spectre/TLBleed/Meltdown" ist nur in wenigen Fällen relevant/gefährlich, für Privatpersonen sowie Menschen am Büroarbeitsplatz praktisch niemals. Nur für Server-Betreiber, und auch nur für jene, die virtuelle Server vermieten.

Das sind daher Detail-Informationen, die nur für echte Profis interessant und wichtig sind. Die lesen das nicht in der WP nach, sondern in Fachliteratur und -Zeitschriften.

Wie ich schon sagte: Gerne, aber ich seh' das nicht als dringliches Artikel-Problem.

--arilou (Diskussion) 16:20, 26. Jul. 2019 (CEST)