News Ryzen 9 9950X3D & 9900X3D: AMD erklärt, wieso es weiterhin nur ein X3D-Chiplet gibt

[Vitche]

Dass die Synchronisierung der beiden Caches eine Herausforderung sein könnte, ist aber ein guter Einwand, hier habe ich womöglich den Aufwand unterschätzt. Ich hätte angenommen, dass man das im Hintergrund über den IF macht.

Das wäre quasi mit jedem neuen Taktzyklus ein DDoS auf den IF, lol.

Die beiden Caches müssen ja nicht perfekt in Echtzeit synchronisiert sein.

Doch, leider funktioniert es sonst nicht und richtet mehr Schaden an als es nutzt.

In den (seltenen) Fällen, wo die Daten von einem Kern des CCD_0 benötigt werden, die zwar schon im Cache des CCD_1 liegen, aber noch nicht synchronisiert wurden, würden die Daten einfach auf die selbe Weise geladen werden, wie dies schon im CCD_1 erfolgt ist (also "langsam" aus dem Speicher).

Aber woher weiß denn CCD1, dass das der Fall ist und in CCD0 Daten zum abrufen liegen? Er müsste vor jedem Cache-Zugriff auf eine Zelle seines "eigenen" L3 erstmal bei CCD0 Nachhören, ob der gerade was in seine Pendant-Zelle reinschreiben mag. Das ist halt ein grundlegendes Kommunikationsproblem. Bei verteilten Rechennetzen ist genau sowas im Grunde genommen stets das Limit, das mit sehr viel Aufwand und komplizierten Algorithmen umschifft werden muss. In einer einzelnen CPU willst du sowas echt nicht haben und Echtzeitanwendungen (= Spiele) schießt es sowieso ab. Stell dir quasi SLI innerhalb der CPU vor, Hilfe.

Sofern dieser Umstand entsprechend selten eintritt, sollte es sich meinem Verständnis nach nicht sonderlich auf die Performance auswirken, oder übersehe ich da was? Mit zunehmender Füllung des Cache (bzw der Caches) sollten diese Situationen ja tendenziell nahezu null sein.

Wie? Je voller der Cache, desto seltener soll es vorkommen, dass unsynchronisierte Daten im Cache sind? Vielleicht denken wir komplett aneinander vorbei, aber es wäre imho genau andersherum.

Der Original-Artikel von Hardwareluxx (der natürlich brav im Artikel verlinkt ist) sagt ja schon ganz klar aus, dass es technisch absolut möglich ist (und schon mehrmals erwogen wurde) und es rein aus finanziellen Überlegungen nicht gemacht wurde. Außerdem wird nicht der Leistungsvorteil an sich geleugnet, sondern nur, dass dieser womöglich nicht so hoch ist, wie ihn sich viele vielleicht vorstellen.

AMD sagt laut HWL eben nicht, ob es überhaupt einen Vorteil gibt. Er kann halt auch denkbar klein sein. Wenn er groß wäre, wäre das Reasoning ja eh anders und man würde einen doppelten X3D nicht direkt abschreiben.

Klingt dort schon ganz anders als die Formulierung (und Ausführungen) hier auf CB: "Mehrleistung durch zweiten 3D V-Cache ist fraglich". Auch andere Publikationen, die sich auf den Hardwareluxx-Beitrag beziehen, sehen das nicht so pessimistisch wie CB hier.

Anderer Redaktionen haben da (verständlicherweise) einfach nicht den Aufwand betrieben, einen Informatiker nach seiner fachlichen Einschätzung zu fragen, was ich als Redakteur praktischerweise nicht musste, weil ich selbst einer bin. Abgesehen davon ist "fraglich" aber auch nicht = "ausgeschlossen".

Sofern also Hardwareluxx hier AMD nicht falsch wiedergegeben hat, steht außer Frage, dass eine Mehrleistung drin ist (wie hoch genau weiß nur AMD und ist sicher davon abhängig, wie viele Kerne ein Spiel bzw Anwendung auslasten kann).

Ich lese das ehrlich gesagt so, dass durchaus offen bleibt, ob überhaupt eine konstruktive Mehrleistung drin ist.

Und die Scheduler-Problematik wäre dann sowieso Geschichte, welche ja das Hauptärgernis ist.

Ne, das ist ja eben die Krux. Die bleibt bestehen, nur eben in abgewandelter Form. Aber das erläutere ich jetzt nicht noch ein drittes Mal, sorry. ^^

Der einzige Grund, warum die X3D besser performen als die normalen, ist die Tatsache, dass die 32 MB L3 pro CCD volllaufen und die 96 MB halt deutlich mehr enthalten.

Man kann das noch weiter nachvollziehen und feststellen, dass der Vorteil daraus entsteht, dass die Daten schneller (= mit niedrigerer Latenz) geladen werden können als beim Schritt zur nächsten Stufe der Speicherhierarchie, also dem System-RAM. D.h. das ganze ist streng genommen kein Speicherplatzproblem, sondern ein Speicherlatenzproblem. Und diese Sichtweise hilft vielleicht auch noch einmal, um zu verstehen, dass es mit dem Weg über IF und I/O-Die zum Cache des zweiten CCDs nicht gelöst wird. Eben weil die Latenz hier signifikant schlechter ausfällt als zu alloziertem Speicher im "eigenen" X3D-Chiplet.

 

[eastcoast_pete]

Für Spiele mag das gelten, aber der 9800X3D war gerade wegen dem Cache in Anwendungen schneller als der 9700X.
Sieht man das nicht aus der Gamingperspektive (wo ein 16-Kerner ohnehin nur in Grenzfällen Sinn macht) Ist es sehr schade, das man hier nicht ein Produkt mit 16 gleichwertigen Kernen präsentiert.
So ist es für beide nix, Gaming und Workstations. Der logische Griff ist dann für Gamer nach wie vor der 9800X3D und alle anderen müssen sich entscheiden, ob mehr Kerne (9950X) oder schnellere Kerne (9800X3D) wichtiger sind.

Zumindest war AMD hier ehrlich: X3D pro CCD kostet Geld, und momentan muss AMD es auch nicht machen, da Intels Arrow Lake den X3D Zens wenig bis gar nichts entgegen zu setzen hat. Ich glaube, wir sehen hier die Spiegelsituation der Zeiten vor Zen1; damals konnte Intel es sich leisten, von Jahr zu Jahr nur ein bisschen an ihren Core 4 Kernern zu machen (zB Takt erhöhen) um den Abstand zu AMDs CPUs zu bewahren. D.h., wir sehen auch hier den Nachteil eines ziemlich einseitigen Wettbewerbs, halt umgekehrt. Dazu kommt, daß es sich für AMD viel mehr auszahlt, wenn sie genug X3D CCDs für EPYCs haben, da dort ihre Gewinnmargen sehr viel höher sind als in Desktop CPUs.

 

[luckysh0t]

Wäre wenigstens mal wieder ein "echter" FX!
Vorschlag an AMD: Nennt ihn FX3D

Dann mit (unified) X-finity 3D Cache ? ^^

 

[Vitche]

Aus dem Artikel bzw. die Argumentation von AMD:

Das war mein eigener Hinweis, den hat AMD so nicht gegeben.

Welche Distanz kann denn ein Signal bei 5 GHz zurücklegen? Wir können ja mal rechnen: […]

Aber vielen Dank für die Rechnung; die wollte ich im Artikel zwecks Umfang nicht anstellen. Du nimmst hier allerdings solides Kupfer an, das ist nochmal was anderes als Silizium/Halbleiter. Da rechnet man gerne Pi mal Daumen mit 1/3 = 100 Mio m/s. Und die Elektronen selbst sind auch nur die halbe Geschichte, weil die Geschwindigkeit der Ausbreitung der Spannung bzw. des elektromagnetische Feldes schneller als die Driftgeschwindigkeit der Elektronen ist. Deine richtigen Schlüsse bleiben davon aber natürlich unverändert. Wirklich interessant wird es dann, wenn man mit dieser Erkenntnis auf bis zu 800 qmm große GPU-Chips schaut.

 

[Kadett_Pirx]

ist eigentlich unverständlich, denn ein 9950X3D² wäre die absolute Spitze des CPU-Programms, wofür man auch einen hohen Preis verlangen könnte

 

[fdsonne]

Wenn ein solcher 9990X3D in keiner Anwendung schneller ist als ein 9950X3D, warum sollte man ihn überhaupt anbieten, bzw warum sollte ihn jemand kaufen?

Warum sollte er das nicht sein!?

Ein entsprechender Epyc mit dem Cache auf allen CCDs ist es ja auch in eben diesen Szenarien, wo das Vorhalten/Ablegen von mehr Daten näher am Core punkte bringt. Das ist nichts, was nur für einen CCD gilt. Der Knackpunkt viel eher die Marktausrichtung. Wahrscheinlich wird in den seltensten Fällen so viel parallel auf einem Customer Ryzen ausgeführt, dass es eben Sinn ergibt für jeden CCD den größeren Cache zu haben. Man darf ja nicht vergessen, es ist kein L3 Cache ja oder nein, sondern es geht lediglich um die Frage, ob etwas mehr oder weniger Cache verbaut ist.

Und selbst wenn, dann hätte man nicht mehr Cache, wenn nur gespiegelt wird.

Es tut mir leid, aber das sind keine faulen Ausreden, das sind Informatik, Physik und Logik.

Naja, man kann es den Leuten nicht verübeln, es wird selten wirklich gut erklärt. Auch in deiner Meldung geht sich das nur bedingt aus, wo du im Text was von addiertem Cache usw. schreibst. Was technisch einfach nicht stimmt. Da wird nix addiert.

Bspw. schreibt AMD für Zen5:

-> "L3 shared among all cores in the complex". Das geht es um Block IM CCX respektive CCD.

Mal für die Faktenbasis, weil das immer wieder so irgendwie behauptet wird. Das Cache/Latenzdiagramm für einen Dual CCD Ryzen schaut in etwa so aus:
https://www.techpowerup.com/forums/posts/5403613

Wie man unschwer erkennt - da wird kein Zugriff auf den zweiten CCD stattfinden, sonst dürfte sich die Latenz nicht um grob über den Daumen Faktor 8 steigern bei mehr wie 32MB Größe.
Man erkennt hier bspw. auch sehr gut, dass der größere L3 Cache durch den Huckepack Cache eine kleine Latenzstrafe bedeutet. Wobei klein in Relation schon relativ groß ist. ~1,5ms von knapp 9ms sind halt schon gut und gerne 15%.
Die nächst größere Stufe in der Treppe ist dann schon Zugriff Richtung RAM, was je nach Memory und Config/Takt usw. bei irgendwo im Bereich 60. 70ms los geht bei wirklich hochtaktendem Speicher.

Es ergibt absolut keinen Sinn Zugriffe über die lahme und latenzsschwache IF zu schicken um dann Daten in den Cache eines anderen CCD abzuwerfen, wenn man diese nicht lokal in diesem CCD benötigt. Umgekehrt genau so. Da wäre der drastisch viel größere RAM einfach aufgrund der Größe und Menge am Stück besser.



Was btw. auch dazu kommt, wenn man sich noch tiefer mit dem Thema beschäftigt. Multi Thread Zugriffe auf den Cache lassen die Latenzen explodieren.
Hier punktet ein Dual/Multi CCD Setup natürlich dann.

 

[Xeljaga]

16 Kerne mit X3D? Hätte auch 800 kosten können und ich hätte es genommen. AMD hat keinen Mut mehr, sieht man auch an den Grafikkarten. Schade.

 

[Vitche]

Auch in deiner Meldung geht sich das nur bedingt aus, wo du im Text was von addiertem Cache usw. schreibst. Was technisch einfach nicht stimmt. Da wird nix addiert.

Wo schreib ich was von addiertem Cache?

Ansonsten stimme ich deinen Ausführungen zu, das deckt sich ja eh mit dem Konsens im Thread.

 

[Syrato]

Und was spräche gegen einen "9990X3D" mit zwei X3D Chiplets für einen gewissen Aufpreis?
Hat AMD den Kampfgeist verloren?
Will man keine neuen Grenzen ausloten?

Einfach den Artikel lesen!
Wie es in der Zukunft, mit neuer Fertigung und neuem Design ausschauen wird, erfahren wir in den nächsten Jahren.

 

[fdsonne]

Wo schreib ich was von addiertem Cache?

Ansonsten stimme ich deinen Ausführungen zu, das deckt sich ja eh mit dem Konsens im Thread.

Ich mein das hier damit:

"Zwar verfügen Ryzen 9 9950X3D und 9900X3D über die gesamte Cache-Hierarchie hinweg dank zweitem Core Chiplet Die insgesamt über mehr Cache als der R7 9800X3D, also 144 MB respektive 140 MB statt 104 MB"

 

[Vitche]

Achso. Damit wollte ich einfach nur kurz erwähnen, wieso die überhaupt mehr Cache haben, obwohl es nicht mehr 3D V-Cache gibt. Inwiefern das überhaupt hilfreich ist bzw. ob CCD0 damit was anfangen kann hab ich nicht eingeordnet, ja - einfach, um es so knapp wie möglich zu halten. Im Grunde genommen findet man da aber noch eimal einen Hinweis, dass ein zweites X3D-Chiplet für CCD0 wenig hilfreich wäre, denn sonst würde ein 7950X3D ja (merklich) schneller sein als ein 7800X3D.

 

[Sharky99]

So klare und unverklausulierte Antworten gibt es nun auch nicht alle Tage.

Die Erklärung ergibt überhaupt keinen Sinn.

1. Über die Wirtschaftlichkeit, also Preis/Leistung entscheidet der Markt. Wenn es einen Markt für eine 5090 für 2500 Euro gibt, würde es auch einen Markt für eine 1500 Euro CPU geben.

2. Es geht hier nicht vorranging darum ob man nur 10% mehr Performance bekommen würde, sondern dass man die Fälle vermeiden würde wo die Spiele/Apps auf den Kernen liegen die keinen L3 Cache haben. Die Performance ist dann unterirdisch. Man könnte es natürlich Softwareseitig lösen, aber leider macht AMD zwar gute Hardware, bei der Software sind sie aber katastrophal. Deshalb empfielt AMD bei Problemen eine Neuinstallation von Windows, wo schon paar Registry Einträge das Problem meist lösen können.

 

[Syrato]

Es ist erschreckend, dass es so viele Besserwisser gibt.

AMD wird an diesem Themen 100% dran bleiben aber aktuell, mit Zen 5, wird es kein zweites CCD, mit x3D, für Gaming/Desktop CPUs geben (Threadripper und Server sind favon nicht betroffen)! (editiert)
Vielleicht mit Zen 6, neue Design's, wir werden sehen.

 

[Araska]

AMD wird an diesem Themen 100% dran bleiben aber aktuell, mit Zen 5, wird es kein zweites CCD mit x3D geben!

Wie jetzt, sind die X3D- Threadripper wieder vom Tisch?

 

[Syrato]

16 Kerne mit X3D? Hätte auch 800 kosten können und ich hätte es genommen. AMD hat keinen Mut mehr, sieht man auch an den Grafikkarten. Schade.

Du kannst ja gerne, mit deinem Koffer voll Geld, zu Dr. Lisa Su spazieren und sie fragen, ob welche für dich produziert werden.
@Araska habs editiert. Ganz ausschliessen, für 10950x3, dann man es nicht, es liest sich nur nicht so... aber beim AMD Marketing, weiss man nie.
Waren die x3D Threadripper jetzt offiziell bestätigt?

 

[BloodGod]

Dann bringt halt einen 9999X3D mit echtem Vollausbau und entsprechendem Preis und einfach mal gucken ob das dann wirklich niemand kauft.

Eine 4090/5090 verkauft sich heutzutage schließlich auch.

 

[incurable]

Doch zuerst frage ich mich [...]

Lenk nicht ab.

'Wir wurden ein paar Mal gefragt' ist kein vernünftiger Grund. Das passiert auch anderen Firmen, die komischerweise kein Problem darin sehen, die Fragen einfach unbeantwortet zu lassen bis das Produkt zur Auslieferung bereit ist.

 

[usernamehere]

Hab eigentlich fest mit dual-3D-Cache gerechnet und bin doch etwas verwundert.
Bin auch mal gespannt, wie lange wir eigentlich noch 6/8/12/16 Kerne bei AMD sehen, immerhin hat sich da seit Zen 1 nicht wirklich etwas getan - wenn man mal von den Ryzen 9 bzw. dem Wegbrechen der TR-CPUs absieht.
Ein paar Kerne extra hätte ich schon manchmal gerne, der nächste Schritt wäre hoffentlich dann mal 10 oder 12 Kerne pro CCD, wenn AM6 kommt.

 

[Faust2011]

Und die Scheduler-Problematik wäre dann sowieso Geschichte, welche ja das Hauptärgernis ist.

Du meinst, wenn beide ComputeDies jeweils mit einem X3D-Cache versehen sind, dann ist der Scheduler fein raus? Das glaube ich nicht, außer:

• die auszuführende Software ist komplett single-threaded
• per Zufall wird derselbe (Software)Thread immer auf denselben Core (bzw. einer der Cores im gleichen CCDs) zugewiesen

In allen anderen Fällen (und das ist dann eigentlich die Regel) muss der Scheduler die Threads in gewisser Weise sticky machen, also gewissen Cores der CPU zuweisen (und kann es nicht total beliebig machen).

 

[lutzlustig]

Wie die Zeit vergeht, schon Zen5. Ich dümpel noch mit meinen Zen+ Threadripper (2950X) rum und bedanke mich immer noch bei AMD, das die einen damals so im Regen stehen ließen und keine Update mehr anboten. Aber die Features von so einem Board sind einfach toll. Müsste bei Upgrade Abstriche machen oder massiv drauf legen. Aber momentan reicht mir die Leistung noch.