Baal Netbeck
Fleet Admiral
- Registriert
- Apr. 2008
- Beiträge
- 11.956
Dies ist ein ausgelagertes Thema aus diesem Hauptthread:
https://www.computerbase.de/forum/t...kussion-zu-spieletests.1728575/#post-20678303
Intro:
Rome TW: Barbarian Invasion ist eine der Erweiterungen zu Rome TW und bringt ein paar neue Funktionen, einen anderen Zeitbereich mit der Bedrohung durch plündernde Horden, mehr Anreize andere Nationen außer den Römern zu spielen und eine größere Herausforderung wenn man doch als Römer spielt.
Das Spiel findet größtenteils auf der Kampagnenkarte statt, wo FPS und Frametimes keine Rolle spielen.
Will man jedoch Schlachten effizienter gewinnen, als mit der automatische Berechnung, muss man selbst die Truppen komandieren und sich auf die Schlachtkarte begeben.
Auf der Schlachtkarte wird man leider von einer traurigen Performance begrüßt.
Die vielen Einheiten überfordern auch moderne CPUs, denn das Spiel unterstützt nur einen CPU Thread.
Wir gucken uns also hier eine single core Performance an.
Mir liegt das Spiel sehr am Herzen und ich erinnere mich noch an die Zeit als ich mit einstelligen FPS meine ruckelnden Armeen über die Karte gescheucht habe...der Pentium 4 war völlig überfordert
.
Die Testkandidaten sind mein Ryzen 1800X in verschiedenen Konfigurationen gegen einen i5 3570K.
Beide mit meiner Vega64 LC(undervolted) gepaart.
Und als Bonus noch meinen alten Core2Quad 9550 mit einer GTX285 hineingemixt.
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, Windows 7 vs. 10 und eine Betrachtung der Infinity Fabric Skalierung.
Fangen wir mit der Testszene an.
https://www.youtube.com/watch?v=0FueCpQomOg&index=1&list=PLP9fskJGwUOT5CByAJMJrXaggyMuUgsFt
Als Szene nutze ich eine nachspielbare historische Schlacht in Chalon, die mit zwei großen Armeen, recht vielen Bogenschützen usw. eine hohe Belastung darstellt. Man könnte auch eine eigene Schlacht erstellen um die FPS noch weiter zu drücken, aber diese Schlacht erschien mir anspruchsvoll ohne unrealistisch zu sein.
Ich habe mich dagegen entschieden das Schlachten Intro zu messen, auch wenn es sehr reproduzierbare Ergebnisse liefern würde. Denn das eigentliche Schlachtgeschehen interessiert mich mehr, als die Aneinanderreihung geskripteter Kameraschwenks.
Ich wähle also all meine Truppen aus, schicke sie mit einem doppelten Rechtsklick, auf Angriffskurs mit der etwas rötere Infantrieeinheit in der Mitte der gegnerischen Armee.
Dann starte ich die Schlacht und eine Sekunde später starte ich die 60s Messung.
Da die Leistung sehr stark mit der Kameraposition schwankt und es schwer ist sie reproduzierbar zu bewegen, habe ich mich dazu entschieden die Kamera einfach automatisch nachrücken zu lassen.
Da die niedrigen FPS am Ende nur wenigen gemessenen Frametimes entsprechen, bleiben gerade für die 99.9th percentile und 0.1% low Werte nur das aller schlechteste Frametime übrig. Das führt leider zu größeren Schwankungen von Messung zu Messung, konnte aber nicht verhindert werden.
Für mehr Frametimes und damit einer besseren Statistik für die 0.1% lows, hätte ich länger messen müssen, aber dann hätte sich das Schlachtenglück(und damit die FPS) zu sehr von Messung zu Messung geändert. Außerdem wären die Chancen gestiegen, dass einer der Generäle ins Gras beißt und die Kamera zu dem Ereignis springt.
Dies wollte ich vermeiden und wenn es passiert ist, habe ich die Messung verworfen und wiederholt.
60s haben sich für mich als ein guter Mittelweg aus Messzeit und Einfluss des Schlachtenglücks erwiesen.
Wer die Szene selbst testen möchte, kann in der .ini Datei die Auflösung auf 1440p stellen...Das ist allerdings kein Muss weil die Auflösung keinerlei Einfluss zu haben scheint.
Alle wichtigen Optionen sind dem Video zu entnehmen.
Frametimegraphen:
Zuerst der Vergleich meines Ryzen 7@3,8GHz und des Ivy Bridge i5 mit 4,4GHz
Wie man sieht, hat das Spiel mit deutlichen Frametime Schwankungen zu kämpfen.
Der i5 startet mit besseren Frametimes aber endet mit schlechteren.
Der Ryzen hat eine konstantere Performance aber im hinteren Teil einige schlechte einzelne Frametimes.
Es sieht so aus als gäbe es für den Ryzen Frametime Stufen.
Erst schwanken die Frametimes ab und zu nach unten, dann hoch und runter....und am Ende ab und zu nach oben.
Der i5 hingegen schwankt immer nach Unten und hält dabei keine feste Stufe, sondern wird graduell schlechter umso mehr auf dem Bildschirm passiert.
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.
Aber erstmal werfen wir einen Blick auf einen Vergleich mit dem alten C2Q 9550:
Der Core2Quad läuft wie zu erwarten schlechter und zeigt wie der Ryzen verschiedene Stufen, deren Frametimes mal nach unten und mal nach oben schwanken.
Vergleichen wir also die Systeme quantitativ:
C2Q vs. i5 vs. Ryzen
Zur Erklärung des Diagramms:
Wie schon in den Frametimegraphen zu sehen, ist der alte Core2Quad ziemlich abgeschlagen und der Ryzen mit 8 Kernen und SMT liegt an der Spitze.
Die schlechtere Performance der 2+2 Kerne hat mich etwas überrascht. Da der Windows Scheduler die Last auf verschiedene CPU Kerne verteilt, könnte ich mir vorstellen, dass mit mehr Kernen seltener der CCX gewechselt wird und daher die Performance besser ist....mehr dazu im nächsten Abschnitt.
Ryzen CCX Konfiguration und SMT
Entgegen meine Theorie mit dem selteneren Wechseln des CCX sehen wir hier keine gute Performance für 4+0, was meine Vermutung wiederlegt.
Eventuell die Daten sind nicht gut genug, was ich bei den nur rund 800 Frametimes pro Messung nicht auszuschließen ist.
Wie man sieht sind so einige Fehlerbalken ziemlich groß.
Dadurch, dass relativ zufällig Frametimes nach oebn schwanken, ändern sich die 5% low bis 1% low Werte von Messung zu Messung stärker...zu sehen z.B. in den nächsten zwei Frametimegraphen:
Leistungsaufspaltung beim i5
Keine großen Überraschungen hier.
Nur 2,8 GHz machen sich trotz schnellem Ram nicht gut, die stock Taktraten mit 1600er Ram(Intel Freigabe) müssen sich der Übertaktung auf 4,4GHz geschlagen geben.
Die Messungen für 1333er DDR3 scheinen eine fehlerhaft zu sein, denn sie fallen komplett aus der Reihe.
Der Wechsel von 1066 auf 1866 macht aus dem 75% schnelleren Ram also nur 4,4% mehr avg FPS aus und 4,5% mehr 1% low.
Von 2,8 zu 4,4GHz sind es 57% mehr Takt. Dies führt zu einer Steigerung der avg FPS von 68% und ganzen 75% bei den 1% low.
Die Ram Geschwindigkeit zeigt sich also als sehr unwichtig, wo der CPU Takt sogar überproportional zulegt.
IPC Vergleich
Fünf mal vier Kerne, ohne HT/SMT, bei 2,8GHz im Vergleich.
Wie wir auch später noch sehen werden spielt hier das Betriebssystem eine wichtige Rolle.
Bei Windows 10 sehen wir eine großen Unterschied vom i5 zu Ryzen und auch der C2Q liegt deutlich vorne.
Denn dieser kommt mit Win 7 fast an den Ryzen mit Win 10 ran und der i5 mit Win 7 schließt zum Ryzen mit Win 10 auf.
DDR3 Ram Skalierung
Ich habe eine etwas andere Auftragung gewählt.
Wir sehen hier wie sich die verschiedenen Statistikwerte mit steigender Ram Geschwindigkeit verändern.
Die fehlerhaften Daten zu 1333 habe ich herausgenommen und wie man hier nochmal sieht, interessiert sich Rome TW scheinbar so gut wie gar nicht für die Ram Geschwindigkeit.
DDR4 Ram Skalierung
Es zeigt sich das gleiche Bild wie bei DDR3. Die Leistung ist praktisch gleich auch wenn wir den Ram um 50% schneller gemacht haben.
Windows 7 vs. 10
Wenn nicht anders erwähnt, kommt immer Windows 10 zum Einsatz.
Egal ob mit 2,8 GHz, Stock oder mit 4,4GHz, Windows 7 gewinnt immer deutlich den Vergleich.
Die Unterschiede sieht man auch deutlich als Frametimegraph:
Es zeigt sich ein deutlicher Unterschied im Verhalten der Frametimegraphen. Unter Windows 7 verhält sich der i5 wie die Ryzen Architectur.
Ich habe nachgeprüft und diese Verhalten sind nicht bloß einige Messungen sondern alle i5 Kombinationen mit Windows 10 zeigen diese graduelle Veränderung, währen der i5 mit Windows 7, der C2Q mit Windows 7 und der Ryzen mit Windows 10 stufenweise mal nach oben oder unten schwanken.
Hat hierfür jemand eine Erklärung?
An dieser Stelle auch nochmal eingefügt die Werte des i5 für Windows 7 alleine:
Am beispiel von 2,8GHz sieht man, dass auch unter Windows 7 Rome nicht von Ram profitiert.
Der Takt jedoch eine große Rolle spielt.
HBCC settings
Die Messung mit dem i5 und ohne HBCC scheint schlechter zu sein als mit 12 zugewiesenen GB.
Auf dem Ryzen gibt es nur im sehr Fehlerbehafteten Mittelteil Unterschiede, die ich zu den Messungenauigkeiten dieser Spielszene zähle.
Es ergibt alles wenig Sinn und was man wählt ist vermutlich egal.
Ryzen optimieren und übertakten
Mit dem 1800X habe ich bereits das stärkste Modell der Ryzen 100er Serie.
Aber wie viel Leistung verschenkt man wenn man weder den Ram im Bios einstellt noch den Energiesparplan ändert.
Der ausbalancierte Energiesparplan sollte inzwischen auch für Ryzen funktionieren und nicht mehr die Kerne schlafen legen aber auf Höchstleistung wird nicht heruntergetaktet.
Und wie viel Leistung kann man mit einem minimalen OC auf 3,8GHz und optimieren von Subtimings noch herausholen?
Man hätte eigentlich erwarten können, dass dank einem 1-2 Kern Boost von 4,1GHz der Stock 1800X zumindest mit docp und Höchstleistungsprofil gewinnen würde.
Aber es zeigt sich ein weiteres Mal, dass der Turbo Boost der Ryzen 1000er Serie praktisch nutzlos ist und die 3,8GHz gewinnen wieder.
Da wir vorher gesehen haben, wie wenig schneller Ram in diesem Spiel bringt, gehe ich davon aus das das ausbalancierte Profil hier für die schlechte Leistung der Bios defaults verantwortlich ist.
Einfuss von Ramtakt auf den Infinity Fabric
Hintergrund:
Ganz wichtig sind hier die Fehlerbalken!
Keiner der Werte hat eine Aussagekraft und der Test bleibt daher ergebnislos!
Fazit:
Rome TW: Barbarian Invasion ist vor allem durch CPU single core Leistung limitiert.
Es liebt mehr CPU Takt und ignoriert praktisch den Ram Takt.
Leider schiebt der Windows Scheduler die Last wild über mehrere CPU Kerne und ich vermute hier eine deutliche Bremse für das Spiel, welche unter Windows 7 weniger auftritt.
HBCC und den Infinity Fabric kann man denke ich ignorieren
Warum die Frametimes so ein komisches Verhalten zeigen kann ich mir nicht erklären....kann da jemand Licht ins Dunkel bringen?
https://www.computerbase.de/forum/t...kussion-zu-spieletests.1728575/#post-20678303
Intro:
Rome TW: Barbarian Invasion ist eine der Erweiterungen zu Rome TW und bringt ein paar neue Funktionen, einen anderen Zeitbereich mit der Bedrohung durch plündernde Horden, mehr Anreize andere Nationen außer den Römern zu spielen und eine größere Herausforderung wenn man doch als Römer spielt.
Das Spiel findet größtenteils auf der Kampagnenkarte statt, wo FPS und Frametimes keine Rolle spielen.
Will man jedoch Schlachten effizienter gewinnen, als mit der automatische Berechnung, muss man selbst die Truppen komandieren und sich auf die Schlachtkarte begeben.
Auf der Schlachtkarte wird man leider von einer traurigen Performance begrüßt.
Die vielen Einheiten überfordern auch moderne CPUs, denn das Spiel unterstützt nur einen CPU Thread.
Wir gucken uns also hier eine single core Performance an.
Mir liegt das Spiel sehr am Herzen und ich erinnere mich noch an die Zeit als ich mit einstelligen FPS meine ruckelnden Armeen über die Karte gescheucht habe...der Pentium 4 war völlig überfordert
.Die Testkandidaten sind mein Ryzen 1800X in verschiedenen Konfigurationen gegen einen i5 3570K.
Beide mit meiner Vega64 LC(undervolted) gepaart.
Und als Bonus noch meinen alten Core2Quad 9550 mit einer GTX285 hineingemixt.
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, Windows 7 vs. 10 und eine Betrachtung der Infinity Fabric Skalierung.
Fangen wir mit der Testszene an.
https://www.youtube.com/watch?v=0FueCpQomOg&index=1&list=PLP9fskJGwUOT5CByAJMJrXaggyMuUgsFt
Als Szene nutze ich eine nachspielbare historische Schlacht in Chalon, die mit zwei großen Armeen, recht vielen Bogenschützen usw. eine hohe Belastung darstellt. Man könnte auch eine eigene Schlacht erstellen um die FPS noch weiter zu drücken, aber diese Schlacht erschien mir anspruchsvoll ohne unrealistisch zu sein.
Ich habe mich dagegen entschieden das Schlachten Intro zu messen, auch wenn es sehr reproduzierbare Ergebnisse liefern würde. Denn das eigentliche Schlachtgeschehen interessiert mich mehr, als die Aneinanderreihung geskripteter Kameraschwenks.
Ich wähle also all meine Truppen aus, schicke sie mit einem doppelten Rechtsklick, auf Angriffskurs mit der etwas rötere Infantrieeinheit in der Mitte der gegnerischen Armee.
Dann starte ich die Schlacht und eine Sekunde später starte ich die 60s Messung.
Da die Leistung sehr stark mit der Kameraposition schwankt und es schwer ist sie reproduzierbar zu bewegen, habe ich mich dazu entschieden die Kamera einfach automatisch nachrücken zu lassen.
Da die niedrigen FPS am Ende nur wenigen gemessenen Frametimes entsprechen, bleiben gerade für die 99.9th percentile und 0.1% low Werte nur das aller schlechteste Frametime übrig. Das führt leider zu größeren Schwankungen von Messung zu Messung, konnte aber nicht verhindert werden.
Für mehr Frametimes und damit einer besseren Statistik für die 0.1% lows, hätte ich länger messen müssen, aber dann hätte sich das Schlachtenglück(und damit die FPS) zu sehr von Messung zu Messung geändert. Außerdem wären die Chancen gestiegen, dass einer der Generäle ins Gras beißt und die Kamera zu dem Ereignis springt.
Dies wollte ich vermeiden und wenn es passiert ist, habe ich die Messung verworfen und wiederholt.
60s haben sich für mich als ein guter Mittelweg aus Messzeit und Einfluss des Schlachtenglücks erwiesen.
Wer die Szene selbst testen möchte, kann in der .ini Datei die Auflösung auf 1440p stellen...Das ist allerdings kein Muss weil die Auflösung keinerlei Einfluss zu haben scheint.
Alle wichtigen Optionen sind dem Video zu entnehmen.
Frametimegraphen:
Zuerst der Vergleich meines Ryzen 7@3,8GHz und des Ivy Bridge i5 mit 4,4GHz
Wie man sieht, hat das Spiel mit deutlichen Frametime Schwankungen zu kämpfen.
Der i5 startet mit besseren Frametimes aber endet mit schlechteren.
Der Ryzen hat eine konstantere Performance aber im hinteren Teil einige schlechte einzelne Frametimes.
Es sieht so aus als gäbe es für den Ryzen Frametime Stufen.
Erst schwanken die Frametimes ab und zu nach unten, dann hoch und runter....und am Ende ab und zu nach oben.
Der i5 hingegen schwankt immer nach Unten und hält dabei keine feste Stufe, sondern wird graduell schlechter umso mehr auf dem Bildschirm passiert.
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.
Aber erstmal werfen wir einen Blick auf einen Vergleich mit dem alten C2Q 9550:
Der Core2Quad läuft wie zu erwarten schlechter und zeigt wie der Ryzen verschiedene Stufen, deren Frametimes mal nach unten und mal nach oben schwanken.
Vergleichen wir also die Systeme quantitativ:
C2Q vs. 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.
Die schlechtere Performance der 2+2 Kerne hat mich etwas überrascht. Da der Windows Scheduler die Last auf verschiedene CPU Kerne verteilt, könnte ich mir vorstellen, dass mit mehr Kernen seltener der CCX gewechselt wird und daher die Performance besser ist....mehr dazu im nächsten Abschnitt.
Ryzen CCX Konfiguration und SMT
Entgegen meine Theorie mit dem selteneren Wechseln des CCX sehen wir hier keine gute Performance für 4+0, was meine Vermutung wiederlegt.
Eventuell die Daten sind nicht gut genug, was ich bei den nur rund 800 Frametimes pro Messung nicht auszuschließen ist.
Wie man sieht sind so einige Fehlerbalken ziemlich groß.
Dadurch, dass relativ zufällig Frametimes nach oebn schwanken, ändern sich die 5% low bis 1% low Werte von Messung zu Messung stärker...zu sehen z.B. in den nächsten zwei Frametimegraphen:
Leistungsaufspaltung beim i5
Keine großen Überraschungen hier.
Nur 2,8 GHz machen sich trotz schnellem Ram nicht gut, die stock Taktraten mit 1600er Ram(Intel Freigabe) müssen sich der Übertaktung auf 4,4GHz geschlagen geben.
Die Messungen für 1333er DDR3 scheinen eine fehlerhaft zu sein, denn sie fallen komplett aus der Reihe.
Der Wechsel von 1066 auf 1866 macht aus dem 75% schnelleren Ram also nur 4,4% mehr avg FPS aus und 4,5% mehr 1% low.
Von 2,8 zu 4,4GHz sind es 57% mehr Takt. Dies führt zu einer Steigerung der avg FPS von 68% und ganzen 75% bei den 1% low.
Die Ram Geschwindigkeit zeigt sich also als sehr unwichtig, wo der CPU Takt sogar überproportional zulegt.
IPC Vergleich
Fünf mal vier Kerne, ohne HT/SMT, bei 2,8GHz im Vergleich.
Wie wir auch später noch sehen werden spielt hier das Betriebssystem eine wichtige Rolle.
Bei Windows 10 sehen wir eine großen Unterschied vom i5 zu Ryzen und auch der C2Q liegt deutlich vorne.
Denn dieser kommt mit Win 7 fast an den Ryzen mit Win 10 ran und der i5 mit Win 7 schließt zum Ryzen mit Win 10 auf.
DDR3 Ram Skalierung
Ich habe eine etwas andere Auftragung gewählt.
Wir sehen hier wie sich die verschiedenen Statistikwerte mit steigender Ram Geschwindigkeit verändern.
Die fehlerhaften Daten zu 1333 habe ich herausgenommen und wie man hier nochmal sieht, interessiert sich Rome TW scheinbar so gut wie gar nicht für die Ram Geschwindigkeit.
DDR4 Ram Skalierung
Es zeigt sich das gleiche Bild wie bei DDR3. Die Leistung ist praktisch gleich auch wenn wir den Ram um 50% schneller gemacht haben.
Windows 7 vs. 10
Wenn nicht anders erwähnt, kommt immer Windows 10 zum Einsatz.
Egal ob mit 2,8 GHz, Stock oder mit 4,4GHz, Windows 7 gewinnt immer deutlich den Vergleich.
Die Unterschiede sieht man auch deutlich als Frametimegraph:
Es zeigt sich ein deutlicher Unterschied im Verhalten der Frametimegraphen. Unter Windows 7 verhält sich der i5 wie die Ryzen Architectur.
Ich habe nachgeprüft und diese Verhalten sind nicht bloß einige Messungen sondern alle i5 Kombinationen mit Windows 10 zeigen diese graduelle Veränderung, währen der i5 mit Windows 7, der C2Q mit Windows 7 und der Ryzen mit Windows 10 stufenweise mal nach oben oder unten schwanken.
Hat hierfür jemand eine Erklärung?
An dieser Stelle auch nochmal eingefügt die Werte des i5 für Windows 7 alleine:
Am beispiel von 2,8GHz sieht man, dass auch unter Windows 7 Rome nicht von Ram profitiert.
Der Takt jedoch eine große Rolle spielt.
HBCC settings
Die Messung mit dem i5 und ohne HBCC scheint schlechter zu sein als mit 12 zugewiesenen GB.
Auf dem Ryzen gibt es nur im sehr Fehlerbehafteten Mittelteil Unterschiede, die ich zu den Messungenauigkeiten dieser Spielszene zähle.
Es ergibt alles wenig Sinn und was man wählt ist vermutlich egal
.Ryzen optimieren und übertakten
Mit dem 1800X habe ich bereits das stärkste Modell der Ryzen 100er Serie.
Aber wie viel Leistung verschenkt man wenn man weder den Ram im Bios einstellt noch den Energiesparplan ändert.
Der ausbalancierte Energiesparplan sollte inzwischen auch für Ryzen funktionieren und nicht mehr die Kerne schlafen legen aber auf Höchstleistung wird nicht heruntergetaktet.
Und wie viel Leistung kann man mit einem minimalen OC auf 3,8GHz und optimieren von Subtimings noch herausholen?
Man hätte eigentlich erwarten können, dass dank einem 1-2 Kern Boost von 4,1GHz der Stock 1800X zumindest mit docp und Höchstleistungsprofil gewinnen würde.
Aber es zeigt sich ein weiteres Mal, dass der Turbo Boost der Ryzen 1000er Serie praktisch nutzlos ist und die 3,8GHz gewinnen wieder.
Da wir vorher gesehen haben, wie wenig schneller Ram in diesem Spiel bringt, gehe ich davon aus das das ausbalancierte Profil hier für die schlechte Leistung der Bios defaults verantwortlich ist.
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!
Keiner der Werte hat eine Aussagekraft und der Test bleibt daher ergebnislos!
Fazit:
Rome TW: Barbarian Invasion ist vor allem durch CPU single core Leistung limitiert.
Es liebt mehr CPU Takt und ignoriert praktisch den Ram Takt.
Leider schiebt der Windows Scheduler die Last wild über mehrere CPU Kerne und ich vermute hier eine deutliche Bremse für das Spiel, welche unter Windows 7 weniger auftritt.
HBCC und den Infinity Fabric kann man denke ich ignorieren
Warum die Frametimes so ein komisches Verhalten zeigen kann ich mir nicht erklären....kann da jemand Licht ins Dunkel bringen?
Zuletzt bearbeitet:
