Archiv verlassen und diese Seite im Standarddesign anzeigen : "Die meisten Computerspiele profitieren nicht von Hyper-Threading, im Gegenteil: Die"
Die meisten Computerspiele profitieren nicht von Hyper-Threading, im Gegenteil: Die Mehrheit der Spiele büßt sogar etwas an Performance ein. Es gibt allerdings auch Ausnahmen wie Anno 1404. (Zitat von http://de.wikipedia.org/wiki/Hyper-Threading)
Stimmt das immer noch?
boxleitnerb
2010-09-04, 19:53:15
Würde mich auch interessieren. Vor allem bei Zweikernern mit HT.
Das stimmt bei Windows 7 nicht mehr - bei Linux und Mac-OS weiss ich es nicht.
Win7 nutzt erst alle "realen" Core - die virtuellen HT Cores werden geparkt.
http://www.drdobbs.com/go-parallel/blog/archives/2010/02/core_parking_in.html;jsessionid=4KAIKNVZE0YKPQE1GHPSKH4ATMY32JVN
Aber im letzten Absatz steht doch In these cases, the additional latency can introduce performance problems, especially if the software tries to offer a real-time response to the user. For example, some software that doesn't require a stable workload could fire the Core Parking algorithms many times in a few seconds and the latency introduced could generate an impact in its real-time response to the user. As you may guess, some games that aren't optimized to take full advantage of all the available hardware threads could face a problem known as micro-stuttering. Gamers call micro-stuttering the problem of not succeeding in displaying regular distributed frames due to unexpected large time intervals between individual images, i.e., a high FPS (short for Frames Per Second) followed by a low FPS.
Siegfried
2010-09-04, 22:34:34
die fps sind immer stabiler wenn man dem spiel 1 festen core zuweißt
das ist mit jeder computeranwendung so
hyperthreading bringt bei heutigen multi-core cpus auch nichts mehr
eine anwendung die auf 8 cores (4+4ht cpu) optimiert wird rechnet langsamer als eine die auf 4 cores optimiert wird (4+0ht cpu)
Das Auge
2010-09-04, 22:53:48
(Zitat von http://de.wikipedia.org/wiki/Hyper-Threading)
Stimmt das immer noch?
Es gab irgendwo mal einen Artikel samt Benchmarks, dessen Fazit war, daß Spiele durchaus von HT profitieren (bei einem älteren Singlecore wie einem hochgetakteten P4 z.B.), weil der Treiber davon profitiert.
Das merkt man auch daran, daß ältere, Singlecore-optimierte, Spiele auf einem ansonsten gleichschnellen Dualcore besser laufen.
Gibt durchaus Spiele, die von SMT profitieren, teilweise sogar deutlich. Ruse ist so eins. Da erreicht ein i5 @ 2,8 GHz (4C / 4T) 42,2 FPS und ein i7 @ 2,8 GHz (4C / 8T) 49,2 FPS im Durchschnitt, laut PCGH. Das Spiel ist aber auch massiv auf Mehrkern-CPUs ausgerichtet und profitiert sogar noch deutlich von 6 Kernen (i7-970 6C / 12T @ 3,2 GHz: 62,4 FPS!).
SMT verlangsamt jedenfalls Spiele nicht mehr unter Windows 7. Es sei denn, die Programmierer sind schuld. Wenn ich mich recht erinnere, war es ArmA II, das z. B. nicht mit 12 Threads klarkam und afaik startete das Spiel sogar gar nicht erst und es musste erst ein Patch her. Mittlererweile dürfte das nie wieder ein Thema sein. Dafür ist Intels Marktmacht zu groß und auch der letzte Spieleentwickler dürfte mitbekommen haben, dass "12 Thread-CPUs" existieren.
y33H@
2010-09-05, 20:22:35
SC und DC mit SMT bringt sehr viel, QC mit SMT wenig bis spürbar. Fps-Verluste durch SMT bei QCs gibt afaik nur noch bei ArmA2.
PatkIllA
2010-09-05, 20:27:28
Lohnt es denn überhaupt noch auf eine spezielle Zahl zu optimieren. Es gibt doch so nette Sachen wie Threadpools mit denen man auch noch vergleichsweise kleine Aufgaben verteilt ausführen kann.
y33H@
2010-09-05, 20:34:48
Bei DCs war das der Fall. Spätestens seit PS3 und 360 ists sinnvoller, möglichst viele Threads zu haben beziehungsweise diese in Worker Jobs zu splitten um somit falls möglich, die Parallelität zu steigern. Anno 1404 hat das schön vorgemacht, RUSE zeigt es ziemlich beeindruckend, auch die MT-Framework 2.0 ist diesbezüglich super.
Sandy wird OCs mit SMT bringen und AMD Module mit doppelten Integer-Cores, d.h. die Parallelität bleibt bzw. steigt.
_DrillSarge]I[
2010-09-06, 04:31:43
die fps sind immer stabiler wenn man dem spiel 1 festen core zuweißt
das ist mit jeder computeranwendung so
not.
bitte auch nicht P4 HT mit dem aktueller i-prozessoren gleichsetzen.
Die Thread-Scheduler von W2K und XP hatten die böse Angewohnheit Single-Thread-Anwendungen dauernd zwischen (virtuellen) CPUs hin und her zu schieben. Das kostet natürlich Leistung. Bei W2K war es besonders schlimm, da der Scheduler die virtuellen Ausführungseinheiten bei aktivierten HT wie normale CPUs behandelte und durch ständige Pipeline-Stalls das Leistung verschlechterte.
Single-Thread-Anwendungen laufen auf Vista/7 dank des besseren Schedulers deutlich effizienter und werden nicht mehr durch die Ausführungseinheitungen durch gewirbelt. Was aber nicht für die Systemprozesse gilt.
Wird ein Prozess dezidiert einer Ausführungseinheit zu gewiesen (Affinity-Setting in Windows) kann eine Single-Anwendung unter Umständen an Leistung gewinnen, da der Thread-Scheduler dann automatisch die Systemprozesse den anderen Ausführungseinheiten zuweist und so widerum ein wenig das Thread-Mixing und der entsprechene Overgead veringert wird.
SC und DC mit SMT bringt sehr viel
Richtig. Aber das sollte man auch weiterdenken. Warum ist das nämlich so? Weil es mittlererweile viele Spiele gibt, die von mehr als 2 Kernen profitieren. Da sind die zusätzlichen 2 Threads natürlich sinnvoll, die so ein i3 mitbringt. Spiele, die von mehr als 4 Kernen profitieren, gibt es aber fast gar nicht. Entsprechend bringen auch mehr als 4 Threads nichts. Wenn aber bald Spiele rauskommen (wie Ruse), die sogar von 6 Kernen profitieren, DANN nützen 8 Threads. Mit anderen Worten: Der i7 wird gegenüber X4 und i5 in Zukunft den Vorsprung noch viel weiter ausbauen. Ruse zeigt doch schon, wie es bei modernen, massiv parallelisierten Spielen laufen kann. Ein i7 mit 2,8 GHz ist 50 % schneller als ein X4 965 BE mit 3,4 GHz. Lost Planet 2 ist ein weiteres Beispiel.
Das heißt, man könnte sich schön langsam überlegen ob man bei den akuellen QCs (i7) auch HT aktiviert unter Win7?
SG
Daredevil
2010-09-06, 11:28:02
Wenn man sich den i7 wegen der Leistung geholt hat und nicht wegen des E-Peen, dann solangsam schon, ja.
:redface: Kurz gesagt also für mich nicht. Der E6700 war halt schon alt...
y33H@
2010-09-06, 13:34:21
Man solllte SMT unter Win7 mittlerweile prinzipiell anlassen.
MaoZeDong
2010-09-11, 14:35:25
Ich habe auf meinem i7@4,2GHz HT abgeschaltet, hauptgrund ist die Hitzeentwichlung, wenn dann mal eine Applikation davon profitiert. Prime 95, Cinebench, e.t.c. Mein Luefter packt das dann nicht mehr. Ausserdem Legt der Scheduler von Windoof 7 gerne mal 2 threads auf einen Core. Da kann man labern wie man will. Ich verliere Leistung und es ruckelt ab und an.
Mit nur 4 echten cores gibt es keine Schwirigkeiten mehr, da kann der Scheduler auch nicht mehr viel falsch machen und die Temperatur bleibt unter 85C.
Auf die vielen kleinen Zicken mit HT kann ich beim Spielen gerne verzichten.
PatkIllA
2010-09-11, 14:38:32
weil du die Kühlung nicht im Griff hast ist HT jetzt schlecht?
Wenn die Temperatur zu hoch ist gibt's throtteling und ja das kostet Leistung.
Troll-Account
2010-09-11, 17:21:50
i7@4,2GHz HT off 85C.
:uconf3:
Didi Bouzul
2010-09-11, 18:19:05
ich kann jedenfalls bestätigen, dass mein atom330 @2ghz ohne ht wesentlich kühler bleibt, bei gleichbleibender Performance. Spiele sind quake live, enemy territory und HL2.
edit: win7 x64
Troll-Account
2010-09-11, 18:35:04
Sollte es ja auch.
Darkman.X
2010-09-11, 21:54:20
Ich habe HT ausgeschaltet. Ich hatte mal den "IntelBurnTest" als Stabilitäts-Test laufen lassen. Dort wird irgendetwas berechnet. Dabei wird unter anderem auch die verbrauchte Zeit + Speed (GFlops) angezeigt.
Bei 4 Worker-Threads auf 4C wird eine bestimmte Zeit + Speed angezeigt (irgendein Wert X).
Bei 4 Worker-Threads auf 4C/8T aber versagte der Win7-Scheduler, die Worker-Threads wurden wieder ständig zwischen den 8T hin und her verschoben. Und da konnte es auch passieren, dass 2 Worker-Threads auf einem Core arbeiteten. Letztendlich stieg die verbrauchte Zeit pro Berechnung an und der Speed (GFlops) war niedriger als mit 4 Worker-Threads auf 4C.
Keine Ahnung in wie weit es auf normale Applikationen/Spiele übertragbar ist. Aber seit dem ich gesehen habe, dass der Win7-Scheduler bei 4 100%-Worker-Threads auf XP-Niveau zurück fällt, seit dem lasse ich HT lieber deaktiviert.
Siegfried
2010-09-11, 22:04:18
I[;8252105']not.
bitte auch nicht P4 HT mit dem aktueller i-prozessoren gleichsetzen.
das ein wissenschaftlicher fakt :uponder:
=Floi=
2010-09-12, 04:18:51
ist das nicht zu kurz gedacht.
1. an darkman: lass mal 8 worker threads laufen, dann hast du eben auch die mehrleistung!
(DAS ist ja der sinn der sache) Der verlust an sich ist auch lächerlich gering, aber der gewinn wenn er da ist schon von vorteil.
2. @ allgemein
ist das thema nicht ein wenig komplexer?! Was passiert, wenn die threads extra auf zwei einzelnen cores laufen und so erst miteinander kommunizieren müssen? doppelter cache zugriff etc. im vergleich dazu sollte ein core mit gleichen cache daten und eingeschaltetem SMT runder laufen.
Darkman.X
2010-09-12, 15:47:31
Ja, du hast Recht, HT kann ein Gewinn sein.
Aber was ist, wenn ein Spiel nur 4 Worker-Threads hat ? Dann kann HT auch ein Verlust sein. Und da es keine (oder nur sehr wenige) Spiele gibt, die von 5 und mehr Kernen profitieren, lasse ich HT lieber deaktiviert und habe so die max. mögliche Performance. Auch wenn sie je nach Situation evtl. nur theoretischer Natur ist.
Anders sieht das Thema bei Besitzern von Dual-Core aus. Dort würde ich HT wahrscheinlich dauerhaft aktiviert lassen. Ich müsste sonst ich für jedes Spiel jedes Mal in BIOS und HT aktivieren/deaktivieren, je nachdem wie wieviele Worker-Threads das jeweilige Spiel hat.
========================
Für deine andere Anmerkung bin ich zu sehr Laie. Wenn ich nach dem AMD-Bulldozer-Thread gehe, bringt HT bei Intel nur 15% Mehrleistung oder so ähnlich. Also 2 Threads auf einem Core 115% Leistung und 2 Threads auf 2 Cores 200% (wenn ich es richtig verstanden habe). Von daher gehe ich auch davon aus, dass 2 100%-Threads auf 2 unterschiedlichen Cores trotz doppelter Cache-Zugriffe usw. schneller sind als zusammen auf einem Core.
Wie das ganze aber z.B. bei 2 50%-Threads aussieht, das weiß ich nicht...
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.