AMD Ryzen 9 9950X3D Gesichtet: Über 5,6 GHz Boost-Takt und 128 MB L3-Cache im CPU-Z Leak

Redaktion

Artikel-Butler
Mitarbeiter
Mitglied seit
Aug 6, 2018
Beiträge
2.406
Bewertungspunkte
11.659
Punkte
1
Standort
Redaktion
Es gibt mal wieder neue Details zum High-End-Prozessor AMD Ryzen 9 9950X3D mit erweitertem L3-Cache. Der AMD Ryzen 9 9950X3D wurde in der Hardware-Datenbank CPU-Z als Engineering-Sample gesichtet. Der Prozessor zeigt sich mit unveränderten Taktraten im Vergleich zur Nicht-X3D-Variante, ergänzt durch zusätzlichen L3-Cache, der mit der 3D-V-Cache-Technologie realisiert wird. Dieser Artikel fasst die wichtigsten technischen […] (read full article...)
 
Irgendwie aber auch schade, daß es keinen X3D Cache unter beiden CCDs geben soll. Meine Vermutung: den gibt's dann nächstes Jahr als neues Topmodel.
 
Find auch auch schade hätte mir gern 16kern gekauft sollte der leak stimmen dann wirds bei mir leider nur 9800x3d werden. Wird die erste cpu seit 7 jahren die weniger als 10 kerne hat macht mich ein bischen traurig.
 
Find auch auch schade hätte mir gern 16kern gekauft sollte der leak stimmen dann wirds bei mir leider nur 9800x3d werden. Wird die erste cpu seit 7 jahren die weniger als 10 kerne hat macht mich ein bischen traurig.
bekommst du das so krass mit ? das du dann weniger kerne hast, weil habe von ein i9 11900kf zu 7800x3d gewechselt und merke kaum unterschied auser natührlich in der gaming leistung.
 
bekommst du das so krass mit ? das du dann weniger kerne hast, weil habe von ein i9 11900kf zu 7800x3d gewechselt und merke kaum unterschied auser natührlich in der gaming leistung.
Das (mögliche ) Problem bei den Ryzens mit mehr als 8 Kernen, also 2 CCDs - 1 CCD mit X3D, einer ohne - ist, daß man gerade Windoof manchmal mit der Nase darauf stoßen muß, ein Programm (Spiel) auf dem CCD mit X3D laufen zu lassen, und nicht auf einem der Kerne auf dem CCD ohne X3D. Bei den 8 und 6 Kernern gibt's ja nur 1 CCD, so daß Programme und OS bei dem 7800X3D, 9800 X3D usw erst gar keine Wahl haben, und immer Kern(e) auf dem CCD mit X3D benutzen müssen. Was man ja gerade in Spielen will. Wenn zB ein 9950 (16 Kerne in 2 CCDs) X3D unter jedem der zwei CCDs hätte, wär es dagegen egal, wo das OS ein Programm ausführen will.

Völliger Spekulatius meinerseits: So einen 2x X3D Zen5 16 Kerner wird AMD uU für HEDT und Workstations zurückhalten , also als entry level Threadripper (mit TR Preisen😜). Sind eben nicht nur Spiele, die durch extra Cache deutlich schneller und effizienter laufen können.

OT: bin gespannt, ob und wie Intel sowas ähnliches wie X3D in Panther Lake bringen wird. Intel ist hier im Zugzwang, und muss sich was einfallen lassen.
 
Laut disem Interview wird die nächsten jahre kein stackt chace kommen. Ob das wirklich so ist oder nicht wird sich zeigen.

 
Zuletzt bearbeitet :
Naja aber Anwendungen die Kerne brauchen werden mit dem 9950 nicht mehr so ausgebremst wie bei den Vorgänger.

Im Endeffekt muss Windows steam und co nur wissen welche App max 8 x3d braucht und alle anderen Laufen mit identischen takt auf 32 Threads
 
Die Aussage "Zusammen mit dem L2-Cache ergibt sich ein Cache-Gesamtvolumen von 144 MB" halte ich für etwas irreführend,
die beiden Caches L2 und L3 sind ja nicht additiv, sondern funktional gestapelt, erst L3, dann L2.
Außerdem ist L2 doch je Core - d.h. L2-Cache-Änderungen müssen an die anderen Cores signalisiert werden, das ist kein großer, zusammenhängender Cache.

Übrigens: die 2 x Cache-Dies würden vermutlich nur was bringen, wenn sie miteinander verbunden wären. Und das dürfte mit dem derzeitigen Chiplet-Design wohl eher nicht möglich sein. Somit kann ein Core des einen Chiplets nicht auf bereits im L3 befindliche Daten des anderen Chiplets zugreifen, sprich: die Daten müssten je nach Thread und Programm in beiden L3 Caches, also doppelt vorgehalten werden und damit auch oft doppelt aus dem RAM geladen werden.

Bei den Server-CPUs greifen dann ohnehin andere Mittel, die fahren auch nicht mit Windows 10, sondern mit Server-Betriebssystemen, die andere Scheduler haben. Manche Server sind ja NUMA, d.h. verschiedene Prozessoren greifen auf unterschiedlichen RAM zu, das dazu passende Scheduling bzw. Thread-Verteilung auf die jeweils zusammenpassenden Cores muss das Betriebsystem können. Bei Servern geht es um Anwendungen, Filesysteme und Datenbanken, die wohl eher ein anderes Thread-Verhalten als Feld/Wald/Wiesen-Games haben.
 
Lt anandtech ist zumindest Zen 2 nur L2->L3 non-inclusive.

Ich meine dennoch, aus Prozessorsicht darf ich nicht einfach L1+L2+L3 rechnen,
weil die L1+L2 ja letztlich nur von jeweils einem Core gesehen werden.
D.h. wenn ein Core eine RAM-Zelle in L1+L2 gelesen hat, haben die anderen Cores erstmal nix davon.
Ebenso dienen die 96 MB L3 ja nicht nur exklusiv einem, sondern acht oder zwölf Cores.

Und die 32+64=96 MB L3 des einen CCDs einfach mit den 32 MB L3 des anderen CCDs addieren,
dürfte ich eigentlich nur, wenn diese L3 Caches untereinander kommunizieren könnten.
Sonst muss nach einem RAM-Write des einen CCDs ein entsprechend vorhandener L3-Eintrag im anderen CCD
invalidiert und dort ggf. neu gelesen werden.

Aber vielleicht konzentriert man sich letztlich besser auf die Resultate,
wenn die Gurken offiziell angekündigt werden.
 
Ein Ausschnitt aus dem Zen5 White-paper:

MEMORY-INTENSIVE WORKLOADS: Many technical workloads process models that require large amounts of memory, putting high demands on memory throughput and cache� These include RTL simulation, computational fluid dynamics, weather forecasting, and molecular dynamics� Some business applications fall into this category as well, including Java® enterprise middleware� To satisfy these high memory demands, certain memory-optimized processors use multiple internal Infinity Fabric™ links between the I/O die and the CPU dies, effectively doubling the maximum theoretical memory throughput of each die� Compute Express Link (CXL®) 2�0 supports cache-coherent memory expansion and interleaving that enables large memory pools, software-managed tiered memory, and memory pooling

Was verbinden die Infinity Fabrik Links nochmal ?

AMD INFINITY ARCHITECTURE When creating a processor based on a hybrid, multi-chip architecture, the performance of the interconnect is of paramount importance� The heart of the AMD Infinity Architecture is a leadership interconnect that supports extraordinary levels of scale at every layer� Components communicate using AMD Infinity Fabric™ technology—a connection that is used between CPUs, between components in the multi-chip architecture, and to connect processor cores, memory, PCIe® Gen 5 I/O, and security mechanisms�
 
Was soll mir das sagen ?

Die Infinity Fabric verbindet die CCDs mit dem IOD, nicht aber die Caches untereinander.
Sonst könnten bereits jetzt beide CCDs auf die gemeinsamen 96+32 MB L3 zugreifen.

Aus der von dir oben verlinkten Webseite entnehme ich:
If this causes a block to be evicted from L1, the evicted block is then placed into L2. This is the only way L2 gets populated.

Auf Ryzen L2-L3 bezogen: in den L3 eines CCD geht nur rein, was aus dem L2 eines Cores dieses CCDs rausfliegt.
Also nix mit "hintenrum über die Fabric in den L3 des anderen CCDs".

Ich bin nicht mal sicher, ob überhaupt die anderen Cores desselben CCDs auf L2->L3 overflow Daten
eines anderen Cores zugreifen dürfen, finde dazu aber nur nicht-AMD-spezifische Aussagen.

Die IF Taktrate liegt übrigens weit unterhalb den Cache-Taktraten, hier zwei Links:
Der Takt des Infinity Fabric liegt üblicherweise zwischen 1.600 und 1.800 MHz.
FCLK is typically far lower than L3 and core clocks.

Im zweiten Link kann man auch sehen, dass die CCDs nicht direkt miteinander verbunden sind,
sondern die CCDs jeweils nur mit der Fabric und..
Wenn die Cores der CCDs über dieses Konstrukt ihre Daten miteinander teilen wollten,
müssten diese ja zweimal übertragen werden (CCDx-Fabric-CCDy), das führt zu Latenzen.

So eine Inter-CCD Cache-Direktverbindung führt zu deftigem Overhead/Komplexität - und die Wege,
auch wenn es sich nur um Milli- oder Mikrometer handelt, sind auch zu berücksichtigen (Latenz).

Die machen ja schon bei der Signalisierung zwischen den CCDs Probleme, hier : Absatz "Kern-Latenzen",
dafür gab's schon einen AGESA Update, da reden wir aber über Prozessor-Signalisierung,
nicht über Cache-to-Cache-Verbindung, wo es um echte Datenmengen ginge.

Aber mal ehrlich, was soll das Bohei um die "möche-ich-haben" doppelten L3-Caches eigentlich ?
Ein Profi, der wirklich Anwendungen fährt, wird doch nicht etwa Spiele auf seine Workstation laden ?
Dann sollte das Finanzamt (und/oder eine eventuelle Geschäftsführung ;-) das aber nicht mitbekommen.

Und ein Gamer, der ab und an ein paar Videos erstellt ?
Sooo langsam sind die ?600X3D/?800X3D nu ja auch wieder nicht.
 
Ich finde es schade, dass anandtech sich zu viel, selbst zusammen gereimt hat.

Hätte er mal bei AMD direkt Nachgefragt, oder deren Quellen genutzt. Wäre er evt. heute noch da, wo er war. ;)

Edit: Alle 3rd Party Tools bestätigen mir, alle Cache Level sind Unified.
Also alles addieren, oder der Diskussion fern bleiben !
 
Zuletzt bearbeitet :
Also alles addieren, oder der Diskussion fern bleiben !
Alles addieren = Marketing. Dazu ist die Funktion der Caches m.E. zu komplex.
Mir selbst war es nur wichtig, die Funktion der Caches besser zu verstehen.

Schleierhaft ist mir allerdings, wie "3rd Party Tools" herausfinden sollen, wie die Hardware strukturiert ist.
Und was ist mit "alle Cache Level sind Unified" gemeint ? Dass alle - auch über Chiplets hinweg - verbunden sind ?
Das würde allen Dokumentationen widersprechen, wir reden nicht nur über Anandtech.
Die Diskussion ist aber ohnehin nicht zielführend - egal, wie der Cache ausgelegt ist,
entscheidend ist, was hinten rauskommt. Also abwarten und Tee trinken.

Der Leak selbst bringt im Grunde nix Neues: wenn man die seitherigen Prozessoren
7950X3D, 9700X, 9800X3D im Zusammenhang betrachtet, kann man sich die Struktur gut herleiten,
einen zweiten 3D-Cache wird es wohl nicht geben, dafür mehr Takt und OC für den 3D-Cache-CCX.
Vielleicht will AMD da zu den Server-Prozessoren (z.B. Genoa-X: je CCD 96 MB L3) differenzieren.

Jedenfalls falls der L3 als Overflow nur je Core-L2 verwendet würde und auch nur dieser jeweilige Core
die Daten wieder aus L3 in seinen L2 zurückbrächte, dann würde ein zweiter Cache-Die Sinn machen.
In dem Fall würde eine Verbindung der beiden L3-Caches auch keinen Sinn machen.
Aber das kann AMD wohl am Besten beurteilen.
 
L1/L2 ist nur für die jeweiligen Kerne verfügbar, der L3 ist für alle Kerne des jeweiligen CCX verfügbar. Ich meine aber das es ein L3 Cache-snooping gib d.h. Kerne eines anderen CCX/CCD können schauen ob dort für sie relevante Daten verfügbar sind. Sehr wahrscheinlich ist auf den fremden L3 aber nur ein lesender Zugriff möglich.
 
Hab bei dem Sauwetter heute mal länger recherchiert, es gibt allerdings keine belastbaren Aussagen und viel Widersprüchliches.
Könnte auch mit dem Zen-Unterschied Server (Genoa/Epyc) vs. Desktop (Ryzen) zu tun haben.

Ich meine aber das es ein L3 Cache-snooping gib
Jedenfalls hat wohl AMD vor einigen Jahren ein Patent für ein Directory-based Cachemanagement eingereicht.
Anscheinend fahren die zwischen den Prozessoren keinen echten Snoop, sondern ein Directory je Node (Chiplet ?).
Die Cachedaten werden schon zwischen den Nodes/Cores ausgetauscht, ich nehm auch an, dass es für I/O-DMA ein Snooping gibt
(die Cores müssen ja erkennen, ob ein DMA-Controller den Speicher geändert hat).

Sehr wahrscheinlich ist auf den fremden L3 aber nur ein lesender Zugriff möglich.
Wenn das zitierte Patent wirklich in den Zen-CPUs implementiert wurde, tauschen die Nodes untereinander (L3) Cache-Inhalte aus.
Das Patent bringt lt. AMD Optimierungen bzgl. der Node-Kommunikation, indem wohl nach meinem Verständnis
der Owner einer Cache-Line (bin dabei über MOESI gestolpert) immer "hart" wechselt
(um die Bilder im o.g. Patent zu verstehen, muss man im PDF die Seite 9 rechts lesen).

Jedenfalls ist die Sache an sich recht geheimnisvoll und ich bin froh,
dass meine Ryzens auch ohne mein Zutun fröhlich und ohne Murren und Knurren arbeiten.
Screenshot - 02.01.2025 , 18_25_30.png
 
komm bis montag können wir doch abwarten da wissen wir mehr :) die werden bestimmt was dazu sagen.
 
Alles addieren = Marketing. Dazu ist die Funktion der Caches m.E. zu komplex.
Mir selbst war es nur wichtig, die Funktion der Caches besser zu verstehen.

Ich habe die Infos von der offiziellen AMD Seite und wenn du mal nach schaust was ein White Paper ist, sollte dir bekannt sein, dass es sich hierbei nicht um Marketing handelt!

Mit einer Sache hast du aber recht, das Thema Cache-Coherent ist ein sehr Komplexe Angelegenheit.
Weshalb sich meiner Meinung nach auch nur Leute damit auseinander setzen sollten, die in der Materie sind.
Da sonst schnell Missverständnisse aufkommen. ;)

Edit: Ein interessanter Link m.M.n. http://lastweek.io/notes/cache_coherence/
 
Zuletzt bearbeitet :
certain memory-optimized processors use multiple internal Infinity Fabric™ links
Das sind die Links zwischen CCD und IO-Die. Was hat das mit Cache zu tun ?

Compute Express Link (CXL®) 2�0 supports cache-coherent memory expansion and interleaving that enables large memory pools, software-managed tiered memory, and memory pooling
Bei CXL geht es nach meinem Verständnis um das Erweitern des RAM mit anderen Medien (SSD), siehe hier und hier und hier

AMD Infinity Fabric™ technology—a connection that is used between CPUs, between components in the multi-chip architecture, and to connect processor cores
Das hatte ich nicht gewusst. Wie der Austausch von Cache-Daten zwischen den Nodes und Cores bei AMD abläuft, geht aus deren Patentdokumenten vor , dieses Prinzip wurde wohl in der Zen-Architektur implementiert.

Das bedeutet aber nicht, dass ein Core direkt auf den Cache eines anderen Dies zugreifen kann, vielmehr bekommt er die Daten über die Links (Latenz !). Ein Direktzugriff eines Core auf den L3 eines anderen Core würde auch dem von dir genannten non-inclusive widersprechen.

Weshalb sich meiner Meinung nach auch nur Leute damit auseinander setzen sollten, die in der Materie sind.
Schade, dass du so denkst, sonst hätte ich dir noch folgende Lektüre empfohlen: Kap. 3, 6, 7 (aus 2022, behandelt zwar Zen 3 EPYC Server Prozessoren, ich nehm aber an, das Prinzip wird auch in Zen 4/5 verwendet, da finde ich nirgends, dass sich da etwas signifikant geändert hätte).
 
Oben Unten