Phenom II X6 (minimum) FPS - Fraps und ein Fehler im System

[puntarenas]

Eine Frage würde ich im Hinblick Phenom II X6 als Gamer-CPU gern geklärt haben, denn sie brennt mir schon eine Weile auf der Seele.

Phenom II X6 im Praxis-Test: Diese Spiele profitieren von sechs CPU-Kernen (http://www.pcgameshardware.de/aid,746325/Phenom-II-X6-im-Praxis-Test-Diese-Spiele-profitieren-von-sechs-CPU-Kernen/CPU/Test/)
Phenom II X6 1090T und 1055T im Test: Sechs CPU-Kerne zum Kampfpreis (http://www.pcgameshardware.de/aid,745670/Phenom-II-X6-1090T-und-1055T-im-Test-Sechs-CPU-Kerne-zum-Kampfpreis/CPU/Test/)

Es macht seit einiger Zeit die Parole die Runde, dass die Min-FPS der Hexacores auch dann höher liegen, wenn die Spielperformance überhaupt nicht über vier Kerne hinaus skaliert.

Im parallelen Thread hatte ein Gast eine (IMO abenteuerliche) Theorie (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8160534#post8160534) aufgestellt, nach der verschieden große Threads eben nicht mehr so hübsch auf die einzelnen Kerne passen, also ein Platzproblem und somit Verteilungs-/Optimierungsproblem bestünde, wodurch die Quadcores ihr Leistungspotential nicht mehr voll ausspielen könnten, es bliebe dann ja "Platz auf der CPU" ungenutzt. Mein Kronzeuge für das Sheduling:

;8162051']Naja, ich habe mir das fiktive Beispiel von Ihm angeschaut und denke, dass die Argumentation totaler Kappes ist (bin wohl nicht allein damit). Die Argumentation beruht nämlich auf der Annahme, dass der Load unteilbar / atomar und somit nicht 'splitbar' wäre, d.h. das ich z.B. nicht hingehen und den Load von 50% auf Core 5 in beispielsweise 20% und 30% aufteilen könnte.

Hält man sich vor Augen, dass ein bestimmter CPU Load allerdings stets einer bestimmten Zahl von CPU-Zyklen entspricht, so sollte man eigentlich recht schnell zu der Einsicht gelangen, dass dies sehr wohl möglich ist. Beispielsweise entspräche bei einer CPU, die 100 Zyklen/s schafft, ein Load von 80% genau 80 Zyklen/s. Womit der CPU 20 Zyklen/s für andere Sachen blieben (OS-Overhead einmal nicht betrachtet), beispielsweise für das 'Abarbeiten des Loads' von Core 6, um im Beispiel vom 'Gast' zu bleiben.

i5/i7 - Phenom II X6 Fakten statt Flames #60ff (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8162051#post8162051)

Im Grunde dürfte das Phänomen der höheren Min-FPS wie oben beschrieben also überhaupt nicht auftreten, denn theoretisch ist völlig egal, wo ein Thread abgearbeitet wird. Natürlich spielt in der Praxis auch noch der Sheduler (http://en.wikipedia.org/wiki/Scheduling_%28computing%29#Windows) eine gewichtige Rolle und wenn diesem der Code quer liegt, kann es schon einmal zu Performanceeinbußen kommen, wie die Probleme des Windows-Sheduler vor Windows 7 mit Hyperthreading deutlich gezeigt haben. In einem solchen Fall (Code und Shedulerstrategie passen nicht so recht) könnte dann die Verfügbarkeit zusätzlicher Kerne natürlich auch zufällig für eine Entspannung der Situation sorgen, der Regelfall sollte das aber kaum sein.

PCGH betont, dass sie sehr gewissenhaft benchen und sie bezeichnen die Min-FPS auch ausdrücklich als reproduzierbar. Das will ich überhaupt nicht anzweifeln, ich frage mich aber, ob sie einen aussagekräftigen Messwert reproduzieren oder einen Messfehler?

Was mir in den Sinn kommt ist das Problem, dass das "Messwerkzeug" Fraps innerhalb des selben Systems wie das auszumessende Spiel, der Grafiktreiber und das OS läuft. Wechselwirkungen sind also nicht ganz auszuschließen. Ideal wäre vermutlich ein Messstand, bei dem man die Fraps-Werte von außerhalb des Systems verifizieren könnte, aber mir ist nicht bekannt, dass dies irgendwo so praktiziert würde. In den laienhaften Sinn kämen mir dabei Messungen mit einer Hochgeschwindigkeitskamera (Errechnung der Framerate über Bildveränderungen auf dem Schirm -> Flügelschlag des Kolibri anyone=) oder Osziloskopmessungen am DVI-Port (sofern dieser nur veränderte Bilder schickt und nicht stur 60/120 Bilder/s).

Kann mir jemand das Phänomen stattdessen auf Basis einer fundierten, theoretischen Annäherung erklären?

[dargo@work]

@puntarenas

Du bist nicht der Einzige den die X6-Benchmarks der PCGH sehr verwundern. Aber warum erwähnst du nur die min.fps im Titel? Wenn man sich den Frameverlauf von BFBC2 anschaut sind auch die avgs deutlich höher in 800x600.

[puntarenas]

Aber warum erwähnst du nur die min.fps im Titel? Wenn man sich den Frameverlauf von BFBC2 anschaut sind auch die avgs deutlich höher in 800x600.
Danke für den Hinweis! Mir ging es in erster Linie um die Parole "Hexacore = höhere Minimum FPS". Sollte es ein prinzpbedingtes Problem mit Fraps-Messwerten geben, kann ich mir gut vorstellen dass dieses auch die AVG-FPS betrifft.

Ich bin wahrlich kein (Benchmark-)Guru, aber Ausreißer bei Min- und Max-FPS würde ich mir noch mit leicht verschobenen Timestamps erklären können, aus denen Fraps dann Laufzeiten errechnet. Bei den AVG-FPS sollte sich das doch eigentlich ausbügeln, keineswegs aber deutlich hervortreten. :uponder: :confused:

Ändert sich eigentlich etwas an den Fraps-Werten, wenn man den High Precision Event Timer (http://de.wikipedia.org/wiki/High_Precision_Event_Timer) verwendet oder ist der bei S1156/AM3-Boards sowieso aktiv?
(nur so ein spontaner Gedanke :redface:)

Edit: "minimum" im Thradtitel in Klammern gesetzt

[dargo@work]

Mir ging es in erster Linie um die Parole "Hexacore = höhere Minimum FPS".

Diese Aussage ist imo eh Quatsch. Min.fps können je nach Benchmark auch durch eine GPU-Limitierung entstehen.


Ändert sich eigentlich etwas an den Fraps-Werten, wenn man den High Precision Event Timer (http://de.wikipedia.org/wiki/High_Precision_Event_Timer) verwendet oder ist der bei S1156/AM3-Boards sowieso aktiv?
(nur so ein spontaner Gedanke :redface:)

Puh, das kannte ich noch nicht. Wenn ich Zuhause bin kann ich das mal probieren.

[dargo]

@puntarenas

Ich kann bei meinem Brett im Bios keinen HPET-Eintrag finden.

[puntarenas]

Ich kann bei meinem Brett im Bios keinen HPET-Eintrag finden.
Dann wird wohl standardmäßig HPET verwendet, bei meinem S775-Board kann ich sogar noch zwischen 32Bit und 64Bit HPET wählen. Andererseits kann man unter Linux zum Beispiel noch zur Bootzeit beeinflussen, welchen Timer-Modus der Kernel letzten Endes nehmen soll und ich habe keine Ahnung wie das unter Windows 7 abläuft oder welchen Timer Windows vorauswählt.

Ich wollte auch noch von Google wissen, ob Fraps davon überhaupt Gebrauch macht, ggf. selbst etwas dazu tun muss oder ob das ganze transparent auf Betriebssystemebene und unabhängig von der Anwendung geschieht. Leider bin ich nicht fündig geworden.

Ist auch nicht so schlimm, so oder so bleibt Fraps ein Teil des Systems, das es ausmessen soll und so oder so bleiben fragwürdige Messergebnisse (aus meiner Sicht ganz besonders die "Losung" von den höheren Min-FPS auch in Spielen, die nicht über vier Kerne hinaus skalieren), die ich mir auf Basis meines begrenzten Verständnisses der Vorgänge in der Rechenkiste da unten nicht rational erklären kann.

Guru help wanted! :up:

[dargo]

@puntarenas

Nach meinen i5-Tests komme ich langsam zu der Erkenntnis, dass es scheinbar doch ein Verteilungsproblem gibt. Zumindest bei manchen Games. Schau dir mal das Diagramm von DIRT2 an:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6973305&postcount=2

Der Quadcore legt sogar stärker zu gegenüber dem Triplecore als der Triplecore gegenüber dem Dualcore. Auf der anderen Seite zeigt Resident Evil 5 sehr schön, dass es auch anders geht. RE5 skaliert zwar weiter noch sehr gut mit dem Quad, der Triplecore legt aber seine +~50% im vollen Zuge zu. Es scheint also kein generelles Verteilungsproblem zu geben. Liegts doch eher an der "Unfähigkeit", begrenztem Budget, Zeitdruck oder was auch immer der Programmierer?

[Demogod]

Das geht vermutlich bei den Xbox Ports in die Tiefen der Unterschiede der verschiedenen Games. Manche erzeugen zusätzlich zum Sound Thread halt evtl 5 Worker Threads und andere nur effektive 4 oder 3. Nur so als Idee. Man könnte ja mal testen, was passiert wenn man nem X6 bei BFBC2 nur 5 Kerne gibt.. und das ganze dann vs 3,4,6 vergleichen. HF ^^

[Gast]

Gerade bei Metro würde ich sagen, dass hier einiges im Argen liegt. Schalte ich 4 meiner 6 Kerne ab, ist das Spiel gerade mal 15% langsamer als mit 4 Kernen, ergo eine einigermaßen schlechte Skalierung. Schalte ich alle 6 Kerne an, skaliert die Engine plötzlich recht gut und legt ggü. dem 4-Kerner ca. 35% zu. 3 Kerne vs. 4 Kerne dagegen ist nahezu unmerkbar langsamer; knapp 8%.

Eventuell liegt's am bescheidenen CPU PhysX. Nachvollziehbar ist's jedenfalls nicht. Die Min-FPS sind nahezu immer gleich.

Getestet in 1024*768, Cpu immer @ 3.4GHZ.

[Gast]

Das geht vermutlich bei den Xbox Ports in die Tiefen der Unterschiede der verschiedenen Games. Manche erzeugen zusätzlich zum Sound Thread halt evtl 5 Worker Threads und andere nur effektive 4 oder 3. Nur so als Idee. Man könnte ja mal testen, was passiert wenn man nem X6 bei BFBC2 nur 5 Kerne gibt.. und das ganze dann vs 3,4,6 vergleichen. HF ^^

Metro ist kein Xbox Port. Der PC war Lead.

[Demogod]

Ich meinte die Portierung wenn Lead bei der Box war. Split Second nutzt nichtmal Dualcore vernünftig (bin grad nicht home daher kann ich es nicht mal schnell anschmeissen und nen Taskman screen bringen aber afair waren bei meinem Quad 2 Kerne mit unter 30% ausgelastet @3,4) scheint also kaum Cpu zu fressen. Jeder Kern der 3,2Ghz BoxCpus soll ungefähr so schnell sein wie ein 1,2-1,5 Ghz Pentium M Kern wenn ich das noch irgendwie richtig im Kopf hab. Wie gesagt müsste man sich da im Detail angucken was das jeweilige Spiel genau tut. Geht das nicht mit ProcessExplorer oder so?

[puntarenas]

Das geht vermutlich bei den Xbox Ports in die Tiefen der Unterschiede der verschiedenen Games.
Ich wüsste nicht, was da "in den Tiefen" großartig passieren sollte und genau dafür suche ich ja nach einer Erläuterung. Der CPU sollte egal sein, ob ein, zwei, zwanzig oder zweihundert Threads, sie arbeitet stoisch Befehlsfolgen ab. Betreibssystemseitig gibt es meinetwegen einen zunehmenden Verwaltungsaufwand, je mehr Threads jongliert werden, aber in kritischen Bereichen sind wir ja bei Games wohl kaum. Jeder Thread wird eine Zeit lang abgearbeitet, wird unterbrochen, schläft und wird wieder abgearbeitet.

Die schlichte Anzahl der Kerne (nicht verwechseln mit der Leistungsfähigkeit des Prozessors) sollte sowieso egal sein, es sei denn eine Anwendung stümpert mit Affinitätsmasken und Thread-Prioritäten herum. Was angesichts der Anfangstage von Multi-Core-CPUs in Verbindung mit einem anachronistischen Windows XP Sheduler noch irgendwie "Notwehr" gewesen sein mag, sollte jetzt mit Windows 7 der Vergangenheit angehören und die Entwickler werden sich zukünftig wohl keine solchen Stunts mehr erlauben.

Ansonsten ist es doch wohl so, dass der Sheduler den Threads (Befehlsfolgen zur Abarbeitung durch die CPU) reihum Rechenzeit auf einem beliebigen Kern zuweist, gewichtet nach Priorität versteht sich. Der Windows 7 Sheduler hat diesbezüglich Fortschritte gemacht und er kennt sogar Hyperthreading, so dass er zunächst vollwertige Kerne mit Arbeit bedenkt.

Jetzt nochmal die Preisfrage. Ich lese die Parole von höheren Min-FPS auf Hexacores und das wohlgemerkt in Spielen, die überhaupt nicht von mehr als 4 Kernen profitieren. Ich lese zudem, dass in GTA4 das Streaming "irgendwie runder laufen soll" mit 6 Kernen. Ich will besonders letzteres, da es aus erfahrenem Munde zu vernehmen war, nicht grundsätzlich in Abrede stellen, denn wir wissen ja spätestens seit der Mikroruckler-Geschichte, dass Framerate allein nicht viel bedeutet, es kommt auch auf die Gleichmäßigkeit über die Zeitachse an. Allein, woher sollten eine gleichmäßigere Frameverteilung oder Vorteile beim Streaming denn kommen, wenn sich diese nicht in der generellen Performance abbilden?

Nochmal, hier geht es nicht um Einzelfälle, sondern um eine allgemeine Frage.

Liefert Fraps mit steigender CPU-Belastung zunehmend verfälschte Werte? Ist der Windows7-Sheduler so schlecht, dass es doch Unterschiede zwischen der schlichten Anzahl an Kernen gibt oder greifen wirklich so viele Spiele manuell in das Sheduling ein (Affinitätsmasken, kaputtgetweakte Thread-Prioritäten), dass Microsoft nichts vorzuwerfen ist und die Game-Entwickler sich und uns einfach regelmäßig mutwillig ins Knie schießen?

Noch eine Frage an die Cracks. Der altbekannte "AMD Dual-Core Optimizer" (eine Schande für Windows XP und Microsoft im Allgemeinen btw) hat bekanntlich dafür gesorgt, dass die Timestamps der ersten AMD Dual-Core-Prozessoren synchronisiert wurden. Da frage ich mich, welche Timestamps nutzt denn eigentlich Fraps? Gibt es einen sauber synchronisierten Timestamp für alle Kerne oder werden die Messwerte womöglich auf Basis von Timestamps berechnet, die durch das wandern über sechs Kerne verfälscht wurden?

:confused:

[Gast]

Der CPU sollte egal sein, ob ein, zwei, zwanzig oder zweihundert Threads, sie arbeitet stoisch Befehlsfolgen ab. Betreibssystemseitig gibt es meinetwegen einen zunehmenden Verwaltungsaufwand, je mehr Threads jongliert werden, aber in kritischen Bereichen sind wir ja bei Games wohl kaum.
Jeder Thread braucht die passenden Daten im Cache, je mehr Threads du auf die CPU wirfst, desto öfter musst du die Caches neu befüllen und wie wichtig die Versorgung mit Daten für aktuelle CPUs ist, muss man die ja sicher nicht erklären.

Schönes Beispiel ist Ice Storm Fighters (s. Benchmarkforum) - auch wenn ich nicht sicher sagen kann, ob das dort gezeigte Verhalten in diesem Fall wirklich am Cache liegt. Ab einer bestimmten Anzahl an Hoverdingern gehen die Fps schlagartig und rapide in den Keller. 40 zu 35 sollten ein Siebtel mehr Last ausmachen, richtig? Die Fps halbieren sich auf vielen Quadcores.

-carsten

[Undertaker]

Das klingt nach einem typischen Grundlast-Phänomen. Nicht-fps abhängige Berechnungen wie die KI der "Hoverdinger" übersteigen aber einer gewissen Anzahl selbiger die Ressourcen der zur Verfügung stehenden CPU, und genau ab diesem Punkt brechen die fps schlagartig in den Keller.

[puntarenas]

Jeder Thread braucht die passenden Daten im Cache, je mehr Threads du auf die CPU wirfst, desto öfter musst du die Caches neu befüllen und wie wichtig die Versorgung mit Daten für aktuelle CPUs ist, muss man die ja sicher nicht erklären.
Schlimmer, mangels fundiertem Grundlagenwissen könntest du mir das nicht einmal in einem Wochenendseminar befriedigend erklären. Prinzipiell kann ich mir aber etwas unter deiner Äußerung vorstellen, ich bin so frei und hake mal nach, ob ich das in die richtige Richtung auffasse. :smile:

Ausgangspunkt war, dass mir unerklärlich schien, wie ein Hexacore reproduzierbare Leistungsvorteile in Spielen erarbeiten können soll, die nicht von mehr als 4 Kernen profitieren. Wenn ich dich richtig verstehe, könnte das "Mysterium" hier verborgen sein:

Beim fröhlichen Zuweisen von Rechenzeit auf einem der Kerne durch den Sheduler wandern die Threads reihum von Core zu Core. Die CPU beginnt die Instruktionen abzuarbeiten und die exklusiven Caches (Level 1+2) füllen sich mit threadrelevanten Daten, so dass die Versorgung der CPU mit Daten aus diesen sehr schnellen Caches regelrecht flustsch.

Dann kommt der Windows-Sheduler mit seinem präemptiven Multitaskingansatz und unterbricht einen Thread, schickt ihn schlafen und weist einem neuen Thread den CPU-Kern zu. Dieser beansprucht die knappen, aber schnellen exklusiven Caches für seinen Kontext und das Spiel beginnt von vorn, wenn auch er schlafen geschickt wird.

Kommt unser ursprünglicher Thread wieder an die Reihe, dann findet er in den exklusiven Level 1+2 Caches möglicherweise keine seiner benötigten Daten wieder, denn diese wurden von Daten anderer Threads verdrängt oder er ist auf einem völlig anderen Kern gelandet. Er muss sich die Daten dann erst wieder zeitaufwändig aus dem Level3-Cache holen.

Jetzt kommt der Witz, wenn ein Spiel von weniger Kernen profitiert, als dem kernreichsten Prozessor in einem Direktvergleich (hier Quad- gegen Hexacore) zur Verfügung stehen, dann bewirken die überzähligen Kerne, dass Threads bei der Zuweisung von Rechenzeit durch das Betreibssystem etwas länger auf einem Kern verweilen können und damit häufiger direkt aus den schnellen, exklusiven Caches arbeiten können.

Hilfreich wäre dabei natürlich, wenn der Windows7-Sheduler eine Strategie fahren würde, Anwendungsthreads möglichst lang auf ein und demselben Kern zu belassen, so lange für übrigen Kleinkram sowieso noch Ressourcen frei sind. Ob das zutrift, weiß ich nicht.

Schwachsinn? Wenn das kein Schwachsinn ist, dann sollte sich der Effekt auch bei Single-Thread-Performancegräbern beispielsweise im Direktvergleich zwischen Dual-, Triple, Quad-, Penta- und Hexa-Core zeigen lassen? :uponder:

[Lokadamus]

Hilfreich wäre dabei natürlich, wenn der Windows7-Sheduler eine Strategie fahren würde, Anwendungsthreads möglichst lang auf ein und demselben Kern zu belassen, so lange für übrigen Kleinkram sowieso noch Ressourcen frei sind. Ob das zutrift, weiß ich nicht.mmm...

Bei Windows 7 wurde einiges geändert und es dürfte in die von dir genannte Richtung gehen.
http://www.golem.de/1003/73762-8.html
Durch den veralteten Thread-Scheduler von Vista steht sich das Betriebssystem oft selbst im Weg. Es verlagert öfter Threads auf Kerne, die schon belastet sind - deren Threads müssen dann wieder auf andere portiert werden.

Darum hat Intel für Windows 7 zusammen mit Microsoft die Funktion des "SMT Parking" entwickelt. Die virtuellen Hyperthreading-Kerne werden dabei erst dann genutzt, wenn die physikalischen Cores voll ausgelastet sind.