• Mitspieler gesucht? Du willst dich locker mit der Community austauschen? Schau gerne auf unserem ComputerBase Discord vorbei!

[Review] Elex - CPU Benchmarks

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:

Elex ist ein neues RPG, das an die Erfolge von Gothic anknüpfen möchte.
Ich bin noch nicht dazu gekommen es wirklich zu spielen, der Einstieg ist aber sehr klassisch und gefällt mir.
Grafisch ist das Spiel kein AAA Titel, mir gefällt es trotzdem;).

Es wird die DX11 API verwendet und trotzdem sind wir fast immer GPU limitiert.

Für einen CPU Benchmark ist das Spiel also nur bedingt geeignet. ;)

Ich teste es hier trotzdem, auch um ein schönes Beispiel zu haben, wie langweilig CPU Tests im GPU limit sind. :cool_alt:

Die Testkandidaten sind wieder 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 und eine Betrachtung der Infinity Fabric Skalierung.

Fangen wir mit der Testszene an.
https://www.youtube.com/watch?v=UkpnKiNwG4I&index=7&list=PLP9fskJGwUOT5CByAJMJrXaggyMuUgsFt

Meine Messung beginnt und ich beginne direkt loszulaufen.
Ich halte Shift um so viel wie möglich zu rennen.
Bei dem Sprung benutze ich das Jetpack mit zwei Schüben und die Messung endet wenn ich am Ende wieder in den Büschen stehen bleibe.

Wer die Szene selbst testen möchte findet im Video die Grafikeinstellungen.
Und hier das benutzte savegame:
https://drive.google.com/drive/folders/1Hahuj2q234W1LTFi5WLAZOo_uR4tF-qu?usp=sharing

Frametimegraphen:
Zuerst der Vergleich meines Ryzen 7@3,8GHz und des Ivy Bridge i5 mit 4,4GHz

elex graph i5 zen.png

Wie man sieht, hat das Spiel eine relativ gleichbleibende Belastung.
Beide CPUs liefern fast gleiche Ergebnisse, schaut man genau hin, erkennt man etwas stärkere Schwankungen beim ivy i5.

Das gleiche Bild zeigt sich mit 4 Kernen und 4 Threads eines Ryzen wie hier zu sehen:

elex graph zen 4vs8c.png

Die 4 Kerne laufen minimal schlechter, im Grunde aber gleich.

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

elex i5 zen.png

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.

Wie schon in den Frametimegraphen zu sehen, liegen Ryzen und der ivy i5@4,4GHz praktisch gleich.
Selbst das senken des DDR4 Takt auf 2133 verschlechtert das Ergebnis praktisch nicht.

Erst das absenken der i5 Taktraten auf den Basis Takt hat einen Einfluss auf die Performance.

Ryzen CCX Konfiguration und SMT

elex ccx smt.png

Alles sieht gleich aus, bis auf 4+0 3200MHz....und hier sehen wir später, das es sich vermutlich um eine unlogische und falsche Messung handelt.


Leistungsaufspaltung beim i5

elex i5 clockram.png

Während mit 4,4GHz und 1866er DDR3 noch für das volle GPU limit reicht, reicht schon weniger Ram speed um dies zu ändern und zumindest in diese Szene FPS Unterschiede zu zeigen.

IPC Vergleich

elex ipc.png

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.

Bei diesem Vergleich sehen wir auch zum ersten Mal Unterschiede bei Ryzen.

Generell kann Ryzen sich hier etwas durch die IPC absetzen....ein großer Teil ist jedoch der Ram.

Unterschiedliche Ram Skalierung bei anderen Kern und Thread Anzahlen?

elex ram 4vs8.png

Wenn wir hier etwas genauer hingucken, sehen wir auch mit 8 Kernen etwas Einfluss durch den Ram.
Mit 4 Kernen ist der Unterschied jedoch größer, 2133er DDR4 ist aber trotzdem kein Problem.

HBCC settings

elex hbcc.png

Abolut keine Unterschiede zu finden.

Ryzen optimieren und übertakten

elex optimize.png

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?

Der Unterschied von Stock Taktraten und dopc Profil zu meinen Optimierungen ist praktisch nicht vorhanden.

Die Bios defaults fallen etwas ab, vermutlich ist ein Teil davon der Wechsel von ausbalanciert zu Höchstleistung.


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.
Eigentlich sollte hier ein Diagramm zum IF stehen, das ich allerdings nicht veröffentlichen möchte.

Stattdessen zeige ich nur die zugrundeliegenden Messungen:
elex 2+2 4+0 wrong.png

Wie wir sehen können scheint die Messung mit 4+0 und 3200er DDR4 nicht gelungen zu sein. Eventuell hat die Grafikkarte nicht getaktet wie sie soll, oder etwas lief im Hintergrund.

Eigentlich hätte ich erwartet das sie die beste Leistung liefern sollte aber das scheint schief gegangen zu sein.

Da ich inzwischen neue Grafikkartentreiber und einige neue Windows updates drauf habe kann ich die Messungen auch nicht vergleichbar zu den anderen wiederholen.

Fazit:

Da ist er also....der erste meiner Test mit so gut wie keinem Wissensgewinn. ;)

Solange man nicht vier Kerne mit wenig GHz und langsamem Ram hat, zeigen sich keine nennenswerten Unterschiede.

Die meisten Messungen zeigen nur unbedeutende Variationen eines GPU limits.

In diesem GPU limit liefern die 4,4GHz des i5 etwas mehr avg FPS als der Ryzen und bei den X% low Werten kann dann der Ryzen eine minimale Führung halten.

Wenn man das Video anguckt, sieht man das die CPU Belastung zwischen 20-30% liegt, was grob vier voll ausgelasteten CPU Kernen entspricht.

Spürbare Unterschiede gab es aber nur mit gesenkten Taktraten.

Die Auswertung des IF war leider nicht möglich.

HBCC war egal und optimieren ist dank GPU limit auch nicht wichtig.

Danke, wer sich dies bis hier her angetan hat;) ..... bald sollten interessantere Tests kommen. :)
 
Zuletzt bearbeitet:
Danke für deine zahlreichen Benchmarks.
Ich bin ebenfalls in einem Bench-Marathon gelandet, vor kurzer Zeit erst.
Allerdings habe ich mich auf folgende Benchmarks beschränkt:

aida64
Cinebench
SuperPI
Passmark PerformanceTest
Superposition Benchmark
UserBenchMark

Ich werde mir das ganze von dir in Ruhe anschauen, sobald ich Zeit habe.
Übrigens hat es seine Gründe, dass die CPU nicht so stark limitiert.
Für die Erklärung der Hintergründe werde ich permanent gebasht.
Sobald ich das errechnet habe, versuche ich es verständlich zu schildern.

Alleine diese häufig kritisierten "synthetischen Benchmarks"
Wie soll das denn sonst funktionieren?
Es ist nun mal so, das Engines verschiedene Berechnungen und Bandbreiten benötigen oder unterstützen.
Das war noch nie anders, als ob es eine "feste Norm" gäbe.

Wenn man in den Kritikpunkten wühlt, findet man immer neue, was auch sonst.
Keine Sache, Eigenschaft, oder Situation etc. lässt sich nicht kritisieren hehe.
 
Zuletzt bearbeitet:
Synthetisch Benchmarks habe ich 2018 nur aida64 und Cinebench R15 gemacht.

Anfang letzten Jahres hatte ich auch noch andere Benchmarks wie Euler3D, Superposition Benchmark, Heaven, 3DMark, wPrime und rendern mit Camtasia Studio gemacht.

Aber seit dem hat sich viel getan und die alten Ergebnisse sind nicht mehr brauchbar.

Hier wären meine aktuellen Ergebnisse für Cinebench und Aida64:
https://www.computerbase.de/forum/t...digkeit-meiner-systeme.1760089/#post-21080223

Man muss beim testen immer Kompromisse machen.
"synthetisch Benchmarks" unterscheiden sich stark in ihrer Qualität und Aussagkraft. Dafür sind sie in der Regel vergleichbar durchführbar.
Daher versuche ich den Nutzen von Fall zu Fall neu zu bewerten.
Superposition ist für mich z.B. rausgeflogen..Heaven auch....3DMark Firestrike und Timespy eigentlich auch.

Was möchtest du denn errechnen?
 
Schön zu sehen, dass du offensichtlich etwas von der Mathematik dahinter verstehst. Das kann man leider über viele Hardware-Redaktionen nicht so unbedingt sagen.

Ich weiß nicht, wie die Leute darauf kamen, dass das Xth percentile so toll sei. Ich glaube Einige wissen wirklich nicht, was es ist.
Von min. FPS hat man sich ja abgewandt, weil sie nur einen einzigen Worst-Case-Wert darstellen, der oft wenig aussagt, da er auch keinerlei Informationen über "seine Umgebung" enthält.
Wie man darauf kam, dass es die Lösung sei, einfach einen anderen Einzelwert zu nehmen, ist mir völlig schleierhaft.
An jeder Stelle, wo ich ein Xth percentile sehe, würde mich viel eher der 100-X% low average oder gar der X% high average interssieren.
Es gibt ja auch noch andere schöne Größen, die man berechnen könnte.
Z.B. den Anteil der Frames unter einer absoluten (30, 60?) oder relativen (50% des AVG?) Grenze.
Oder noch eine Standardabweichung auf die 1% lows. Oder oder oder... viele interessante Dinge. :)

Ich persönlich bevorzuge übrigens doch durchaus die 0,1% low averages. Am Besten aber natürlich sowohl 1% als auch 0,1%.

Da du ja Freude an den Zahlen zu haben scheinst, kannst du ja mal gucken, ob du in der Richtung "FPS / CPU-Auslastung" etwas Nettes findest.
Da wollte ich immer mal schauen, was man da machen kann, und ob da auch z.B. im GPU-Limit etwas Interessantes raus kommt.
Habe aber aktuell leider weder die Zeit noch die Hardware, um da mal ernsthaft etwas zu versuchen.
Natürlich gibt es Schwierigkeiten, z.B. wenn Kerne prinzipiell gar nicht genutzt werden.
Auch habe ich noch nicht recherchiert, wie verlässlich denn die Auslastungswerte, die man so bekommt, denn wirklich sind.
Wie gesagt, kannst ja mal schauen, ich fänd es spannend. :)
 
@Hopsekäse

Ich bin ein großer Fan der 1% low Werte, weil sie schon ziemlich gut zeigen wie sich das Spiel anfühlt aber noch relativ gut reproduzierbar sind. Die 0.1%finde ich auch super, aber diese basieren eben nur auf sehr wenigen Werten.

Ein Spiel das im Schnitt mit 60FPS läuft und das ich 40s lang messe ergibt ja nur 2400 Frametimes.
Nehme ich da die 0,1% und bilde den avg, habe ich im Grunde nur die schlechtesten zwei Frametimes berücksichtigt :(

Die Xth percentile sind wirklich eine komische Idee gewesen. ;)
CB begründet die Verwendung ja damit, dass diese eben keine Ausreißer beinhalten und da stimme ich zu.....aber in der Regel bin ich ja daran interessiert zu erfahren wie sich das Spielen anfühlt, und da gehören zumindest die reproduzierbaren Ausreißer(meiner Meinung nach) mit dazu.
Die percentile haben aber ihre Berechtigung, wenn man Ausreißer eben absichtlich ausklammert.

Was du mit dem Anteil der Frames unter 30 60 usw angesprochen hast, habe ich schon längst gemacht....nur nicht in diesen Tests integriert, weil es schwer war dies mit den anderen Werten zu kombinieren....den Rest konnte man ja in 1/s angeben.

Standardabweichungen und Gaußsche Fehlerfortpflanzung sind meine Wege um die Fehlerbalken zu bestimmen.

Wobei mich die Standardabweichung der Einzelmessungen nicht groß interessiert. Die Fehlerbalken sind die empirische Standardabweichung über die drei Messwerte, die den Mittelwert ergeben. So habe ich ein Maß dafür ob die Ergebnisse reproduzierbar waren.

Ich habe für die Tests immer fünf Frametime-Messungen gemacht und mein Programm wertet alle fünf aus und gibt mir zwei kombinierte Statistiken aus, einmal aus den jeweils drei besten und einmal aus den drei schlechtesten Werten gemittelt und mit empirischer Standardabweichung....und einer Angabe aus welchen Messungen die Werte stammen.

So versuche ich die Messungen, die durch Hintergrundprogramme oder Nachladeruckler gestört wurden aus der besseren Statistik automatisch herauszuhalten und gebe dann den Mittelwert über diese drei (hoffentlich) ungestörten Messungen aus.

Beispiel für Zen 4+4 3,8GHz 3200 CL14er Ram mit Vega64(undervolted).....also das was mein Daily system ist.
elex statistik beispiel a.JPGelex statistik beispiel b.JPG
 
Zuletzt bearbeitet:
Das stimmt natürlich, dass man längere Testsequenzen braucht, damit die 0,1% auch nennenswert viele Frames umfassen.

Was ich halt am 99th percentile immer doof finde, ist das Folgende:
Beim percentile weiß ich ja nichts über die Frames unterhalb des Schwellwertes. Insofern kann natürlich ein percentile auch keine Ausreißer enthalten, weil es eben nur ein einziger Wert ist. Aber nach dem Wert können theoretisch sogar nur noch Standbilder kommen.
Natürlich ist das nicht sehr wahrscheinlich. Aber möglich ist es z.B. trotz eines 99th percentile von (umgerechnet) 30FPS in 1% der Zeit sehr starke framedrops zu haben. Und 1% der Zeit ist halt schon ein gar nicht mal so kleines Stück. In dieses "Fenster", das vom 99th Percentile nicht abgedeckt wird, passen z.B. jede Spielminute 0,6s lange framedrops. Je nach dem wie tief die drops sind, sind 0,6s mitunter schon sehr spürbar.

Nun ist der 1% average natürlich schon viel besser. Aber er ist halt auch nur ein average. Da können natürlich auch wieder Einige besonders hoch (nah am percentile) und Andere wieder besonders niedrig sein. Da könnte man dann gucken, um welchen Faktor das in etwa die oben genannte Rechnung beeinflussen könnte. Oder man guckt sich halt den 0,1% average an, da weiß man dass das unberücksichtigte Fenster halt um den Faktor 10 kleiner ist.


Das mit den Fehlerbalken habe ich gar nicht gesehen. Ist leider immer etwas schwer darzustellen, wenn die Punkte schon nahe beieinander liegen und die Fehlerbalken dann auch noch nicht besonders groß sind.
Ich fänd halt die Standardabweichung der Einzelmessungen bei den averages ganz interessant. Zumindest prinzipiell... In deinem Fall hier bringt das natürlich wenig. Wenn ich den 1% avg habe und den 0,1% avg, der aus 2-3 Framezeiten besteht, dann habe ich ja quasi die Spannweite über den Bereich. Da brauche ich nicht auch noch die Standardabweichung.

Dass du die FPS unter Grenzwert schon hast, ist natürlich super. :D

Aber genug zu noch weiteren möglichen Rechenspielen.
Wie gesagt, das Thema FPS / CPU-Auslastung würde mich mal interessieren.
Hast du da schonmal etwas probiert?
 
Was du zu den Percentile und X% low Werten schreibst habe ich auch schon versucht in Worte zu fassen.
Einmal in dem "Hauptthread"(ganz oben verlinkt)...findet sich im Spoiler "Nomenklatur" .....
...und hier:
https://www.computerbase.de/forum/threads/frametime-vs-fps.1728576/#post-20678304
... habe ich noch ein paar Beispiele drin, die die Probleme genauer beleuchten. Allerdings habe ich den zweiten Artikel letztes Jahr erstellt und noch keine X% low Werte verwendet.

Bei den Fehlerbalken bin ich froh, wenn sie nicht gesehen werden. ;)
Dann wurde der Mittelwert aus drei gut reproduzierbaren Werten gebildet. :)

Ich könnte natürlich heranzoomen, aber dann sehen das unbedarfte Leute, gucken nicht auf die Skalierung und interpretieren große Unterschiede in die Ergebnisse, die in Wahrheit völlig irrelevant sind.

Deine Idee CPU Auslastung und FPS als Messung zu verknüpfen ist sehr interessant!

Ich hatte sowas mal als grobe Idee im Kopf gehabt aber dann schnell wieder verworfen.
Ich müsste die CPU Auslastung kleinschrittig protokollieren können. Die Angaben, die der MSI Afterburner in OSD macht sind da nicht genau genug und man kann sie soweit ich weiß nicht protokollieren.
HWInfo könnte sowas machen...das letzte mal als ich das installiert hatte, hat es aber Abstürze verursacht....bin also nicht sonderlich scharf darauf es zu nutzen;)

Wenn du eine Idee hast, wie man die Auslastung protokollieren kann, wäre ich dankbar :)
 
Sorry für die späte Rückmeldung, hatte das Thema abonniert aber keine Benachrichtigung bekommen. :freak:

Bei Thema Auslastung loggen ging es mir leider genauso wie dir.
Habe auch nur mal im Afterburner geguckt, aber leider weiß ich eben auch nicht wie genau die sind. Dass man sie auch nicht einfach so mitloggen kann, war mir auch beim kurzem betrachten aufgefallen.

HWInfo habe ich gerade mal angeschmissen. Das würde natürlich bieten, was man braucht. Kriegst du das mit den Abstürzen vielleicht mit aktuellen Versionen etc wieder hin?
Eine genaue Zuordnung von Framezeiten / -Verläufen ist dann zwar nicht so gut machbar, aber ansonsten erscheint es mir ganz tauglich.
Die Polling-Frequenz ist auch einstellbar, leider nicht niedriger als 100ms. =(
Die resultierenden csv-Datein kann man anständig automatisiert verarbeiten. Average total, per core etc könnte man alles ausrechnen.
Auch so Dinge wie time below threshold (Auslastung) sollten machbar sein.
Über das Polling-Intervall kriegt man vielleicht sogar halbwegs brauchbar eine Zuordnung zu den Framewerten aus dem Afterburner hin. Dann könnte man vielleicht sogar so interessante Sachen machen wie Auslastung while <30 FPS etc.

Ich denke wenn HWInfo stabil läuft, kann man da einige spannende Dinge mit anstellen.
Natürlich weiß man weiterhin nicht wie genau denn die berichtete Auslastung wirklich ist.
 
Danke für die Antwort:)

Das Problem mit Harware Info war irgendwas mit Mainboard Sensoren, die in unregelmäßigen Abständen Abstürze verursacht haben. Man konnte irgendwie das Auslesen deaktivieren....war mir nur damals nicht wichtig genug gewesen und vermutlich ist es inzwischen eh gefixed...die haben ja einen guten Ruf mit ihren updates.

Ich kann da durchaus nochmal reingucken....bin zeitlich aber in den nächsten zwei Wochen ziemlich am Limit....eigentlich wollte ich auch einen 2700X kaufen aber dafür ist keine Zeit....Ich werde versuchen hier und da für die letzten drei Spiele, die ich getestet hatte, die Diagramme und Artikel fertig zu machen und hoffentlich auch eine gemeinsamme Auswertung über alle Spiele zu schaffen.

Der Rest muss erstmal hinten anstehen;)....dann wäre so eine Auswertung sicherlich möglich....ich müsste sicherlich die Messungen irgendwie synchronisieren....vermutlich die Frametimes durch lokale Durchschnitte glätten um beide miteinander verrechnen zu können....mal sehen wie das gehen würde.
 
Zurück
Oben