Baal Netbeck
Fleet Admiral
- Registriert
- Apr. 2008
- Beiträge
- 11.936
Dies ist ein ausgelagertes Thema aus diesem Hauptthread:
https://www.computerbase.de/forum/t...kussion-zu-spieletests.1728575/#post-20678303
Intro:
Ashes of the Benchmark....Ach ne...Ashes of the Singularity
.
Spielerisch eine Art Supreme Commander Klon, ist es eher für seine DX12 und Vulkan Unterstützung, sowie die gute Auslastung von vielen CPU Threads bekannt.
Es wird ebenfalls DX11 angeboten und es gibt einen integrierten CPU und einen GPU Benchmark.
Dabei lässt sich der CPU Benchmark leider nicht mit DX11 starten.
Ich habe mich auf DX12 und den CPU Benchmark focusiert, als Ergänzung jedoch auch DX11 gegen DX12(erzwungenermaßen im GPU Benchmark) getestet.
Die Testkandidaten sind mein Ryzen 1800X in verschiedenen Konfigurationen gegen einen i5 3570K.
Beide mit meiner Vega64 LC(undervolted) gepaart.
In diesem Review zeige ich diverse Aspekte wie:
Einflüsse von 4 vs 8 Kernen, SMT an/aus, Skalierung mit Ramgeschwindigkeit, verschiedene CCX Konfigurationen für Ryzen. IPC Vergleiche, Einfluss des HBCC, Einfluss von CPU und RAM Optimierungen, DX12 vs 11 und eine Betrachtung der Infinity Fabric Skalierung.
Fangen wir mit der Testszene an.
Wie man in dem Video sehen kann lässt DX12 hier seine Muskeln spielen und eine Auslastung von über 80% bei einer 16 Thread CPU sucht seinesgleichen.
Laut den Entwicklern sind die Benchmarks aufgebaut und berechnet wie richtige Gameplay Szenen und sollen repräsentativ für diese sein.
Allerdings werden im normalen Spiel CPUs mit vier oder weniger Kernen mit deutlich weniger Partikeleffekten belastet und laufen deshalb besser als die eigentlich stärkeren 6 und 8 Kern CPUs. In den Benchmarks soll dies nicht so sein und auch die 4 Kerner müssen die Arbeit der größeren CPUs verrichten.
Eine etwas komische Entscheidung aber mir soll es egal sein.
Verglichen mit einem normalen Spiel gegen mehrere KI Gegner zeigte sich eher ein Verhalten wie in dem GPU Test.
Das bedeutet eine eigentlich gute Performance , die dann deutlich abfällt, wenn man eine große Armee angesammelt hat und damit geballt den gegnerischen Nexus/Hauptstreitmacht angreift.
Diese großen Schlachten sind dann ungefär so wie der CPU Test es dauerhaft zeigt.
Da mich immer diese Worst case Szenarien interessieren, habe ich mich für den CPU Benchmark entschieden.
Obwohl so ein Benchmark eine gute Reproduzierbarkeit erwarten lässt, wurde ich enttäuscht. Die Schwankungen sind relativ groß und auch nachdem ich von erst nur 30s auf 170s Messung gegangen bin, ist es noch nicht perfekt.
Und fünf mal den drei minütigen Benchmark mit 23s Ladezeit zu starten ist sehr zeitaufwendig.
Wer die Szene selbst testen möchte findet im Video die Grafikeinstellungen.
Wichtig ist, dass unter DX12 das Fraps Overlay nicht funktioniert und Fraps beim starten nicht offen sein darf.
Man muss also erst das Spiel starten, es dann minimieren um Fraps zu starten(170s einstellen) und die Messungen blind aktivieren sobald der eingeblendete Countdown des Benchmarks für eine Sekunde verschwunden ist.
Frametimegraphen CPU Benchmark:
Zuerst der Vergleich meines Ryzen 7@3,8GHz und des Ivy Bridge i5 mit 4,4GHz
Wie man sieht, hat das Spiel eine relativ gleichbleibende Performance, die periodisch hoch und runter schwankt.
Der Ryzen kann sich mit seinen 16 Threads deutlichst absetzen und zeigt viel niedrigere Frametimes auch wenn im hinteren Bereich ein paar Ausreißer dabei sind.
Sonderlich gut scheint dem Spiel die Ryzen Architectur jedoch nicht gut zu schmecken, denn mit nur vier Kernen gibt es ein Kopf an Kopf Rennen mit dem i5 3570K, den der i5 im Detail für sich entscheiden kann.
Wo in vielen anderen Spielen der i5 trotz 600MHz mehr hinten liegt, kann er sich hier besser behaupten.
Um diesem Auf und Ab eine quantitative Entsprechung zu geben benutze ich eine Reihe statistischer Werte die ich aus der Auswertung von jeweils fünf Messungen gewinne.
Die gezeigten Frametimeverläufe waren jeweils die zweit besten was die 0.1% low Werte angeht.
i5 vs. Ryzen
Zur Erklärung des Diagramms:
Wie schon in dem Frametimegraph zu sehen, liegt der Ryzen mit 8 Kernen und SMT deutlich in Führung, auch wenn er ab und zu Ausreißer in den Frametimes hat, die aber immer noch besser sind als die der anderen Testkandidaten.
Der i5 mit 4,4GHz kann sich vor die 4 Kerne des Ryzen schieben und zeigt weniger Schwankungen.
Wird bei den 4 Zen Kernen SMT hinzugeschaltet, steigt die Leistung deutlich und taktet man den i5 nur mit Referenztakt und freigegebenem Ram, fällt dieser deutlich zurück.
Ryzen CCX Konfiguration und SMT
Ashes of the Singularity ist eines der wenigen Spiele, die auch bei 8 Kernen noch von SMT profitieren.
Der CPU Benchmark giert nach Rohleistung.
Die 4+0 Konfiguration schlägt hier die 2+2 Konfiguration und würde sich minimal vor den i5 mit 4,4GHZ schieben.
4+0 hat den Vorteil keine Komunikation der Kerne über den IF zu haben, muss im Gegenzug aber mit dem halben L3 Cache zurechtkommen.
Wie wir in diesem Frametimegrah sehen, sind die Unterschiede gut messbar, zeigen aber keine Auffälligkeiten im Erscheinungsbild:
Leistungsaufspaltung beim i5
Ein gesenkter Ram Takt macht sich nicht gut, jedoch immer noch besser als der Referenztakt.
IPC Vergleich
Drei mal vier Kerne, ohne HT/SMT, bei 2,8GHz im Vergleich.
Ryzen ist zweimal vertreten und zwar einmal mit schnellem und einmal mit langsamem Ram.
Auch mit 2133er DDR4 zeigen sich noch IPC Vorteile für den Ryzen, vor allem weil ich hier nicht die 2+2 sondern die 4+0 Konfiguration gewählt habe.
Unterschiedliche Ram Skalierung bei anderen Kern und Thread Anzahlen?
Egal ob 4 Kerne oder 8 mit SMT. Der Gewinn durch schnellen Ram ist deutlich.
Auch der i5 profitiert von schnellerem DDR3 Ram.
CPU vs GPU Benchmark
Bevor wir uns DX11 vs 12 abgucken können müssen wir einen Blick auf den GPU Benchmark werfen, da wir nur hier diesen Vergleich machen können.
GPU Benchmark Videos:
Und hier den Vergleich der Frametimeverläufe:
Man kann sehen, dass der GPU Benchmark über weite Teile deutlich besser läuft und größere Schwankungen von Szene zu Szene zeigt.
In einigen Szenen ist die Performance dann sogar schlechter als im CPU Benchmark, wenn auch nicht deutlich.
Im Video kann man sehen, das DX12 es schafft die Grafikkarte fast immer auf einer hohen Auslastung zu halten und Auch diese schlecht laufenden Szenen vor allem durch die GPU limitiert sind.
Das wird auch durch folgenden Frametimevergleich bestätigt:
Der Ryzen kann sich mit seinen 8 Kernen, in diesen Szenen, nicht absetzen und läuft dank größerer Schwankungen sogar schlechter. Wieder einmal zeigt sich, dass es im GPU limit vor allem Takt braucht.
Vorteile kann Ryzen in den anspruchsloseren Szenen für sich verbuchen. Hier kann er mit mehr CPU Rohleistung höhere FPS erreichen.
DirectX 11 vs 12
Sowohl auf dem i5 als auch auf dem Ryzen hat die Vega64 Probleme mit DX11.
Ich hoffe man kann alles erkennen obwohl ich vier Frametimegraphen in ein Diagramm gequetscht habe.
Neu hinzugekommen sind im Vergleich zum vorherigen Diagramm blau als i5 mit DX11 und gelb als Ryzen mit DX11.
Eine ganze Reihe Szenen, die vorher GPU limitiert waren sind jetzt CPU limitiert und läufen massiv schlechter.
DX11 kann die CPUs nicht richtig auslasten und wird zum Flaschenhals.
Die meisten Szenen, die vorher relativ anspruchslos waren und wo der Ryzen seinen Vorteil ausspielen konnte zeigen ein unverändertes Bild.
i5 DX11 liegt auf i5 DX12 und zen DX11 liegt auf zen DX12.
Die Statistik zeigt folgende Unterschiede:
Der Ryzen kann sich unter DX12 bei den avg FPS durchsetzen, was wenig Bedeutung hat, wenn man sich die Frametimegraphen anguckt. Denn dort wird klar, das Ryzen nur in den eh schon gut laufenden Szenen gewinnt.
Der i5 gewinnt dann bei den X% low Werten und damit im wichtigeren Teil.
Auch unter DX11 gewinnt der Ryzen bei den avg FPS, kann aber bei den X% low Werten zumindest einen Gleichstand halten.
Schön sieht man an den Daten, wie viel größer der Unterschied der avg FPS zu den X% low Werten bei DX11 ist im Vergleich zu DX12. Aber das sah man ja schon in den Frametimegraphen.
Für eine Nvidia Grafikkarte würde das Bild vermutlich anders aussehen aber mit einer AMD GPU empfehle ich auf jeden Fall DX12 zu verwenden.
HBCC settings
In diesem Spiel scheinen 16GB HBCC zu viel zu sein.
8 und 12GB lassen sich aufgrund der großen Fehler nicht mit Gewissheit unterscheiden. 12GB könnten aber besser sein.
Ich traue meinen Daten hier nicht genug um eine Empfehlung abzugeben. Eventuell hätte ich dem Treiber auch mehr Zeit geben müssen sich an das Spiel anzupassen.
Ryzen optimieren und übertakten
Mit dem 1800X habe ich bereits das stärkste Modell der Ryzen 1000er Serie.
Aber wie viel Leistung verschenkt man wenn man weder den Ram im Bios einstellt noch den Energiesparplan ändert?
Und wie viel Leistung kann man mit einem minimalen OC auf 3,8GHz und optimieren von Subtimings noch herausholen?
Beides bringt überraschend viel.
100MHz mehr allcore(3,6% mehr score in Cinebench) und 9,6% mehr Leserate des Ram bringen 9,5% mehr avg FPS und 2,3% mehr 1% low.
Der ausbalancierte Energiesparplan sollte inzwischen auch für Ryzen funktionieren und nicht mehr die Kerne schlafen legen aber auf Höchstleistung wird nicht heruntergetaktet.
Einfuss von Ramtakt auf den Infinity Fabric
Hintergrund:
Ganz wichtig sind hier die Fehlerbalken!
Alle Werte haben Unsicherheiten, die ihrer eigenen Größe entspricht!
Ein Vorteil scheint aber durchgängig vorhanden und dürfte um die 3% sein.
Mein Fazit aus diesem speziellen Ergebnis lautet:"Da das Spiel von schnellerem Ram profitiert, sollte man wenn möglich diesen einsetzen.
Die Angst das der IF sonst deutlich limitiert ist in diesem Fall nicht völlig unbegründet, allerdings wirken die Gewinne klein wenn man bedenkt, dass auch 4+0 mit 16-18% durch den Ram zulegt.."
An dieser Stelle
Fazit:
Ashes of the Singularity zeigt ein durchwachsenes Bild.
Der CPU Benchmark mit seiner hohen CPU Auslastung, zeigt eindrucksvoll, was DX12 und CPUs mit vielen Kernen/Threads leisten können.
Man muss sich jedoch fragen ob dies ein sinnvoller Test ist.
Denn im GPU Test zeigt sich der i5 sogar besser als der dicke 8 Kerner!
Der CPU Benchmark ist also sinnlos aufgeblasen mit Arbeit für die CPU, die einer Techdemo gleicht und dem eigentlichen Spiel nur bedingt entspricht.
Der Name Ashes of the Benchmark ist also wirklich Programm.
Und ein Programm, das ich als Ausblick in eine stark multithreading orientierte PC-Spiele-Zukunft gerne annehme.
Wichtig für diesen Test war vor allem die Fallstricke zu zeigen und dafür zu sensibilisieren wie mit dieser Techdemo umgegangen wird.
Wenn ihr in Tests nur den Namen lest, horcht auf und guckt genau ob die CPU Szene oder die GPU Szene oder gar eine Gameplayszene benutzt wurde....Und die API nicht vergessen!
Denn durch geziehlte Kombinationen kann man das Ergebnis massiv verändern und mal einen einige Jahre alten quadcore als Held zeigen oder ihn als abgeschlagen brandmarken.
Ich bin mir nicht sicher, wie meine Ergebnisse mit einer Nvidia GPU ausgegangen wären, aber ich hätte vermutet, dass der starke Einbruch bei verwendung von DX11 nicht passiert wäre.
Über den HBCC konnte ich keine verlässliche Aussage treffen.
Die Analyse des Infinity Fabric Einflusses ist stark fehlerbehaftet und mit Vorsicht zu genießen!
Es scheint aber wichtiger zu sein als in anderen Spielen, was logisch erscheint, wenn das Spiel viele Threads benutzt und damit auch viel Kommunikation über den IF läuft.
Was meint ihr zu den Problematiken für Tests mit diesem Spiel?
Tolle Techdemo oder sinnlos da nicht relevant?
https://www.computerbase.de/forum/t...kussion-zu-spieletests.1728575/#post-20678303
Intro:
Ashes of the Benchmark....Ach ne...Ashes of the Singularity
.Spielerisch eine Art Supreme Commander Klon, ist es eher für seine DX12 und Vulkan Unterstützung, sowie die gute Auslastung von vielen CPU Threads bekannt.
Es wird ebenfalls DX11 angeboten und es gibt einen integrierten CPU und einen GPU Benchmark.
Dabei lässt sich der CPU Benchmark leider nicht mit DX11 starten.
Ich habe mich auf DX12 und den CPU Benchmark focusiert, als Ergänzung jedoch auch DX11 gegen DX12(erzwungenermaßen im GPU Benchmark) getestet.
Die Testkandidaten sind mein Ryzen 1800X in verschiedenen Konfigurationen gegen einen i5 3570K.
Beide mit meiner Vega64 LC(undervolted) gepaart.
In diesem Review zeige ich diverse Aspekte wie:
Einflüsse von 4 vs 8 Kernen, SMT an/aus, Skalierung mit Ramgeschwindigkeit, verschiedene CCX Konfigurationen für Ryzen. IPC Vergleiche, Einfluss des HBCC, Einfluss von CPU und RAM Optimierungen, DX12 vs 11 und eine Betrachtung der Infinity Fabric Skalierung.
Fangen wir mit der Testszene an.
Wie man in dem Video sehen kann lässt DX12 hier seine Muskeln spielen und eine Auslastung von über 80% bei einer 16 Thread CPU sucht seinesgleichen.
Laut den Entwicklern sind die Benchmarks aufgebaut und berechnet wie richtige Gameplay Szenen und sollen repräsentativ für diese sein.
Allerdings werden im normalen Spiel CPUs mit vier oder weniger Kernen mit deutlich weniger Partikeleffekten belastet und laufen deshalb besser als die eigentlich stärkeren 6 und 8 Kern CPUs. In den Benchmarks soll dies nicht so sein und auch die 4 Kerner müssen die Arbeit der größeren CPUs verrichten.
Eine etwas komische Entscheidung aber mir soll es egal sein.
Verglichen mit einem normalen Spiel gegen mehrere KI Gegner zeigte sich eher ein Verhalten wie in dem GPU Test.
Das bedeutet eine eigentlich gute Performance , die dann deutlich abfällt, wenn man eine große Armee angesammelt hat und damit geballt den gegnerischen Nexus/Hauptstreitmacht angreift.
Diese großen Schlachten sind dann ungefär so wie der CPU Test es dauerhaft zeigt.
Da mich immer diese Worst case Szenarien interessieren, habe ich mich für den CPU Benchmark entschieden.
Obwohl so ein Benchmark eine gute Reproduzierbarkeit erwarten lässt, wurde ich enttäuscht. Die Schwankungen sind relativ groß und auch nachdem ich von erst nur 30s auf 170s Messung gegangen bin, ist es noch nicht perfekt.
Und fünf mal den drei minütigen Benchmark mit 23s Ladezeit zu starten ist sehr zeitaufwendig.
Wer die Szene selbst testen möchte findet im Video die Grafikeinstellungen.
Wichtig ist, dass unter DX12 das Fraps Overlay nicht funktioniert und Fraps beim starten nicht offen sein darf.
Man muss also erst das Spiel starten, es dann minimieren um Fraps zu starten(170s einstellen) und die Messungen blind aktivieren sobald der eingeblendete Countdown des Benchmarks für eine Sekunde verschwunden ist.
Frametimegraphen CPU Benchmark:
Zuerst der Vergleich meines Ryzen 7@3,8GHz und des Ivy Bridge i5 mit 4,4GHz
Wie man sieht, hat das Spiel eine relativ gleichbleibende Performance, die periodisch hoch und runter schwankt.
Der Ryzen kann sich mit seinen 16 Threads deutlichst absetzen und zeigt viel niedrigere Frametimes auch wenn im hinteren Bereich ein paar Ausreißer dabei sind.
Sonderlich gut scheint dem Spiel die Ryzen Architectur jedoch nicht gut zu schmecken, denn mit nur vier Kernen gibt es ein Kopf an Kopf Rennen mit dem i5 3570K, den der i5 im Detail für sich entscheiden kann.
Wo in vielen anderen Spielen der i5 trotz 600MHz mehr hinten liegt, kann er sich hier besser behaupten.
Um diesem Auf und Ab eine quantitative Entsprechung zu geben benutze ich eine Reihe statistischer Werte die ich aus der Auswertung von jeweils fünf Messungen gewinne.
Die gezeigten Frametimeverläufe waren jeweils die zweit besten was die 0.1% low Werte angeht.
i5 vs. Ryzen
Zur Erklärung des Diagramms:
Aufgetragen auf der y- Achse sind die "inversen Frametimes". Das sind im Grunde die FPS aber halt nicht durch "Zählen von Frames über einen Zeitraum" bestimmt, sondern über den Kehrwert der Frametimes gebildet.
Wenn ihr hier bei einem Wert links(avg FPS) 44 in 1/s seht, dann würde euch Fraps auch 44 FPS anzeigen.
Aus dem Frametimeverlauf bestimme ich einen effektiven Frametimeverlauf. Diesen habe ich ausführlich im Hauptthread unter "Nomenklatur" diskutiert.
"avg eff FPS" ist der Kehrwert des Durchschnitts dieses effektiven Frametimeverlaufs.
Um so stärker dieser Wert gegenüber den avg FPS abfällt um so stärker sind die relativen Schwankungen der Frametimes ....eine Art "Mikroschwankungsindikator".
Es folgen die Xth percentile und X% low Werte, die sich Stück für Stück immer weiter den schlechten Frametime Werten zuwenden und daher für das Spielgefühl besonders wichtig sind.
5%low und 99th percentile sind dabei noch eher auf den allgemeinen Spielfluss konzentriert und bekommen wenig bis nichts von einzelnen Frametimepeaks(Rucklern) mit.
Die letzten drei Werte werden je nach Spiel mehr oder weniger von diesen Frametimepeaks dominiert und sind meiner Meinung nach oft das beste Mittel um zu beschreiben ob und wie "Ruckelig" sich das Spiel anfühlt.
Leider basieren sie nur auf einem kleinen Teil der Frametimes und daher unterliegen sie größeren Ungenauigkeiten.
Auch wenn ich die 0,1% low Werte sehr schätze, bieten sie oft zu schlechte Reproduzierbarkeiten und daher bin ich ein großer Fan der 1% low Werte.
Diese sind in der Regel noch gut zu reproduzieren und entsprechen sinnvoll dem Spielgefühl.
Die Linien zwischen den Symbolen sind extra gestrichelt, da sie nur zur besseren Lesbarkeit beitragen sollen und keine Punkte dazwischen suggerieren sollen.
In der Legende sieht man die Symbolformen und Farben der verscheidenen Testkandidaten.
Die Wertepunkte selbst sind Durchschnittswerte aus den drei besten Werten von fünf Messungen und haben zusätzlich Fehlerbalken, die sich aus der empirischen Standardabweichung dieser drei besten Werte ergeben.
Wenn ihr hier bei einem Wert links(avg FPS) 44 in 1/s seht, dann würde euch Fraps auch 44 FPS anzeigen.
Aus dem Frametimeverlauf bestimme ich einen effektiven Frametimeverlauf. Diesen habe ich ausführlich im Hauptthread unter "Nomenklatur" diskutiert.
"avg eff FPS" ist der Kehrwert des Durchschnitts dieses effektiven Frametimeverlaufs.
Um so stärker dieser Wert gegenüber den avg FPS abfällt um so stärker sind die relativen Schwankungen der Frametimes ....eine Art "Mikroschwankungsindikator".
Es folgen die Xth percentile und X% low Werte, die sich Stück für Stück immer weiter den schlechten Frametime Werten zuwenden und daher für das Spielgefühl besonders wichtig sind.
5%low und 99th percentile sind dabei noch eher auf den allgemeinen Spielfluss konzentriert und bekommen wenig bis nichts von einzelnen Frametimepeaks(Rucklern) mit.
Die letzten drei Werte werden je nach Spiel mehr oder weniger von diesen Frametimepeaks dominiert und sind meiner Meinung nach oft das beste Mittel um zu beschreiben ob und wie "Ruckelig" sich das Spiel anfühlt.
Leider basieren sie nur auf einem kleinen Teil der Frametimes und daher unterliegen sie größeren Ungenauigkeiten.
Auch wenn ich die 0,1% low Werte sehr schätze, bieten sie oft zu schlechte Reproduzierbarkeiten und daher bin ich ein großer Fan der 1% low Werte.
Diese sind in der Regel noch gut zu reproduzieren und entsprechen sinnvoll dem Spielgefühl.
Die Linien zwischen den Symbolen sind extra gestrichelt, da sie nur zur besseren Lesbarkeit beitragen sollen und keine Punkte dazwischen suggerieren sollen.
In der Legende sieht man die Symbolformen und Farben der verscheidenen Testkandidaten.
Die Wertepunkte selbst sind Durchschnittswerte aus den drei besten Werten von fünf Messungen und haben zusätzlich Fehlerbalken, die sich aus der empirischen Standardabweichung dieser drei besten Werte ergeben.
Wie schon in dem Frametimegraph zu sehen, liegt der Ryzen mit 8 Kernen und SMT deutlich in Führung, auch wenn er ab und zu Ausreißer in den Frametimes hat, die aber immer noch besser sind als die der anderen Testkandidaten.
Der i5 mit 4,4GHz kann sich vor die 4 Kerne des Ryzen schieben und zeigt weniger Schwankungen.
Wird bei den 4 Zen Kernen SMT hinzugeschaltet, steigt die Leistung deutlich und taktet man den i5 nur mit Referenztakt und freigegebenem Ram, fällt dieser deutlich zurück.
Ryzen CCX Konfiguration und SMT
Ashes of the Singularity ist eines der wenigen Spiele, die auch bei 8 Kernen noch von SMT profitieren.
Der CPU Benchmark giert nach Rohleistung.
Die 4+0 Konfiguration schlägt hier die 2+2 Konfiguration und würde sich minimal vor den i5 mit 4,4GHZ schieben.
4+0 hat den Vorteil keine Komunikation der Kerne über den IF zu haben, muss im Gegenzug aber mit dem halben L3 Cache zurechtkommen.
Wie wir in diesem Frametimegrah sehen, sind die Unterschiede gut messbar, zeigen aber keine Auffälligkeiten im Erscheinungsbild:
Leistungsaufspaltung beim i5
Ein gesenkter Ram Takt macht sich nicht gut, jedoch immer noch besser als der Referenztakt.
IPC Vergleich
Drei mal vier Kerne, ohne HT/SMT, bei 2,8GHz im Vergleich.
Ryzen ist zweimal vertreten und zwar einmal mit schnellem und einmal mit langsamem Ram.
Auch mit 2133er DDR4 zeigen sich noch IPC Vorteile für den Ryzen, vor allem weil ich hier nicht die 2+2 sondern die 4+0 Konfiguration gewählt habe.
Unterschiedliche Ram Skalierung bei anderen Kern und Thread Anzahlen?
Egal ob 4 Kerne oder 8 mit SMT. Der Gewinn durch schnellen Ram ist deutlich.
Auch der i5 profitiert von schnellerem DDR3 Ram.
CPU vs GPU Benchmark
Bevor wir uns DX11 vs 12 abgucken können müssen wir einen Blick auf den GPU Benchmark werfen, da wir nur hier diesen Vergleich machen können.
GPU Benchmark Videos:
Erst DX12:
Und dann DX11
Und dann DX11
Und hier den Vergleich der Frametimeverläufe:
Man kann sehen, dass der GPU Benchmark über weite Teile deutlich besser läuft und größere Schwankungen von Szene zu Szene zeigt.
In einigen Szenen ist die Performance dann sogar schlechter als im CPU Benchmark, wenn auch nicht deutlich.
Im Video kann man sehen, das DX12 es schafft die Grafikkarte fast immer auf einer hohen Auslastung zu halten und Auch diese schlecht laufenden Szenen vor allem durch die GPU limitiert sind.
Das wird auch durch folgenden Frametimevergleich bestätigt:
Der Ryzen kann sich mit seinen 8 Kernen, in diesen Szenen, nicht absetzen und läuft dank größerer Schwankungen sogar schlechter. Wieder einmal zeigt sich, dass es im GPU limit vor allem Takt braucht.
Vorteile kann Ryzen in den anspruchsloseren Szenen für sich verbuchen. Hier kann er mit mehr CPU Rohleistung höhere FPS erreichen.
DirectX 11 vs 12
Sowohl auf dem i5 als auch auf dem Ryzen hat die Vega64 Probleme mit DX11.
Ich hoffe man kann alles erkennen obwohl ich vier Frametimegraphen in ein Diagramm gequetscht habe.
Neu hinzugekommen sind im Vergleich zum vorherigen Diagramm blau als i5 mit DX11 und gelb als Ryzen mit DX11.
Eine ganze Reihe Szenen, die vorher GPU limitiert waren sind jetzt CPU limitiert und läufen massiv schlechter.
DX11 kann die CPUs nicht richtig auslasten und wird zum Flaschenhals.
Die meisten Szenen, die vorher relativ anspruchslos waren und wo der Ryzen seinen Vorteil ausspielen konnte zeigen ein unverändertes Bild.
i5 DX11 liegt auf i5 DX12 und zen DX11 liegt auf zen DX12.
Die Statistik zeigt folgende Unterschiede:
Der Ryzen kann sich unter DX12 bei den avg FPS durchsetzen, was wenig Bedeutung hat, wenn man sich die Frametimegraphen anguckt. Denn dort wird klar, das Ryzen nur in den eh schon gut laufenden Szenen gewinnt.
Der i5 gewinnt dann bei den X% low Werten und damit im wichtigeren Teil.
Auch unter DX11 gewinnt der Ryzen bei den avg FPS, kann aber bei den X% low Werten zumindest einen Gleichstand halten.
Schön sieht man an den Daten, wie viel größer der Unterschied der avg FPS zu den X% low Werten bei DX11 ist im Vergleich zu DX12. Aber das sah man ja schon in den Frametimegraphen.
Für eine Nvidia Grafikkarte würde das Bild vermutlich anders aussehen aber mit einer AMD GPU empfehle ich auf jeden Fall DX12 zu verwenden.
HBCC settings
In diesem Spiel scheinen 16GB HBCC zu viel zu sein.
8 und 12GB lassen sich aufgrund der großen Fehler nicht mit Gewissheit unterscheiden. 12GB könnten aber besser sein.
Ich traue meinen Daten hier nicht genug um eine Empfehlung abzugeben. Eventuell hätte ich dem Treiber auch mehr Zeit geben müssen sich an das Spiel anzupassen.
Ryzen optimieren und übertakten
Mit dem 1800X habe ich bereits das stärkste Modell der Ryzen 1000er Serie.
Aber wie viel Leistung verschenkt man wenn man weder den Ram im Bios einstellt noch den Energiesparplan ändert?
Und wie viel Leistung kann man mit einem minimalen OC auf 3,8GHz und optimieren von Subtimings noch herausholen?
Beides bringt überraschend viel.
100MHz mehr allcore(3,6% mehr score in Cinebench) und 9,6% mehr Leserate des Ram bringen 9,5% mehr avg FPS und 2,3% mehr 1% low.
Der ausbalancierte Energiesparplan sollte inzwischen auch für Ryzen funktionieren und nicht mehr die Kerne schlafen legen aber auf Höchstleistung wird nicht heruntergetaktet.
Einfuss von Ramtakt auf den Infinity Fabric
Hintergrund:
Wer sich mit Ryzen beschäftigt hat, der wird öfter gehört haben, dass Ryzen schnellen Ram braucht, weil sonst die Kommunikation zwischen den CCX durch einen lansamen IF behindert wird.
Aber ist dem auch so? Ich habe noch keinen brauchbaren Test gesehen, der das untersucht hat und habe mir was eigenes überlegt.
Theoretisch ist da schonmal was dran. Gerade in neueren PC Spielen wird die Arbeit auf mehrere Kerne aufgeteilt und es findet viel Kommunikation statt um alles synchron zu halten und die Ergebnisse zusammenzuführen.
Der IF ist an den Takt des Ram gekoppelt und es gibt Veröffentlichungen, die zeigen das sich die Latenzen von einem CCX zum anderen mit schnellerem Ram verbessern.
Die Frage ist, ob dies rein theoretisch ist oder wirklich so signifikant, dass es sich auch in der Spieleperformance niederschlägt.
Leider steigt mit schnellerem Ram auch die Spieleperformance und es wird schwer zu sehen, was davon die IF Verbesserung war und was einfach der schnelle Ram.
Die IF Unterschiede von 2+2 zu 4+0 werden durch den doppelten L3 Cache bei 2+2 verschleiert.
Vorgehen
Bei den Ryzen 8 Kernern hat man die Möglichkeit über das Bios Kerne zu deaktivieren und dies habe ich einmal als 2+2 und einmal als 4+0 Konfiguration gemacht. SMT war deaktiviert.
Dann habe ich beides einmal mit 2133 und einmal mit 3200er Ram getestet.
Dann habe ich den prozentualen Performance Gewinn(2133 zu 3200) einmal für 2+2 und für 4+0 ermittelt und die Differenz gebildet.
Unter der Annahme, das der Gewinn durch den schnelleren Ram gleich sein sollte, zeigt die Differenz also den reinen Einfluss durch den beschleunigten IF.
Die Ergebnisse beruhen allerdings auf je vier fehlerbehafteten Größen und wenn man mit Gaußscher Fehlerfortpflanzung die Fortpflanzung dieser Fehler in das Endergebnis berechnet, zeigen sich leider große Unsicherheiten.
Aber ist dem auch so? Ich habe noch keinen brauchbaren Test gesehen, der das untersucht hat und habe mir was eigenes überlegt.
Theoretisch ist da schonmal was dran. Gerade in neueren PC Spielen wird die Arbeit auf mehrere Kerne aufgeteilt und es findet viel Kommunikation statt um alles synchron zu halten und die Ergebnisse zusammenzuführen.
Der IF ist an den Takt des Ram gekoppelt und es gibt Veröffentlichungen, die zeigen das sich die Latenzen von einem CCX zum anderen mit schnellerem Ram verbessern.
Die Frage ist, ob dies rein theoretisch ist oder wirklich so signifikant, dass es sich auch in der Spieleperformance niederschlägt.
Leider steigt mit schnellerem Ram auch die Spieleperformance und es wird schwer zu sehen, was davon die IF Verbesserung war und was einfach der schnelle Ram.
Die IF Unterschiede von 2+2 zu 4+0 werden durch den doppelten L3 Cache bei 2+2 verschleiert.
Vorgehen
Bei den Ryzen 8 Kernern hat man die Möglichkeit über das Bios Kerne zu deaktivieren und dies habe ich einmal als 2+2 und einmal als 4+0 Konfiguration gemacht. SMT war deaktiviert.
Dann habe ich beides einmal mit 2133 und einmal mit 3200er Ram getestet.
Dann habe ich den prozentualen Performance Gewinn(2133 zu 3200) einmal für 2+2 und für 4+0 ermittelt und die Differenz gebildet.
Unter der Annahme, das der Gewinn durch den schnelleren Ram gleich sein sollte, zeigt die Differenz also den reinen Einfluss durch den beschleunigten IF.
Die Ergebnisse beruhen allerdings auf je vier fehlerbehafteten Größen und wenn man mit Gaußscher Fehlerfortpflanzung die Fortpflanzung dieser Fehler in das Endergebnis berechnet, zeigen sich leider große Unsicherheiten.
Ganz wichtig sind hier die Fehlerbalken!
Alle Werte haben Unsicherheiten, die ihrer eigenen Größe entspricht!
Ein Vorteil scheint aber durchgängig vorhanden und dürfte um die 3% sein.
Mein Fazit aus diesem speziellen Ergebnis lautet:"Da das Spiel von schnellerem Ram profitiert, sollte man wenn möglich diesen einsetzen.
Die Angst das der IF sonst deutlich limitiert ist in diesem Fall nicht völlig unbegründet, allerdings wirken die Gewinne klein wenn man bedenkt, dass auch 4+0 mit 16-18% durch den Ram zulegt.."
An dieser Stelle
Fazit:
Ashes of the Singularity zeigt ein durchwachsenes Bild.
Der CPU Benchmark mit seiner hohen CPU Auslastung, zeigt eindrucksvoll, was DX12 und CPUs mit vielen Kernen/Threads leisten können.
Man muss sich jedoch fragen ob dies ein sinnvoller Test ist.
Denn im GPU Test zeigt sich der i5 sogar besser als der dicke 8 Kerner!
Der CPU Benchmark ist also sinnlos aufgeblasen mit Arbeit für die CPU, die einer Techdemo gleicht und dem eigentlichen Spiel nur bedingt entspricht.
Der Name Ashes of the Benchmark ist also wirklich Programm.
Und ein Programm, das ich als Ausblick in eine stark multithreading orientierte PC-Spiele-Zukunft gerne annehme.
Wichtig für diesen Test war vor allem die Fallstricke zu zeigen und dafür zu sensibilisieren wie mit dieser Techdemo umgegangen wird.
Wenn ihr in Tests nur den Namen lest, horcht auf und guckt genau ob die CPU Szene oder die GPU Szene oder gar eine Gameplayszene benutzt wurde....Und die API nicht vergessen!
Denn durch geziehlte Kombinationen kann man das Ergebnis massiv verändern und mal einen einige Jahre alten quadcore als Held zeigen oder ihn als abgeschlagen brandmarken.
Ich bin mir nicht sicher, wie meine Ergebnisse mit einer Nvidia GPU ausgegangen wären, aber ich hätte vermutet, dass der starke Einbruch bei verwendung von DX11 nicht passiert wäre.
Über den HBCC konnte ich keine verlässliche Aussage treffen.
Die Analyse des Infinity Fabric Einflusses ist stark fehlerbehaftet und mit Vorsicht zu genießen!
Es scheint aber wichtiger zu sein als in anderen Spielen, was logisch erscheint, wenn das Spiel viele Threads benutzt und damit auch viel Kommunikation über den IF läuft.
Was meint ihr zu den Problematiken für Tests mit diesem Spiel?
Tolle Techdemo oder sinnlos da nicht relevant?
Zuletzt bearbeitet:
