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.

 

[Boogyman]

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.

Bei mir löscht das Spiel die Einstellungen einfach wieder raus, keine Ahnung warum.

 

[KOKOtm]

Bei mir löscht das Spiel die Einstellungen einfach wieder raus, keine Ahnung warum.

Hallo. Die Quelle, wo ich das her hatte sagte damals, man solle die config.wtf einfach schreibschützen. Komischerweise muss ich das nicht, bei mir lief es auch so. Dachte erst an einen veralteten Artikel und WoW hat dieses Verhalten nicht mehr. Liegt vielleicht auch daran, das ich WoW einfach nur noch starte, ohne das es jemals installiert worden ist...oder oder oder. Alles Vermutungen. Denke Schreibschutz hilft erstmal.

Aber um es jetzt wirklich mal auf das Wesentliche zu komprimieren, denn Performance per Die-Größe und Wirtschaftlichkeit wurde hier nicht gefragt, sondern ob SMT(HT) an oder aus ist:

AN: Auf alle Fälle bei Windows 7. Guter Artikel btw, der da oben irgendwo als Quelle für den Sheduler gepostet wurde.

AUS: Bei irgendwelchen schlecht programmierten Spielen, wo man dann tatächlich mit 30% Leistungseinbußen zu rechnen hat und immer noch über 60fps hat...nein, dann doch lieber an. Also wenn Du an der Stottergrenze spielst, mach es halt aus. Wenns noch mehr stottert, dann machs wieder an, aber in der Regel lass es AN.

 

[Boogyman]

Hallo. Die Quelle, wo ich das her hatte sagte damals, man solle die config.wtf einfach schreibschützen. Komischerweise muss ich das nicht, bei mir lief es auch so. Dachte erst an einen veralteten Artikel und WoW hat dieses Verhalten nicht mehr. Liegt vielleicht auch daran, das ich WoW einfach nur noch starte, ohne das es jemals installiert worden ist...oder oder oder. Alles Vermutungen. Denke Schreibschutz hilft erstmal.

Aber um es jetzt wirklich mal auf das Wesentliche zu komprimieren, denn Performance per Die-Größe und Wirtschaftlichkeit wurde hier nicht gefragt, sondern ob SMT(HT) an oder aus ist:

AN: Auf alle Fälle bei Windows 7. Guter Artikel btw, der da oben irgendwo als Quelle für den Sheduler gepostet wurde.

AUS: Bei irgendwelchen schlecht programmierten Spielen, wo man dann tatächlich mit 30% Leistungseinbußen zu rechnen hat und immer noch über 60fps hat...nein, dann doch lieber an. Also wenn Du an der Stottergrenze spielst, mach es halt aus. Wenns noch mehr stottert, dann machs wieder an, aber in der Regel lass es AN.

Wie sehe ich allgemein, ob es etwas gebracht hat? Im Falle von Spielen, zeigt ja z.B. der Task Manager beim switch auf den Desktop keine Prozessor Belastung mehr durch das jeweilige Programm an, die kommt ja erst wieder, wenn ich zurück ins Spiel wechsel.

 

[pajaa]

@mr.dude&Untertaker_1
Ich habe soeben alle fraglichen Posts von euch entfernt.

 

[X909]

@mrdudes post auf der ersten seite

Ich bin zu Faul (vor allem mit dem PPC) im Detail zu antworten. Einigen wir uns auf "Du hast Recht und ich mei Ruhe"

Kannst Dich ja bei Gelegenheit genauer Informieren. Im 3dcenter Forum sind Leute unterwegs, die recht gut in der Materie sind. Schau Dir auch mal die Breite des Backends aktueller CPUs und die praktisch erreichbare IPC rate eines Threads an. Flussdiagramme können helfen um zu erkennen, dass die Auslastung "hinten" nur besser werden kann wenn von vorne mehr kommt Es geht dabei um den Gesamtdurchsatz, nicht um die pro-thread-power.


Mit Windows 7 habe ich natürlich selbst getestet.