Bericht Bericht: 1, 2, 3 oder 4 CPU-Kerne?

[abulafia]

Mich wundert, das der Triple-core so schlecht abschneidet. Hier skaliert die Leistung ja schlechter als beim Quad!

Ich habe vor einiger Zeit einen ähnlichen Test nur mit Bioshock durchgeführt, mit einem ausdrücklich anderen (imho wesentlich interessanteren) Schwerpunkt: Theoretische Leistung von Single-, Dual-, Triple- und Quad-Cores.

Bei mir hat die Leistung antiproportional mit den Kernen skaliert, so wie man es erwarten würde:

Ja, gute Arbeit. Das entspricht auch dem erwartetem Ergebnis. Und zeigt, wie gut ein Spiel von mehr Kernen profitieren kann.

"Antiproportional" ist es natürlich nicht.


Die problematische Sätze im Fazit sind:

Doch auch ein paar Negativbeispiele offenbart unser Test: So liegt die 1-Kern-CPU in Bioshock (+10 %), Call of Juarez (+4 %) oder Stalker (+4 %), abhängig von der gewählten Auflösung, vorne.
(...)
Unterm Strich spricht auch aus Sicht der Spieler allerdings nichts mehr gegen einen Zweikern-Prozessor. (...) Mehr als zwei Kerne können vorteilhaft sein, doch profitieren zurzeit nur sehr wenige Spiele von zwei weiteren Recheneinheiten.

Für den ersten Teil ist dringend eine technisch plausible Erklärung nötig. Es ist zwar eine interessante Beobachtung, die aber so weit von der Erwartungen abweicht, dass eine genauere Untersuchung notwendig ist, bevor das einfach in ein Endergebnis übernommen werden sollte. Die Aussage gilt nur für diesen sehr speziellen und unzweckmäßigen Testaufbau.

Gegen einen Mehrkernprozessor sprach aus Leistungssicht in jüngster Zeit nie etwas. Es wird impliziert, dass eine normale Single-Kern-CPU noch mithalten kann. Das gilt aber höchstes für eine fiktive Single-Core2-4GHz-CPU. Und selbst bei dieser ist das Ergebnis seltsam.

Der letzte Satz stimmt aus gleichen Gründen nicht. Der Testaufbau ist nicht geeignet, einen solchen Schluss in dieser allgemeinen Form zu treffen.

Der Artikel ist, wie leider nur die wenigen verstanden haben, KEIN CPU-Test. Der Artikel soll zeigen, wass einem Multi-Core-CPUs in aktuellen (und nicht in Zukünftigen) Spielen bringen und nicht, was sie eventuell in unrealistischen Situationen bringen. Aus diesem Grund haben wir uns für die Auflösung 1280x1024 entschieden, die für eine GeForce 9800 GX2 schon sehr klein ist. AA/AF haben wir noch Hinzugeschaltet, da die meisten so wohl Spielen werden.[...]

Da die Kritik öfters aufkam: Wie gesagt, das ist kein CPU-Test, vielmehr ein "Spieletests mit Fokus auf Multi-Core". Und mit einer 9800 GX2 muss man in Crysis nicht unbedingt nur in High-Quality oder ähnliches Spielen. Very High ist da durchaus möglich.

Was "Multi-Cores bringen" wurde aber auch nicht gezeigt. Es wurde nur gezeigt, dass es bei einem 4-GHz-Core2 in den getesteten Situationen scheiß egal ist, wie viele Kerne er hat, da die Grafikkarte schon in vernünftigen Auflösungen eher schlapp macht. Mehr nicht. Die Kritik ist ja gerade die, dass sich daraus keine allgemeinen Aussagen für übliche Systeme treffen lassen.

Ein Spieletest, der Untersucht ob Spiele von mehr Kernen profitieren, war es entsprechend auch nicht. Gleiche Argumentation. Du widersprichst dir hier auch selbst. Der Versuchsansatz von CroneKorkN wäre hier zweckmäßiger gewesen.

Wenn der Artikel so missverstanden wird, ist das im übrigen auch ein Indiz für seine Qualität. Da du den Fehler mit der übertakteten CPU schon eingeräumt hast, ein kleiner Fehler, der den Test leider in der Folge unbrauchbar macht, muss man den Rest auch nicht mehr rechtfertigen. Der Ansatz mit der moderaten, realistischen Auflösung war ja richtig, hat aber das Problem der Unbalance zwischen GPU und CPU Leistung nicht gelöst, da eine unrealistische CPU Leistung entgegenwirkte.

Der Test lässt allerdings eine Frage offen: Ist ein Single-Kern Core2 mit 4 GHz für aktuelle Grafikkarten bereits überdimensioniert?

Danke für die viele Arbeit, auch wenn sie nicht zum beabsichtigten Ergebnis führte.

Mich interessiert auch, wer an solchen Tests alles mitwirkt, oder ob du das alles alleine machst, also warm das niemandem vorher aufgefallen ist. Die Umsetzung ist ja gut gelungen, der Fehler lag hier eher in der Konzeption.

 

[Jake_Dunn]

....dass es mit einer Single-Core-CPU jetzt auch nicht so dermaßen schlecht aussieht. Natürlcich ist man aber mit einer DC-CPU besser bedient.

Der CRYSIS "Test" zeigt das ein SC schneller ist als ein DC od. QC was absoluter BS ist.

Ich hab mal aus Fun das Tank-Level versucht mit einem Kern zu zocken, daß war unmöglich ich hatte ein teilweise ein stehendes Bild und Soundloops.
Es war so schlimm das ich nichtmal eine vernünftige Messung mit FRAPS (min., avg., max. FPS) machen konnte.
Settings waren 1920x1080, High/Med

 

[Unyu]

Der CRYSIS "Test" zeigt das ein SC schneller ist als ein DC od. QC

Das sind weniger als 1%. Fällt unter Messtoleranz.

 

[abulafia]

Nein, denn der Fehler ist nicht vereinzelt aufgetreten,

So liegt die 1-Kern-CPU in Bioshock (+10 %), Call of Juarez (+4 %) oder Stalker (+4 %)

und das sind keine Messfehler mehr. Die Abweichung bei Crysis vom Erwartungswert muss man folglich dann auch als systematischen Fehler auffassen und kann sich nicht auf einen Messfehler berufen. Dass das Ergebnis bei Bioshock sehr seltsam ist, zeigt auch der Post von CroneKorkN mit seinen Ergebnissen.

 

[Jake_Dunn]

Bezüglich der Min-FPS. Ich habe schon mehrmals erwähnt, dass ich kein Freund von reinen Min-FPS-Angaben bin. Min-FPS sagen im Endeffekt noch viel weniger aus als Average-FPS-Werte. Es muss nur mal ein einziges Frame ruckeln und schon hat man einen schlechten Min-FPS-Wert. Die drei niedrigsten (oder ähnliches) zu nehmen bringt einem auch nichts, da kann ähnliches passieren, was dann aber nicht der Wirklichkeit entspricht. Wenn, dann machen wir Verlaufsdiagramme, was in meinen Augen die mit Abstand beste (und aufwendigste) Lösung ist. Da die Min-FPS je nachdem stark auf die CPU gehen, haben wir ja auch extra drei Verlaufsdiagramme angefertigt.

Gerade auf die min. FPS kommt aber an und da gibt es erhebliche unterschiede zwischen SC und DC und zum Teil auch bei QC.
Und das es schwer ist das zu benchen ist klar, aus den von dir angesprochenen Gründen, aber es ist der einzige Weg die vorteile von Mehrkern CPU's aufzuzeigen in "Normalen Settings" die man spielt.

Noch ein Tip!
Testet am besten mit einer Single Graka (z.b. 8800GTX), da SLI auch das Ergebniss verfälschen kann, da die Sync. im Treiber auch recht CPU-Lastig ist und die GX2 mit VeryHigh+AA u. AF (CRYSIS) schon in ein Vram-Limit raseln kann.
Bei der CPU einfach den 7er Multi nehmen, denn 2,8ghz@Yorkfield ist immernoch sehr schnell.

Das sind weniger als 1%. Fällt unter Messtoleranz.

Wayne ist trotzdem BS was bei Test rausgekommen ist.

 

[aspro]

Nein, denn der Fehler ist nicht vereinzelt aufgetreten, und das sind keine Messfehler mehr. Die Abweichung bei Crysis vom Erwartungswert muss man folglich dann auch als systematischen Fehler auffassen und kann sich nicht auf einen Messfehler berufen. Dass das Ergebnis bei Bioshock sehr seltsam ist, zeigt auch der Post von CroneKorkN mit seinen Ergebnissen.

Eine Möglichkeit, das zu erklären, wurde ja schon genannt. Nämlich, dass der simulierte Single-Core den gesamten 4MB shared L2 nutzen kann, beim Dual-Core aber die 4MB für beide Kerne reichen müssen. Und Spiele können ja nie genug Cache kriegen.

 

[Unyu]

Wayne ist trotzdem BS was bei Test rausgekommen ist.

Schon klar.

 

[SirOPIUM]

Wenn man die Verlaufsdiagramme ausreichend genau (hoch genug, breit genug, genug horizontale Zwischenstriche, ...) macht, bieten sie die größtmögliche Information aus einem Benchmark an: wie groß ist in jeder Sekunde Benchmarkzeit die entsprechende Framerate. Min- und Max-FPS sind dann der tiefste/höchste Punkt der Verlaufskurve. Imo würde es sich auch anbieten, die AvgFPS als horizontale Linie einzumalen.

Die Messdauer zu erhöhen verschafft zwar ein besseres Bild wie oft bestimmte FPS Werte auftreten, aber wenn weiterhin ein 5 Sekunden-Intervall verwendet wird, wird es an sich nicht genauer.

Ich bin leider nicht ganz sicher wie die FPS bestimmt werden. Werden (wie die Bezeichnung vermuten lässt) schlicht die Frames innerhalb einer Sekunde gezählt?
Rein physikalisch gesehen wäre die Zeitdauer zwischen den einzelnen Frames (oder bei Mehrfach-GPUs und Alternate frame rendering zwischen jedem zweiten Frame) in meinen Augen das korrekte Mess"objekt". FPS lassen sich mathematisch auch sehr leicht daraus ermitteln. Bei konsequenter Aufzeichnung aller Abstände über einen gewissen Zeitraum könnte somit das Verlaufsdiagramm noch genauer werden.

 

[Jake_Dunn]

Eine Möglichkeit, das zu erklären, wurde ja schon genannt. Nämlich, dass der simulierte Single-Core den gesamten 4MB shared L2 nutzen kann, beim Dual-Core aber die 4MB für beide Kerne reichen müssen.

Bei der CPU die CB verwendet hat sind das sogar 6mb

Und Spiele können ja nie genug Cache kriegen.

Stimmt nicht immer, denn ein Quake 4 ist sehr Cache-Lastig und manch andere Games überhaupt nicht.

 

[HomerJSi]

Die Messdauer zu erhöhen verschafft zwar ein besseres Bild wie oft bestimmte FPS Werte auftreten, aber wenn weiterhin ein 5 Sekunden-Intervall verwendet wird, wird es an sich nicht genauer.

Ich bin leider nicht ganz sicher wie die FPS bestimmt werden. Werden (wie die Bezeichnung vermuten lässt) schlicht die Frames innerhalb einer Sekunde gezählt?
Rein physikalisch gesehen wäre die Zeitdauer zwischen den einzelnen Frames (oder bei Mehrfach-GPUs und Alternate frame rendering zwischen jedem zweiten Frame) in meinen Augen das korrekte Mess"objekt". FPS lassen sich mathematisch auch sehr leicht daraus ermitteln. Bei konsequenter Aufzeichnung aller Abstände über einen gewissen Zeitraum könnte somit das Verlaufsdiagramm noch genauer werden.

Also wenn man mit FRAPS bencht kriegt man eine Tabelle (die man mit Excel oder OOCalc öffnen kann), wo für jede Sekunde die Anzahl Bilder ausgegeben wird (also tatsächlich Frames pro Sekunde). Da wird FRAPS einfach die einzelnen Bilder pro Sekunde zählen.

Es wird auf das gleiche rauskommen, die Frametimes zu messen, und die Frametimes solange aufzuaddieren, bis man auf eine Sekunde kommt (abgesehen von Rundungsfehlern). FPS wären dann die Anzahl der Additionen, bis man auf eine Sekunde kommt. Wäre definitiv der intuitivere Ansatz.

AvgFPS ergibt sich dann: (Anzahl Bilder in der ersten Sekunde + ... + Anzahl bilder in der letzten Sekunde)/Anzahl Sekunden, die der Benchmark läuft. Oder mit Frametimes: Alle Frametimes aufaddieren und durch Gesamtzahl Frames teilen ("Average Frametime"), und dann tausend Milisekunden durch Average Frametime (da Frametimes typischerweise in Milisekunden gemessen).

Am Übersichtlichsten fände ich es ein Verlaufsdiagramm anzugeben, das für jede Sekunde die FPS ausgibt (weil es eben Frames pro Sekunde sind) - aus nem FRAPS-Benchmark ohne Probs zu erstellen. Zeitliche Auflösung von einer Sekunde ist hinreichend genau. Natürlich würden in so einem Diagramm dann Mikroruckler nicht erfasst. Aber das wäre hier nicht das Problem. Eine Erhöhung der Messdauer wäre zwar wünschenswert im Sinne einer größeren Stichprobe, dürfte aber den zeitlichen Aufwand für solche Tests sprengen.

 

[Gelbsucht]

Da sieht mann einmal wie unwichtig die CPU für die meisten Games ist im Verhältniss zur Grafikkarte.

Nein, man sieht die Entwicklung zu immer mehr grafiklastigen Spielen. Das dürfte den Hintergrund haben, das es für die meisten einfacher ist, eine neue Graka einzubauen, als gleich CPU + Kühler zu tauschen. Weiterhin können damit auch auf enfache Art ältere Systeme bedient werden, da deren Besitzer eher eine neue/stärkere Graka einbauen anstatt gleich die Basis upzugraden (CPU, Ram und Board)...

Ist ja auch in Ordnung angesichts der Leistungssprünge bei den GPUs.

 

[SirOPIUM]

Die Messdauer muss ja nicht auf zwei Stunden ausgedehnt werden. Ein paar Minuten (um unterschiedliche Situationen erfassen zu können) sollten aber durchaus drin sein. Haben wir in den Verlaufsdiagrammen ja teilweise auch schon.

Die Berechnung der FPS aus den Frametimes hatte ich mir eigentlich anders vorgestellt: Der Kehrwert der Frametimes sollte jedesmal einen (theoretischen) FPS wert liefern. Somit hätte man nach 100 Frames 99 FPS Werte.
Je nach dem, wie genau die Zeiten gemessen werden können, wäre somit wohl der genaueste Verlauf möglich.

Mir ist durchaus bewusst, dass die Bezeichnung FPS durch diese Berechnung genau genommen falsch ist, was aber lediglich daran liegt, dass dieser Begriff als Synonym für Bildrate verwendet wird.

 

[Vetinari]

Ich hätte noch eine kleine Frage:
Wurde bei diesem Test die Multithreading-Option des nvidia-Treibers deaktiviert (kann man das bei ATI eigentlich auch?)?
Wenn nein, würde ich behaupten dass etwaige Performance-Differenzen auf die Einflüsse der Optimierung der Grafiktreiber zurückzuführen wären - und nicht auf die Optimierung der Spiele selbst. Soweit ich weiss profitiert SLI (da zusätzlicher Mehraufwand für den Treiber (und dementsprechend auch für die CPU) wegen AFR) zusätzlich von mehreren Kernen. Da es laut der Testbeschreibung explizit um die Spiele und nicht den Profit durch entsprechende Optimierung bei den Treibern geht, wäre hier doch ein ungewollter Störfaktor mit in die Resultate hineingeraten?

 

[Fairy Ultra]

wäre noch interessant wie jetzt ein AMD mit nativen design abschneidet.

mfg

 

[HomerJSi]

@Sir Opium: OK wie man letztlich FPS aus Frametimes berechnet, darüber kann man sich vermutlich streiten.

Nimmt man den Kehrwert der Frametime (evtl. mal 1000 Milisekunden, falls die Frametime in Milisekunden gemessen wird) hat man zwar auch eine Framerate, aber nicht mehr pro Sekunde (weil ja nicht mehr die Bildanzahl pro Sekunde erfasst wird). Es wäre allerdings die Messung der Bildrate mit der feinsten zeitlichen Auflösung.

Hast recht, dass da der Sprachgebrauch unpräzise ist - FPS ist nur eine Möglichkeit, die Bildrate zu messen.

Ich überlege grad nur, wie dann die x-Achse bei so einer Bildratenmessung (Kehrwert der Frametimes) skaliert wäre. Vermutlich wäre das dann nicht mehr der Zeitablauf in Sekunden (wie in diesen Verlaufsdiagrammen), sondern einfach [Anzahl] Bilder (die im Benchmark abgespielt werden).

Edit - Aber: würde man eine Bildrate mittels Kehrwert der Frametimes ermitteln, würden wenigstens Mikroruckler berücksichtigt ... von daher gar nicht mal so blöd die Idee

 

[SirOPIUM]

Beispiel:
Frametime: 23ms = 0,023s
Kehrwert davon = 1/0,023s = 43,478... * 1/s = 43,478... FPS

Somit hätte man eine Prognose, wieviele Frames in der nächsten Sekunde berechnet werden. Aber aus dem Grund, dass es nur eine Prognose ist und diese voraussetzt, dass in jedem Frame das selbe berechnet wird, ist die Bezeichnung FPS mE nicht ganz zutreffend. Aber das ist letzt endlich Haarspalterei.

Als Skalierung der Bezugsachse kann man entweder die Frames selbst nehmen (bzw die Nummer der entsprechenden Frametime), oder aber wie gewohnt die Zeit. Dazu müsste theoretisch nur die Summe aller vorangehenden Frametimes gebildet werden oder, um Quantisierungsfehler nicht zu summieren, ein Zeitstempel mit Bezug auf den Startwert direkt mitprotokolliert werden.

Die größte Sorge bei dieser Variante ist die Zeiteinteilung in Millisekunden, da diese einfach zu ungenau ist. Es wäre also vermutlich zusätzliche Hardware erforderlich.

 

[HomerJSi]

^^ Bei dieser Vorgehensweise misst man nunmal die Zeit, die vergeht, bis ein Bild fertig gerendert auf dem Bildschirm erscheint. Ein daraus abgeleiteter Wert (die Bildrate als Kehrwert der Frametime) hat somit imo zwangsläufig einen künstlichen Charakter.

Rechnet man auf FPS um (wie du in deinem Beispiel 43,478 FPS), hat das imo den Vorteil, dass man sich unter FPS plausibel etwas vorstellen kann (43,ungerade Bilder pro Sekunde). Nichts desto trotz steckt in dieser Umrechnung die Annahme, dass alle folgenden Bilder genauso schnell berechnet werden (was spätestens mit der nächsten Frametime widerlegt sein dürfte Prognosewert imo gleich null aber du sagst selbst, dass das Haarspalterei ist ... da stimme ich zu.

Letztlich muss eine Analyse imo nützlich sein: und eine Berechnung der FPS über Frametimes finde ich ehrlichgesagt ziemlich nützlich: hier geht keine Information durch Umrechnung in eine Kennzahl verloren ... und nebenbei (wie schonmal gesagt) würden sich Mikroruckler in einer stark schwankenden FPS-Zahl widerspiegeln.

Edit: wenn ich mal Zeit/Lust habe, werd ich mal ein Frametime-Benchmark machen (FRAPS protokolliert netterweise auch die Frametimes mit).

 

[bensen]

Da es laut der Testbeschreibung explizit um die Spiele und nicht den Profit durch entsprechende Optimierung bei den Treibern geht, wäre hier doch ein ungewollter Störfaktor mit in die Resultate hineingeraten?

hat wolfgang doch oben erwähnt
der test soll zeigen was dem spieler eine multicore cpu bringt
wodurch man jetzt im detail welche vorteile erhält ist ja sekundär

das würde ja alles mehr zu ner theoretischen betrachtung gehören, was hier wohl nicht angestrebt war

 

[SirOPIUM]

Hatte auch eben in diesem Artikel gesehen, dass Fraps die Frametime ebenfalls protokolliert. Ich weiß nur nicht wie genau das Programm die Zeiten bestimmen kann. Sollte die Genauigkeit im Bereich von Nanosekunden liegen (was aus den Zahlenwerten schließen könnte), sollte das mE ausreichen.

Das Problem mit Alternate frame rendering und den Mikrorucklern ist bei der Berechnung allerdings ein gewaltiger Störfaktor.
Wenn man diese Werte genauso behandeln würde wie eine die einer SingleGPU-Messung würde das, wie richtig erkannt wurde, zu starken Schwankungen der Bildrate führen. Allerdings würde ein daraus resultierender Graph (auf Grund der vielen Messstellen) unübersichtlich bis komplett unleserlich werden.
Ich bin daher der Meinung, dass auf jeden Fall berücksichtigt werden sollte, ob eine MultiGPU Lösung vorliegt und wie diese arbeitet.

Eine Möglichkeit damit umzugehen wäre es die Daten für jede GPU auszuwerten, so dass bei einem Triple-GPU-System die Frames 0,3,6,9,... für die 1. GPU, die Frames 1,4,7,10,... für die 2. GPU und die Frames 2,5,8,11,.. für die 3. GPU als Grundlage für die oben beschriebene Auswertung dienen. Hier müsste natürlich noch korrigiert werden, dass die Zeiten jetzt etwa drei mal so lang sind. Ob man die drei resultierenden Messreihen mittelt oder in Vergleich zueinander setzt (interessant bei der Kombination unterschiedlicher GraKas). Damit wäre zwar das Problem durch stark schwankende Bildraten auf Grund von Mikrorucklern kompensiert, dafür würde aber Genauigkeit verloren gehen oder aber der komplette Test unbrauchbar werden, da das Verhalten der CPU hier (soweit mir momentan bekannt ist) in keiner Weise beurteilt werden kann. Hilfreich wäre es (je nach Ziel des Tests) die entsprechende Komponente als einzigen limitierenden Faktor zu erlauben.

 

[Vetinari]

das würde ja alles mehr zu ner theoretischen betrachtung gehören

Praxisrelevant ist es definitiv nur beschränkt. Aber ich persönlich würde gerne auch etwas die Zusammenhänge sehen und etwas daraus lernen - viele Tests sind mir persönlich zu wenig tiefgründig und haben keine wirkliche Substanz, aus der man etwas richtig brauchbares gewinnen kann. Vielleicht bin ich ja auch zu anspruchsvoll was den Lerngehalt betrifft