i7 920, hyperthreatingfrage

[SleepySlow]

ahoi zusammen!

laut gamestarbericht (klick) ist hyperthreating in den meisten spielen eine bremse und lediglich beim multitasking interessant.

soll ich eurer meinung nach nun hyperthreating im bios deaktivieren, oder eingeschalten lassen?

danke schon mal für eure antwort.

[pajaa]

Hi,

Wenn du mit dem Rechner nur spielst, kann es je nach Spiel wirklich mehr fps bringen, wenn du das Hyperthreading bzw das SMT, wie Intel es nun nennt, abschaltest.
Wenn du das System noch nicht hast, würde ich an deiner Stelle auf einen i5/P55 setzen.

[highko]

ist völlig banane, weil der unterschied nie und nimmer bei irgendeinem aktuellen game ins gewicht fällt.

[mr.dude]

soll ich eurer meinung nach nun hyperthreating im bios deaktivieren, oder eingeschalten lassen?

Wenn du dir diese Frage schon stellst, dann kaufe dir besser einen Prozessor ohne Hyperthreading.

[Fürchterlich]

kannst ruhig anlassen, fällt bei aktuellen grafiklastigen Spielen nicht ins Gewicht.

[X909]

Und bei Windows 7 gibts auch keine nennenswerten Performanceeinbußen mehr wenn SMT = on.

[SleepySlow]

alles klar, vielen dank für eure antworten

[madjim]

ist völlig banane, weil der unterschied nie und nimmer bei irgendeinem aktuellen game ins gewicht fällt.

Das stimmt so nicht.

Fast Alle Games laufen mit SMT langsamer. WoW zB sogar bis zu 30%.

Nur weniger Games profitieren von SMT, zB Anno 1404.

Ich habe SMT abgeschaltet. Damit basta.

[Opteron]

Abschalten oder die Game Prozesse mit diversen Tools an die Kerne festzurren.

[SleepySlow]

Abschalten oder die Game Prozesse mit diversen Tools an die Kerne festzurren.

heißt bei dir "anzurren" die prozesse mittels taskmanager an prozessorkerne anzu"tackern", oder können deine tools was anderes?

[KOKOtm]

Das stimmt so nicht.

Fast Alle Games laufen mit SMT langsamer. WoW zB sogar bis zu 30%.

Nur weniger Games profitieren von SMT, zB Anno 1404.

Ich habe SMT abgeschaltet. Damit basta.

WoW nutzt nur standardmäßig die falschen Kerne (1 echten, 1 Virtuellen). Kein Wunder, das dann Einbußen entstehen.

http://www.wowwiki.com/CVar_processAffinityMask

mit

SET processAffinityMask "85"

werden z.B. alle 4 echten Kerne genutzt, da ist nichts mehr mit Einbußen.

Ebenso in Verbindung mit http://www.wowwiki.com/CVar_timingMethod

set timingMethod "2"

zu nutzen.

[SleepySlow]

ungeachtet der tatsache, dass sich dieser kleiner ausflug auf ein einziges spiel bezieht, meine frage jedoch wesentlich allgemeiner formuliert war, stellt sich mir die frage, wieso du [SET processAffinityMask "85"] angibst, obwohl auf wiki für i7 255 empfohlen wird?

und alle 4 echten kerne wiederrum, wie du schreibst, müssten also eigentlich mit "7" laufen.

oder habe ich da was falsch verstanden?

[mr.dude]

255 (dezimal) = 11111111 (binär)

Hier sind also alle logischen Prozessoren des i7 maskiert. Was dir nicht weiterhilft, da das sowieso das Standardverhalten ist.

Keine Ahnung, wie Windows die logischen Prozessoren ordnet. Nehmen wir mal an, sie sind entsprechend den Kernen geordnet, was wohl am wahrscheinlichsten ist. Also realer Prozessor -> fake Prozessor -> realer Prozessor -> fake Prozessor -> usw. Dementsprechend müsste die Affinity Mask wie folgt aussehen:

01010101 (binär) = 85 (dezimal)

Eben wie von KOKOtm bereits erwähnt.

[X909]

Wie bereits erwähnt, der Scheduler von Windows 7 ist da "geheilt" und lastet erst die CPU 0 und dann 2-4-6 aus, bevor er auf die 1-3-5-7 geht.

Ansosten helfen auch Easytoolz, ein kleines aber feines Progrämmchen. Weiß aber nicht wo man das noch her bekommen kann.

[mr.dude]

Wie bereits erwähnt, der Scheduler von Windows 7 ist da "geheilt" und lastet erst die CPU 0 und dann 2-4-6 aus, bevor er auf die 1-3-5-7 geht.

Nun ja, "Heilung" kann man das nicht direkt nennen. Eine solche Vorgehensweise wird das Problem lediglich mindern, aber nicht komplett beseitigen.

[X909]

Warum? Damit wird die Last zuerst auf alle Kerne verteilt und HyperThreading dann genutzt, wenn es auch etwas bringt.

[FidelZastro]

Was ist eigentlich Hyperthreating? Ist das das, was man tun muss, um ziel eines präventivschlags der Amerikaner zu werden?

[mr.dude]

Warum?

Weil man für eine komplette Lösung die aktuelle Auslastung überwachen müsste. Nehalem kann das nicht. Und Windows 7 hat meines Wissens nach so etwas ebenfalls nicht implementiert. Bleibt am Ende zusätzlich das Problem, dass SMT halt keine wirklich optimale Lösung für Hardware Multithreading ist. Die Execution Units sind eben nur einmal vorhanden pro Kern. Da kann der Thread Scheduler noch so clever sein. Im schlimmsten Fall klauen sich die Pipelines die Execution Units weg und behindern sich gegenseitig.

[KOKOtm]

Wie bereits erwähnt, der Scheduler von Windows 7 ist da "geheilt" und lastet erst die CPU 0 und dann 2-4-6 aus, bevor er auf die 1-3-5-7 geht.

Ansosten helfen auch Easytoolz, ein kleines aber feines Progrämmchen. Weiß aber nicht wo man das noch her bekommen kann.

Ja, solange andere Programme es nicht überschreiben, so wie WoW es ja mit der 3 (11000000) macht ... also 1 physikalischer, ein logischer Kern.

Die HT Kerne will ich gar nicht mit angeben, die können von mir aus die Hintergrundprozesse haben.

[X909]

Wenn ein Programm natürlich von Haus aus eine CPU-Affinity mitbringt, kann das nachteilig sein. Das ist richtig.

@ mr.dude

Deine "Nachteile" von HT sind keine, denn diese Effekte treten bei sauberer Lastverteilung durch Windows nur dann ein, wenn tatsächlich mehr Threads als physische Kerne Last erzeugen. Und genau dann erhöht HT den Durchsatz. Die Execution Units sind i.d.R. zu maximal etwa 30% ausgelastet, die "Breite" des Backends reicht locker für 2 Threads aus.

[fromhell101]

Also ich kann keinen wirklichen unterschied merken wenns an ist.

[mr.dude]

Deine "Nachteile" von HT sind keine, denn diese Effekte treten bei sauberer Lastverteilung durch Windows nur dann ein, wenn tatsächlich mehr Threads als physische Kerne Last erzeugen. Und genau dann erhöht HT den Durchsatz. Die Execution Units sind i.d.R. zu maximal etwa 30% ausgelastet, die "Breite" des Backends reicht locker für 2 Threads aus.

Nein. Erstens, wie gesagt, so intelligent, dass der Thread Scheduler immer auf die richtigen logischen Prozessoren verteilt, ist Windows nicht. Auch nicht Windows 7. Denn dafür müsstest du eine ausgiebige Last Analyse durchführen. Das macht weder die Hardware noch die Software. Und zweitens, völlig unabhängig davon, wenn 2 Threads auf einen Kern und damit die gleichen Execution gleichzeitig zugreifen, sperren sie sich gegenseitig. Gut zu beobachten bei HPC Workloads. SMT ist ja dafür da, die Execution Units besser auszunutzen. Sind diese schon gut ausgelastet, kann das auch nach hinten losgehen. Diese Nachteile sind also sehr real und in Studien nachgewiesen.
Allerdings sollte man auch dazu sagen, die Intel Implementierung ist relativ mies. IBMs SMT Implementierung ist zB um einiges besser. Es kommt auch nicht von ungefähr, dass AMD kein SMT implementieren wird. Das inkonsistente Performance Profil ist eben ein gewichtiger Nachteil.

[madjim]

Nein. Erstens, wie gesagt, so intelligent, dass der Thread Scheduler immer auf die richtigen logischen Prozessoren verteilt, ist Windows nicht. Auch nicht Windows 7. Denn dafür müsstest du eine ausgiebige Last Analyse durchführen. Das macht weder die Hardware noch die Software. Und zweitens, völlig unabhängig davon, wenn 2 Threads auf einen Kern und damit die gleichen Execution gleichzeitig zugreifen, sperren sie sich gegenseitig. Gut zu beobachten bei HPC Workloads. SMT ist ja dafür da, die Execution Units besser auszunutzen. Sind diese schon gut ausgelastet, kann das auch nach hinten losgehen. Diese Nachteile sind also sehr real und in Studien nachgewiesen.
Allerdings sollte man auch dazu sagen, die Intel Implementierung ist relativ mies. IBMs SMT Implementierung ist zB um einiges besser. Es kommt auch nicht von ungefähr, dass AMD kein SMT implementieren wird. Das inkonsistente Performance Profil ist eben ein gewichtiger Nachteil.

Seit längerem eine nachvollziehbare Antwort.

SMT oder HT wie man es auch nennen mag hatte aus Intel Sicht nur einen wirklichen Sinn: Die Programme auf Multithreading vorzubereiten.
Erst kam mit dem P4 HT. Als dann die ersten "echten" 2 Kerner auf dem Markt kamen, verschwand HTwieder.
Jetzt da Dualcore sich etabliert hat ist der nächste Schritt auf 8 oder gar 16 Cores. Deswegen SMT.

[X909]

Nein. Erstens, wie gesagt, so intelligent, dass der Thread Scheduler immer auf die richtigen logischen Prozessoren verteilt, ist Windows nicht. Auch nicht Windows 7. Denn dafür müsstest du eine ausgiebige Last Analyse durchführen. Das macht weder die Hardware noch die Software.

Windows 7 verteilt so lange auf je eine logische CPU jedes Kerns, bis genügend Parallelität möglich ist um (am Beispiel des i7) 4 logische CPUs auszulasten. Stehen beispielsweise genug Threads für 5 CPUs zur Verfügung, nutzt der Scheduler die freien Ressourcen der übrigen logischen Threads.

Und zweitens, völlig unabhängig davon, wenn 2 Threads auf einen Kern und damit die gleichen Execution gleichzeitig zugreifen, sperren sie sich gegenseitig. Gut zu beobachten bei HPC Workloads. SMT ist ja dafür da, die Execution Units besser auszunutzen. Sind diese schon gut ausgelastet, kann das auch nach hinten losgehen. Diese Nachteile sind also sehr real und in Studien nachgewiesen.

Sie sperren sich nicht gegenseitig sondern sie werden intern abwechselnd abgearbeitet. Dabei werden "Lücken" im µOP-Strom bzw. Stalls gefüllt (wenn ein Thread warten muss, läuft der andere) und dadurch kann der Durchsatz bei Vollast um etwa 30% gesteigert werden.

Es gibt tatsächlich auch Ressourcen, die geteilt werden müssen. Daher ist keine 100%ige Skalierung möglich.

Allerdings sollte man auch dazu sagen, die Intel Implementierung ist relativ mies. IBMs SMT Implementierung ist zB um einiges besser. Es kommt auch nicht von ungefähr, dass AMD kein SMT implementieren wird. Das inkonsistente Performance Profil ist eben ein gewichtiger Nachteil.

Ob Intels Implementierung mieß ist liegt nicht in meinem (unserem?) Ermessen. Intel gibt nur sehr wenig zusätzliche Ressourcen (Transistoren = DIE-Fläche = Stromverbrauch) für SMT aus. Es geht darum, brach liegende Ressourcen noch zu nutzen. Bei IBM ist die Intention eine andere, daher wird auch anders Designed.

SMT ist eine der wirtschaftlichsten Methoden mehr Durchsatz aus einer CPU zu quetschen! Klar gibt es bestimmte (seltene) Fälle, in denen HT etwas Performance kostet - dann i.d.R. 1-3%. Echte Nachteile hat man aber nur, wenn ein Scheduler a la Vista oder älter benutzt wird. Die Vorteile wenn man hohe Parallelität hat, ist wesentlich durchschlagender.

Immer dann wenn z.B. 8 Statt 4 logische CPUs des i7 genutzt werden, kann ich deutlich bessere Leistungswerte bei verhältnissmäßig geringem Mehrverbrauch messen.

Wusstest Du, dass Prime etwa 30% zulegt? Folding@Home ein viertel schneller arbeitet und man beim Encoden/Packen/Ver-/Entschlüsseln deutliche Performancezuwächse verzeichnen kann?

Nicht umsonst wird in Reviews üblicherweise betont, dass der i7 gerade bei starkem Multithreading besonders davonzieht.

---------- Beitrag hinzugefügt um 20:17 ---------- Vorheriger Beitrag war um 20:14 ----------

Als dann die ersten "echten" 2 Kerner auf dem Markt kamen, verschwand HTwieder.

HT wurde bis zuletzt in Extreme und Xeon CPUs genutzt. Dann musste man mit dem Core2 technologisch neu ansetzen, da das HT-fähige Netburst Design aufgegeben wurde.

Als nächster logischer Schritt wurde Core2 HT-fähig gemacht und zusammen mit vielen weiteren Änderungen als i7 verkauft

[mr.dude]

Windows 7 verteilt so lange auf je eine logische CPU jedes Kerns, bis genügend Parallelität möglich ist um (am Beispiel des i7) 4 logische CPUs auszulasten. Stehen beispielsweise genug Threads für 5 CPUs zur Verfügung, nutzt der Scheduler die freien Ressourcen der übrigen logischen Threads.

Quelle? Ich glaube eher, dass du dir da zu viel ausdenkst bzw zu viel Wunschdenken im Spiel ist.

Sie sperren sich nicht gegenseitig sondern sie werden intern abwechselnd abgearbeitet. Dabei werden "Lücken" im µOP-Strom bzw. Stalls gefüllt (wenn ein Thread warten muss, läuft der andere) und dadurch kann der Durchsatz bei Vollast um etwa 30% gesteigert werden.

Nein. Du scheinst dich mit CPU Frontend und Backend nicht wirklich auszukennen. Wie wollen sich zwei Frontends im selben Takt eine Execution Unit teilen? Es geht schlichtweg nicht. Es ist Fakt, dass sich mehrere Pipelines gegenseitig Execution Units wegnehmen können, je nach Anwendung. Da brauchst du nichts gegenteiliges erfinden. Ich habe eher das Gefühl, hier wird wieder mal versucht, sich den i7 schön zu reden anstatt Tatsachen zu akzeptieren.

SMT ist eine der wirtschaftlichsten Methoden mehr Durchsatz aus einer CPU zu quetschen! Klar gibt es bestimmte (seltene) Fälle, in denen HT etwas Performance kostet - dann i.d.R. 1-3%. Echte Nachteile hat man aber nur, wenn ein Scheduler a la Vista oder älter benutzt wird. Die Vorteile wenn man hohe Parallelität hat, ist wesentlich durchschlagender.

Grob rechnet man bei Intels SMT Implementierung mit -10% bis +30%. Aber du scheinst es immer noch nicht verstanden zu haben. Wenn SMT Performance kostet, muss das nicht unbedingt am Thread Scheduler liegen. Es liegt teilweise an der SMT Implementierung selbst.


Btw, ich würde empfehlen, dir mal Dresdenboys Blog anzuschauen. Da findest du auch einiges zu den Problemen von SMT.