Special AMD Ryzen 7 9850X3D: RAM-Skalierung von DDR5-4800 bis DDR5-6000 geprüft

Du hast also weder die CPU noch den RAM und mutmaßlich auch nicht die im Test verwendete RTX 5950. Aber einzig die gewählte Testauflösung verhindert, dass die Testergebnisse zu deiner "Praxis" passen? :confused:
Verstehe, man darf also nicht daran interessiert sein, ob man beim Aufrüsten viel Performance verliert, wenn man langsameren Speicher verwendet, weil man die Hardware NOCH nicht hat?

Seltsame Einstellung. Wenn ich die Hardware schon hätte, bräuchte ich diesen Test gleich überhaupt nicht ;)

Das kommt so rüber, als würdet ihr genau wissen, wie wertlos ein Test in dieser Auflösung ist, aber trotzdem besteht ihr drauf, dass er sinnvoll sein soll.

Als Spieler möchte man nicht wissen, wie brauchbar eine Hardware ist, wenn man die niedrigste Auflösung verwendet, sondern wie es bei der verwendeten Auflösung ist, oder zumindest einer Auflösung in der Nähe und nicht einer Auflösung, die vor 5 - 10 Jahren mal aktuell war.

Weil man eben nicht weiß, ob die Auflösung einen Unterschied macht bei langsamerem Speicher. Wüsste man das, bräuchte man keinen Test.

Auch CPU-Tests in niedrigster Auflösung müssen nichts über die Performance in höheren Auflösungen sagen. Weil man da ins GPU-Limit kommt, helfen oft bessere CPU's garnicht.
 
Zuletzt bearbeitet:
Als Spieler möchte man nicht wissen, wie brauchbar eine Hardware ist, wenn man die niedrigste Auflösung verwendet, sondern wie es bei der verwendeten Auflösung ist, oder zumindest einer Auflösung in der Nähe und nicht einer Auflösung, die vor 5 - 10 Jahren mal aktuell war.
Oh doch. Wie soll ich sonst abwägen welche Kompromisse ich einzugehen bereit bin. Wie soll ich ein Budget definieren, wenn ich nicht weiß, welche Hardware was leistet?

Weil man eben nicht weiß, ob die Auflösung einen Unterschied macht bei langsamerem Speicher. Wüsste man das, bräuchte man keinen Test.
Wieso weiß man das nicht? Bist Du im GPU Limit, hat der Ram keinen Einfluss. Vorausgesetzt der RAM ist nicht zu wenig.

Weil man da ins GPU-Limit kommt, helfen oft bessere CPU's garnicht.
Und deswegen sind CPU Tests im GPU Limit sinnfrei.

Deine Argumentation ist für mich nicht schlüssig. Du testest ja auch nicht mit 30 FPS Limit und mit einer RX6800 in 3840x2160p.
 
Wie erklärst du den von Igor gemessen Unterschied bei der Leistung?

Bislang gar nicht. Ich kann anhand der Arbeitsweise der Hardware bestimmte Erklärungen ausschließen. Aber ich kann nicht anhand von vier Werten sagen, warum sich eine bestimmte Hardware-Konfiguration besonders gut oder eine andere besonders schlecht verhält, sondern allenfalls typische Hintergründe zitieren – aber dieser Fall ist offensichtlich nicht typisch. So etwas zu analysieren, kann etliches an zusätzlichen Tests erfordern.

Edit: Je mehr ich lese, desto schwieriger wird es für mich, die Thematik nachzuvollziehen.
Das bedeutet, ein 9800X3D mit negativem CO und erhöhtem PBO Scalar müsste bereits ähnliches Verhalten zeigen?
Hast du eine Quelle für AMDs Designentscheidungen dieser CPU?

Wieso passiert das mit höherem Takt häufiger? Das Programm ist doch maßgeblich dafür verantwortlich, oder nicht? Das widerspricht doch den Ergebnissen bzw. Ausführungen von Igor.

Der Programmablauf hat natürlich entscheidenden Einfluss, aber bei zwei Messungen mit dem gleichen Programm sollte er keine Unterschiede hervorrufen. Ebenso wenig sollte sich die Caching-Strategie bei zwei Prozessoren mit gleicher Architektur und gleichem Firmware-Stand unterscheiden. Die Grundannahme ist also, dass 9800X3D und 9850X3D zum gleichen absoluten Zeitpunkt die gleichen Daten aus dem langsamen DDR5-4800 RAM pre-Cachen. Der höher taktende 9850X3D hat, wenn keine anderen Limits vorliegen, zu diesem Zeitpunkt bereits mehr Programmcode abgearbeitet, was die Wahrscheinlichkeit steigert, dass ein Teil der geladenen Daten veraltet ist. Auch in Gegenrichtung sollte eine höher taktende CPU Cache und Speicherinterface schneller auslasten: Wo mehr berechnet wird, müssen mehr Daten zurückgeschrieben werden und immer wenn das nicht schnell genug geht, wird ein größerer Teil des Caches als Puffer benötigt, anstatt frei verplant werden zu können; die höher taktende CPU hat erneut mehr Cache-Misses im verbleibenden Rest und ist abhängiger vom Speicherinterface.

Das sind aber alles sehr esoterische Spezialfälle. Sie sollen illustrieren, dass Igors Erklärung einer besseren Cache-Ausnutzung bei höherem Takt genau das Gegenteil der Erwartungen darstellt, aber sie sollen keine Leistungsunterschiede erklären. Normalerweise sollte die Cache-Nutzung im Inneren von 9800X3D und 9850X3D ziemlich exakt gleich sein, da alle beteiligten Komponenten mit entsprechend höherem Takt arbeiten. Ob der 9850X3D 100,00 Prozent so viele Cache-Misses wie der 98500X3D hat oder 100,05 Prozent, spielt für Praxisbenchmarks keine Rolle, es gibt nur architektonisch keinen Grund für die Annahme, es könnten zum Beispiel 90,00 Prozent, also signifikant weniger sein. Was für die Systemperformance viel wichtiger sein sollte: Wie groß ist die Strafe bei einem Cache-Miss? Wie lange braucht das Speichersystem, um die Daten nachzuliefern und wie viele CPU-Zyklen gehen in dieser Zeit verloren?
Da ist die Erwartung ganz klar: Mehr beim 9850X3D. Er muss auf den DDR5-4800 genau so viele ns warten, verwirft aber in dieser Zeit bis zu 10 Prozent mehr Taktzyklen. (Den genauen Realtakt in den Benchmarks sollte man als erstes prüfen.)

Auch das widerspricht den Aussagen/ Ergebnissen von Igor.

Es widerspricht der hier geäußerten Erklärung. Was seine Ergebnisse sonst begründen könnte, muss untersucht werden. Aufgrund der schon im Mittel quasi-linearen, in einzelnen Tests also mutmaßlich supralinearen Leistungsskalierung mit dem CPU-Soll-Takt, halte ich Ursachen außerhalb des Cache-Systems für wahrscheinlich.

Man bekommt das Gefühl, dass bei PC Hardware so langsam die ersten Schranken in Sichtweite kommen.

Hardware arbeitet ständig an der Grenze irgendwelcher Schranken. Hat sie schon immer gemacht, wird sie auch immer machen. Die Frage ist: Wie aufwendig wird es, die gerade dominierende Schranke zu öffnen?

Würde ich so nicht sagen. Heute haben wir vielfältige Möglichkeiten, uns über aktuelle Geschehnisse zu informieren. Damals, als Hardware noch richtig (!) teuer war, ging das nicht. Vielleicht verschieben sich manche Upgrades jetzt und die Leute wissen ihre Hardware mehr zu schätzen. Würde der Wegwerfgesellschaft mal den nötigen Denkzettel verpassen. Verglichen zu "damals" ist Hardware heute immer noch spottbillig.

Anhang anzeigen 1515421
Quelle

Der "Tower 486" oben rechts kostet 1,67 1991er Durchschnittsgehälter. Das wären aktuell 7.865 Euro, also beinahe die gleiche Zahl. Dafür bekam man etwas, was damals eine Einsteiger-Workstation-CPU gewesen sein müsste, eine großzügige Menge RAM, einen riesigen High-End-Massenspeicher und die seinerzeit schnellste GPU (keine^^). Also sagen wir mal 32 Kern Threadripper, 256 GiB, RTX 5090, zweimal 4 TiB PCIe 5.0. Meinst du wirklich, das war damals "richtig teuer" verglichen mit heute? Es würde mich sehr wundern, wenn du ein Komplettsystem mit diesen Specs auch nur zum gleichen relativen Preis findest.
 
Zuletzt bearbeitet:
Ich versuche das einmal sauber und nachvollziehbar zusammenzufassen, ohne mich auf Spekulationen oder „magische Effekte“ zu stützen.

Der Kern des Missverständnisses liegt in der Annahme, dass zwei CPUs mit identischer Architektur und identischem Cache-Ausbau zwangsläufig auch identisch auf den Speichertakt reagieren müssten. Das ist in der Praxis moderner Prozessoren so nicht richtig. Cache-Größe ist ein statischer Wert, die tatsächliche Wirksamkeit des Caches ist jedoch dynamisch und hängt vom zeitlichen Verhalten der Kerne, vom Boost- und Power-Management, vom Scheduling und nicht zuletzt von der Firmware ab.

Der entscheidende Punkt ist, dass „mehr Zeit zum Abarbeiten von Cache-Daten“ kein Vorteil ist. Ein langsamerer oder früher aus dem Boost fallender Kern erledigt nicht weniger Arbeit und benötigt nicht weniger Daten, er benötigt nur länger dafür. Dadurch verlängern sich kritische Phasen, in denen Datenabhängigkeiten aufgelöst werden müssen, Prefetch-Horizonte überschritten werden und Speculation an Wirkung verliert. Das führt nicht zu weniger, sondern tendenziell zu mehr real wirksamen Speicherzugriffen pro abgeschlossener Arbeitseinheit. Höherer und stabilerer effektiver Takt kann diese Speicherlatenzen dagegen besser überdecken.

Genau hier setzt der Ryzen 7 9850X3D an. Durch sein etwas größeres Boost-Fenster und die stabilere Boost-Charakteristik werden viele Arbeitsphasen schneller abgeschlossen, solange die Daten im L3-Cache liegen. Die Cache-Trefferquote steigt dabei nicht „magisch“, sondern indirekt, weil weniger Zeit vergeht, in der neue Daten aus dem Arbeitsspeicher nachgeladen werden müssen. Das ist ein zeitliches Effektivitätsproblem, kein strukturelles Cache-Größenproblem. Deshalb reagiert der 9850X3D in der Praxis weniger empfindlich auf langsameren Speicher, obwohl beide CPUs nominell über den gleichen Cache verfügen.

Ein Messfehler ist aus meiner Sicht ebenfalls unwahrscheinlich. Der Effekt zeigt sich reproduzierbar über mehrere länger laufende Anwendungen hinweg und tritt konsistent in derselben Richtung auf. Zufällige Messabweichungen würden sich nicht so gleichförmig und über unterschiedliche Workloads hinweg bemerkbar machen, zumal ich viele Applikationen mehrmals laufen lasse.

Zusätzlich darf man nicht vergessen, dass AMD CPUs intern sehr wohl unterschiedlich behandelt, auch wenn sie sich auf dem Papier stark ähneln. Unterschiede bei FIT-Kurven, Boost-Decay-Zeiten, Power-Transient-Handling oder Cache- und Fabric-Policies werden über Firmware und AGESA gesteuert und sind gängige Praxis. Es ist daher technisch absolut plausibel, dass der 9850X3D hier andere Default-Parameter nutzt als der 9800X3D. Dass der 9850X3D auf nicht gepatchten Boards bereits ein abweichendes Verhalten gezeigt hat, spricht eher für solche internen Unterschiede als gegen die Messungen.

Kurz gesagt: Gleicher Cache bedeutet nicht gleiche Cache-Effektivität. Der 9850X3D kompensiert die grundsätzliche Speicherabhängigkeit von Zen 5 durch stabileren Boost und feinere Regelmechanismen besser als der 9800X3D. Die gemessenen Unterschiede sind damit weder esoterisch noch widersprüchlich, sondern technisch erklärbar.
 
Am Ende interessiert mich derzeit nur, ob der 9800X3D durch den Launch des 9850X3D günstiger wird. Wenn das eintritt, halte ich den 9850X3D durchaus für lobenswert. :D
 
Bei 52 protokollierten Workstation-Benchmarks mit mehreren Iterationen eher unwahrscheinlich. Zumal sich meine Zuwächse genau mit dem internationalen Durchschnitt decken. Dann hätte der Rest auch falsch gemessen. Es sind knapp 4% mehr Performance, alles transparent belegt, normalisiert und veröffentlicht.

Zusammengefasst:

1770199007460.png


1770199050220.png


@blautemple Es steht Dir frei, die Challenge anzunehmen und das Gegenteil zu beweisen. Aber da wird sicher nichts kommen, nehme ich mal an.

Selbstzitat von oben:
Zusätzlich darf man nicht vergessen, dass AMD CPUs intern sehr wohl unterschiedlich behandelt, auch wenn sie sich auf dem Papier stark ähneln. Unterschiede bei FIT-Kurven, Boost-Decay-Zeiten, Power-Transient-Handling oder Cache- und Fabric-Policies werden über Firmware und AGESA gesteuert und sind gängige Praxis. Es ist daher technisch absolut plausibel, dass der 9850X3D hier andere Default-Parameter nutzt als der 9800X3D. Dass der 9850X3D auf nicht gepatchten Boards bereits ein abweichendes Verhalten gezeigt hat, spricht eher für solche internen Unterschiede als gegen die Messungen.
Ich möchte auch keiner Redaktion etwas unterstellen, aber ich bin mir nicht sicher, ob immer mit dem BIOS gebencht wurde, das AMD zur Verfügung gestellt hat. Ich musste mein MSI-Brett z.B. auf ein BIOS vom November zurückflashen. Damit habe ich alles noch einmal gebenchmarkt. Der 9800X3D und der 9850X3D wurden also unter absolut gleichen Voraussetzungen gebencht, ohne alte Messwerte zu nutzen. Lustigerweise waren die Kontrollmessungen des 9800X3D mit dem neueren AGESA sogar einen Tick besser. Ich habe aber Reviews mit Boards gesehen, wo AMD explizit noch kein neues BIOS mitgeschickt hat.
 
Zuletzt bearbeitet:
Ich versuche das einmal sauber und nachvollziehbar zusammenzufassen, ohne mich auf Spekulationen oder „magische Effekte“ zu stützen.

Der Kern des Missverständnisses liegt in der Annahme, dass zwei CPUs mit identischer Architektur und identischem Cache-Ausbau zwangsläufig auch identisch auf den Speichertakt reagieren müssten. Das ist in der Praxis moderner Prozessoren so nicht richtig. Cache-Größe ist ein statischer Wert, die tatsächliche Wirksamkeit des Caches ist jedoch dynamisch und hängt vom zeitlichen Verhalten der Kerne, vom Boost- und Power-Management, vom Scheduling und nicht zuletzt von der Firmware ab.

Bis hierhin d'accord. Meine obigen, theoretischen Ausführungen berufen sich immer auf gleiche Technik/Cache-Logik/etc.. Wenn AMD den 9850X3D anders arbeiten lässt als den 9800X3D, dann kann natürlich ein anderes Verhalten dabei herauskommen.

Das wäre dann aber eben kein Effekt des höheren Taktes beim 9850X3D, sondern einer abweichenden Ansteuerung. Und zumindest seitens AMD gibt es keine Aussagen, die architektonische Änderungen naheliegen. Wenn @PCGH_Dave Zeit hat, kann er ja einfach mal die 9800X3D über- oder/und 9850X3D untertakten und prüfen, ob es @Iso Unterschiede gibt.

Der entscheidende Punkt ist, dass „mehr Zeit zum Abarbeiten von Cache-Daten“ kein Vorteil ist. Ein langsamerer oder früher aus dem Boost fallender Kern erledigt nicht weniger Arbeit und benötigt nicht weniger Daten, er benötigt nur länger dafür. Dadurch verlängern sich kritische Phasen, in denen Datenabhängigkeiten aufgelöst werden müssen, Prefetch-Horizonte überschritten werden und Speculation an Wirkung verliert. Das führt nicht zu weniger, sondern tendenziell zu mehr real wirksamen Speicherzugriffen pro abgeschlossener Arbeitseinheit. Höherer und stabilerer effektiver Takt kann diese Speicherlatenzen dagegen besser überdecken.

Hier wiederholst du, nahezu wortgleich, deine letzte Erklärung. Ich betone daher noch einmal: Prefetch-Horizonte und Cache-Verweildauer werden nicht absoluter Zeit gemessen. Ein Prefetcher arbeitet mit einem Takt, OoO-Logik kann in-flight-Windows von einer bestimmten Anzahl Takte managen und Inhalte lässt man grundsätzlich so lange im Cache, bis sie durch einen neueren oder wichtigeren Wert überschrieben werden – was beides vom Fortlauf des Programms abhängt. Also von erfolgten Rechentakten, nicht von verstrichenen (Nano-)Sekunden.

Bei 52 protokollierten Workstation-Benchmarks mit mehreren Iterationen eher unwahrscheinlich. Zumal sich meine Zuwächse genau mit dem internationalen Durchschnitt decken. Dann hätte der Rest auch falsch gemessen. Es sind knapp 4% mehr Performance, alles transparent belegt, normalisiert und veröffentlicht.

Zusammengefasst:

Anhang anzeigen 1515566

Hast du auch die Taktraten protokolliert? Einige Benchmarks fallen schon auf, wenn man den Vorsprung des 9850X3D gegenüber dem 9800X3D @DDR5-4800 mit dem Vorsprung @-6000 vergleicht:

Inventor: +12 Prozent statt +6 Prozent
Photoshop: +11 Prozent statt +6 Prozent
Blender: +16 Prozent statt +3 Prozent
After Effects: +22 Prozent statt +6 Prozent
AI Vision: +37 Prozent statt +3 Prozent

Es wäre unwissenschaftlich, Messergebnisse auszusortieren, nur weil sie aus dem Rahmen fallen. Aber ausgehend von im Mittel knapp 6 Prozent mehr Takt (in PCGH-Messungen) sind alle Steigerungen um einen größeren Faktor zumindest interessant/einen weiteren Blick wert. Entweder da liegt ein außergewöhnliches Boost-Verhalten nur mit langsamen RAM vor, oder es kommen nicht-lineare Effekte zum tragen, die gar nichts mit der Taktung zu tun haben. Da die @6000-Werte recht normal aussehen, währen vor allem die @4800er-Szenarien einen zweiten Blick wert. (Als Redakteur eines Magazins mit "Games" im Namen kann ich leider keine eigenen Messungen beitragen. Wir sind froh genug, wenn Adobe im produktiven Hintergrund fehlerfrei läuft. Regelmäßige Benchmarks mit der ganzen Suite werden dem Leser als Übungsaufgabe überlassen.^^)

Wenn man diese fünf Benchmarks ausklammert und nur die verbleibenden 10 betrachtet, verliert der 9800X3D mit langsameren RAM übrigens 2,3 Prozent Leistung und der 9850X3D ... Trommelwirbel ... 2,3 Prozent.
 
Besonders extrem ist es im reinen Compute, vor allem dem AI Szenario. Das habe ich mehrmals gemessen und es hat sich nichts daran geändert. Was nicht heißt, dass die die CPU mit 6000 so viel schneller wäre, sondern dass der 9800X3D mit 4800 immer dann so langsam wird. Durchschnittstakt bei Blender z.B. rund 5.1 GHz, der 9850X3D bei 5.2 GHz
 
Zusätzlich darf man nicht vergessen, dass AMD CPUs intern sehr wohl unterschiedlich behandelt, auch wenn sie sich auf dem Papier stark ähneln. Unterschiede bei FIT-Kurven, Boost-Decay-Zeiten, Power-Transient-Handling oder Cache- und Fabric-Policies werden über Firmware und AGESA gesteuert und sind gängige Praxis. Es ist daher technisch absolut plausibel, dass der 9850X3D hier andere Default-Parameter nutzt als der 9800X3D. Dass der 9850X3D auf nicht gepatchten Boards bereits ein abweichendes Verhalten gezeigt hat, spricht eher für solche internen Unterschiede als gegen die Messungen.
Wenn das so wäre, frage ich mich, warum sich das Marketing von AMD nicht and diesen Themen abarbeitet, weil der 9850X3D ansonsten nichts neues bieten würde.

Kurz gesagt: Gleicher Cache bedeutet nicht gleiche Cache-Effektivität. Der 9850X3D kompensiert die grundsätzliche Speicherabhängigkeit von Zen 5 durch stabileren Boost und feinere Regelmechanismen besser als der 9800X3D. Die gemessenen Unterschiede sind damit weder esoterisch noch widersprüchlich, sondern technisch erklärbar.
Das Boostverhalten scheint es nicht zu sein, denn wie du unten selbst schreibst, trennen die beiden CPUs 100Mhz im Schnitt. In anderen Szenarien hält der 9800X3D seinen Boost sogar konstanter als der 9850.

Besonders extrem ist es im reinen Compute, vor allem dem AI Szenario. Das habe ich mehrmals gemessen und es hat sich nichts daran geändert. Was nicht heißt, dass die die CPU mit 6000 so viel schneller wäre, sondern dass der 9800X3D mit 4800 immer dann so langsam wird. Durchschnittstakt bei Blender z.B. rund 5.1 GHz, der 9850X3D bei 5.2 GHz
Für mich ergibt das immer noch nicht so richtig Sinn. Der 9850 müsste unter gleichen Bedingungen aufgrund der höheren Taktung mehr ans Speicherinterface gebunden sein als ein 9800 mit weniger Takt. Und du glaubst - leider hast du keine konkrete Quelle -, dass AMD nicht nur diesen Nachteil einfach kompensiert hat, sondern sogar deutlich überkompensiert hat, aber nur bei bestimmten Anwendungen.
Das klingt für mich nicht ganz plausibel, denn, wenn AMD rein durch AGESA "mal eben" einen 20% Leistungsvorteil rausholen könnten, warum schlachten sie das Thema nicht vom Marketing gnadenlos aus? Eine bessere Gelegenheit als diese Speicherkrise werden sie kaum bekommen. Warum bieten sie das (mutmaßlich) nur auf einer CPU an?

Edit: Wie @PCGH_Torsten schrieb, ein Vergleich beider CPUs mit festem Takt von beispielsweise 5Ghz, sollten bestätigen, ob beim 9850 hinter den Kulissen etwas geändert wurde, oder nicht?
 
Da haben die geneigten CPU-Tester tatsächlich Arbeit vor sich. 16 Prozent Mehrleistung bei real 2 Prozent mehr Takt schreien nach einer Erklärung. Respektive umgekehrt: Wieso verliert der 9800X3D 12 Prozent seiner DDR5-6000-Leistung, obwohl das Testszenario Compute-limitiert sein soll? Wie kann er in einem anderen, (noch stärker?) Compute-limitierten Szenario sogar um 26 Prozent einbrechen, obwohl der Speichertakt nur um 20 Prozent sinkt?
 
Wenn man diese fünf Benchmarks ausklammert und nur die verbleibenden 10 betrachtet, verliert der 9800X3D mit langsameren RAM übrigens 2,3 Prozent Leistung und der 9850X3D ... Trommelwirbel ... 2,3 Prozent.
Exakt, das passt einfach nicht.

Irgendwo ist in den Messungen der Wurm drin.
Bei 52 protokollierten Workstation-Benchmarks mit mehreren Iterationen eher unwahrscheinlich.
Du willst mir also allen ernstes weiß machen dass der 9850X3D mit 4800MT/s RAM 16% schneller als der 9800X3D in Blender ist während der Unterschied bei 6000MT/s nicht mal 3% beträgt? Das kann einfach nicht stimmen.

Hat AMD da irgendeine magische Sauce in den Cache gekippt ohne dass das Marketing davon Bescheid weiß, oder wie?
 
Zuletzt bearbeitet:
Mit Sicherheit :D

Der beobachtete Effekt ist m.E. weder ein Messfehler noch Esoterik, sondern das Ergebnis eines sehr spezifischen Workloads in Kombination mit Zen-5-Charakteristik, X3D-Cache und Firmware-Regelung. Entscheidend ist dabei z.B. Blender mit dem IgoBOT-Modell, das extrem viele Vertices besitzt und bei dem ein erheblicher Teil der Rechenzeit in das CPU-basierte Denoising fließt. Dieses Denoising ist formal compute-lastig, arbeitet aber mit großen, schlecht lokalisierten Datenstrukturen und vielen kurzen, latenzsensitiven Zugriffen auf temporäre Puffer, Normalen und Tiefeninformationen. Es ist damit nicht klassisch bandbreitenlimitiert, aber hochgradig abhängig davon, wie gut Speicherlatenzen überdeckt werden können. Ich nutze das Modell sehr bewusst, weil es auch bei GPUs echt fies ist.

Beim Ryzen 7 9800X3D führt langsamerer Speicher sicher dazu, dass diese Denoising-Phasen länger dauern und der effektive Kerntakt häufiger aus dem optimalen Boost-Fenster fällt. Sobald die CPU Speicherlatenzen nicht mehr sauber überdecken kann, kippt die Auslastung der Recheneinheiten. Der Leistungsverlust ist dann nicht mehr proportional zum geringeren Speichertakt, sondern fällt überproportional aus, im Extremfall zweistellig. Das erklärt die starken Einbrüche bei DDR5-4800 trotz nominell „compute-limitierter“ Last.

Der Ryzen 7 9850X3D verhält sich hier sicher robuster, obwohl Cache-Größe und Architektur identisch sind. Durch stabileres Boost-Verhalten, etwas höhere effektive Frequenzen und feinere Regelmechanismen werden einzelne Rechen- und Denoising-Phasen schneller abgeschlossen. Temporäre Daten bleiben häufiger innerhalb des Cache-Residency-Fensters, externe Speicherzugriffe werden besser überdeckt. Die Cache-Trefferquote wird dabei nicht magisch erhöht, sondern zeitlich effizienter genutzt. Genau deshalb reagiert der 9850X3D deutlich weniger empfindlich auf langsameren Speicher.

Dass sich dieser Effekt besonders stark beim IgoBOT zeigt, ist sicher kein Zufall. Szenen mit extrem hoher Mesh-Komplexität und starkem CPU-Denoising sind deutlich latenzsensitiver als texturdominierte Workloads. Letztere arbeiten mit besser vorhersagbaren, zusammenhängenderen Datenzugriffen und würden deutlich weniger extreme Unterschiede zeigen. Gleicher Cache bedeut nicht automatisch gleiche Cache-Effektivität. Wenn man hingegen immer ähnliche, vor allem auch Grafik-lastike Szenarien misst, kommt auch immer das Gleiche raus. In einem latenzsensitiven Workload wie Blender-Denoising mit extrem komplexer Geometrie entstehen nichtlineare Schwelleneffekte. Der 9800X3D fällt bei langsamem RAM unter diese Schwelle, der 9850X3D bleibt darüber. Da es nicht nur eine Anwendung ist, die solche Effekte erzeugt, kann man sicher nicht von einm temporären Messfehler ausgehen.

Alle genannten Programme haben nämlich gemeinsam, dass sie formal compute-lastig sind, intern aber stark latenzsensitiv arbeiten. Sie bestehen nicht aus gleichmäßigem Dauerrechnen, sondern aus vielen kurzen Rechenphasen mit Synchronisationspunkten und schlecht vorhersagbaren Datenzugriffen. Dazu kommen große, fragmentierte Datenstrukturen und umfangreiche Post-Processing-, Filter-, Denoising- oder Analyse-Schritte.

In genau solchen Workloads greifen nichtlineare Schwelleneffekte. Sinkt die Fähigkeit einer CPU, Speicherlatenzen zu überdecken, kippt die Effizienz plötzlich und es gehen nicht ein paar Prozent verloren, sondern zweistellig Leistung. Der Ryzen 7 9800X3D gerät bei langsamerem RAM in diesen ungünstigen Bereich, der 9850X3D bleibt dank stabilerem Boost und effizienterer zeitlicher Cache-Nutzung darüber. Deshalb sieht man hier +12, +16 oder sogar +37 Prozent statt der erwarteten +3 bis +6 Prozent. Nicht wegen mehr Cache oder „magischem Takt“, sondern weil all diese Programme latency-dominated compute workloads mit starkem Phasencharakter sind.

Außerdem traue ich es AMD zu, dass man den 9850X3D per AGESA, FIT-Kurven, Boost-Decay oder Power-Transient-Handling anders parametriert als den 9800X3D und damit Vorteile erzielt.

Ich bin aktuell krank und habe mir neben einer Gürtelrose am Kopf dazu gleich noch eine schwere Neuropathie eingefangen, die den ganzen Körper komplett schmerzen lässt. Das schränkt mich beim Arbeiten extrem ein, so dass ich das alles nicht noch einmal komplett nachstellen kann. Aber das können andere sicher genauso gut.
 
Nicht wegen mehr Cache oder „magischem Takt“, sondern weil all diese Programme latency-dominated compute workloads mit starkem Phasencharakter sind.
Aha, der 9850X3D hast also entsprechend mindestens 16% mehr Takt in diesem Szenario?

Das ist Quatsch und das weißt du auch. Wenn das bei 4800MT/s so extrem helfen würde, müssten die Vorteile auch bei 6000MT/s durchschlagen. Tun sie aber nicht, also ist etwas an deiner Messung faul.
 
Blender reagiert auf Speicher eigentlich kaum, soweit ich mich erinnere.

Da kam es doch immer auf CPU Takt an deswegen wurden die Intels doch damals so gerne dafür genutzt... (oder irre ich mich nun?)
 
Es ist nicht die Frage ob, sondern was du renderst.

Das Gegenargument scheitert an einem grundlegenden Kategorienfehler. Niemand behauptet, der 9850X3D hätte „16 Prozent mehr Takt“. Das ist eine falsche Gleichsetzung. Leistung in latenzdominierten Workloads skaliert nicht linear mit dem Kerntakt, sondern zeigt Schwellenverhalten. Kleine Unterschiede in effektivem Takt, Boost-Stabilität oder Latenzüberdeckung entscheiden darüber, ob Kerne rechnen oder real warten. Genau das erzeugt zweistellige Abstände, ohne dass der nominelle Takt stark steigt.

Ebenso falsch ist die Annahme, ein Effekt müsse bei DDR5-6000 genauso stark auftreten wie bei DDR5-4800. Bei 6000 MT/s liegen beide CPUs oberhalb der kritischen Schwelle, Speicherlatenzen sind kurz genug, der Abstand schrumpft. Bei 4800 MT/s fällt der 9800X3D in bestimmten Workloads darunter, der 9850X3D nicht. Das ist ein klassisches nichtlineares Schwellenphänomen, kein linearer Skalierungseffekt.

Die Schlussfolgerung „dann ist die Messung faul“ ist damit logisch unbegründet. Ein Messfehler wäre zufällig oder inkonsistent. Hier tritt der Effekt reproduzierbar in genau den Workloads auf, die bekanntermaßen latenzsensitiv und phasenlastig sind. Wer daraus „magischen Takt“ oder einen Messfehler ableitet, zeigt vor allem, dass er lineare Skalierung unterstellt, wo sie architektonisch nicht gilt. :)
 
Bei 6000 MT/s liegen beide CPUs oberhalb der kritischen Schwelle, Speicherlatenzen sind kurz genug, der Abstand schrumpft. Bei 4800 MT/s fällt der 9800X3D in bestimmten Workloads darunter, der 9850X3D nicht. Das ist ein klassisches nichtlineares Schwellenphänomen, kein linearer Skalierungseffekt.
Aha? Cache ist um viele Faktoren schneller als Ram. Was soll das denn für ein Schwellenwert sein?
Die Schlussfolgerung „dann ist die Messung faul“ ist damit logisch unbegründet. Ein Messfehler wäre zufällig oder inkonsistent.
Es muss kein Messfehler sein, es kann auch ein Konfigurationsfehler, ein Fehler in der Anwendung oder was weiß ich sein. Fakt ist aber, die Ergebnisse sind völlig unlogisch und ich bin doch schwer verwundert dass du die, ohne sie zu hinterfragen, einfach so veröffentlichst und dann eine Wall of Text raushaust in der vom neuen optimierten Cache schwadronierst, ohne dass du das mit harten Fakten untermauern kannst.

Ich bleibe dabei, die Werte stinken bis zum Himmel und ergeben überhaupt keinen Sinn.
Blender reagiert auf Speicher eigentlich kaum, soweit ich mich erinnere.

Da kam es doch immer auf CPU Takt an deswegen wurden die Intels doch damals so gerne dafür genutzt... (oder irre ich mich nun?)
Nein nein, der neue Wunder Cache macht das. Wichtig ist dass der nur bei 4800MT/s was bringt.
 
Zuletzt bearbeitet:
@igorsLAB Danke, für deine Ausführungen.
Die Begründung deiner Argumentation fußt, jedoch auf zwei Annahmen, wenn ich das richtig verstehe.

1. Zen5 hat ein optimales Taktfenster, was durch AGESA beeinflusst werden kann, in dem andere Systeme innerhalb der CPU am besten zusammen arbeiten.

2. AMD hat diese Systeme beim 9850 besser bzw. beim 9800 schlechter an deren Taktbereich angepasst.

Ich halte besonders die zweite Aussage als Folgerung nicht plausibel, weil allein die Serienstreuung innerhalb einer CPU Modelreihe ähnlich groß ist, wie der Taktunterschied zwischen 9800 und 9850, wie Roman mal gemessen hat. Die beiden Testsamples von PCGH belegen diesen Umstand.

Man könnte auf dieser Basis behaupten, dass deine Messungen korrekt sind, dieser aber nur aufgrund der speziellen Charakteristik deiner Samples zustande kommen, weil AMD den optimalen Betriebspunkt von Zen5 zu eng hinsichtlich der Toleranzen gesteckt hat.

Das klingt für mich ebenfalls nicht plausibel.
 
Zurück