SleepySlow
Neuling
Thread Starter
- Mitglied seit
- 19.08.2009
- Beiträge
- 30
Follow along with the video below to see how to install our site as a web app on your home screen.
Anmerkung: this_feature_currently_requires_accessing_site_using_safari
Wenn du dir diese Frage schon stellst, dann kaufe dir besser einen Prozessor ohne Hyperthreading.soll ich eurer meinung nach nun hyperthreating im bios deaktivieren, oder eingeschalten lassen?
ist völlig banane, weil der unterschied nie und nimmer bei irgendeinem aktuellen game ins gewicht fällt.
Abschalten oder die Game Prozesse mit diversen Tools an die Kerne festzurren.
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.
Nun ja, "Heilung" kann man das nicht direkt nennen. Eine solche Vorgehensweise wird das Problem lediglich mindern, aber nicht komplett beseitigen.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.
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.Warum?
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.
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.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.
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.
Als dann die ersten "echten" 2 Kerner auf dem Markt kamen, verschwand HTwieder.
Quelle? Ich glaube eher, dass du dir da zu viel ausdenkst bzw zu viel Wunschdenken im Spiel ist.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.
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.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.
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.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.
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.
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.