Diskussion:Hyper-Threading
aus Wikipedia, der freien Enzyklopädie
Warum kann der neue Core 2 Duo kein HYperthreading, obwohl die Technologie neuer ist? ICh dachte, ich finde auf dieser Seite die Antwort dazu. Ist die Technologie bereits veraltet? Karoschne 18:37, 20. Jul 2006 (CEST)
- Weil Hyper-Threading eher ein Bugfix für den P4 war. Aufgrund seiner überlangen Pipeline kam es öfter vor das die Recheneinheiten nicht immer ausreichend mit Daten gefüttert wurden. Mit HTT konnten diese immer schön gefüllt bleiben und somit erhöhte sich die Rechenleistung. --Denniss 22:33, 20. Jul 2006 (CEST)
- Immer wieder der selbe Schmarrn. Hyperthreading ist kein Bugfix und auch nicht veraltet. Es ist einfach nur Intels Implementierung von hardwareseitigem Multithreading nach dem Schema simultanes Multithreading in der Netburst-Architektur. Es ist Parallelverarbeitung auf Thread-Ebene. Es ist eine Technik aus den 80ern. Es wird nicht weniger oder mehr sinnvoll durch eine bestimmte Pipeline-Länge. Es dient einfach nur dazu, in der Mikroarchitektur liegende Ressourcen zur Parallelverarbeitung auch mehreren gleichzeitig parallel laufenden Befehls- und Datenströmen zugänglich zu machen. Ist das denn wirklich so schwer zu verstehen? Der Artikel gibt euch doch alle Informationen in die Hand. Bei NetBurst gab es mal die schöne Rechnung, dass für nur 5% mehr Diefläche ein Durchsatzgewinn von potenziell bis zu 20% zu erwarten ist. Daher war es sinnvoller, diese Technik zu implementieren, als mehr Cache, tiefere Puffer oder mehr Ausführungseinheiten etc. zu verbauen. SMT ist immer sinnvoll, da keine Mikroarchitektur einer general purpose CPU ideal auf alle Anforderungen jedes Codes zugeschnitten werden kann. Momentan ist die Software aber noch nicht weit genug, als dass es wirklich viel Sinn ergeben würde, wenn man auch Multicore-CPUs wieder mit SMT ausstatten würde (Sun und IBM haben andere Anforderungen zu bedienen als die x86-Welt). Wenn schon ganze Kerne oft leerlaufen, kann sich auch kein Gewinn durch SMT einstellen. SMT wird aber wieder kommen.
- p.s. SMT erhöht auch keine Rechenleistung! Das geht gar nicht, da ja keine zusätzlichen Ausführungseinheiten durch SMT herbeigezaubert werden. SMT kann nur den Durchsatz erhöhen, eben durch Parallelverarbeitung, die sonst brachliegende Ressourcen einsetzt. Nachteile wie Cache Thrashing (ja, mit "h") und die erhöhte Verwaltungsarbeit können aber auch Leistung kosten (hier stimmt der Begriff Leistung wieder). Immer dieses Geflame gegen SMT, nur weil man es nicht versteht... --Endorphine 21:22, 5. Dez. 2006 (CET)
- Bugfix für den P4 gehört eher in Anführungszeichen, der P4 war ja nicht fehlerhaft aber aufgrund seiner recht langen Pipeline hatte er doch öfter mit Pipelinestalls zu kämpfen. Beim P4 brachte Hyper-Threading doch schon recht viel indem es die nicht doppelt vorhandenen Rechenwerke besser auslastete. Allem Anschein nach bringt HTT ja nicht viel bei Prozessoren mit vergleichsweise kurzen Pipelines denn sonst wären die z.B. beim A64/Opteron oder Pentium M/Core/Core2 auch enthalten. Wobei es ja Spekulationen gibt dass es bei späteren Generationen bei Intel wieder reinkommen könnte. --Denniss 23:15, 5. Dez. 2006 (CET)
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)
Meiner Erfahrung nach bringt HT garnichts. Ich habe einen Dual Xeon 604 mit Hyperthreading. Linux (SuSE 8.2, uname -a: "Linux riedquat 2.4.20-64GB-SMP #1 SMP Sat Feb 7 02:07:52 UTC 2004 i686 unknown unknown GNU/Linux") meldet 4 CPUs.
Benchmarks sind c/s real OpenBSD Blowfish
Zahlenliste: Benchmarks pro john-Prozess
Klammern: (Summe, Durchschnitt)
john 1x: 382 (382, 382)
john 2x: 382, 383 (765, 382.5)
john 4x: 196, 70.8, 71.4, 203 (541.2, 135.3)
Ich kann keinen Performance-Gewinn durch Hyperthreading sehen, eher das Gegenteil. Klar dass bei john 4x der Schnitt runter geht. Aber zumindest sollte der Schnitt nicht unter der Hälfte des 2x-Schnitt liegen, und die Summe nicht so deutlich darunter.
Hat jemand Erfahrungen diesbezüglich mit Linux / GCC?
Wie sieht das ganze unter anderen OS aus (BSD, Windows)?
Im Augenblick sieht es für mich so aus, als ob der Kauf des Dual Intel Xeon 604 eine Fehlentscheidung war und ich besser zu einem Dual AMD Athlon MP gegriffen hätte bzw. man heute besser einen Dual AMD Opteron nehmen würde.
--ChristianHujer 19:31, 12. Apr 2004 (CEST)
- Aktuell wohl noch besser: Auf die DualCore-Opterons warten ;-) --ChristianHujer 10:24, 3. Sep 2004 (CEST)
Inwiefern muss eigentlich ein Compiler Hyperthreading unterstuetzen um es nutzen zu koennen? Reicht es nicht, multithreaded zu programmieren? -- twm
Soviel ich weiß, gilt folgendes:
- Theoretisch reicht Multithreaded-Programmierung und SMP-Unterstützung im Betriebssystem
- Normal compilierter Code läuft auf einem Pentium IV oder Xeon 604 parallel mit Hyperthreading meiner Erfahrung nach langsamer als hintereinander (urgs!)
- Es handelt sich nicht um 2 CPUs, sondern nur das Simulieren von 2 CPUs mit Hilfe des Aufteilens von CPU-Resourcen.
- Damit Instruktionen mittels Hyperthreading parallelisiert werden können, müssten sie von ihrer Natur (nicht Reihenfolge) her grundsätzlich schonmal parallelisierbar sein. Zwei FPU-Instruktionen gleichzeitig geht nicht, zwei INT-Instruktionen dagegen schon (afaik 1 FPU aber 2 ALUs im Pentium IV bzw. Xeon).
- Einfach HT-optimierter Code verteilt die Instruktionen so, dass für den Fall, dass gleichzeitig ein ebenfalls HT-optimierter Code läuft, möglichst viel Code parallelisiert werden kann. D.h. "plump" gesagt statt 5 FPU-Instruktionen und danach 5 INT-Instruktionen werden diese abgewechselt (sofern die Programmlogik dies zulässt).
- Speziell HT-optimierter Code läuft auch ohne SMP-Betriebssystem und kann mit Hilfe interner "Lightweight-Threads" Aufgaben parallelisieren.
Alles nur graue Theorie, leider sind auf der Intel Website die Informationen zu den CPUs nicht so leicht zu finden wie z.B. bei Motorola, und ich verliere immer so schnell die Geduld...
ChristianHujer 22:19, 20. Apr 2004 (CEST)
- Wie bitteschön soll man mit leichtgewichtigen Threads HT nutzen können? --Tali 11:33, 1. Sep 2004 (CEST)
- Voraussetzung dafür ist, dass das Anwendungsprogramm einen Teil außerhalb des Userspace z.B. in Form eines Treibers besitzt, welcher die privilegierten CPU-Instruktionen nutzen kann, welche normalerweise nur im Supervisor-Mode verwendbar sind, um einen eigenen Scheduler für die Threads zu installieren. Allerdings sind Betriebssysteme ohne SMP-Unterstützung heutzutage eher die Ausnahme. Gilt natürlich nur, wenn man unter Lightweight-Thread jede Form von Thread versteht, die insbesondere aus Sicht des Betriebssystems weniger Verwaltungsaufwand als ein vollwertiger Prozess bedeutet. --ChristianHujer 10:24, 3. Sep 2004 (CEST)
An den Verfasser des Eintrags: 'Ressource' im Deutschen mit Doppel-s.
- Danke für den Hinweis :-)
ein thread ist ein "lightweight process", nichts sonst! das klärt was, hoffe ich ;)
Bitte beim Editieren des Artikels beachten: Hyperthreading kann nur den Durchsatz erhöhen, jedoch nicht die Leistung! Es kann mit Multithreading/Multitasking mehr pro Zeiteinheit verarbeitet werden, Code an sich wird jedoch nicht schneller ausgeführt als ohne Hyperthreading. Endorphine 23:16, 10. Jul 2006 (CEST)
[Bearbeiten] HyperThreading geht nicht mit zwei Speicher-Bänken - warum?
In meinem Asus Board P5WD2 Premium mit Pentium D 3,4 GHz funktioniert Windows (XP oder 2003 Server Enterprise) mit einer Bank (2 Speichermodule) mit 2 GB (2 x 1 GB). Sobald ich die zweite Speicherbank auffülle und somit 4 GB habe, stürzen beide Windows Versionen beim Starten ab, wenn Hyperthreading im BIOS aktiviert ist. Ohne Hyperthreading funktioniert alles wunderbar. Weiß jeamnd warum? Gibt es ein Workaround, damit ich mit beiden Bänken (4GB) HTT einsetzen kann? --85.181.21.189 04:33, 18. Aug 2006 (CEST) René
