Anno Baals großer Anno 1800 Benchmark - Wie viel RAM und wie schnell?

Wie viel RAM für Anno 1800 und wie schnell soll er sein?​

Entstehung und Erklärungen zum Skript-Benchmark​

Dieser Thread ist ein Ableger eines großen Anno 1800 Benchmarks, der aufgeteilt werden musste.
Der Hauptthread mit den Inhaltsverzeichnis bietet Erläuterungen die vorher gelesen werden sollten.

Die Frage nach der sinnvollen Menge an RAM für Anno 1800 war ein zentraler Grund für den großen Aufwand mit dem Skriptbenchmark.

Spoiler: Weitere Erklärungen

Windows fängt schon ab ca. 80% reserviertem RAM an, vermehrt Daten in die Auslagerungsdatei zu verschieben, so dass es mit wenig RAM schwer ist herauszufinden ob wirklich noch Platz da ist, oder ob notwendige Daten ausgelagert wurden.
Selbst wenn man sehr viel RAM einbaut und sich die reservierte Menge anguckt, und feststellt, dass z.B. mehr als 16GB reserviert wurden, ist das noch kein Garant dafür, dass die 16 GB wirklich zu wenig sind.
Denn es kann sein, dass die wirklich benötigten Daten in die 16 GB passen und der Rest der in die Auslagerungsdatei wandert, kann überflüssig/ungenutzt sein.

Man muss es also austesten und sehen unter welcher Ramkapazität es vermehrt Ruckler gibt.
Da einen Anno Spieler eher nicht die ersten Minuten der Spielzeit interessieren, ist der Spielstand aus dem Lategame mit DLCs und die lange Vorbereitungsphase nötig, um eine Antwort zu liefern die relevant für den Spieler ist.

Die Ergebnisse für die Ramkapazität​

Was man hier sieht sind die prozentualen Unterschiede durch unterschiedlich viel Ram auf die 1% und 0,1% low Frametimes, am Beispiel von Zen2 CPUs.
Der untere Block bezieht sich auf einen Ryzen 3100 der einen halbierten L3 Cache gegenüber einer normalen Zen2 CPU hat, wie sie im oberen Block dargestellt ist.
Wir sehen für den Ryzen 3100 durch den Wechsel von 16 GB auf 32 bzw. 64 GB RAM einen riesen Sprung von 73-130%.
16 GB sind also definitiv zu wenig und 64 GB unnötig viel Kapazität.

Der mittlere Block unterscheidet sich in der Ramgeschwindigkeit gegenüber dem oberen Block und muss mit nur 2666 MT/s auskommen, da die 4 GB Module nicht so hoch zu takten sind.
Mit 100% wieder bezogen auf 16GB RAM, bricht die Leistung mit nur 8 GB massiv ein und liefert weniger als 31%, der bereits nicht ausreichenden 16 GB konfiguration.
32 und 64 GB gewinnen fein den low Frametimes 53-92% und liegen wieder fast gleichauf.
Die 24 GB sind bei den 1% low Frametimes nur leicht schlechter als 32 und 64 GB.
Auch wenn mit 64 GB verfügbarem RAM, davon ca 33 GB reserviert werden, müssen bei 24 GB Ram scheinbar nicht so viele wichtige Daten ausgelagert werden, als dass es einen deutlichen Nachteil bedeutet.

Die Tests bei 3400 MT/s mit 32, 48 und 64 GB im oberen Block zeigt keine Unterschiede außerhalb der Messunsicherheit, da bereits 32 GB ausreichend viel sind.

Als weiteren Indikator für das Auslagern wurde bei einigen Messungen die geschriebenen GB auf dem Systemlaufwerk vor und nach den Messungen verglichen.
Mit 64 GB und 48 GB wurde in den ca. 2 Stunden nur 1 GB an Daten geschrieben.
Mit 32 GB waren es 3 GB,
mit 16 GB waren es 20-21GB,
und mit 8 GB waren es 67 GB die auf das Systemlaufwerk geschrieben wurden.

Was bedeutet das für die FPS?​

Wie zu erwarten gibt es selbst mit 16 GB nur geringe Einbußen für die FPS und lediglich 8 GB liegt deutlich zurück.

Zwischen dem unteren und dem mittleren Block gibt es kaum Unterschiede in der Leistung, obwohl beide gegenüber dem oberen Block andere Nachteile haben.

Der untere Block muss auf die Hälfte des L3 Cache verzichten und hat nur vier statt acht Kerne.
Der mittler Block hat den vollen Cache und 8 Kerne, hat aber dafür mit 2666 statt 3400 MT/s, den langsameren RAM.
Die Effekte heben sich scheinbar zufällig nahezu auf.

Mehr zu Cache und Kernen in einem anderen Artikel-Thread und mehr zur Ramgeschwindigkeit weiter unten.

Wie sieht es mit der RAM-Kapazität bei Zen/Zen+ und Zen3 aus?​

Spoiler: Nicht viel interessantes bei Zen und Zen+ CPUs

Beide Architekturen reagieren genauso wie Zen2.
Zu erwähnen wären die Ergebnisse mit halbiertem L3 Cache, die sogar weniger Skalierung zeigen als die normalen 8 MB pro CCX.
Ein größerer L3 Cache fängt also keine Laufwerkszugriffe auf die Auslagerungsdatei ab.

Spoiler: Mehr Cache reagiert auch bei Zen3 stärker

Die normalen 32 MB L3 Cache reagieren wieder ähnlich auf den Wechsel von 16 auf 32 GB RAM.
Aber die 96 MB L3 Cache profitieren nochmal ein gutes Stück stärker und die 0,1% low Frametimes verdreifachen sich.
Es ist zu vermuten, dass eine schnellere CPU prozentual stärker profitieren kann, wenn sie nicht so oft auf das Laufwerk warten muss.

Spoiler: Einfach nur mehr Diagramme zur Ramkapazität(für besonders Interessierte Leser)

Welchen Einfluss hat die Ramgeschwindigkeit?​

Das Optimieren des RAMs ist in den letzten Jahren deutlich populärer geworden. Mehr Spieler haben entdeckt oder mitbekommen, dass schnellerer RAM im CPU Limit einen deutlichen Einfluss haben kann.
Und da die aktuellen CPUs nur selten signifikant optimiert werden können, ist schneller Ram eine der letzten Möglichkeiten für mehr FPS und bessere Frametimes.

Fangen wir mit einem FPS-Verlaufsdiagramm bei Zen2 an:

Wieder am Beispiel von Zen2 CPUs sieht man einen nicht ganz linearen Verlauf und stattdesen ein Abflachen hin zu 3400-3733 MT/s.

Dem Wert bei 3733 muss eigentlich kritisch betrachtet werden, da er mit anderen Timings entstanden ist als die Werte bis 3400.
Es mussten einige Timings höher gesetzt werden um den Takt zu erreichen aber andere Timings konnten sogar verbessert werden weil hier nur Micron-E benutzt wurde und die anderen Werte einem gemeinsammen Nenner aus Micron-E/B und Samsung B-Die gerecht werden mussten.

Nimmt man den Wert bei 3733 MT/s raus, sieht der Verlauf schon deutlich linearer aus.

Die roten Datenpunkte entsprechen dem halben L3 Cache des Ryzen 3100 und man kann sehen, dass die FPS sehr ähnlich steigen aber auf einem niedrigeren Level starten.

Sehen wir uns die prozentualen Verbesserungen an, dann zeigt sich eine ordentliche Skalierung von der DDR4 Basis 2133 MT/s zu den schnellen 3400 MT/s mit tollen 42%. ...und sogar 47,5% bei maximalem OC.
Das gilt auch genauso für die Situation mit halbiertem L3 Cache.
Wer Anno 1800 spielt sollte sich also dringen Gedanken um seinen RAM machen.

Der Sprung von 26 auf 38 FPS ist stark spürbar und macht das Spiel flüssiger und reaktionsschneller.

Wie sieht es aus wenn man den Ram nicht manuell optimieren möchte und auf ein XMP Profil zurückgreift?​

Alle XMP Profile sind schonmal deutlich besser als die Basis 2133 MT/s die viele Mainboards automatisch wählen.

Selbst der 4000 CL18 19er Ram, der aufgrund des asynchronen Betriebs zwischen MCLK und FCLK sogar schlechter läuft als die 16 GB Hynix Ram mit 3000 CL16 18, liegt 26% über 2133 MT/s.
Micron Ram ist leider nicht mehr zu vernünftigen Preisen zu kaufen, aber in der Vergangenheit war es eine tolle Empfehlung wie sich hier zeigt.
Wird nur das XMP Profil geladen, schlagen die 3600 Cl16 18 von Micron die sündhaft teuren Samsung B-Die 3200 14 14 und liegen mit den 3600 16 16 gleichauf. Der Samsung speicher hat zwar mehr Potential für niedrige tRFC Latenzen und bessere Haupttimings aber die Wahl der Timings durch das Mainboard bzw. XMP-Profil machen davon keinen Gebrauch.
Das Potential der Micron Chips zeigt sich auch in dem Ergebnis des OC Wertes auf 3733 bei manuell ausgeloteten Timings.
Immerhin 13% mehr FPS konnten durch das manuelle Optimieren aus dem 3000 15 16er Kit herausgeholt werden.

Ob das stundenlange Herumprobieren und Testen von Ramtakt und Timings, sowie eine erhöhte DRAM Voltage, diese 13% rechtfertigt muss jeder für sich entscheiden.

Spoiler: RAM-Empfehlungen

Für Ryzen sollte der asynchrone Betrieb von FCLK/MCLK dringend vermieden werden und auch ein möglichst hoher Takt ist anzustreben.
Optimierte SubTimings sind nochmal ein i-Tüpfelchen das ein paar weitere Prozent herausholen kann.
Wer ein gutes Preis/Leistungsverhältnis anstrebt und sich nicht mit manuellen Einstellungen herumschlagen möchte für den sind 2x16 GB 3200 Cl16 18 18er Kits eine gute Wahl die auch in den meisten Fällen problemlos funktionieren sollten.
Wer ein gutes Angebot findet kann auch auf 3600 MT/s gehen, aber hier kann es passieren dass die Subtimings sehr viel schlechter gewählt werden oder das die Stabilität nicht gegeben ist.

Spoiler: ZenTimings Screenshots zu den verwendeten Ramprofilen

XMP:

Manuelle Timings:

Die manuellen Timings mussten auf diversen Ramriegeln mit 3400 MT/s laufen um eine gute Vergleichbarkeit zu gewährleisten.
Natürlich könnten sie besser sein wenn sie jeweils einzeln optimiert worden wären, aber ich musste mich am kleinsten gemeinsamen Nenner orientieren.
Die Hynix-Chips können diese Timings nur bei 2666 MT/s.

Wie sieht es bei Zen/Zen+ und Zen3 aus?​

Zen und Zen+ reagieren sehr ähnlich wie Zen2 und profitieren von 2133 auf 3400 MT/s mit 34-40% mehr FPS.

Links sieht man, dass die Steigerung der FPS nicht sonderlich gut mit einer lineare Regression dargestellt werden kann. Es gibt eine Art Sättigung bei höherer Ramgeschwindigkeit.

Rechts bei den Prozentbalken profitiert Zen3 (32 MB L3) mit 38% mehr FPS von dem Wechsel auf 3400 und mit 42% durch das OC auf 3733 MT/s.
Jeder Prozentpunkt bei der Ramgeschwindigkeit wird damit zu 64% in mehr FPS verwandelt.
50% mehr RAM-Takt(Bei festen Timings) würde dann also erwartungsgemäßt 50*0,64=32 Prozent mehr FPS erzeugen.

In älteren Tests von mir mit Ivy Bridge(DDR3) lag diese "Rendite" über 12 Spiele bei durchschnittlich 40% und mit dem Ryzen 1800X bei nur 24%...beides also deutlich schwächer und nur Spiele-Ausnahmen waren an 60% ran gekommen.

Die 96MB L3 Cache CPU(Ryzen 5800X3D) profitiert prozentual bei den FPS weniger stark, als die normale Version mit 32 MB L3 Cache.
Allerdings muss man hier beachten, dass die CPU auch 44% höhere FPS erreicht und in Teilen der Messung anfängt GPU limitiert zu sein.
Das ist auch gut daran zu erkennen, dass sich die 0,1% und 1% Low Frametimes sehr ähnlich verbessern (egal ob 32 oder 96 MB L3 Cache) und nur die FPS zu höherem Takt begrenzt wirken.

Die Aussage, dass eine X3D CPU kaum von schnellem RAM profitiert bewahrheitet sich im Falle von Anno 1800 also nicht.
Die wichtigen 1% low Frametimes profitieren sehr ähnlich und man sollte den RAM hier nicht einfach ignorieren.

Spoiler: Weitere Diagramme die ich noch hatte(für besonders Interessierte Leser)

Fazit​

Trotz des großen Aufwandes um ein besonders anspruchsvolles Lategame zu simulieren, sind mehr als 32 GB RAM nicht nötig für Anno 1800.

Mehr RAM senkt die Schreiblast auf dem Systemlaufwerk von ungefär 3 GB auf 1 GB pro 2h aktivem Spielen, was für moderne SSDs irrelevat ist.
Dem Benchmark fehlen zwar noch die letzten drei DLCs aus 2023 so dass sich die Situation nochmal leicht verschieben könnte wenn wirklich alles ausgenutzt wird, da aber schon 24 GB nahezu ausreichend waren sollten 32GB auch bei weiter gestiegenen Anforderungen ausreichen.

Schneller Ram ist zusätzlich sehr wichtig. Überhaupt ein XMP Profil mit mehr als 3000 MT/s geladen zu haben bringt schonmal einen gewalltigen Schub gegenüber den Basis-2133 MT/s.
Manuelles Optimieren des Rams ist dann eine Kür die nochmal etwas drauflegen kann, aber Wunder sollte man nicht erwarten.

Es sei auch nochmal darauf hingewiesen, dass schlecht konfigurierter Ram oder sogar single Channel Ram keinen Einfluss auf die Häufigkeit von Frametimepeaks hat!
Die Ausprägung der Peaks reagiert prozentual sehr ähnlich zu den FPS und schnellerer RAM macht diese weniger störend und spürbar. Er zaubert diese aber nicht einfach weg!
Zu wenig Ram führt hingegen zu deutlich mehr Frametimepeaks und das Aufrüsten kann viele wegzaubern, aber leider nie alle Peaks.

Mit wie viel RAM spielt ihr Anno 1800?​

Und wie ist euer RAM konfiguriert? XMP, selbst optimiert, oder habt ihr das Bios eventuell gar nicht angerührt?​

<- Vorheriger Thread(Cache, Kerne/Threads, CCX usw.) --Übersicht-- nächster Thread(RAM: Ranks, Channel, BankgroupSwap) ->

 

[Lord Maiki]

Erstmal Glückwunsch an deine Frau und dich zum Kind und dem Kind alles Gute.




Ich finde es gut, dass jemand die Leistungsanforderungen zu diesem Spiel gemessen hat. Ich spiele es zwar nicht (keine Zeit dafür) aber ähnliche Spiele. Da Simulation, Strategie und Open World-Spiele meist vom gutenSpeicher samt Cache und Laufwerk profitieren habe ich 32 GB DDR4 3200 Speicher verbaut.

Ich hatte an einigen Stellen mit der Formulierung und Verständnis zu kämpfen. Zumal nicht immer klar was welches Aspekt die Aussagen sich genau beziehen.Dann gibt es noch einige Sätze bei denen etwas fehlt.

2 Beispiele(ich habe nicht alles gelesen):

Zwischen dem unteren Block mit halbem L3 Cache und halben Threads und dem mittleren​

Ist einfach nur die Threadanzahl gemeint? Zumal der Ryzen 3100 kein SMT unterstützt. Auch beim gesamten Satz nicht klar was nun genau gemeint ist. Bezieht sich das nun auf die gleiche prozentuale Steigerung (Diagrammm darüber) oder gleiche Absolutwerte (Diagramm darunter)?

Die 96MB L3 Cache CPU profitiert bei den FPS weniger stark als die normale Version mit 32 MB L3 Cache.​

Hier fehlt die Vergleichsgröße. Da 3 Absätze weiter in diesem Zusammenhang die Speichergeschwindigkeit steht, gehe ich davon aus, dass diese gemeint ist. Das würde auch zu den allgemeinen Aussagen zu dem Prozessor passen. Komischerweise ist die Steigung der gerade beim Zen-3d Prozessor im Diagram weiter oben ähnlich zu dem Zenx Prozessor. Die Regressionsgerade hat sogar eine leicht höhere Steigung (wobei ich bei dem Verlauf der Punkte nicht unbedingt lineare Funktion dafür annhmen würde).

Auch finde ich seltsam, dass die Einheit anstatt der entsprechenden Größe aufgeführt sind. Zumal eine Größe in mehreren Einheiten angegeben werden kann bzw. eine Einheit zu mehreren Größen passt (1/s = Frequenz).

Deine Tochter scheint dich ganz schön auf Trab zu halten.

 

[michi_z1981]

Also wenn ich dich richtig verstehe

Hatte es anders gemeint.
Den Unterschied von der ersten Version zu heute. Also mit fast 5 Jahren Entwicklungszeit.

Da fehlt mir das Gefühl, obwohl sich meine Hardware um mindestens 50% verbessert hat, doch der Fortschritt.

Ich besitze alle Addons. Bis aus Session 4 haben wir im Multiplayer auch alle Welten besiedelt und ausgebaut.

Leider hab ich aus den Anfangstagen mit dem 3930k keine Erinnerung mehr, wieviel sich das System genommen hat.

So 2011, 3930k mit 6c/12t mit 16GB DDR3

Dann kam AM4 mit 3900x, dann 5900x, und wegen Anno erst 32 GB RAM Ballistix, dann 64GB. Alle waren 3200@3600 16-19-19 bei 1,4V am Start. Lief ganz gut und stabil.

Und jetzt AM5 mit 7900x und 32 GB RAM auf 6000 mit Latenz auf EXPO 6000 Niveau.



Aber ganz interessante Werte, was die FPS am Anfang und danach dann angeht. Echt viel. Was da verloren geht.
Aber andererseits stabile 60-80 sind ja bei einer solchen Simulation schon ausreichend.

 

[Baal Netbeck]

Ich hatte an einigen Stellen mit der Formulierung und Verständnis zu kämpfen. Zumal nicht immer klar was welches Aspekt die Aussagen sich genau beziehen.Dann gibt es noch einige Sätze bei denen etwas fehlt.

Ja, da hast du recht. ich habe viele der Texte neben dem Baby aufpassen am Smartphone geschrieben und dann an den PC geschickt...da passieren leicht Fehler und ich habe mich dann heute recht spontan entschieden alles zu veröffentlichen.
Dadurch habe ich nicht mehr richtig Korrektur gelesen und es sind einige Dinge unverständlich.
...Ich arbeite dran.

Ist einfach nur die Threadanzahl gemeint? Zumal der Ryzen 3100 kein SMT unterstützt. Auch beim gesamten Satz nicht klar was nun genau gemeint ist. Bezieht sich das nun auf die gleiche prozentuale Steigerung (Diagrammm darüber) oder gleiche Absolutwerte (Diagramm darunter)?

Ich sehe ein, dass das komisch geschrieben war...in meinem Kopf ergab es Sinn.
Ich habe es jetzt in mehrere Sätze aufgebrochen, damit es hoffentlich klarer wird...bin mir nicht sicher ob es funktioniert hat.

Doch, der 3100 hat 4 Kerne und 8 Threads.

Es bezieht sich auf das Zen2 Diagramm darüber, wo man FPS, 1% und 0,1% low Frametimes sehen kann.

Und der mittlere und der untere Block haben beide ihre Einschränkung gegenüber dem obersten Block.
-Der mittlere hat 2666 statt 3400 MT/s beim RAM.
-Und der untere hat zwar 3400 MT/s, aber nur 4 Kerne 8 Threads statt 8 und 16....und er hat nur 2x8 statt 2x16 MB L3 Cache.

Beide haben mit ausreichend RAM..... um die 31 FPS ...1% lows um die 12 1/s und 0,1% lows um die 4,7 1/s.
Die 2x4 GB haben keinen Vergleichswert.

Es hatte mich beim Anblick der Daten verwundert, dass der Leistungsverlust so ähnlich ist, obwohl die Gründe für den Leistungsverlust so unterschiedlich sind.

Ich hatte erwartet, dass man z.B. mit weniger Cache und weniger Kernen eher die Frametimes leiden und die FPS höher bleiben....oder umgekehrt...oder dass zumindst beide Blöcke unterschiedlich viel prozentual verlieren.

Aber scheinbar heben sich die Effekte zufälligerweise auf.

Hier fehlt die Vergleichsgröße. Da 3 Absätze weiter in diesem Zusammenhang die Speichergeschwindigkeit steht, gehe ich davon aus, dass diese gemeint ist. Das würde auch zu den allgemeinen Aussagen zu dem Prozessor passen. Komischerweise ist die Steigung der gerade beim Zen-3d Prozessor im Diagram weiter oben ähnlich zu dem Zenx Prozessor. Die Regressionsgerade hat sogar eine leicht höhere Steigung (wobei ich bei dem Verlauf der Punkte nicht unbedingt lineare Funktion dafür annhmen würde).

Ja, es geht um die Speichergeschwindigkeit.

Ja, die Steigung ist auf die FPS bezogen....nicht auf eine prozentuale Verbesserung.... Das war mir auch selbst aufgefallen und ich hätte vermutlich besser die prozentuale Steigerung auf der Y-Achse aufgetragen, dann könnte man die Steigungen vergleichen.

So sagt sie aus, wie stark die FPS mit dem Ramtakt steigen(also als linearer Fit approximiert) aber das ist natürlich nicht zu vergleichen mit den anderen Steigungen, wo die CPU eine andere Rohleistung hat.

Ein linearer Fit ist dafür sicherlich nicht passend, aber gerade das soll ja auch ins Auge springen....also dass man in eine Art Sättigung läuft und es zu hohen Ramgeschwindigkeiten nicht mehr so linear läuft wie manch einer es vermuten könnte.

Wobei das bei dem X3D besonders für die FPS gilt, die durch ein gelegentliches GPU-Limit ausgebremst werden.
Die 0,1 und 1% low Frametimes steigen zwar auch nicht perfekt linear aber "linearer" als die FPS.

Auch finde ich seltsam, dass die Einheit anstatt der entsprechenden Größe aufgeführt sind. Zumal eine Größe in mehreren Einheiten angegeben werden kann bzw. eine Einheit zu mehreren Größen passt (1/s = Frequenz).

Stimmt schon....Es steht im Titel "FPS Entwicklung mit Ramgeschwindigkeit"...daher würde ich schon sagen, dass es klar sein sollte dass MT/s die Ramgeschwindigkeit ist und 1/s die FPS.
Aber ja, das ist nicht gut beschriftet.

Dass da immer Einheit: 1/s steht ist Faulheit von mir....ich habe Templates für die verschiedenen Diagrammtypen und dann muss ich an den Achsen nix ändern, weil 1/s für FPS, und 1% low Frametimes passt.

Ich habe die Punkte die du genannt hast auf meine To do Liste geschrieben und wenn ich Zeit/Lust dazu habe, verbessere ich die Punkte.

Vielen Dank für dein Feedback... sehr hilfreich.

Ergänzung (13. März 2023)

Den Unterschied von der ersten Version zu heute. Also mit fast 5 Jahren Entwicklungszeit.

Ich habe den Eindruck, dass da keine Optimierungen bezüglich der Leistung durchgeführt wurden.

Ich hatte hier einen Test von der damaligen Beta gemacht:
https://www.computerbase.de/forum/t...-technickcheck-und-erfahrungsbericht.1854582/

Damals habe ich eine CPU Auslastung im CPU-Limit von 26-28% beobachtet....mit einem Ryzen 1800X also 16 Threads.
Und CapFrameX nennt für den Durchschnitt mit dem 5800X3D 28,2%.

Da hat sich null getan und das Spiel läuft weiterhin in ein single-Thread-Drawcall-Limit, was eine bessere Ausnutzung von mehr als 4 Kernen verhindert.

Die FPS sind schwer zu vergleichen....damals noch eine Vega64 und 1440p...

Aber um die 40 FPS mit einem Spielstand der von den Drawcalls ungefär mit dem 65K Benchmark von CB passen sollte....und da machte der Ryzen 1400@3,9GHz ca 36 FPS...im Skript ist der 1800X 27% besser....aber die jetzigen Tests sind mit besserem Ram als damals....dafür der 1400 mit weniger Cache und nur 4 Kernen....
Summa Summarum kann ich sagen, dass ich keine Aussage treffen kann.

Es ist aber nicht unrealistisch, dass sich die grundsätzliche Drawcall-Programmierung nicht verbessert hat.

Ubisoft hat ein paar Leistungskiller gefixed...da gab es einen Bug, der an Häfen immer mehr neutrale Schiffe erschaffen hat und diese die Leistung runtergezogen haben.
Das gleiche mit Schiffen die sich auf Handelsrouten am Kartenrand festgebugt haben.

Und es gab lange Zeit im Spiel einen Bug, der die FPS sogar beim nichtstun mit der Zeit hat sinken lassen.
Diese Dinge sind gefixed worden....
Auch muss ich sagen, dass ich überrascht bin wie gut das Spiel die 5 statt 2 Inselwelten verkraftet.

Das ist schon nicht schlecht gemacht....nur das multithreading der Drawcalls läuft schlecht und der VRAM sollte entlich mal ausgenutzt werden....wofür habe ich denn 16 GB?

Da fehlt mir das Gefühl, obwohl sich meine Hardware um mindestens 50% verbessert hat, doch der Fortschritt.

Kann ich verstehen.
Aber Anno kann, zumindest nach meinen Tests, nichtmal 6 Kerne auslasten.
Dein alter Intel hatte also genug Kerne und bestimmt eine bessere Ramlatenz als alle Systeme danach.
DDR3 war reaktionsschneller als DDR4 und DDR4 ist schneller als DDR5.
Und die RAM Latenz ist bei Intel besser, als beim multichiplet Design von AMD.

Und meine Tests zeigen auch, dass die Rambandbreite(der große Vorteil von DDR4 und DDR5) für Anno fast egal ist.

Also ja...deine Hardware ist grundsätzlich schon viel schneller geworden, aber Anno profitiert nur wenig von den Dingen die sich verbessert haben und die Ramlatenz ist vermutlich sogar schlechter geworden.

Aber andererseits stabile 60-80 sind ja bei einer solchen Simulation schon ausreichend.

Ja, das sehe ich auch so. Für Anno reichen mir eigentlich auch 40 FPS ganz gut.

Aber dann kann es gar nicht schnell genug sein, wenn ich auf Schiffe oder Itementwicklungen warte und selbst der X3D die maximale Spielgeschwindigkeit nicht ganz ausgereizt bekommt.

Es ist schon deutlich, wie groß der Unterschied vom 3950X zum 5800X3D ist, selbst wenn beide optimal mit RAM versorgt sind.
Es ist nicht so, als wäre der 3950X schlecht in Anno, aber wenn man den X3D zum Vergleich hat, will man nicht wieder zurück.

 

[Lord Maiki]

Das Gehirn spielt einem gerne Streiche und fügt Details dazu. Diese Form der Veröffentlichung bringt mir auch mehr als später ein besser formulierter Text. Deswegen bin auch froh, dass du es gemacht hast.



In deinem Test scheint mir die ausreichende Größe und Geschwindigkeit des Speichers eine Wichtige vielleicht sagar die wichtigste Größe für ein flüssiges Spielgefühl bei Anno 1800 zu sein. Wirklich überrachen tut das Ergebnis mich nicht. Im Gegenteil, es ist so wie ich es erwarten würde. Der Cache reduziert die Anforderung an den Speicher sehr gut. Als Fazit sollte deswegen auch die Wichtigkeit des Speichers hervorheben.

AMD hat vor einiger Zeit mal ein Bild herausgebracht, bei dem vier Haupteinflussgrößen des Hauptprozessors bei Spielen aufgeführt sind. Taktfrequenz, Anzahl Kerne, (Speicher) Latenz und Intercorekommunikation. Da bei der CPU im Normalfall die Latenz wichtiger als der Speicherdurchsatz (bei GPU umgekehrt) kann man das ganze auch Leitungsfähigkeit eines Kernes, Anzahl Kerne, Latenzen des Speichersystem und Intercorekommunikation auffassen.

Beim Fazit würde ich auch den Halbsatz mit … simulieren weglassen. Erstens hast du nicht simuliert sondern deinen Spielstand vermessen. Zweitens gehört der Hinweis zu der Schwierigkeit der Messungen in einen der ersten Sätze bei denen es um die Motivation geht. Im Grunde liest sich der Satz für nich wie: Selbst bei einer vollgebauten Karte (Welt) hat sich 32 GB Ram als empfehlenswerte Größe herausgestelltt. Mehr Ram bringt einen nur sehr geringen Zusatznutzen und weniger Ram erhöht die Auslagerung auf den Datenträger und letztlich die Zähigkeit des Spielflusses. Die genauen Werte stehen ja weiter oben.

Auch das Wort Rendite scheint mir in diesem Zusammenhang fehl am Platz zu sein. Es geht ja um Nutzen-/Leistungssteigerung und nicht um Zinszahlungen.

Ergänzung (14. März 2023)

Die Frametimes steigen zwar auch nicht perfekt linear aber "linearer" als die FPS.

Den Satz verstehe ich nicht. Die Frametimes sind doch nur der Reziprokwert der "FPS". Wie kann dan die Steigung der Funktion eine anderen Form haben.

 

[Baal Netbeck]

In deinem Test scheint mir die ausreichende Größe und Geschwindigkeit des Speichers eine Wichtige vielleicht sagar die wichtigste Größe für ein flüssiges Spielgefühl bei Anno 1800 zu sein. Wirklich überrachen tut das Ergebnis mich nicht. Im Gegenteil, es ist so wie ich es erwarten würde. Der Cache reduziert die Anforderung an den Speicher sehr gut.

Ja, ausreichen RAM ist der wichtigste Faktor....das verbessert das Spielgefühl/ sorgt für weniger Ruckler.

RAM Geschwindigkeit ist einerseits wichtig....wobei ich mich halt auf Basis 2133 MT/s beziehe und man mit einem XMP Profil schon viel rausholt.
Die meisten werden hoffentlich ein halbwegs ordentliches XMP Profil geladen haben und dann sind ca 10% die man mit stundenlangem RAM-Optimieren noch rausholen kann nicht mehr so ausschlaggebend.

Der Cache verringert vor allem die mittlere Zugriffszeit....das ist aus meiner Sicht der große limitierende Faktor in Anno 1800.
Zu wenig RAM kontert er nicht und auch nicht wirkcklich langsamen RAM.

Als Fazit sollte deswegen auch die Wichtigkeit des Speichers hervorheben.

Ja, das Fazit ist noch nicht so ausgearbeitet....das habe ich wohl zu früh veröffentlicht.....ich gehe nach und nach die Threads durch und poliere etwas.

uch das Wort Rendite scheint mir in diesem Zusammenhang fehl am Platz zu sein. Es geht ja um Nutzen-/Leistungssteigerung und nicht um Zinszahlungen.

Ja... In meinem Kopf ist Rendite halt der Anteil den ich rausbekomme wenn ich etwas investiere.
Investiere ich in X-Prozent-schnelleren RAM, welche Steigerung bekomme ich dann bei den FPS.

Ich suche mal nach einem anderen Wort...."Effizienz" hatte ich erst überlegt, aber da denke ich dann an eine Energieeffizienz.

Ergänzung (14. März 2023)

Den Satz verstehe ich nicht. Die Frametimes sind doch nur der Reziprokwert der "FPS". Wie kann dan die Steigung der Funktion eine anderen Form haben.

...ich meinte die 1% und 0,1% low Frametimes....die ich ja nicht in ms sondern in 1/s angebe.
Einfach 1000/X mit X in ms.
Ist also die gleiche Einheit.

Man kann sich um die Benennung streiten, da es ja eher "inverse Frametimes" oder so heißen müsste, aber so hat es sich halt eingebürgert.
Computerbase schrieb ja glaube ich früher 99.8th Percentile in FPS .....was dann nach den invertieren eher 0,2 sein müsste .....und jetzt habe ich FPS, 1% Perzentil gelesen.
Computerbase nimmt halt lieber die Perzentil, da man damit keine Ruckler erfasst und das macht die Messung reproduzierbarer.....aber es ist auch nicht aussagekräftig wenn man wissen möchte was mehr oder weniger ruckelt.

Gamers Nexus und HWunboxed schreiben 1% LOW und ich berechne meine 1% low Frametimes genauso.

CapFrameX hat das irgendwann umgestellt und nimmt nicht den Mittelwert von den langsamsten 1% der Frametimes.....sondern da wurden die 1% low Frametimes irgendwie aufintegriert bis sie 1% der Gesamtzeit erreicht haben. Das ergibt deutlich niedrigere Werte, da die allerschlechtesten Frametimes natürlich dann überproportional in dem 1% der Messdauer vertreten sind.

CapFrameX hatte nun auch(wieder) das was Gamers Nexus und ich machen, es aber jetzt 1% low average genannt....und ihre alternative Version heißt jetzt 1% low integral.

Und der Afterburner kann Framerate 1% Low messen, was aber aus meiner Sicht großer Blödsinn ist, da nicht die gesamte Messung berücksichtigt wird. Stattdessen wird eine Art "moving window" benutzt.
Die Angabe bezieht sich also immer auf einen gleich großen Satz Frametimes bei dem während der Messung pausenlos neue Frametimes dazu kommen.....aber es fliegen nicht einfach die ältesten Frametimes raus.
Das wäre dann zwar nur eine Messung über die letzten X Sekunden, aber immerhin dafür passend.
Was meinen Beobachtungen zufolge passiert ist, dass aus dem Datensatz zufällige Frametimes rausfliegen und das das Ergebnis eventuell nichtmal ein Durchschnitt der schlechtesten Frametimes ist, sondern das eventuell sogar Percentile sind??
Auf jeden Fall kann man sehen, wie einzelne Ruckler eine Messung schlagartig runterhauen(sofern so gut)...aber normalerweise müsste der Wert sich kontinuierlich verbessern wenn mehr Frametimes zur Messung dazu kommen weil der Anteil des einzelnen Frametimes abnimmt.
Aber was passiert, ist dass es einfach schlecht bleibt, bis es irgendwann sprungartig wieder besser wird...und manchmal springt es hoch oder runter ohne das ich das nachvollziehen kann.

Für eine reproduzierbare Messung ist das völlig ungeeignet, aber leider benutzen sehr viele Benchmarks auf Youtube diese Option.
Ich habe da auch mal eine Anfrage gestellt und die Antwort war "It works as intended."

Daher mache ich die Auswertung selbst....da weiß ich genau, was berechnet wurde und wer wissen möchte wie, für den habe ich das in dem Thread zur Auswertung aufgeschrieben.

 

[Lord Maiki]

Ich meinte diese Aussage erstmal mathematisch. Der Kehrwert einer linearen funktion ist auch eine lineare Funktion.

Bei der Frametime und 1% Diskussion halte ich mich raus. (Ich glaube auch nicht, dass ich mein Gehirm so verwinden kann, um hinter der ganzen Logik zu steigen) Ich möchte nur 2 (3) Anmerkungen machen. Ich halte diese Forderung von hoher Reproduzierbarkeit bei den Benchmarks für falsch. Es gab mal ein Gespräch von 2 sowjetischen Wissenschaftler (einer hat den Chemie- der andere den Physiknobelpreis gewonnen) über die Messungen von dynamischen Systemen. Die sind zum Ergebnis gekommen, dass es gute und reproduzierbare Ergebnisse nur bei statischen Systemen geben kann. Dynamische Systeme tragen eine Ungenauigkeit in sich. Und ein Spiel, das etwas auf sich hält, ist ein dynamisches System. Es gibt zwar Tricks die Auswirkungen zu begrenzen, aber dadurch wird die Aussagekraft auch geringer.

Die Verwendung der geringsten 1% gegenüber der davor gebräuchlichen Low-Angabe mag besser sein. Im Grunde ist das nur ein wenig an den Symtomen herumdoktoren. Es fallen nur ein paar Ausreißer heraus und der Zahlenwert wird leicht angehoben. Eine Ursache-Wirkungs-Beziehung gibt es auch weiterhin nicht.

Im Grunde kann nur der Spielhersteller ein Benchmark zusammenstellen, der die dynamischen Elemente und eine gewisse Reproduzierbarkeit ohne riesigen Aufwand abdeckt. Aber ein solcher Benchmark würde (wird) niemals von den Techseiten akzeptiert. Denn dieser würde deren Geschäftsgrundlage zerstören. Zum Sammel der Benchmarkergebnisse reicht eine einfache Internetseite bzw. ein Forum aus. Zum Anderen fallen die Techseiten als Marketingagenturen für die Hardware-Hersteller aus. Diese würden sich direkt an die Spielehersteller wenden (das tuen sie jetzt schon). Auch wäre die nötige Tranperenz eines solchen Benchmarks eine Einladung zum Schummeln (es gibt genug Beispiele dafür).

Ich finde, dass das Fazit von der Übersichtsseite soweit passend.

Ja... In meinem Kopf ist Rendite halt der Anteil den ich rausbekomme wenn ich etwas investiere.
Investiere ich in X-Prozent-schnelleren RAM, welche Steigerung bekomme ich dann bei den FPS.
Ich suche mal nach einem anderen Wort...."Effizienz" hatte ich erst überlegt, aber da denke ich dann an eine Energieeffizienz.

Effizienz ist schon besser. Es drückt ja eine hohe Ausnutzung an. Vielleicht noch Effektivität. Wobei dieses mehr auf die Qualität abzielt.

 

[Baal Netbeck]

Ich halte diese Forderung von hoher Reproduzierbarkeit bei den Benchmarks für falsch.

Uh...steile These!

Den Gedankengang verstehe ich auch nicht.
Was sagt denn ein Benchmark aus, der eine schlechte Reproduzierbarkeit hat?
Nicht sonderlich viel, da die Ergebnisse dann auch ein reines Zufallsprodukt sein können und dann kann man sich die Vergleiche auch gleich sparen.

Die sind zum Ergebnis gekommen, dass es gute und reproduzierbare Ergebnisse nur bei statischen Systemen geben kann. Dynamische Systeme tragen eine Ungenauigkeit in sich.

Ich denke nicht, dass die das so gemeint haben....kenne das Gespräch nicht, aber es ist wissenschaftlicher Konsens, dass jede Messung eine Unsicherheit in sich trägt....selbst wenn sich nichts verändert und du einfach mehrfach misst.
Ein statisches System, das keinerlei Unsicherheit hat, kann nur eine simple theoretische Berechnung sein....die Realität ist immer vom Zufall geprägt und man muss nur genau genug hingucken.

Die Zielsetzung bei Experimenten(im Grunde ist ein Spielebenchmark auch ein Experiment) ist es ein Ergebnis zu erhalten und wenn man es ordentlich macht, schätzt man dafür möglichst gut die Messunsicherheit ab.

Das mache ich hier auch, indem ich über die Standardabweichung der Einzelwerte ein Maß für die Schwankung angebe. Und in dem entsprechenden Thread diskutiere wie ich überprüft habe, ob diese Abschätzung ausreichend ist.

So kannst du z.B. die Diagramme angucken und die Fehlerbalken beachten. Wenn sich die Fehlerbalken von zwei Messungen nicht überschneiden, kann man mit hoher Gewissheit sagen, dass ein echter Unterschied besteht.....zu genau sollte man diese Regel nicht nehmen...aber die Fehlerbalken sind ist ein Hinweis auf die Güte der Messung und wenn man es dann noch mit etwas gesundem Menschenverstand bewertet, sieht man ob es eine brauchbare Messserie war.

Die Standardabweichung schätzt natürlich nur die statistische Schwankung der Messungen ab und kann keine Aussage über systematische Fehler machen....Windows Hintergrundprozesse...betrunkene Elektronen...Vollmond..
Dies esystematischen Fehler kann man aber fast nie abschätzen und wenn einem offenkundige systematische Fehler auffallen, dann sollte man sie wenn möglich ausgleichen.

Es gibt auch einen guten Vortrag zur Codeoptimierung...müsste ich suchen....da wird z.B. diskutiert wie der Zufall die Benchmarks von Programmcode beeinflusst.
Man sollte meinen, dass ein deterministischer Code immer gleichschnell abläuft, aber dem ist nicht so.
Es landen schon beim starten des PCs die Daten an anderen Stellen im RAM und wenn der Code läuft, auf anderen CPU Threads und auch anders im Cache.
So kann es nach einer tollen Reproduzierbarkeit aussehen wenn man mehrfach hintereinander Messungen macht, aber nach einem Neustart kann das Ergebnis anders aussehen.

In dem Sinne ist es gar nicht so schlecht, dass Anno ein paar Zufalls-Komponenten hat.
Sofern man also lange und oft misst kann man den ursprünglichen Bias eher brechen....ich mache ja auch zwischen den Messungen noch die Zwischensequenzen wo ich andere Daten in den RAM/VRAM mische.

Es gibt zwar Tricks die Auswirkungen zu begrenzen, aber dadurch wird die Aussagekraft auch geringer.

Wieder bin ich verloren....bei bestimmten Tricks ist das sicherlich der Fall, aber grundsätzlich ist es doch gut wenn die Reproduzierbarkeit besser wird, weil ich damit erst einen Vergleich anstellen kann der mit sehr hoher Wahrscheinlichkeit einen echten Unterschied darstellt.

Welche Tricks habe ich denn angewandt, die deiner Meinung nach problematisch sind?

Im Grunde ist das nur ein wenig an den Symtomen herumdoktoren. Es fallen nur ein paar Ausreißer heraus und der Zahlenwert wird leicht angehoben. Eine Ursache-Wirkungs-Beziehung gibt es auch weiterhin nicht.

Die Ursache-Wirkungs-Beziehung kannst du in den meisten wissenschaftlichen Experimenten nicht wirklich benennen...du kannst eine Theorie vorstellen, und eine mathematische Beschreibung der Zusammenhänge suchen, aber das funktioniert fast nur für idealisierte Systeme.

In der Praxisanwendung wird es dann beliebig kompliziert und ein Spiele-Benchmark hat tausende Systeme in Wechselwirkung.

Und irgendwie muss man Vergleichsgrößen definieren.
Ich kann auch 230 Frametimeverläufe zeigen, die dann keiner überblicken und auch nicht mit dem bloßen Auge vergleichen kann.

Man muss den komplexen Ablauf der Frametimes irgendwie quantitativ vergleichen können und da bieten sich diverse Methoden an, die alle ihre Vor- und Nachteile haben.

Ich habe mich für FPS, 1% und 0,1 Low Frametimes entschieden.
Die FPS geben ein gutes maß für den Input Lag und die maximal mögliche Spielgeschwindigkeit.
Und die Low Frametimes vergleichen wie stark die Ruckler reinhauen.

Ich bin für die Zukunft auch für bessere Methoden zu haben und ich habe auch etwas eigenes entwickelt, das die FPS ersetzen könnte, aber das wäre zu kontrovers.

Im Grunde kann nur der Spielhersteller ein Benchmark zusammenstellen, der die dynamischen Elemente und eine gewisse Reproduzierbarkeit ohne riesigen Aufwand abdeckt.

Die Entwickler hätten es sicherlich einfacher als ich mit Autohotkey....ich muss Elemente anklicken lassen und Wartezeiten definieren, die auch für die langsameren CPUs das aktualisieren der Texturen wahrscheinlich macht....usw.
Die Entwickler könnten direkt die entsprechenden Funktionen aufrufen und warten bis diese durchgelaufen sind....Aber da hört es schon auf.

Was sind denn für dich dynamische Elemente?
Wenn man allen Zufall aus dem System nimmt(angenommen das wäre dann noch das gleiche Spielerlebnis undüberhaupt möglich) hat man auch wieder nur einen Spezialfall simuliert, der nicht mit deiner Realität vor dem Heim-PC übereinstimmt.

Mein Ziel war es einen anspruchsvollen Test zu kreieren der hoffentlich für viele Annoholiker eine Relevanz hat.
Kein Test der Welt kann alles abdecken und berücksichtigen...auch nicht der Spielehersteller selbst....man kann sich aber bemühen.

Aber ein solcher Benchmark würde (wird) niemals von den Techseiten akzeptiert. Denn dieser würde deren Geschäftsgrundlage zerstören. Zum Sammel der Benchmarkergebnisse reicht eine einfache Internetseite bzw. ein Forum aus.

Jetzt wird es verschwörungsideologisch!
Es gibt doch viele Techseiten, die auch Ergebnisse mit integrierten Benchmarks präsentieren.

Es gibt leider nahezu keinen integrierten Benchmark, der auch gut repräsentiert was der Spieler in Spiel sieht und fühlt....zumindest kenne ich keinen einzigen.
Ein paar sind ganz gut zu gebrauchen, aber den perfekten Benchmark kann es gar nicht geben und es ist besser wenn mehrere Techseiten sich daran versuchen einen guten zu finden....warum sollte sich sonst jemand anstrengen?

Auch wäre die nötige Tranperenz eines solchen Benchmarks eine Einladung zum Schummeln

Ja....ist in der Vergangenheit auch passiert und daher guckt man besser nach Quellen die sich einen guten Ruf aufgebaut haben.

Vielleicht noch Effektivität. Wobei dieses mehr auf die Qualität abzielt.

Das Wort passt sicherlich besser...ich werde es ersetzen.

 

[Lord Maiki]

Die Zielsetzung bei Experimenten(im Grunde ist ein Spielebenchmark auch ein Experiment) ist es ein Ergebnis zu erhalten und wenn man es ordentlich macht, schätzt man dafür möglichst gut die Messunsicherheit ab.

Nein, die Zielsetzung ist unterschiedlich.

Wikipedia:

Benchmarkings sind genormte Mess- und Bewertungsverfahren, mit deren Hilfe man die Leistung von EDV-Systemen oder Systemklassen ermitteln und diese nach bestimmten Kriterien miteinander vergleichen kann.

Ein Experiment im Sinne der Wissenschaft ist eine methodisch angelegte Untersuchung zur empirischen Gewinnung von Information. Im Unterschied zur bloßen Beobachtung oder der Demonstration eines Effekts werden im Experiment Einflussgrößen verändert.

Das Experiment liefert immer ein Ergebnis (selbst ein Fehlschlag ist ein Ergenis). Nur für den Messsklaven endet mit dem Ergebnis die Arbeit. Für einen Wissenschaftler "beginnt" sie erst. Dieses Ergebnis muss überprüft, interpretiert und in das bestehene System eingeordnet werden. Und dazu gehört eine Fehlerbetrachtung. Eine Fehlerbetrachtung ist weit mehr als nur eine Bestimmung der Messungenauigkeit, in der man den Mittelwert aus 3 Messungen bildet. Es ist eine systematische und kritische Auseinandersetzungen mit allen Aspekten des Experimentes. Dazu genhört auch die Messmethode, Messgerät, Durchführung als auch Formel und deren Annahmen.

Der Umfang einer Fehlerbetrachtung ist sehr unterschiedlich. Bei guter bis absoluter Reproduzierbarkeit (bzw. das erwartete Ergebnis wird gemessen) ist diese sehr kurz und einfach. Bei schlechter Reproduzierbarkeit ist diese sehr lang und schwierig zu erstellen (weil man hier viele Überlegungen anstellen und diese überprüfen muss). Diese Arbeit versucht man zu vermeiden, aber das ist nicht immer möglich.

Übrigens die ganze Diskussion startet mit dieser Aussage von dir.

Die Frametimes steigen zwar auch nicht perfekt linear aber "linearer" als die FPS.

Da sieht man auch den Unterschied zwischen Messungenauigkeit und Fehlerbetrachung. Bei einer Messungenauigkeit mag das i.O. sein. Im Rahmmen einer Fehlerbetrachtung ist diese Aussage diskussionswürdig.



Zu den anderen Aspekten könnte ich auch ein Text zu schreiben, aber ich lass es lieber. Ich verstehe es einfach nicht, wieso in solche Diskussion die Aussagen in S//W Denken gepresst werden.



PS.: Auf der Übersichtsseite ist Nische mit e geschrieben

 

[Baal Netbeck]

Nein, die Zielsetzung ist unterschiedlich

Was ist denn die Zielsetzung?
Dann nenn es "Informationsgewinn" statt Ergebnis, aber ich mache ja kein Experiment und gucke nicht was rauskommt.

Und nur weil Wikipedia da eine andere Definition vorschlägt, ist das ja noch lange keine verpflichtende Vorgabe für den Sprachgebrauch des Wortes Benchmarking.

Dein Zitat:

Ein Experiment im Sinne der Wissenschaft ist eine methodisch angelegte Untersuchung zur empirischen Gewinnung von Information. Im Unterschied zur bloßen Beobachtung oder der Demonstration eines Effekts werden im Experiment Einflussgrößen verändert.

Das passt doch auf das was ich mache.
Ich ändere zum Beispiel die Einflussgröße "Ramgeschwindigkeit" und Beobachte welchen Effekt das auf die Ergebnisse meiner Benchmarkmessung hat.

Ich gewinne also die Information wie stark Anno 1800 in meinem Beispiel mit der Ramgeschwindigkeit skaliert.

Das Experiment liefert immer ein Ergebnis (selbst ein Fehlschlag ist ein Ergenis).

Dem stimme ich zu.... Aber was hat das mit meinem Benchmark zu tun?

Nur für den Messsklaven endet mit dem Ergebnis die Arbeit. Für einen Wissenschaftler "beginnt" sie erst.

Gut, dass ich nicht nur die Ergebnisse in ein Diagramm gepackt habe, sondern diese auch ausgewertet und interpretiert habe.

Dieses Ergebnis muss überprüft, interpretiert und in das bestehene System eingeordnet werden.

Gut das ich alle drei Sachen gemacht habe.

Und dazu gehört eine Fehlerbetrachtung. Eine Fehlerbetrachtung ist weit mehr als nur eine Bestimmung der Messungenauigkeit, in der man den Mittelwert aus 3 Messungen bildet. Es ist eine systematische und kritische Auseinandersetzungen mit allen Aspekten des Experimentes. Dazu genhört auch die Messmethode, Messgerät, Durchführung als auch Formel und deren Annahmen.

Das klingt so, als würdest du unterstellen, ich hätte diese Dinge nicht gemacht.

Ich kann dir versichern, dass ich mich meine Messmethode eingehend untersucht habe...ich habe schon vorher verschiedene Programme(Messgeräte) ausprobiert und verglichen....und nicht jedes Experiment hat gleich Formeln und Annahmen....oft guckt man auch einfach was passiert und findet dann eine mathematische Beschreibung oder Erklärung.

Und Annahmen wie ich die Ergebnisse erwarte habe ich schon...teilweise auch in den Text geschrieben...keine Ahnung was du da sehen möchtest?

Der Umfang einer Fehlerbetrachtung ist sehr unterschiedlich. Bei guter bis absoluter Reproduzierbarkeit (bzw. das erwartete Ergebnis wird gemessen) ist diese sehr kurz und einfach. Bei schlechter Reproduzierbarkeit ist diese sehr lang und schwierig zu erstellen (weil man hier viele Überlegungen anstellen und diese überprüfen muss). Diese Arbeit versucht man zu vermeiden, aber das ist nicht immer möglich.

Wieder klingt es so, als würdest du mir unterstellen ich häte mir keine Gedanken um die Reproduzierbarkeit gemacht.....Du warst es doch, der weiter oben geschrieben hat:

Ich halte diese Forderung von hoher Reproduzierbarkeit bei den Benchmarks für falsch.

Im Thread zu dem Skripbenchmark liste ich eine Reihe Probleme die die Reproduzierbarkeit erschweren auf und erkläre auch zu einigen wie ich die Auswirkungen minimiert habe.

Da stecken noch deutlich mehr Test, Überlegungen und Feinheiten drin, die ich hier auf einige wesentliche Punkte heruntegebrochen habe....kann ich gerne irgendwann ergänzen.

Wenn dich etwas Konkretes stört oder wundert, kannst du gerne nachfragen.
Und wenn du sinnvolle Verbesserungsvorschläge hast, nehme ich die auch gerne an und kann sie in Zukunft umsetzen.

Aber einfach unterschwellig sugerieren, ich hätte schlampig gearbeitet finde ich etwas unverschämt.

Da sieht man auch den Unterschied zwischen Messungenauigkeit und Fehlerbetrachung. Bei einer Messungenauigkeit mag das i.O. sein. Im Rahmmen einer Fehlerbetrachtung ist diese Aussage diskussionswürdig.

Ja, ich habe einen linearen Regression benutzt um zu verdeutlichen, dass es nicht linear läuft....und ich habe es nicht optimal ausformuliert.....von mir aus.

Man kann da sicherlich versuchen eine Theorie zu entwickeln....die wird aber an der Realität scheitern, da ich dutzende Parameter einbringen müsste....und ein Fit mit so vielen Parametern kann alles anfitten....es hat dann nur keine Aussagekraft mehr.

wieso in solche Diskussion die Aussagen in S//W Denken gepresst werden.

Ich sehe das S/W Denken nirgendwo....woraufbeziehst du dich?

Auf der Übersichtsseite ist Nische mit e geschrieben

Finde ich nicht? ....Es sind aber bestimmt noch duzende Fehlerchen drin.... Vieles habe ich am Handy geschrieben.

 

[Timesless]

Vorher: i7 5930k mit 16 GB DDR4-2133 im Quad Channel mit XMP

Jetzt: R9 5900x mit 64 GB DDR-4-3200 im Dual Channel mit DOCP? (XMP)

Ist schon ab 10k Einwohnern ein deutlicher Unterschied, vorher war es Spielbar, nun macht es Spass

 

[SebiLegend]

Saugut, was Du hier aufgezogen hast @Baal Netbeck!
Bei mir ist seit 40000 Einwohnern und dem ersten DLC gerade das Problem, dass ein wenig Reinzoomen und das Wechseln der Inseln schon genau die Probleme bedeuten, die schon oft zitiert wurden: ruckeln, zuckeln usw. Klar, an sich ist es verkraftbar, aber n bißchen tut es schon weh, weil ich n Schönbauer bin und es für mich auch entspannt sehen möchte. Da wäre schon weniger Ruckeln nice...
Mein System: Ryzen 5 3600 mit 50mV UV auf Gigabyte B450 I Aorus Pro WIFI, 2x8 GB RAM Corsair LPX 3200-C16, RTX 2070, Kingston A2000 1TB und Win10
Für den 5800X3D ist leider zurzeit kein Budget da, deswegen wollte ich jetzt mal testen, was mir 32GB RAM bringen. Da ich im Dan Case A4-SFX unterwegs bin und einen Alpenföhn Black Ridge CPU-Kühler nutze, habe ich nur die Wahl zwischen diesen drei Corsair LPX-Modelle mit 3600-C18 oder 3600-C16: Geizhals Corsair LPX-RAM.
So wie ich es verstanden habe und weil ich kein manuelles RAM-OC nutzen möchte, würden die 3600-C16 schon Sinn machen, oder?

 

[Baal Netbeck]

So wie ich es verstanden habe und weil ich kein manuelles RAM-OC nutzen möchte, würden die 3600-C16 schon Sinn machen, oder?

3600 16 19 19 wäre bei xmp auch meine Wahl.

16 16 16 ist sehr teuer und 18 22 22 nicht so viel günstiger.

Ergänzung (3. Juli 2023)

Du kannst als weitere Optimierung dem Spiel nur jeden zweiter Thread zuweisen und du kannst die optimierten Grafikeinstellungen probieren.
Anti aliasing auf 2x oder 4x...wenn du die 32GB hast, kann man auch die Texturen auf hoch stellen...das sollte das Spiel wieder besser "fluppen" lassen.

 

[SebiLegend]

Vielen Dank für Deine schnelle Antwort! Die optimierten Einstellungen werde ich auf jeden Fall vorher versuchen und dann entscheiden, ob ich Geld in die Hand nehme. War sehr spannend, Deine Erläuterungen und Tests zu lesen

 

[SebiLegend]

So, hier mal die Einstellungen, auf die ich mich jetzt mit mir geeignigt habe Auf meiner Hauptinsel in der Alten Welt läuft es viel besser, vor allem schneller hin dazu, dass alle Texturen geladen sind. Auf einer anderen Insel bringt es irgendwie wenig. Bei der Hauptinsel läuft der RAM voll, bei einer anderen nicht. Es ist wild, aber fühlt sich besser an und hat so 5-15% bessere Frames und n geschmeidigeres Gefühl.
So werde ich erstmal damit leben können, denke ich, und weiter zocken. Mal gucken, wie es sich dann wirklich im Spielgefühl nach eins, zwei Stunden anfühlt...

 

[Baal Netbeck]

Wenn du die DLCs hast und Lust dazu, kannst du ja mal den skriptbenchmark selbst probieren.

Auf der Fazit Seite gibt es ganz unten einen link zu einen google drive Ordner, der Anleitung, savegame und Skript beinhaltet.

Man muss leider sehr viel beachten... Den Kameraabstand erhöhen... Rechtsklick menü deaktivieren... randscrollen deaktivieren... Auflösung muss 1080p sein ....sowas halt, da das Skript sonst nicht funktioniert.

Und man braucht autohotkey und capframeX...muss in capframeX den Benchmark hotkey auf das Komma am Nummernblock setzen...und das Skript läuft fast 2h.

Alles nicht so der massentaugliche Benchmark

Ergänzung (3. Juli 2023)

So, hier mal die Einstellungen, auf die ich mich jetzt mit mir geeignigt habe

Das sieht sinnvoll aus.

 

[gidra]

Interessant zu sehen, dass fast jeder hier auf 32 GB oder mehr setzt.
Vor einigen Jahren galten 32 GB ja noch als völlig übertieben fürs Gaming.

Anno war und nach wie vor ist das einzige Spiel, welches die 16 gb Ram bei 2K überschritten hat. Es waren 21-22 gb.

Vergleiche ich z.B. den Computerbase Test mit 10K Einwohnern, was ich noch als Anfangsphase in Anno 1800 beschreiben würde....dann komme ich da auf 106 FPS(bin mir nicht sicher ob das GPU Limitiert war)
Also von einer Anfangsphase mit 106 FPS für das Standbild zu 81 FPS beim Lategame Standbild und dann 33 Minuten später 67 FPS.
Und bei dem Skriptbenchmark sind dann im Mittel 60,5 rausgekommen.

Mit 1800x hatte ich zum Schluss, bei etwa 50.000 Einwohner, teilweise 18-23 fps. Mit KIs, alle Inseln besetzt und Bewegung ohne Ende. Wenn ich in ein paar Tagen auf 5700x und 32 gb Ram aufgerüstet habe, starte ich eine neue Partie.

Wobei, trotz super Arbeit, wäre die tatsächliche Geschwindigkeit der Ram-Kits interessant. Die DR sind doch bei gleicher Frequenz schneller. Die erwähnst du im Titel, gehst aber im Artikel selbst, nicht darauf ein. Aber vielleicht ist die tatsächliche Differenz auch vernachlässigbar.

 

[Baal Netbeck]

Wobei, trotz super Arbeit, wäre die tatsächliche Geschwindigkeit der Ram-Kits interessant. Die DR sind doch bei gleicher Frequenz schneller. Die erwähnst du im Titel, gehst aber im Artikel selbst, nicht darauf ein. Aber vielleicht ist die tatsächliche Differenz auch vernachlässigbar.

Du meinst welche Bandbreite/Latenz die in synthetischen Tests schaffen?

Ich habe zu den Ramkonfigurationen teilweise "Aida64" oder "DRAM Camculator" Messungen, aber eher nur Stichproben um zu sehen ob alles normal läuft.
Um das fair zu vergleichen bräuchte ich viele viele Messungen, da diese Tests schon durch winzige Hintergrundaktivitäten stark beeinflusst werden und ich halte den Preis für Aida64 für übertrieben, weshalb ich das nicht kaufen möchte.

Es kommt da darauf an, wie viele Ranks sich pro Channel ergeben und dann noch wie BankgroupSwap konfiguriert ist....welche CPU verwendet wird usw.

In der Tendenz hat ein Rank pro Channel eine minimal bessere Write Bandbreite und bessere Latenzen.
Zwei oder mehr Ranks pro Channel haben dann bessere Read und vor allem Copy Bandbreiten.

z.B. 49.800 MB/s zu 50150 MB/s bei Write.
Aber dann 49.200 MB/s zu 43.300 MB/s Copy und 50.200 zu 50.000 bei read.
Und die Latenz ungefär 0,3 ns besser für einen Rank....Alles aus Aida64.
BankGroupSwap kann falsch konfiguriert dazu führen, dass auch mehr Ranks auf die schlechte copy Bandbreite von einem Rank zurückfällt, das sollte aber mit BankGrouSwapAlt kein Problem sein.

Außer Copy ist das alles fast Messungenauigkeit....Und in Anno scheint auch das keine Rolle zu spielen.

In diesem Teil des Artikels findest du noch mehr Daten dazu:
https://www.computerbase.de/forum/t...mark-ram-ranks-channel-bankgroupswap.2135054/
Da sieht man, dass bei Zen und Zen2 CPUs im Mittel ist kein Unterschied messbar ist.

Und Auch mit Zen3, wo es in anderen Spielen angeblich große Vorteile geben soll, habe ich nichts messen können.

 

[gidra]

Hast recht. Es wird gesagt, dass die Geschwindigkeit vom Ram nur dann anfängt eine Rolle zu spielen, wenn die CPU sich im Limit befindet. Bei einem 4-Kerner trifft es zu, aber so wie dein Test zeigt, wird nicht mal der 6-Kerner voll ausgelastet. Demnach, auch wenn die CPU im Spiel limitiert, so ist sie doch dennoch nicht voll ausgelastet, weshalb die Geschwindigkeit des Rams kaum eine Rolle spielen dürfte?

 

[Baal Netbeck]

Es wird gesagt, dass die Geschwindigkeit vom Ram nur dann anfängt eine Rolle zu spielen, wenn die CPU sich im Limit befindet. Bei einem 4-Kerner trifft es zu, aber so wie dein Test zeigt, wird nicht mal der 6-Kerner voll ausgelastet.

Die CPU kann die FPS limitieren, auch ohne von der Programmierung voll ausgenutzt zu werden... egal ob 4 , 6, 8 oder 16 Kerne.

Ob dann schneller RAM hilft, hängt von der Art und der Zusammensetzung der Berechnungen ab...nicht von der Auslastung.

Demnach, auch wenn die CPU im Spiel limitiert, so ist sie doch dennoch nicht voll ausgelastet, weshalb die Geschwindigkeit des Rams kaum eine Rolle spielen dürfte?

Den Zusammenhang siehst du falsch.

Nachfolgende Zahlenbeispiele sind z.B. ungefähre Aida64 Latenzen oder eigene Beobachtungen mit Ryzen CPUs...keine Gewähr auf Richtigkeit und Vollständigkeit.

Jede Berechnung der CPU braucht Daten....große/kleine, viele/wenige.... Sind die Daten bereits im L1 Cache(ca. 1ns), gibt es gar keine Verzögerung und die CPU-Pipeline kann direkt weiterarbeiten....im L2 Cache gibt es meist eine kurze Verzögerung(3-4 ns)....im L3 Cache dauert es nochmal etwas länger bis die CPU weitermachen kann(9-11 ns) und sind die Daten nicht im Cache, kommt der RAM dran und da sind es bei DDR4 und AMD je nach CPU und RAM, 60-100 ns......und von der SSD, weil es ausgelagert wurde oder neu aus einer Datei gelesen werden muss, so 100.000 - 500-000 ns.....mit HDDs so 12.000.000 ns bis Sekunden.

Jeder CPU Kern hat eine eigene MemoryControlUnit(MCU), die die benötigten Daten im Cache sucht oder bei RAM/Laufwerk anfragt.
Wurden die Daten kurz vorher schonmal benötigt, oder erzeugt, sind sie noch im Cache.
Auch benutzt die MCU branch prediction(Sprungvorhersage) um zu erraten was wohl als nächstes benötigt wird.
Im einfachsten Fall wäre das z.B. die Situation in der eine Liste abgearbeitet wird und die CPU fetcht sich die instruction

Liste_A[0] = Liste_A[0]*2;

Die CPU soll also das erste Element der Liste verdoppeln.... Jetzt muss die MCU also den Wert dieses Elements heranschaffen und nehmen wir an, das ist nicht im Cache, aber im RAM... Dann dauert das mit normalem XMP RAM z.B. 75 ns.
....erst läuft die Pipeline noch ein paar Schritte weiter, aber wenn es dann an den Punkt kommt, wo die Multiplikation ausgefüllt werden soll, stoppt die ganze Pipeline und wartet auf den Wert von Liste_A[0]...auch wenn die CPU jetzt nicht wirklich arbeitet, gilt der CPU Kern trotzdem als ausgelastet, da er damit beschäftigt ist zu warten...mit Simultaneous threading(SMT) könnte eine andere unabhängige Berechnung zum Überholvorgang ansetzen, aber das spielt hier keine Rolle....
Was eine Rolle spielt ist, ob die MCU errät was als nächstes kommt.
Wenn nach dem ersten Element gefragt wurde, wird sie davon ausgehen, das es mit den anderen Elementen weitergehen wird und fragt den Ram-Controller eben nicht nur nach dem ersten Element, sondern gleich nach den ersten X...vielleicht 64 Elementen.
Ist die nächste Instruction dann

Liste_A[1] = Liste_A[1]*2;

dann ist der Wert schon im L1 Cache und wird wirklich die ganze Liste abgearbeitet, dann spielt der RAM ab da keine Rolle mehr, da die ganzen Werte in den Cache geladen werden bevor sie benötigt werden.

Daher reagiert sowas wie Excel oder fast jede normale Anwendung nicht auf schnellen RAM oder auf X3D CPUs...die Sprungvorhersage ist auf modernen CPUs zu gut und ein Großteil ist rechtzeitig im Cache.

In Spielen passiert aber vieles Verschiedenes durcheinander und unvorhersehbar....daher sieht man hier meist einen hohen Anteil an cache misses.....und viel Rechenzeit der CPU Kerne geht fürs Warten drauf.

Mit einer höheren CPU- Gesamtauslastung gehen sicherlich mehr Ramzugriffe einher und dann wird die Bandbreite wichtiger, aber die Latenz ist meiner Erfahrung nach oft das wichtigste und in Anno 1800 ganz besonders.

Und da ist es egal wie die CPU Auslastung ist..... Wenn die GPU auf Drawcalls warten muss und es viele CPU cache misses gibt, wartet sie auch immer auf den RAM und profitiert von mehr RAM Geschwindigkeit(in diesem Fall Latenz).