AMD - Zen 5 (3/4 nm, 2024) [Archiv] - Seite 4

Archiv verlassen und diese Seite im Standarddesign anzeigen : AMD - Zen 5 (3/4 nm, 2024)

basix

2023-04-07, 11:39:22

https://youtu.be/SupjLqPbFpY?t=2540

Aus dem Video etwas früher:
https://youtu.be/SupjLqPbFpY?t=2022

Raja joins Tenstorrent board --> Die AI-Bude, wo Jim Keller werkelt

Interesting. Jim scheint jedenfalls viel von Raja zu halten :) Das haben auch schon frühere Aussagen von Jim so ausgestrahlt

Edit:
Tenstorrent hatte gestern ein Live-Event ...

siehe: https://www.youtube.com/@tenstorrentinc/streams

und da wurde eine äußerst interessante Folie gezeigt:

Man gibt die Core Performance von Zen 5 mit +30% ggü. Zen 4 Core an.

Die Tenstorrent CPU in dem Beispiel sind 20% schneller als Zen 4 und keine 10% langsamer als Zen 5. Damit wäre man hinsichtlich Performance wie auch IPC (Zen 5 mit ~4 GHz, Tenstorrent mit ~3.8 GHz) sehr nahe dran mit ihrem RISC-V Core

Und da die Folie von Jim Keller stammt, hat sie eigentlich relativ viel Credibility.

latiose88

2023-04-07, 12:22:25

Ich könnte mir in Zukunft auch bei amd z. B 16 Kerner big cores und keine kerne extra vorstellen so das es dann 24 Kerne mit smt dann 40 threads sind. Ich komme ja mit wenig l3 cache zurecht. Aber zwischen 16 und 32 l3 cache gab es sehr wohl nen leichten unterschied. So riesig war er jedoch nicht gewesen. Hier könnte das verkleinern durchaus OK sein. Wenn man also wo anderst stärkt dann gleicht man das ja wieder aus.

Kein Wunder also das in gewissen Maße die e Kerne was gerbracht hatten. Habe eine sehr geringe missrate und eine sehr gute Hitrate bei meinem intensiven Programm. Es verwendet mehr intensive die Kerne als den Cache.
Siehe also l1 zu l2 cache. Darum merke ich ja erst bei 16 MB l3 anstatt 32 MB l3 cache nen kleinen Einbruch bei der leistung. Dürfte so um die 1-2 % leistungseinbruch sein.

Wenn man also sehr stark von l3 abhängig wäre, würde der einbruch deutlich stärker sein. Ich bin also echt auf die Zen 4c gespannt wie da so die leistung sein wird. Merke ich da keinen einbruch dann ist das Bild davon sehr eindeutig. Ich hatte immer den Fehler gemacht cache zu viel Bedeutung zu zu sprechen. Scheinbar müssen die Kerne auch hinter her kommen. Es bringt also nix wenn der Cache so groß ist. Weil dann können diese es ja nicht mehr füllen um den Vorteil davon zu haben. Ab wieviel missrate kann man von cache sagen das man davon profitiert hätte. Auf jedenfall fast Richtung Null 0 % ist es gewiss dann eindeutig.
Ich habe jedoch nur den l1 zu l2 missrate getestet. Nicht jedoch den l3 missrate. Wäre mal interessant wo es ne bremse gibt.
Und ob bei so einer missrate ne Erhöhung des cache dem entgegen bringen kann.
Bei einer hohen ist ja klar das die kerne nicht die volle Leistung entfalten können. Bei ner kleinen missrate machen sie schon das was sie können. Dann ist es wohl klar die Kerne sind nicht stark genug.

Warum aber trotz sehr geringer missrate der kerntakt nicht so viel mehr Leistung herausgeholt werden kann verstehe ich allerdings nicht so. Bei Zen 4 sieht es ja da schon anderst aus. Da scheint diese wohl auf hohen takt ausgelegt zu sein. Darum ist da der Gewinn an Leistung sehr viel stärker als der takt gegeben hatte.

Bei Zen 5 erwarte ich da eine noch größere Steigerung. Vielleicht geht da ja noch 400 MHz merk allcore takt. So das dann 5,5 anstatt 5,1 GHz. Das wird meiner Anwendung freuen.

Da merkt man dann wenn takt doch was bringt das es dann nicht durch den Cache limitiert geworden war.
Schade das man das nicht selbst ausprobieren kann, in dem man cache abschaltet zum testen ob die Anwendung davon wirklich profitiert oder nicht und dann noch mal auf die missrate schauen wie stark diese steigt.

Nun ja um das zu testen zu können, müsste man dann mit bauswiese getrennte Funktion einbauen. Soweit ist aber noch keiner der hersteller. Auch interessant wie hoch diese missrate bei Intel so wäre.

CrazyIvan

2023-04-07, 12:40:07

Naja man kann Kerne auf Effizienz für verschiedene Betriebsbereiche trimmen. Zen ist effizient im Bereich von vielleicht 2-10W pro Core. Darunter und darüber sinkt die Energieeffizienz. Entsprechend ist es natürlich eine Auslegungsfrage für welchen Bereich man effizient sein sill. Universell geht das nicht.
Die E Cores Bei Apple sind dann wahrscheinlich besonders energieffizient zwischen ein paar hundert mW und 1-2 tausend mW pro Kern. Also weit genug weg gespreizt von den P Cores.
Das ist sicherlich gerade für Backgroundtasks energieeffizient. Für mibile ideal.
Naja mal abwarten ob Zen 5c mehr Unterschied zu Zen 5 zeigt als Zen 4 zu 4c. :)
Erst einmal sollten wir mal abwarten, wie Bergamo und PHX2 sich so zu Raphael, Phoenix und Genoa verhalten.

Und dann kennst Du ja meine 1001 Energieeffizienzmessungen:
Mein Renoir R7 4700U ohne SMT läuft mit 12w cTDP unter CB23 am effizientesten. Das sind 1,5w pro Kern, und da ist sogar noch der uncore mit drin.

83396

amdfanuwe

2023-04-07, 12:59:11

Ja, in meinen Augen wird V-Cache bei AMDs BIG-Cores in der Zukunft Standard,
Seh ich nicht so.
Von V-Cache profitieren nicht alle Applikationen. Da wird AMD auch weiterhin diversifizieren und CPUs mit und ohne V-Cache anbieten.

Zudem wird der V-Cache auch nicht mehr so einen großen Performance Zuwachs bringen, wenn im I/O schon ein IF$ vorhanden ist.

robbitop

2023-04-07, 13:01:52

Erst einmal sollten wir mal abwarten, wie Bergamo und PHX2 sich so zu Raphael, Phoenix und Genoa verhalten.

Und dann kennst Du ja meine 1001 Energieeffizienzmessungen:
Mein Renoir R7 4700U ohne SMT läuft mit 12w cTDP unter CB23 am effizientesten. Das sind 1,5w pro Kern, und da ist sogar noch der uncore mit drin.

83396
Ja aber ich würde wetten, dass Apples E Kerne da nochmal ein ganzes Stück drunter liegen.

Zudem wird der V-Cache auch nicht mehr so einen großen Performance Zuwachs bringen, wenn im I/O schon ein IF$ vorhanden ist.
Den muss man wie gesagt erstmal hinbekommen. Die jetzigen L3 Caches schaffen ~10 ns bei 96 MiB. Sobald das aus dem die rauswandert, wird es deutlich langsamer. Muss man mal sehen ob AMD das in absehbarer Zeit macht. Wäre zunächst mal ein downgrade.

basix

2023-04-07, 13:29:45

10ns für einen so grossen Cache sind extrem gut. Wäre interessant, wie das mit zusätzlichen Stapeln so aussehen würde.

amdfanuwe

2023-04-07, 14:11:35

Den muss man wie gesagt erstmal hinbekommen. Die jetzigen L3 Caches schaffen ~10 ns bei 96 MiB. Sobald das aus dem die rauswandert, wird es deutlich langsamer.
Klar wird das bisher deutlich langsamer, da dann ein RAM Zugriff fällig wird.

Wieviel langsamer wird es durch eine Zugriff aufs I/O? 10 Zyklen, 2ns mehr?
Habs mal versucht einzuzeichnen:
83397
Ist ja auch die Frage, wieviel IF$ im I/O verbaut wird, 16MB pro SI ~20mm² mehr oder geht AMD in die vollen und spendiert jedem SI 64MB?
Vielleicht auch stacked Option auf dem I/O?
Zumindest sollte IF$ auf dem I/O billiger sein als gestackter V-Cache.
Zudem hat AMD ja immer noch die Möglichkeit zusätzlich L3 V-Cache zu stacken.

Also von daher denke ich nicht, dass bei ZEN5 jeder CCX einen fetten L3 bekommt.

Edit: Quelle des ursprünglichen Bildes:
https://chipsandcheese.com/2022/11/08/amds-zen-4-part-2-memory-subsystem-and-conclusion/

amdfanuwe

2023-04-07, 14:21:30

10ns für einen so grossen Cache sind extrem gut. Wäre interessant, wie das mit zusätzlichen Stapeln so aussehen würde.
Sind immer noch 50 Zyklen bei 5GHz.
Bei 3GHz sind es dann ~16ns.

latiose88

2023-04-07, 14:37:14

also sind weniger Zyklen wie 16 ns schneller als mit mehr.Irgendwann kommt der Punkt wohl das es nicht mehr weniger Zyklus werden.Naja man kann es halt nicht unendlich steigern.

Der_Korken

2023-04-07, 14:40:15

Ich finde die 96MB 3D-L3-Cache mit 10ns sind ein lokales Optimum, das mit der aktuellen Architektur erreicht wird. ich glaube nicht, dass der Nachfolger diese Konstruktion in allen Punkten schlagen muss, weil sich die Anforderungen auch mit der Zeit verschieben.

Conroe hatte einen 4MB L2-Cache mit irgendwas um die 15 Takte Latenz, den sich beide Kerne geteilt haben. Mit Penryn hatte man sogar auf 6MB erhöht. Der Nachfolger Nehalem sah auf den ersten Blick deutlich schlechter aufgestellt aus. Der L2 hatte nur noch 256kB bei immernoch 11 (oder 12?) Takten Latenz und der L3 war mit 8MB kleiner als die 2x6MB der vorigen Quadcores und hatte zudem mehr als doppelt so viel Latenz (irgendwas >30 Takte, zudem in der langsameren Uncore-Domain). Trotzdem war Nehalem der überlegenere Prozessor. Bei Dualcore-Last lief Penryn natürlich weiterhin gut durch den schnellen L2, aber je mehr die Multicore-Anforderungen stiegen, desto mehr ist Nehalem davongezogen. Ich erinnere mich da an Benchmarks von dargo, der mit seinem Core 2 Quad in CPU-limitierten Szenen ca. 60% Speedup von 2C auf 4C gemessen hat und daraus gefolgert, dass das gebenchte Spiel nur zu 60% von den zusätzlichen Kernen profitiert. Später hatte er einen Nehalem gebencht und im selben Spiel 80-90% Speedup, einfach weil die Architektur viel besser skaliert hat.

Natürlich hatte Core 2 seine eigenen Baustellen, z.B. den externen Speichercontroller und den lahmen FSB als Die-to-Die-Verbindung. Trotzdem können da schon Parallelen entstehen, wenn man sich die neuen X3D-Modelle anschaut. Solange alles in 8 Kerne passt, ist der 7800X3D der King, genauso wie ein 7700K von Intel der King der Quadcores war. Der 7900X3D ist in Spielen langsamer als der 7800X3D, weil 6 "schnelle" Kerne offenbar mittlerweile zu wenig sind und getrennte Caches viel Performance kosten. Sobald 8 Kerne nicht mehr reichen, wird auch ein 7950X3D aus dem gleichen Grund nicht gut aussehen. Entweder stackt man langfristig auch Cache auf den zweiten CCD oder man vergrößert die CCDs, sodass alle Workloads immer auf ein CCD passen.

Oder man verändert den Ansatz und verschiebt den Cache auf den IOD. Man verliert bei der Latenz die Zeit, die man braucht um einen Cache-Miss im lokalen L2 bis zum L3-Controller auf dem IOD zu schieben:

Vorher: L1-Query, L2-Query, L3-Query
Nachher: L1-Query, L2-Query, Die-to-Die-Latenz, L3-Query.

Man darf nicht den Fehler machen und denken, dass man erst nach 10ns aus dem CCD raus kommt. Wenn dort kein L3 mehr ist, muss dort auch keine Zeit aufgewendet werden ihn zu durchsuchen. Und der L3 auf dem IOD würde - da man ihn quasi 1:1 kopieren könnte - auch nicht mehr Zeit brauchen als der aktuelle L3 auf dem CCD. Wenn man jetzt die Verbindung zwischen L2 und L3 maximal auf Latenz optimiert, fände ich es nicht abwegig wenn man irgendwas um die 20-24ns schafft. Ja, das ist langsamer als 10ns, aber sind auch keine 30-40ns. Dafür hat man einen Ansatz der mit beliebig vielen CCDs skaliert, den ich mit mehr Cache-Stacks auch global hochskalieren kann und der die Cache-Redundanz minimiert.

CrazyIvan

2023-04-07, 14:49:32

@robbitop
Ja, auf jeden Fall. AMD kann bei Zen4c froh sein, hinsichtlich Effizienz an die großen Apple Mx Kerne ranzukommen.

@amdfanuwe
Du hast IMHO eine etwas romantische Vorstellung vom IF-Cache im Hinblick auf CPUs. Bei GPUs funktioniert das deshalb so gut, weil die deutlich sensibler auf Bandbreite und deutlich weniger sensibel auf Latenz reagieren. Bei CPUs ist der Latenzunterschied zwischen V-Cache und IF-Cache im IOD schon brutal. Und das Thema Bandbreite ist auch nicht so ganz zu verachten bei derzeit nur 64/32 GByte/s via IFoP.

basix

2023-04-07, 16:57:13

Sobald man weiss, dass die Daten nicht im privaten L2$ liegen, weiss man in welchem Slice des L3$ es sein muss. Ob das auf dem selben Die ist oder nicht spielt keine Rolle. Das ist bereits heute bei Zen 2-4 so, dass man auf den Remote L3$ zugreifen kann. Nur bringt das fast nichts hinsichtlich Performance.

Deswegen sollte ein direkter CCD <-> CCD Link die Situation deutlich beschleunigen. Sagen wir mal 5ns Penalty für den Remote L3$:
- 2ns fürs off-chip Interface, (2x da hin und zurück)
- 1ns zusätzlicher Overhead (z.B. zusätzliche Logik, grössere Gesamtmenge des Caches)

CCD1 -> CCD2 -> CCD1 ist immer noch viel besser als heute mit CCD1 -> IOD -> CCD2 -> IOD -> CCD1 oder CCD1 -> IOD -> DRAM -> IOD -> CCD1

@amdfanuwe
Du hast IMHO eine etwas romantische Vorstellung vom IF-Cache im Hinblick auf CPUs. Bei GPUs funktioniert das deshalb so gut, weil die deutlich sensibler auf Bandbreite und deutlich weniger sensibel auf Latenz reagieren. Bei CPUs ist der Latenzunterschied zwischen V-Cache und IF-Cache im IOD schon brutal. Und das Thema Bandbreite ist auch nicht so ganz zu verachten bei derzeit nur 64/32 GByte/s via IFoP.

Aus meiner Sicht wäre LLC im IOD nur folgend sinnvoll:
1. 3D Stacking
2. Kurzes und breites Die-to-Die Interface (ähnlich GCD -> MCD bei N31)

3D-Stacking halte ich aus Skalierbarkeits- und Kostengründen für ausgeschlossen. Konstrukte wie MI300 und Meteor Lake zeigen zwar dass es geht, aber Aufwand / Ertrag stimmt hier nicht. Zumindest für Zen 5. Was in 5 Jahren dann sein wird, ist ein anderes Thema.
Ein kurzes und breites Die-to-Die Interface wäre eher denkbar. Das wäre aber Desktop/Mobile only. Bei Server würde das die Skalierbarkeit limitieren. Da wäre sowas wie bei MI300 deutlich vorteilhafter.

Wenn ich diese beiden Lösungen anschaue, scheint mir ein direktes CCD <-> CCD Interface simpler und kostengünstiger skalierbar

Complicated

2023-04-07, 17:08:48

latiose88

2023-04-07, 17:11:27

ja schon nur wie breit kann man es denn maximal so noch machen.Da ist halt der Platz auch irgenwann mal der Limiterende Faktor wie ich finde.

amdfanuwe

2023-04-07, 18:05:08

Bei CPUs ist der Latenzunterschied zwischen V-Cache und IF-Cache im IOD schon brutal. Und das Thema Bandbreite ist auch nicht so ganz zu verachten bei derzeit nur 64/32 GByte/s via IFoP.
Dann leg doch mal Zahlen auf den Tisch.
Das IFoP muss derzeit ja auch nicht schneller sein als der RAM.

Nightspider

2023-04-07, 21:36:46

Selbst zwischen Ryzen 3300X und 3100 lagen teils schon 15 bis >20% in latenzkritischen Spielen, obwohl die Kerne sogar noch auf dem gleichen Chip saßen.

https://pics.computerbase.de/9/2/6/9/0/12-1080.7a3f1958.png

Bei der aktuellen Architektur würde es massig Leistung in Spielen kosten den L3 in den IO zu schieben.
Wenn dann müsste AMD die komplette Architektur umbauen und den Cache im IO nur als weitere Ebene der Speicherhierarchie umsetzen.

Wenn die Core Chiplets direkt auf Cache gestacked werden würden, könnte an die Latenz aber noch sehr niedrig halten.

10ns für einen so grossen Cache sind extrem gut. Wäre interessant, wie das mit zusätzlichen Stapeln so aussehen würde.

Da sich die Wege quasi nicht verlängern würden (wir sprechen hier von vielleicht 1mm), dürften die Latenzen kaum steigen, wenn man 1-2 weitere V-Cache lagen stapelt.

basix

2023-04-07, 21:51:48

Wird eher die Latenz für den zusätzlichen Verwaltungsaufwand sein. Signallaufwege eher weniger.

amdfanuwe

2023-04-07, 22:09:46

Selbst zwischen Ryzen 3300X und 3100 lagen teils schon 15 bis >20% in latenzkritischen Spielen, obwohl die Kerne sogar noch auf dem gleichen Chip saßen.

Ist doch kein Wunder. Wenn die L3 Caches ihre Daten nicht direkt abgleichen können, findet das halt über den Umweg DRAM statt. Da ist es egal, ob die CCX im selben Die sitzen oder eigene Dies haben.

Wenn dann müsste AMD die komplette Architektur umbauen und den Cache im IO nur als weitere Ebene der Speicherhierarchie umsetzen.

Genau so. IF$ = L4 LLC
Dazu breitbandigere Anbindung und die anderen Caches entsprechend angepasst.

CrazyIvan

2023-04-07, 22:43:54

Dann leg doch mal Zahlen auf den Tisch.
Das IFoP muss derzeit ja auch nicht schneller sein als der RAM.

Habe ich die nicht gerade genannt? Sämtliche 1 CCD Zen4 SKUs sind faktisch nicht in der Lage, DDR5 6000 voll auszureizen, weil der IFoP gar nicht die Brandbreite von MC zu CCD darstellen kann.
Bei EPYC gibt es für <=4 CCD SKUs den Wide Mode, der zwei IFoP Ports pro CCD verwendet und dadurch die Bandbreite (und auch den Verbrauch) verdoppelt. Aber da reden wir auch von 12 Kanal DDR5.
Der L3 hat IIRC ca. 2,5 TByte/s Bandbreite - also knapp Faktor 50 mehr - und zusätzlich um mehrere Größenordnungen geringere Latenz, als sie ein IOD-angebundener Cache hätte. Und ja, mit Advanced Packaging wie Infinity Fan-out Links ist einiges möglich. Aber den V-Cache macht man damit sicher nicht obsolet - und das war ja wohl eingangs Dein Gedanke, wenn ich das so richtig verstanden habe.

amdfanuwe

2023-04-08, 00:40:02

und zusätzlich um mehrere Größenordnungen geringere Latenz, als sie ein IOD-angebundener Cache hätte.

Das ist eben keine Zahl.
Faktor 50 ist L3 zu DRAM.
Größenordnungen geringere Latenz hat der DRAM sicherlich, aber warum sollte ein Cache im I/O so lahm sein?
Ein paar Hops mehr, evtl. etwas geringere Bandbreite wegen IF-Link Anbindung, aber doch keine Größenordnungen geringere Latenz.

Nach diesem Bild ist es Faktor 8 zum I/O Die. Im Wide Mode nur noch Faktor 4.
83403
Und mit Fast FanOut Links wie bei RDNA3
83404

ist man bei 2304/6 = 384B/CLK
Ist mehr als der L3 an die 8 Kerne liefert.

Man braucht den großen L3 ja auch, damit nicht alle Kerne gleichzeitig auf den langsamen RAM zugreifen.
Mit weiteren Cache im I/O wird das halt entschärft.

Aber den V-Cache macht man damit sicher nicht obsolet - und das war ja wohl eingangs Dein Gedanke, wenn ich das so richtig verstanden habe.
Da hast du mich falsch verstanden.
Ich meine die ganze Zeit nur, dass IF$ zusätzlich im I/O kommt und dadurch L3 was kleiner ausfallen könnte. Das V-Cache zusätzlich möglich ist habe ich mehrmals geschrieben.

robbitop

2023-04-08, 06:41:24

Die Frage ist: wozu ein weiterer L4 Cache bei diesem riesen L3 Caches wird man zusätzlich sicherlich kaum nich Hitrate gewinnen. Deminishing returns. Ggf ist diese direkte Verschaltung von 2 ccds (aber hoffentlich low latency - also extra ifop + räumlich näher zusammen + moderner interconnect wie info-r) sinnvoll weil sie den nutzbaren L3 für das Silizium fast kostenfrei versoppelt. Wahrscheinlich mit einem Latencystep ab dem Punkt wo man den ccd verlässt. Sehr pragmatisch.

CrazyIvan

2023-04-08, 07:26:47

@amdfanuwe
Ich bin da bei robbi. Diese paarweise Verbindung hat möglicherweise einen größeren Charme - vielleicht ist aber auch das bereits zu kompliziert gedacht: Betrachtet man local-L3 + remote-L3 als eine Cache-Stufe, dann verschlechtert das die Latenz des lokalen dramatisch. Betrachtet man den remote-L3 als L4, dann muss man die Sinnfrage stellen, weil der ja nur die selbe Größe besitzt, wie der lokale L3.

Ich habe noch einmal versucht, mir ein paar Zahlen zu vergegenwärtigen:
Laut TPU-Review (https://www.techpowerup.com/review/amd-ryzen-7-7800x3d/6.html) hat der L3 des 7800X3D eine Bandbreite von knapp 700 GByte/s in beide Richtungen. Die 2,5 TByte/s aus dem Kopf waren tatsächlich L1. Nichtsdestotrotz ist das Faktor 10 der IFoP-Bandbreite in Lese- und Faktor 20 in Schreibrichtung.

Ja, die Bandbreite kann man mit InFO-R und Co. massiv aufbohren - allerdings muss das auch einen Nutzen bringen. Ich persönlich glaube da noch nicht so dran. Zwar wird etwas in der Art als Nachfolge des IFoP kommen - aber vielleicht eher in Richtung 256 GByte/s, um für künftige RAM-Generationen gewappnet zu sein. Die Cache-Lokalität ist in meinen Augen eine der ganz großen Stärken von AMDs Architektur.

Bezüglich Latenzen:
Der L3 ist bei 13ns. Was für eine Latenz hätte ein hypotethischer IF-Cache auf dem IOD?
Man kann sich als Referenz vielleicht RDNA3 hernehmen? Hier kommt CnC (https://chipsandcheese.com/2023/01/07/microbenchmarking-amds-rdna-3-graphics-architecture/) auf brutal schlechte Werte von 180ns bei N31 - siehe Bild unten.
Das ist jedoch vermutlich nicht ganz fair. Schaut man sich die Core-to-Core Latency des Anandtech-Reviews zum 7950X (https://www.anandtech.com/show/17585/amd-zen-4-ryzen-9-7950x-and-ryzen-5-7600x-review-retaking-the-high-end/10) an, dann sind das ca. 80ns. Die Hälfte davon wären also 40ns, um im IOD zu landen. Da haben wir aber noch keine Zyklen verbraucht, um den Cache auch tatsächlich zu durchsuchen. Ab da kann man nur noch spekulieren, ob das mit InFO-R viel schneller wäre - aber selbst 30-40ns Latenz ist dann ein Bereich, der einer CPU nicht mehr so wahnsinnig viel nützt.
Und dann braucht man einen IF-/L4-/LL-Cache, der mindestens Faktor 2-4 größer sein sollte als der lokale, um überhaupt etwas zu bewirken. Also 400 MByte auf dem IOD - ich weiß ja nicht...

/edit:
Achja, und das ganze Nicht-CCD-Cache-Gedöns bringt ja überhaupt nur bei SKUs >1 CCD (und iGPU) etwas - das ist aus AMDs Sicht schon wieder Nische und damit den ganzen Ziehauf vermutlich nicht wert.

83405

iamthebear

2023-04-08, 11:27:35

Das Problem, was ich bei der direkten Dual CCD Verbindung sehe ist, dass der Markt dafür relativ klein ist:
.) Der Großteil des Clientmarktes hat nur 1 CCD und hierfür ist der L3 aktuell perfekt so wie er ist.
.) Der Großteil des Servermarktes (zumindest der Teil bei dem AMD gerade eine Chance hat) hat mehr als 2 CCDs. Da hilft die Lösung auch nicht weiter.

Die 12/16 Kerner sind aktuell nur eine relativ kleine Nische. Das mag sich in Zukunft ändern aber dann wird AMD bei Zen6 vermutlich auch auf 12 Kerne pro CCD gehen.

basix

2023-04-08, 12:02:07

Das wird dann eher so aussehen:
https://www.researchgate.net/figure/a-Top-view-of-the-evaluated-25D-multi-core-system-with-a-64-core-CPU-chip-in-the_fig2_280534413
https://www.researchgate.net/profile/Ajaykumar-Kannan/publication/280534413/figure/fig2/AS:669002925887498@1536514135916/a-Top-view-of-the-evaluated-25D-multi-core-system-with-a-64-core-CPU-chip-in-the.png

Bei Desktop würde ich auf InFO-R mit max. 2 CCDs tippen. Da braucht es das komplizierte Routing Netzwerk gar nicht.

Wenn man aber mehr CCDs verschalten will, EPYC wäre so ein Beispiel, dann könnte man sich sowas überlegen. Interposer und 2.5D Stacking generiert allerdings einiges an Mehrkosten und die Flexibilität / Skalierbarkeit wird etwas eingeschränkt. Man müsste je nach Core Count andere Interposer auflegen oder viel Dummy Silicon bestücken.

EPYC als MCM Package ist hinsichtichlich Skalierbarkeit einfach genial. Bleibt man auch dort bei InFO-R und max. 2x CCDs als Gruppe, hat man trotzdem eine schöne Steigerung der Core Cluster Grösse, ohne die Skalierbarkeit auf Package-Ebene zu beeinträchtigen.
- Zen 2 = 4C
- Zen 3 = 8C
- Zen 4 = 8C
- Zen 5 = 2*8 = 16C
- Zen 6 = 2*(8...16) = 16...32C --> (mehr Cores pro CCD/CCX? Dual-8C-CCX auf dem CCD und dann 4x CCX pro 2er CCD-Gruppe verbunden?)

Der letzte Punkt hinsichtlich Zen 6 könnte noch interessant sein. Wenn AMD bei Zen 5 ein direktes CCX <-> CCX Interface etablieren sollte, ist das mMn auch auf einem einzelnen CCD umsetzbar (mit sogar verbesserten Performance Metriken). Damit könnte man bei Zen 6 die Core Anzahl verdoppeln, ohne die Anzahl Cores innerhalb eines CCX anzuheben. Und ist dieses Interface skalierbar auf z.B. max. 4x CCX, kann man wiederum mit einer 2x CCD Gruppe arbeiten. Im Falle des von dir angesprochenen 2.5D Interposer Netzwerks könnte man ja auch auf N-CCX skalieren (mit einigen Performance-Nachteilen bei sehr vielen CCDs, da die Wege länger werden).

Prinzipiell ist ein direktes CCD <-> CCD Interface (oder besser gesagt CCX <-> CCX) auf viele Wege umsetzbar:
- on-Die
- InFO-R
- 2.5D Interposer

Das erlaubt eine nochmals variablere und höhere Skalierbarkeit, welche je nach Produktkategorie und Zen-Generation neu evaluiert werden kann. Und man erhält als Resultat eine CPU, die näher an einem monolithischen Chip arbeitet (was immer das Ziel ist bei Chiplets). Grundlage ist aber, dass man eine Mehrzahl von CCX direkt miteinander verschalten kann. mMn ist das sinnvoller als wie bei Intel die Cores uniform ans selbe Mesh anzutackern. 8-16C mit extrem kurzen Wegen und schnellem Cache, zum Rest braucht man etwas länger aber mit einem vereinfachten Netzwerk.

Die Frage ist: wozu ein weiterer L4 Cache bei diesem riesen L3 Caches wird man zusätzlich sicherlich kaum nich Hitrate gewinnen. Deminishing returns. Ggf ist diese direkte Verschaltung von 2 ccds (aber hoffentlich low latency - also extra ifop + räumlich näher zusammen + moderner interconnect wie info-r) sinnvoll weil sie den nutzbaren L3 für das Silizium fast kostenfrei versoppelt. Wahrscheinlich mit einem Latencystep ab dem Punkt wo man den ccd verlässt. Sehr pragmatisch.
So sehr ich die Idee mit einem gemeinsamen grossen LLC mag, so schwer ist die konkrete Umsetzung. Sobald man Off-Die gehen muss, entstehen automatisch erhöhte Latenzen. Und der schnelle L3$ ist einer der grossen Vorteile von Zen. Wenn man den L3$ komplett entfernt und in den IOD wandert, ist das ohne 2.5D/3D Stacking auch nicht sinnvoll. Datenlokalität und Energieverbrauch würden leiden. Genug Cache macht lokal einfach Sinn. Und da der L3$ ein Victim Cache ist (und vermutlich bleiben wird), sollten etwas zusätzliche Latenz für den Remote-L3$ (vielleicht nennt man das dann L3.5 oder L4 wie bei IBM) gar nicht so tragisch sein. Man hat auf die am meisten benötigten Daten immer noch kurze Zugriffswege im eigenen L3$. Was sicher schwierig sein wird:
- Management der Belegung - Wie viel Remote-Cache darf ein einzelnes Program überhaupt belegen, um nicht was anderes zu tangieren? Noisy Neighbour Problem
- Datenduplikationen möglichst vermeiden vs. Performance/Latenz - Heute werden vermutlich einige Daten in mehreren CCDs doppelt vorgehalten (ist das so?). Das könnte man per Zusammenschaltung vermeiden. Nur wird man eine Performance-Regression haben, wenn man auf den Remote-L3$ zugreifen muss.

Und ausserdem gibt es gar nicht so extrem viele Anwendungen, wo man von dem grösseren L3$ profitiert. Milan-X zeigt bei Datenbanken, HPC und CAD-Design einige grosse Sprünge. X3D primär in Spielen. Die meisten anderen Anwendungen sind mit den 32MB zufrieden. Kürzere Latenzen bei Core-to-Core Kommunikation sind sicher auch nicht schlecht. Aber wie viele Programme profitieren wirklich davon? Ist mir unbekannt.

Das Problem, was ich bei der direkten Dual CCD Verbindung sehe ist, dass der Markt dafür relativ klein ist:
.) Der Großteil des Clientmarktes hat nur 1 CCD und hierfür ist der L3 aktuell perfekt so wie er ist.
.) Der Großteil des Servermarktes (zumindest der Teil bei dem AMD gerade eine Chance hat) hat mehr als 2 CCDs. Da hilft die Lösung auch nicht weiter.

Die 12/16 Kerner sind aktuell nur eine relativ kleine Nische. Das mag sich in Zukunft ändern aber dann wird AMD bei Zen6 vermutlich auch auf 12 Kerne pro CCD gehen.
Da gebe ich dir komplett recht. Habe oben geschrieben, dass nur eine begrenzte Anzahl an Anwendungen von grösseren Clustern profitiert. Trotzdem gibt es sie und die aktuelle Topologie bei Zen 3/4 führt zu einigen Ineffizienzen wie zusätzliche Chipfläche für Interfaces & grosse Caches sowie Datenmultiplikation über mehrere CCDs.

Wie oben von mir beschrieben, geht es mMn in Richtung direktes CCX <-> CCX Interface, welche je nach Ausgestaltung auch 2-N CCX verbinden kann. On-Die wie auch Off-Chip. Wäre mMn die nächste Stufe der Skalierung vieler CCDs und man kommt damit näher an einen monolithischen Chip heran (Cache-Grösse, Core-to-Core Latenz, Datenduplikation). Der erste Schritt kann jetzt 2x CCD/CCX sein. Der nächste bei Zen 6 nochmals eine Verdopplung (z.B. 2*8 = 16C pro CCD). Und bei Zen 7 geht man dann auf noch grössere Cluster, evtl. via 2.5D. So sähe für mich diese Roadmap aus ;)

Habe gestern noch ein paar aktuelle Talks von Jim Keller auf YT angeschaut. Waren interessante Sachen dabei. Eine Aussage davon war, dass die Die-to-Die Interfaces sowie die Packaging Technologie nun an einem Punkt angelangt sind, wo sie mit relativ geringen Mehrkosten und ausreichend hoher Performance genutzt werden können. Soweit ich verstanden habe waren das so Sachen wie InFO-R und 2.5D (3D-Stacking ist noch eine ander Liga). Für Chiplets und die Verbindung mehrerer Chiplets optimal.

Complicated

2023-04-08, 13:04:08

Vielen Dank für deinen ausführlichen Beitrag. Du hast das gut zusammen gefaßt und ich stimme bis auf eine Ansicht mit dir überein. Wo wir unterschiedlich argumentieren ist bei den nächsten Steps. Während Du aus Desktop-Sicht spekulierst, so mein Eindruck:

Wie oben von mir beschrieben, geht es mMn in Richtung direktes CCX <-> CCX Interface, welche je nach Ausgestaltung ach 2-N CCX verbinden kann. On-Die wie auch Off-Chip. Wäre mMn die nächste Stufe der Skalierung vieler CCDs und man kommt damit näher an einen monolithischen Chip heran (Cache-Grösse, Core-to-Core Latenz, Datenduplikation). Der erste Schritt kann jetzt 2x CCD/CCX sein. Der nächste bei Zen 6 nochmals eine Verdopplung (z.B. 2*8 = 16C pro CCD). Und bei Zen 7 geht man dann auf noch grössere Cluster, evtl. via 2.5D. So sähe für diese Roadmap aus ;)

Ich spekuliere aus Serversicht und mit der Annahme, dass Desktop das nimmt was Server vorgibt, da die selben Chiplets genutzt werden sollen. Damit wäre deine Spekulation aus meiner Sicht eine Roadmap, die schon etablierte Servertechnik nicht als erste Synergie im Desktop nutzt. Da denke ich wird AMD den günstigeren Weg gehen für das Gesamtunternehmen, da auch die Xilinx XDNA Integration benötigt. Beide Ansätze zu verfolgen könnte kontraproduktiv sein und ich sehe hier ein "entweder oder".

CrazyIvan

2023-04-08, 13:18:55

@basix
Sorry, dass ich jetzt gar nicht auf jeden einzelnen Punkt Deines doch Recht langen und gleichermaßen schön zu lesenden Beitrags eingehe - aber ich sehe das in weiten Teilen wie Du.
Einen Punkt wollte ich doch noch einmal aufgreifen:

Und ausserdem gibt es gar nicht so extrem viele Anwendungen, wo man von dem grösseren L3$ profitiert. Milan-X zeigt bei Datenbanken, HPC und CAD-Design einige grosse Sprünge. X3D primär in Spielen. Die meisten anderen Anwendungen sind mit den 32MB zufrieden. Kürzere Latenzen bei Core-to-Core Kommunikation sind sicher auch nicht schlecht. Aber wie viele Programme profitieren wirklich davon? Ist mir unbekannt.

Gerade in dieser Disziplin hat ja SPR in der Theorie einen gigantischen Vorteil, mit seinem riesigen, kohärenten, unified L3 sowie Dank EMIB enorm breiten Core-to-Core-Connections. In der Praxis bleibt davon jedoch so gut wie nichts übrig. Deshalb haben auch CnC völlig zu recht die Frage gestellt, warum Intel hier so einen enormen Aufwand betreibt:
There’s really something to be said about working smarter, not harder. AMD avoids the problem of building an interconnect that can deliver high bandwidth and low latency to a ton of connected clients. This makes CCD design simpler, and let EPYC go from 32 cores to 64 to 96 without worrying about shared cache bandwidth.
https://chipsandcheese.com/2023/03/12/a-peek-at-sapphire-rapids/

Zu InFO-R bei ZenX hatte ich mal ein Gedankenspiel angestellt bzgl. Geometrien und Platz auf dem Package. Vielleicht findest Du das ja auch Recht spannend und hast vielleicht eine Meinung dazu (und sorry, falls ich das schonmal gepostet haben sollte):

83406

83407

Hier noch ein paar Randbemerkungen:

Als jeweilige Grundfläche habe ich nur genau die Bounding Boxen der bereits heute auf den Packages platzieren Dies verwendet.
Die Sizes entsprechen als Berechnungsgrundlage denen der aktuellen Generation.
Die angrenzenden Kanten sollten genug Beachfront für mindestens 256 GByte/s via InFO-RDL haben.
Dass der Server-IOD möglicherweise aus geflippten Zwillingen besteht, ist eine eher gewagte These.

basix

2023-04-08, 14:16:15

del

basix

2023-04-08, 14:20:17

Ich spekuliere aus Serversicht und mit der Annahme, dass Desktop das nimmt was Server vorgibt, da die selben Chiplets genutzt werden sollen. Damit wäre deine Spekulation aus meiner Sicht eine Roadmap, die schon etablierte Servertechnik nicht als erste Synergie im Desktop nutzt. Da denke ich wird AMD den günstigeren Weg gehen für das Gesamtunternehmen, da auch die Xilinx XDNA Integration benötigt. Beide Ansätze zu verfolgen könnte kontraproduktiv sein und ich sehe hier ein "entweder oder".

Jein ;)

Man würde schon die Servertechnik für Desktop übernehmen. Nur gehe ich davon aus, dass es zumindest bei Zen 5 eher auf InFO-R als auf 2.5D basieren wird. XDNA kann man damit immer noch realisieren:
- 1x Chiplet = Zen 5; 1x Chiplet = XDNA; verbunden via Die-to-Die Interface
- Zen 5 CLuster aus 2x CCD; XDNA Cluster aus 2x XDNA Chiplet; verbunden via IOD
- MI300 All-In Ansatz

Gerade in dieser Disziplin hat ja SPR in der Theorie einen gigantischen Vorteil, mit seinem riesigen, kohärenten, unified L3 sowie Dank EMIB enorm breiten Core-to-Core-Connections. In der Praxis bleibt davon jedoch so gut wie nichts übrig. Deshalb haben auch CnC völlig zu recht die Frage gestellt, warum Intel hier so einen enormen Aufwand betreibt:
https://chipsandcheese.com/2023/03/12/a-peek-at-sapphire-rapids/

Korrekt. Bei SPR sind allerdings alle Cores "uniform" angebunden. Und die Latenzen sind recht schlecht. 30ns L3$ Latenz? Das ist übel. SPR sieht mir nochmals deutlich stärker auf Vektor/Matrix-Performance ausgerichtet als noch SKL-X, wo die Latenz besser versteckt werden kann aber nach viel Bandbreite gefragt wird. Und nicht ohne Grund wird man bei Emerald Rapids auf 2x Die zurückgehen, damit man den nicht vorhandenen diagonalen Pfad zwischen den 4 Chiplets eliminieren kann:
https://www.computerbase.de/2023-03/intel-xeon-sierra-forest-mit-144-kernen-granite-rapids-mit-mcr-8800/

Bezüglich Die-to-Die Interface hat Ian Cutress die Zahlen von SPR:
- 5...8ns für die Tile-to-Tile Latency
- Das doppelte davon für den diagonalen Pfad
https://twitter.com/IanCutress/status/1500609374414417928?lang=de

Bei einer CCX Verbindung teilt man das Problem /8, da nur CCX miteinander vernetzt werden sollen und man nicht alle Cores verbinden muss. Das vereinfacht das Problem bereits enorm.

Zu InFO-R bei ZenX hatte ich mal ein Gedankenspiel angestellt bzgl. Geometrien und Platz auf dem Package. Vielleicht findest Du das ja auch Recht spannend und hast vielleicht eine Meinung dazu (und sorry, falls ich das schonmal gepostet haben sollte):

83406

83407

Hier noch ein paar Randbemerkungen:

Als jeweilige Grundfläche habe ich nur genau die Bounding Boxen der bereits heute auf den Packages platzieren Dies verwendet.
Die Sizes entsprechen als Berechnungsgrundlage denen der aktuellen Generation.
Die angrenzenden Kanten sollten genug Beachfront für mindestens 256 GByte/s via InFO-RDL haben.
Dass der Server-IOD möglicherweise aus geflippten Zwillingen besteht, ist eine eher gewagte These.

Natürlich finde ich das spannend ;)

Ist relativ elegant gelöst. Ich sehe Vorteile wie Nachteile:
+ Deutlich verkürzte Wege CCD <-> IOD
+ CCD <-> IOD ist vom Prinzip her identisch wie heute, einfach deutlich breiter angebunden und deutlich performanter
+ Bandbreite des Infinity-Fabrics im IOD kann sehr hoch ausfallen. Evtl. eine Art Ringbus, um alle CCDs zu verbinden.
+ Zentrales Kohärenz-Management im IOD anstatt ein 2-stufiges (direktes CCD <-> CCD Interface + CCD <-> IOD)
+ Kurze Wege zwischen allen CCD, fast uniform. Differenz zwischen CCD1, CCD2 und CCDn ist geringer
+ IO-Overhead minimiert. Beim CCD wie auch IOD. Die heutigen IFOP-PHY sind relativ fett
+ "Geflippter Zwilling" finde ich gar nicht so abwegig, siehe heutiges Zen 4 IOD (Floorplan, Die Shot) und auch den nächsten Punkt unten
+ Turin vs. Siena gleich gratis: 1x und 2x IOD. Who knows, evtl. ist das Siena IOD bereits dein Turin IOD (96x PCIe Lanes, 6x DDR5-Channels) --> Effizienter Einsatz von R&D und schnelle Time-to-Market für Zen 5
+ XDNA sehr simpel realisierbar. Anstatt ein Zen CCD wird einfach was anderes bestückt. Muss natürlich die gleichen oder zumindest ähnlichen Abmasse haben. Das sehen wir aber bereits bei MI300
+ Vermeidung von 2.5D Stacking
- Platzierung IO (DDR5, PCIe) wird etwas schwierig. PCIe könnte man gleich wie heute lassen aber wo platziert man DDR5? Die CCDs sind im Weg
- IOD mit relativ ungünstigem Seitenverhältnis, umso näher an einem Quadrat desto besser. Das kann man aber wohl optimieren, da sie eh etwas breiter sein werden als du sie gezeichnet hast. Und beim Desktop sind 2x CCD wohl genug
- 2x IOD anstatt 1x IOD wie heute. Bandbreite, Latenz, Kohärenz-Management, Verwaltung der CPU. Aber bereits heute ist bei Epyc das in 4-Quadranten aufgeteilt. Das würde vermutlich so bleiben oder könnte auf 2-Segmente verbessert werden (pro IOD ein Segment)
- Starke Abhängigkeiten von IOD und Chiplet Kantenlängen. Könnte dazu führen, dass man jede Generation ein neues IOD benötigt und auch die XDNA Tiles neu aufsetzen muss
- Bandbreite und Latenz (2x Hops) vermutlich geringer, als wenn man zwei CCDs direkt verbinden würde. Aber wie bereits angesprochen, evtl. gar nicht so tragisch, je nach Anwendung. Wenn ich die Zahlen von SPR sehe (siehe oben verlinkten Twitter Beitrag von Ian Cutress), könnte das sogar mit in etwa Icelake-X-SP Latenzen klappen (40-50ns)
- Shared Remote-L3$ wird durch die gestiegene Latenz deutlich unwahrscheinlicher oder zumindest weniger schlagkräftig. 10+15=25ns sind halt deutlich schlechter als 10+8ns = 18ns. Besser als nichts ist es aber schon ;)

Edit:
Ich habe noch ein anderes Konzept, wie man die CCD verbinden könnte und das DDR5-IO Problem nicht hätte. Verlangt aber nach einem zusätzlichen Chiplet und das IOD sowie das zusätzliche Chiplet wären zwischen Siena und Turin nicht transferierbar.
- DDR5 Channels gehn seitlich aus dem IOD raus, gleich wie heute
- Verbindung zwischen IOD und "XDNA Connect" muss die IFOP und PCIe Verbindungen bereitstellen. PCIe PHY wären dann auf dem "XDNA Connect" Chiplet. IFOP PHY benötigt man nicht mehr sondern deutlich kleinere für InFO-R

davidzo

2023-04-08, 15:02:53

Bei der aktuellen Architektur würde es massig Leistung in Spielen kosten den L3 in den IO zu schieben.
Wenn dann müsste AMD die komplette Architektur umbauen und den Cache im IO nur als weitere Ebene der Speicherhierarchie umsetzen.
Du denkst da zu sehr in festen Cache Hierachien. Die Grenzen der Hierachien verschieben sich ja mit der jeweiligen Kapazität. Es gibt z.B. überhaupt keinen Performancenachteil wenn der L3 plötzlich 30 statt 12ns ist und im I/O Die liegt, solange die on-Die Hitrate dieselbe ist.
Wenn der L2 wie spekuliert im ganzen CCX geshared ist und annähernd die hitrate liefert die im moment auf den L3 entfällt bleibt das ganze ein Nullsummenspiel. Und den Latenzzuwachs eines so großen L2s wird dann dadurch aufgefangen dass auch der L1 massiv anwächst. Und dessen Latenz wiederum wird kaschiert durch einen größeren ROB. Irgendwo müssen die N4 Transistoren ja hin, sonst wäre ein 8C DIE unter 30mm2 wenn man den L3 ausgelagert hat und hätte sicher nicht genügend fanout area.

Der L3 ist bei 13ns. Was für eine Latenz hätte ein hypotethischer IF-Cache auf dem IOD?
Man kann sich als Referenz vielleicht RDNA3 hernehmen?

Kann man nicht. Ein GPU Cache ist nicht auf Latenz sondern auf Bandbreite optimiert. Latenz war nie der Fokus, daher hinkt der Vergleich.

Ab da kann man nur noch spekulieren, ob das mit InFO-R viel schneller wäre - aber selbst 30-40ns Latenz ist dann ein Bereich, der einer CPU nicht mehr so wahnsinnig viel nützt.
Und dann braucht man einen IF-/L4-/LL-Cache, der mindestens Faktor 2-4 größer sein sollte als der lokale, um überhaupt etwas zu bewirken. Also 400 MByte auf dem IOD - ich weiß ja nicht...

Bei Broadwell waren es auch 40ns und trotzdem etwas gebracht, nicht nur für die GPU. Und das war nichtmal SRAM sondern lahmer EDRAM als MCM mit lächerlichen 50gb/s angebunden.
Ich halte 20-30ns mit advanced Packaging/UCIe für machbar bei einer Größe von 64-128mb ohne Stacking. Mit Stacking wären das dann 192-384mb + 10% mehr Latenz.
Als L4 wäre die Latenz höher weil sich hier die vorherigen Cachestufen addieren, also die Latenz des L3. Daher halte ich es eben für möglich dass hier keine zusätzliche Hierachie geaddet wird, sondern es sich um den L3=LLC handelt.

AMD hat schon angekündigt dass Zen5 ein breiterer Core wird der mehr ILP extrahieren kann. Mit mehr ILP geht in der Regel einher dass der Core weniger empfindlich bei der Cache-Latenz wird, da in der Regel proportional zu den Pipes und Decode width auch der ROB ausgebaut wird.
Da passt es nur ins Bild dass AMD diese Core-Veränderungen nutzt um jede einzelne Cache-stufe zu vergrößern (auf Kosten der Latenzen). Um den Compute DIE nicht anwachsen zu lassen und eine hohe Transistordichte in N4 zu realisieren ist der nächste logische Schritt dann den L3 auszulagern der momentan mehr als 50% der DIEfläche einnimmt und in N4 kaum noch weiter skaliert. Und zwar auf den billiger zu fertigenden i/o DIE. Da die Latenz bei diesem Schritt drastisch anwächst muss der L2 das bereits auffangen und wird riesig und geshared pro CCX. Der SRAM Anteil beim Zen5 CCX wird also weiter vorhanden sein, aber sich vielleicht eher in 60-Kerne/40-cache verschieben als aktuell.

So sehr ich die Idee mit einem gemeinsamen grossen LLC mag, so schwer ist die konkrete Umsetzung. Sobald man Off-Die gehen muss, entstehen automatisch erhöhte Latenzen. Und der schnelle L3$ ist einer der grossen Vorteile von Zen. Wenn man den L3$ komplett entfernt und in den IOD wandert, ist das ohne 2.5D/3D Stacking auch nicht sinnvoll. Datenlokalität und Energieverbrauch würden leiden. Genug Cache macht lokal einfach Sinn.

Genau, aber Datenlokalität kann auch der L2 übernehmen. Man sollte immer den Latenzverlauf als ganzes anschauen und nicht in festen cache Hierachien denken.

Und ausserdem gibt es gar nicht so extrem viele Anwendungen, wo man von dem grösseren L3$ profitiert. Milan-X zeigt bei Datenbanken, HPC und CAD-Design einige grosse Sprünge. X3D primär in Spielen. Die meisten anderen Anwendungen sind mit den 32MB zufrieden. Kürzere Latenzen bei Core-to-Core Kommunikation sind sicher auch nicht schlecht. Aber wie viele Programme profitieren wirklich davon? Ist mir unbekannt.

Bei einem breiteren Core wird vor allem mehr Bandbreite gebraucht um diesen zu füttern, gerade in HPC Anwendungen mit viel FP.

basix

2023-04-08, 15:11:12

Prinzipiell denken wir alle in die gleiche Richtung, nur mit verschiedenen Ansätzen:
- Datenlokalität und schnelle on-Die Caches sollen beibehalten werden
- LLC soll effizienter genutzt werden und im besten Fall unified sein. Und das bei möglichst geringer Latenz
- CCD-to-CCD Latenz und Bandbreite sollen verbessert werden

Ob das jetzt über CCD Grenzen hinweg shared L3$ sind (direkte CCD-to-CCD Verbindung oder via IOD), InFO-R/2.5D Ansätze oder vergrösserte L2$ mit IOD-LLC sind eigentlich egal. Die Ziele sind die selben ;)

Die konkrete Lösung wird von folgendem abhängen:
- Performance
- Energieffizienz
- Skalierbarkeit (Architektur, Packaging)
- Wirtschaftlichkeit
- Chiplet-Reuse

Und hier ist dann zumindest mein Problem: Ich kenne zwar die Kriterien, kann sie aber nicht quantifizieren. Deswegen kann es prinzipiell jede der vorgeschlagenen Lösungen sein.

CrazyIvan

2023-04-08, 15:11:12

Jein ;)
+ Turin vs. Siena gleich gratis: 1x und 2x IOD. Who knows, evtl. ist das Siena IOD bereits dein Turin IOD (96x PCIe Lanes, 6x DDR5-Channels) --> Effizienter Einsatz von R&D und schnelle Time-to-Market für Zen 5

Und genau das spekuliere ich insgeheim seit langem. Ich muss mir mal ein Wettbüro suchen, das mir für sowas eine Quote macht ;D
Was auch dafür spricht:
Dieser bereits InFO-R fähige Bergamo wird 1:1 auf MI300 verwendet (+ 2x ein weiteres, Custom-4c CCD).
Die Spekulation Zen5+Zen4c basiert darauf, dass die großen Kerne mit der nächsten Generation auf InFO-R wechseln, die kleinen aber ja erst viel später released werden. Somit kann man bereits auf den Vorgänger zurückgreifen.
Außerdem gibt die gesparte Energie am Interconnect Bergamo mehr Luft zum Atmen im TDP Rahmen.

- Starke Abhängigkeiten von IOD und Chiplet Kantenlängen. Könnte dazu führen, dass man jede Generation ein neues IOD benötigt und auch die XDNA Tiles neu aufsetzen muss

Japp. Bestimmt bleibt das IOD absehbar auf N-1, sodass sich die Maskenkosten in Grenzen hielten. Und das Design dürfte gar kein riesiger Aufwand sein, wenn die Basis einmal existiert.

Den Rest Deiner Einschätzung teile ich voll und ganz.

robbitop

2023-04-08, 15:11:36

CrazyIvan

2023-04-08, 15:20:27

Kann man nicht. Ein GPU Cache ist nicht auf Latenz sondern auf Bandbreite optimiert. Latenz war nie der Fokus, daher hinkt der Vergleich.

Weshalb ich ihn auch direkt im Folgesatz wieder kassiert habe. Aber den mochtest Du nicht mitzitieren ;)

Um den Compute DIE nicht anwachsen zu lassen und eine hohe Transistordichte in N4 zu realisieren ist der nächste logische Schritt dann den L3 auszulagern auf dem billiger zu fertigenden i/o DIE.
Genau, Cache raus aus dem CCD. Aber ich halte V-Cache als Quasi-Standard sowie optional mehr als eine Lage halt für wahrscheinlicher, als LLC@IOD. Aber ausschließen möchte ich das ganz explizit auch nicht.

CrazyIvan

2023-04-08, 15:24:02

@basix
Absolut.
Deswegen sind wir ja auch Armchair engineers ;D
Bewusste Inkompetenz und so.

basix

2023-04-08, 16:03:05

IMO gibt es doch gar keinen Handlungsbedarf bei den größeren Cache Stufen.

Wieso nicht? Milan/Genoa-X sowie X3D erhöhen die Kosten. CCD-to-CCD Kommunikation ist auch eher langsam. Und wenn die Cores immer schneller werden, erhöht das auch den Druck auf die zugrundeliegende Speicherinfrastruktur.

Wenn man mit der Basiskonfiguration mehr rausholen kann, dann ist das immer ein Vorteil. 3D V-Cache wird noch länger nur zu Premium-Preisen verfügbar sein.

Und dann noch folgende Punkte als Anregung:

Wenn man den LLC über mehrere CCDs sharen kann, könnte man dann evtl. nicht denn LLC pro CCD verrignern? Sagen wir mal 2MB/Core anstatt 4MB/Core? Wäre das kostenmässig bei den sehr teuer werdenden N3+ Prozessen sowie faktisch nicht skalierendem SRAM nicht ein wahnsinniger Vorteil? Bei einem 16C CCD mit 64MByte LLC wäre der Anteil von SRAM an der Die-Size riesig. 16C mit 32MByte wären deutlich balancierter.
Zen 5 soll die erste grosse Erneuerung seit Zen 1 sein. Deswegen wird dessen Basis bis mindestens Zen 7 bestehen bleiben. Da braucht man etwas, was die stärker werdenden Cores unterstützt, ohne dass die Kosten bei den teueren Nodes explodieren. Ein grösserer shared Cache mit allerdings weniger Cache hinsichtlich MByte/Core wären eine möglich Lösung des Problems
Gaming würde bei 32 -> 16 MByte LLC sicher leiden. Allgemeine Verbesserungen am Pre-Fetching, grösserer L2$(?) und eine deutlich verbesserte Speicherlatenz (sagen wir mal <50ns anstatt 60-70ns) aufgrund der InFO-R Links zwischen CCD und IOD könnten für eine Kompensation sorgen. Im Notfall noch X3D, wenn man den Gaming-King haben will (zu Premium Preisen wie heute)

robbitop

2023-04-08, 16:11:37

Klar, wenn man mehr rausholen kann - immer her damit. Wird aber wie gesagt mehr als schwer bei der schon fast kranken Mischung aus Größe und Latenz.

Ja wenn man 2x CCDs schnell verschalten kann und damit sagen wir mal ab dem Zugriff auf dem L3 des anderen CCDs bei Mitte 20 ns landet, wird das schon nochmal dölller. Aber wahrscheinlich im Endergebnis kaum noch besser weil deminishing returns. ;)
Aber ja obiges könnte man einfach mitnehmen. Das wäre auch eher eine Art "double down" auf dem bestehenden Konzept als eine Änderung.

amdfanuwe

2023-04-08, 16:14:41

Bezüglich Latenzen:
Der L3 ist bei 13ns. Was für eine Latenz hätte ein hypotethischer IF-Cache auf dem IOD?
Man kann sich als Referenz vielleicht RDNA3 hernehmen? Hier kommt auf brutal schlechte Werte von 180ns bei N31 - siehe Bild unten.
Das ist jedoch vermutlich nicht ganz fair. Schaut man sich die Core-to-Core Latency des Anandtech-Reviews zum 7950X (https://www.anandtech.com/show/17585/amd-zen-4-ryzen-9-7950x-and-ryzen-5-7600x-review-retaking-the-high-end/10) an, dann sind das ca. 80ns. Die Hälfte davon wären also 40ns, um im IOD zu landen.

Hey, danke, Das Bild mit der Cache Latenzy zum RDNA3 war mir noch nicht bekannt. Hab ich wieder was zu kauen.
Bei der Core-to-Core sind die 80ns doch der DRAM Zugriff.
Der Test funktioniert doch folgendermaßen:
Core x schreibt einen Wert und Core x+n liest diesen.
Bei Core 0 auf Core 1 sind es ~6,6ns, weil die Daten in L2
Core x auf Core y im gleichem CCX ~17ns, Daten im L3
Core x auf Core z in anderem CCX ~77ns, Daten im DRAM
Sieht man auch schön beim 3950X mit 4 Core CCX, da war L3 noch deutlich langsamer.
https://images.anandtech.com/doci/16214/CC3950X.pnghttps://images.anandtech.com/doci/16214/CC3950X.png
Du landest also mitnichten nach 40ns im I/O sondern im DRAM.
Bei einem Cache im I/O entfiele die ganze RAS, CAS und die 16 Takte Übertragungszeit für den Zugriff auf den DRAM.

basix

2023-04-08, 16:15:42

@robbi:
Wie gesagt, ob 2x CCD direkt verschalten oder so wie von CrazyIvan dargestellt alle CCDs deutlich näher ans IOD bringen sind verschiedene Lösungsansätze fürs gleiche Problem. Inkl. unterschiedlicher Vor- und Nachteile.

Ich denke aber es macht zu 100% Sinn, die bestehende LLC-Kapazität effiziener auszunutzen. Ist einfach ein Kostenthema bei den neueren Nodes. V-Cache geht zwar immer, allerdings ist das ebenfalls mit Zusatzkosten verbunden, auch wenn es in N6 gefertigt würde.

robbitop

2023-04-08, 16:22:57

davidzo

2023-04-08, 16:33:41

Naja die Hitrate mit geshartem L2 von 96 MiB L3 (VCache stand jetzt) + 1 MiB L2 (L2 Stand jetzt) gleichzuziehen wird ohne "L2 VCache" nicht drin sein. ;)
Es ist die Mischung aus Geschwindigkeit und Größe, die den jetzligen L3 VCache so einzigartig macht. Das geht nur durch das Stapeln. Für einen herkömmlichen Cache der so groß ist, sind die 13 ns unfassbar schnell.

Ja, in allen Bereichen besser sein als die jetzige Cache-Struktur wird man sicher nicht, das wird immer ein Tradeoff sein. Alderlake hat ja auch eine massiv höhere L3 und Speicherlatenz als Rocketlake und trotzdem das bessere Cache Subsystem. Vor allem wenn mehr Bandbreite gefragt ist triumphiert Golden Cove dann (ironischerweise vor allem bei AVX-512).
Eine neue Cache Architektur für einen neuen Core muss also nicht unbedingt latenzärmer sein als die alte. Sonst wäre der Phenom X4 heute noch state of the Art.

Lassen wir den X3D doch erstmal außem vor und vergleichen die normalen "basis"-CPUs. Die X3D-CPUs verzerren das Bild und wie man sieht ist auch der 7700X im Schnitt nicht schneller in Games als ein 5800x3d. Man kann also gar nicht erwarten dass eine mainstream Zen5 CPU einen 7800x3d beim Cachesystem outperformt.

IMO gibt es doch gar keinen Handlungsbedarf bei den größeren Cache Stufen.
Handlungsbedarf gibt es sowieso nie.
Aber es wird neue Cores geben, also wird auch das Cachesytem eine andere Balance haben.

Aber dass beim LLC noch viel auf dem Teller liegt zeigt ja Broadwell. Der 5775C liegt trotz 4 Kernen und 28% niedrigerem Turbotakt und mickrigen 25gb/s DDR3 SI in Spielen auf einem Niveau mit einem 10700K.
Und das mit einem 42ns langsamen EDRAM LLC der weniger als 50GB/s für vier Cores bietet.

Zen5 Cores bei 5Ghz sollten locker den dreifachen Core-Durchsatz haben. Für 8Kerne braucht man also gut 300Gb/s. Das sollte ein leichtes sein, jetzt schon mit ifop und erst recht mit UCIe + Info-Variantionen.
Ifop durch das package kostet derzeit etwa 10ns obendrauf.
Lass es also ein 64mb L3 Cache sein der 25ns langsam ist. Dazu DDR5 mit 60-70ns und 7200mhz um die nötige Bandbreite zu liefern.

Wenn der L2 dazu auf 16mb anwächst bei mit rund 6ns verdoppelter Latenz und der 128kb L1 bei ca. 1,5ns liegt, dann gibt es zwar sehr viele Bereiche der Latenzverlaufskurve die mehr Latenzen haben als bei Zen4, aber ebenso auch viele die besser sind. Ist das besser als eine aktuelle x3d CPU? Nein - aber vermutlich in der Masse auch viel günstiger zu fertigen. X3D ist aktuell auch einigen wenigen teuren Nischenprodukten vorbehalten und die Gerüchte sagen nichts darüber ob das spezielle Packaging irgendwann in den mainstream geht.

Das Ziel muss es doch sein das Cachesystem auf den breiteren Core vorzubereiten, also trotz mit DDR5 gleichem Speicherstandard viel mehr Bandbreite zu schaffen und gleichzeitig die durchschnittliche Latenz und Hitrate nicht massiv anwachsen zu lassen. Die Cache Hierachien, Dram controller etc. müssen dann noch auf die verfügbaren Technologienodes und Waferspace aufgeteilt werden.

Was das für die X3D CPUs bedeutet weiß ich nicht. AMD könnte sowohl L3 auf dem i/o DIE stapeln als auch L2 auf dem CCX. Natürlich ist gestapelter Cache auf dem CCX effektiver für Spiele als zusätzlicher Cache auf dem i/o DIE. Aber ich würde nicht erwarten dass AMD generelle Architekturentscheidungen von Nischenprodukten im Spielemarkt abhängig macht.
Ich könnte mir durchaus vorstellen dass der 7800x3d die letzte Spiele-CPU mit schmalen Cores und ultra low latency Cache wird und AMD in Zukunft eher die Core-performance über die Breite erhöht wie Intel das seit einigen Generationen tut.

latiose88

2023-04-08, 16:37:10

ähm eine Frage das InFO-R ist doch eine Firma oder eine Technik?
Was ist denn das IOD-LLC Ausgeschrieben?
Achja was ist denn bitte sehr eine Chiplet-Reuse?

Hoffe das geht weil sonst alles kann ich eben nicht verstehen.
Achja der Vorschlag mit ein Chiplet mit 2x8 mag sich zwar gut anhören aber es kostet eben auch Leistung weil die Kommikation dann Umständlicher Stukturiert werden muss von der CPU.

Aber klar wenn so viel wie möglich im L2 Cache stattfindet wird die Anwendung unabhängiger vom L3 Cache.Kann das sogar so weit gehen das es dann selbst mit halbierten L3 Cache keine Leistung verliert,weil das meiste ja schon vom L2 Cache vorselektiert worden ist,so das weniger im L3 Cache geladen wird.

Und was passiert wenn ne Anwendung vom Cache nur wenig Profitiert,also wenig Bandbreite vom Ram und Cache profitiert als gedacht.GIbt es da noch was anderes was die Leistung massiv beeinflussen kann.Oder skaliert dann die Leistung dementsprechend nach oben weil die Kerne nicht limiertiert werden? Und warum geht die Leistung trotz nicht limierens nicht nach oben,gibt es da einen bestimmten Grund dafür,weil immer was mit Bandbreit limitieren wird?

CrazyIvan

2023-04-08, 16:40:42

basix

2023-04-08, 16:42:19

Ich glaube nicht, dass man ohne großen schnellen lokalen Cache eine Regression vermeiden kann. Ein L4 auf's I/O Die oder eine Verschaltung von 2x CCDs bei Beibehaltung des großen VCaches pro CCD hingegen wären ein Schritt nach vorn.
Selbst beim richtig nahe ran rücken und modernen Packagingverfahren wird das ordentlich Latenz kosten. Das war selbst mit den MCDs bei N31 so (Info-R, riesen Bandbreite, schön nah dran). Für GPUs kein Drama für CPUs relevant.

Hinsichtlich Latenz: Siehe Tweet von Ian Cutress zu Sapphire Rapids. Da kommen 5-8ns Die-to-Die dazu, womit man ausgehend von 13ns bei ~20ns für den Remote-L3$ landen würde. Finde ich mehr als nur OK.

Wenn ich tippen müsste, würde ich vermuten, dass der große VCache bleibt und es Dinge eher "on top" dazu gibt.
Ich denke auch, dass der grosse LLC auf dem CCD bleibt und V-Cache ebenfalls. Nur halt anders balanciert (z.B. mehr L2$ und weniger L3$/Core) und deutlich performanter angebunden zwischen den CCDs (Bandbreite, Latenz). Die Packaging Technologien haben sich hier in den letzten 5 Jahren deutlich weiterentwickelt.

Meine Tipps:
- Zen 5 @ N4X, 8C/CCD, 32 MByte L3$, irgendwas an L1/L2 angepasst
- Zen 6 @ N3X, 16C/CCD, 32 MByte L3$
- 2x CCDs direkt verschaltet und herkömmliche IFOP-Verbindung zwischen CCD und IOD
- ...oder wie von CrazyIvan gezeigt CCD via InFO-R ans IOD angebunden

ähm eine Frage das InFO-R ist doch eine Firma oder eine Technik?
Was ist denn das IOD-LLC Ausgeschrieben?
Achja was ist denn bitte sehr eine Chiplet-Reuse?
- InFO-R = TSMCs Technik, um Chiplets via Substrat zu verbinden (ohne Interposer). Beispiel: RDNA3 mit N31, wo das GCD und die MCDs via InFO-R verbunden werden
- IOD = I/O Die von Zen
- LLC = Last Level Cache = L3-Cache bei Zen
- Chiplet Reuse = man kann das selbe Chiplet für mehrere Produkte verwenden. Siehe CCD von Zen, das bei Desktop Ryzen wie auch Server Epyc verwendet wird. Das kann man natürlich auf andere Dinge ausweiten wie z.B. das IOD oder das MCD bei RDNA3, welches bei N31 wie auch N32 zum Einsatz kommt

reaperrr

2023-04-08, 16:45:42

Complicated

2023-04-08, 16:49:43

Du denkst da zu sehr in festen Cache Hierachien. Die Grenzen der Hierachien verschieben sich ja mit der jeweiligen Kapazität. Es gibt z.B. überhaupt keinen Performancenachteil wenn der L3 plötzlich 30 statt 12ns ist und im I/O Die liegt, solange die on-Die Hitrate dieselbe ist.
Wenn der L2 wie spekuliert im ganzen CCX geshared ist und annähernd die hitrate liefert die im moment auf den L3 entfällt bleibt das ganze ein Nullsummenspiel. Und den Latenzzuwachs eines so großen L2s wird dann dadurch aufgefangen dass auch der L1 massiv anwächst. Und dessen Latenz wiederum wird kaschiert durch einen größeren ROB. Exakt, was ich meine. Und weiter führend auf den Punkt gebracht:

AMD hat schon angekündigt dass Zen5 ein breiterer Core wird der mehr ILP extrahieren kann.
+1

Genau, aber Datenlokalität kann auch der L2 übernehmen. Man sollte immer den Latenzverlauf als ganzes anschauen und nicht in festen cache Hierachien denken.
+1

Bei einem breiteren Core wird vor allem mehr Bandbreite gebraucht um diesen zu füttern, gerade in HPC Anwendungen mit viel FP.
+1
Prinzipiell denken wir alle in die gleiche Richtung, nur mit verschiedenen Ansätzen:
[..]
Die konkrete Lösung wird von folgendem abhängen:
- Performance
- Energieffizienz
- Skalierbarkeit (Architektur, Packaging)
- Wirtschaftlichkeit
- Chiplet-Reuse

Korrekt. Und daher sind meiner Meinung nach die nächsten Schritte auf folgendem begründet:

Was auch dafür spricht:
Dieser bereits InFO-R fähige Bergamo wird 1:1 auf MI300 verwendet (+ 2x ein weiteres, Custom-4c CCD).
Die Spekulation Zen5+Zen4c basiert darauf, dass die großen Kerne mit der nächsten Generation auf InFO-R wechseln, die kleinen aber ja erst viel später released werden. Somit kann man bereits auf den Vorgänger zurückgreifen.
Naja die Hitrate mit geshartem L2 von 96 MiB L3 (VCache stand jetzt) + 1 MiB L2 (L2 Stand jetzt) gleichzuziehen wird ohne "L2 VCache" nicht drin sein. ;)
Es ist die Mischung aus Geschwindigkeit und Größe, die den jetzligen L3 VCache so einzigartig macht. Das geht nur durch das Stapeln. Für einen herkömmlichen Cache der so groß ist, sind die 13 ns unfassbar schnell.
IMO gibt es doch gar keinen Handlungsbedarf bei den größeren Cache Stufen.
Nimmt man nun für XDNA nicht lediglich an, dass AI als Chiplet angebunden wird, sondern dass Entwicklungen für XDNA aus der Xilinx-IP für ein NoC genutzt werden, wirst Du dieses vielleicht entsprechend anpassen:

Man würde schon die Servertechnik für Desktop übernehmen. Nur gehe ich davon aus, dass es zumindest bei Zen 5 eher auf InFO-R als auf 2.5D basieren wird. XDNA kann man damit immer noch realisieren:
- 1x Chiplet = Zen 5; 1x Chiplet = XDNA; verbunden via Die-to-Die Interface
- Zen 5 CLuster aus 2x CCD; XDNA Cluster aus 2x XDNA Chiplet; verbunden via IOD
- MI300 All-In Ansatz
[...]
Edit:
Ich habe noch ein anderes Konzept, wie man die CCD verbinden könnte und das DDR5-IO Problem nicht hätte. Verlangt aber nach einem zusätzlichen Chiplet und das IOD sowie das zusätzliche Chiplet wären zwischen Siena und Turin nicht transferierbar.
- DDR5 Channels gehn seitlich aus dem IOD raus, gleich wie heute
- Verbindung zwischen IOD und "XDNA Connect" muss die IFOP und PCIe Verbindungen bereitstellen. PCIe PHY wären dann auf dem "XDNA Connect" Chiplet. IFOP PHY benötigt man nicht mehr sondern deutlich kleinere für InFO-R
Mit dem Releases der Versal ACAP AI Engines und dem dazugehörigen NoC sind Teile diese Interconnect-Details womöglich das, was man sehen wird in EPYC und Weiterentwicklung von MI 300. Die Versal-Serie beinhaltet neben einer HBM-Konfiguration eine Reihe an SKUs ohne HBM und dafür mit APU, DSP und DDR4 MC:
https://docs.xilinx.com/v/u/en-US/ds950-versal-overview
Das dort verwendete NoC bindet schon alles an, bis auf x86 Chiplets.
Die Details dort sind sehr aufschlußreich bis in den letzten genutzten PHY mit Transferraten die genutzt werden.
Für mich sieht das im Prinzip schon Zen5-Ready aus. Mir kommt auch der Verdacht, dass AMD AI Engines in den CPUs und GPUs untergebracht hat um damit das NoC und andere Interconnects zu verwalten. Und gar nicht primär um da AI Workloads darauf laufen zu lassen. (Vielleicht als Zweitverwendung in Consumer-SKUs für Bildverbesserungen/Streaming auf Desktop und Mobile)

https://support.xilinx.com/s/article/1132493?language=en_US

The AI Engine interface includes PL and NoC interface tiles and a configuration tile. Interface from the PL to the AI Engine Array is done using AXI4-Stream interfaces through both the PL and NoC interface tiles. Interface from the NoC to the AI Engine Array is done using AXI4-Memory Mapped interfaces through the NoC interface tiles.

https://xilinx.file.force.com/servlet/servlet.ImageServer?id=0152E000003pLNx&oid=00D2E000000nHq7

Each AI Engine tile includes:

One tile interconnect module which handles AXI4-Stream and Memory Mapped AXI4 input/output
One memory module which includes a 32 KB data memory divided into eight memory banks, a memory interface, DMA, and locks.
One AI Engine

The AI Engine can access up to 4 memory modules in all four directions as one contiguous block of memory. This means that in addition to the memory local to its tile, the AI Engine can access the local memory of 3 neighboring tiles (unless the tile is located on the edges of the array):

The memory module on the north
The memory module on the south
The memory module on the east or west depending on the row and the relative placement of the AI Engine and memory module.

https://xilinx.file.force.com/servlet/servlet.ImageServer?id=0152E000003pLNy&oid=00D2E000000nHq7

CrazyIvan

2023-04-08, 16:50:43

Für 8Kerne braucht man also gut 300Gb/s. Das sollte ein leichtes sein, jetzt schon mit ifop und erst recht mit UCIe + Info-Variantionen.

Mit IFoP machst Du da aber mal gar keinen Stich.
Nochmal: 64/32 GByte/s im üblichen Narrow Mode und das doppelte im seltenen Wide Mode. Ist noch ein Stück zu 300 Gbyte/s.
Bzgl. anderer Technologien bin ich bei Dir.

basix

2023-04-08, 16:55:16

@Complicated:
"Versal ACAP AI Engines for Dummies" finde ich gut :D;)

Complicated

2023-04-08, 16:59:12

Ja, ich fand es komplex genug :D

amdfanuwe

2023-04-08, 17:31:11

@amdfanuwe
Würde mich sehr wundern, wenn die c2c Latenz den Hop zum RAM beinhaltet. Da der ja bei Zen4 ca. 60-70ns Latenz hat, geht das auch irgendwie nicht auf.
Lasse mich da aber sehr gern eines besseren belehren.

Verwechselst du das mit 60 - 70 Takten Latenz?
Die Angaben für RAS,CAS etc bei den Speichermodulen sind in Takten angegeben.
CAS ist bei DDR ~13ns, 20 Takte bei DDR4 3200 laut Wiki.
Dazu noch RAS und 16 Takte bei DDR5 (8 bei DDR4) zur Datenübertragung.
Sind wir bei 60-70 Takten Latenz.
Bei 3 GHz Speichertakt dauert ein Takt ~0,33ns
sind wir bei 20-23ns Latenz.

Durch mehrere Speicherkanäle lässt sich das effektiv noch senken.
CB notiert auch eine Formel für effektive Latenz:
Die primär für Spieler besonders relevanten und im Hinblick auf die Minimum-FPS interessanten effektiven Latenzen und Latenzzeiten werden wie folgt berechnet:

CAS-Latency ÷ effektiven Speichertakt × 2.000 ns
https://www.computerbase.de/2022-06/ddr5-arbeitsspeicher-bandbreiten-latenzen/
In der folgenden Tabelle dort wird die Latenz im Schnitt zu 13ns berechnet, je nach RAM Typ.

amdfanuwe

2023-04-08, 18:17:26

Hier ist ein Code zur Core to Core Latenz Messung, wie sie wohl auch bei Anandtech verwendet wird.
https://github.com/ajakubek/core-latency/blob/master/main.cpp

CrazyIvan

2023-04-08, 19:16:11

@amdfanuwe
Nein, ich hatte das einfach nur heute morgen im TPU Review gesehen:
https://tpucdn.com/review/amd-ryzen-7-7800x3d/images/aida64-cache-mem.png

basix

2023-04-08, 19:17:18

Wieso sollte man den DRAM bei einer solchen Messung miteinbeziehen? Das macht keinen Sinn. Ist bei Intel ja auch nicht so, dass die Core-to-Core Latenz so gemessen wird. Dort ist das Resultat eher so 30ns, was definitiv deutlich unter der DRAM-Latenz liegt. Dass das bei Zen so nahe zusammenliegt ist eher Zufall.

Bei AMD muss man über den SDF Transport Layer, welcher im IOD liegt (Infinity Fabric). Core-to-Core ist das dann CCX -> CCM -> SDF -> CCM -> CCX und dann den selben Weg wieder zurück: https://fuse.wikichip.org/news/1064/isscc-2018-amds-zeppelin-multi-chip-routing-and-packaging/2/

davidzo

2023-04-08, 19:25:13

@amdfanuwe
Würde mich sehr wundern, wenn die c2c Latenz den Hop zum RAM beinhaltet. Da der ja bei Zen4 ca. 60-70ns Latenz hat, geht das auch irgendwie nicht auf.
Lasse mich da aber sehr gern eines besseren belehren.

Was denn sonst, du glaubst doch nicht allen ernstes dass die IFOP Links 40ns Latenz adden? Wenn das so wäre, dann würden die monolitischen APUs im gaming ja völlig dominieren und wir hätten einen gigantischen Abstand zwischen Intel und AMD.

Nee, das sind nicht mehr als 10ns die auf den Die to Die interconnect entfallen. Der Abstand zwischen Comet Lake und Zen2 waren ca. 20ns, also 45ns vs 65ns. CML hatte allerdings auch mehr Takt und kleinere schnellere L2s und L3s. Mit Alderlake hat sich der Vorsprung auf weniger als 5ns egalisiert, da bei GLC sowohl der L2 als auch L3 langsamer sind als bei Zen3+4. RTL hat als monolitische CPU fast identische Dram Latenzen wie eine Zen4 Chiplet CPU. Der Die to Die interconnect fällt also nicht wirklich ins Gewicht.

basix

2023-04-08, 19:37:54

CrazyIvan hat nicht die IFOP Link Latenz in Frage gestellt, sondern dass das den DRAM beinhaltet. Und nein, tut es definitiv nicht. Wieso auch? Wieso sollte ich zum DRAM raus, wenn ich Daten aus z.B. dem L2$ des anderen CCD haben will? Macht keinen Sinn.

Wenn man von CCD <-> CCD komuniziert, muss man für hin und zurück total 4x über den IFOP wandern. Das beinhaltet den physischen Link zwischen den Die sowie das Packet-Routing im IOD. Deswegen kommen da total +50ns bei Zen 4 obendrauf, wenn man aus dem CCD raus muss zum zweiten CCD.
Ich weiss auch nicht, wieso das +50ns sind. Ich hätte gehofft, dass man das bei Zen 4 auf <30ns runterdrückt, wenn man nun IF Gen 3 hat und ein 6nm IOD...

Die APUs performen wegen folgenden Gründen in Gaming schlechter:
- Geringere Taktraten
- Halbierter L3$
- Halbierter Infinity Fabric Takt (Energieeffizienz) und deswegen relativ hohe Speicherlatenzen

Oder man kann es auch so sehen: Ein 5800X ist in Gaming nicht schneller als ein 5950X aber zum Teil deutlich schneller als ein 5700G. Der Workload wird anscheinend so gemanaged, dass da nicht sehr viel zwischen den zwei CCD transferiert wird. Und da die APU einen kleineren LLC und sogar schlechtere DRAM-Latenzen hat wie eine Single-CCD CPU, kann die APU im Gaming gar nicht schneller sein.

Edit:
Der Die-to-Die Latenz ist schon ein Thema, denn die Differenz zwischen L3-Latenz und DRAM-Latenz ist bei den Intel Chips kleiner. Ist allerdings wirklich nicht sehr viel, so 5-10ns zwischen z.B. Alder Lake und Zen 3. Da hast du also recht, dass das Die-to-Die Interface hier keinen Beinbruch darstellt.

latiose88

2023-04-08, 20:05:24

also wenn bei Zen 5 so alles geregelt wird das zwischen 16 und 32 Mb so garkein Leistungsunterschied mehr vorhanden ist,spielt dies für mich ja auch keine Rolle.VIelleicht ist ja da der L1 und L2 Cache so groß das es noch weniger bei mir ne Rolle spielt wie groß der L3 Cache sein wird.Zwischen 16 und 32 Mb habe ich schon noch einen Unterschied feststellen können,zwischen 32 und 64 MB L3 Cache jedoch 0 % Unterschiede.Vielleicht wird das ja noch was.Wenn die Missrate zwischen L1 und L2 bei -% sind,dann wird spätestens ab da der L3 Cache bei mir wohl keine so große Rolle mehr geben oder wird die Missratte niemals weniger als 0 % betragen können und wer von euch hatte denn schon mal sowas wie 0,10 % Missrate gehabt?
Bei Zen 4 wird die wohl noch weniger sein als zuvor schon also noch weniger als 0,10 %.
Bei Zen 5 erwarte ich also wenn es so weiter geht eine 0 % Missrate.Das wird ein spaß.Endlich frei sein vom Cache,unabhängig und dafür die voll CPU Leistung geniesen.Und wer weis vielleicht reduziert sich ja beim Ram auch die abhängigkeit richtung Null %.Alleine 2% sind garnix mehr.Und mit etwas glück wird es in Zukunft auch da 0% Unterschiede geben.Wenn das der Fall ist,muss ich mir nur noch um die CPU Leistung Gedanken machen und kann dann egal welchen Ramtakt da kaufen.
Bei Games wird das zwar noch immer in Zukunft eine Rolle spielen ,da ich jedoch null neue Games habe,kann mir das voll egal sein.Ich richte mich also voll auf das eine Programm das wirklich CPU Leistung braucht.Und kaufe auch nach dieser Anwendung.Weis nicht ob das für manche Strange klingt aber so ist es.Habe daher schon alle Zen 4 Tests dank User durch.Nun heißt es auf Zen 5 warten und erhoffe mir da noch mehr Leistung.Ich treibe es bis es keine Steigerung mehr gibt.
Und ich weis es gibt bei ner Anwendung keine Unendliche Optimierung,alles hat irgendwann ein Ende.Sollte es mal so weit sein,das zwischen 8 und 16 Kernen keinen Unterschied mehr gibt,dann kann ich auch lowend PCs zusammen Bauen.Das wird ein Spaß und maximale Kostenersparnis.Denn untere Liga Steigt die CPU Leistung ja ebenso an wie bei den 12 und 16 Kernen.
Und egal wie der neue Aufbau auch sein mag,wenn es am Ende das Ziel von mehr Leistung mich voran gebracht hat umso besser.Und wenn sich herausstellt das ich auch den niedrigsten Ramtakt fahren kann,dann ist Geld gespart umso besser für mich.
Man merkt also mein Fokus liegt bei 100 % auf die CPU.
So viel Zeit und steigerung hat nur ich in das ganze gesteckt.Ne normale Person würde sich diese Mühe nicht machen.

CrazyIvan

2023-04-08, 20:34:20

@davidzo
Ja, ich meinte das so, wie basix es auch ausgeführt hat. Und wenn ich mich nicht täusche, dann spielen da auch die gestackten Latenzen der gesamten Cache-Hierarchie doppelt rein, oder nicht? Wenn man die, sowie das IOD Routing abzieht, ist man recht schnell bei den Zahlen, die Du auch aufführst.
Das bedeutet wiederum im Umkehrschluss, dass da auch mit InFO, EMIB und Co. gar nicht mehr wahnsinnig viel drin sein wird. Der Hauptvorteil ist neben Bandbreite und Dichte nunmal pJ/bit.

amdfanuwe

2023-04-08, 22:01:27

CrazyIvan hat nicht die IFOP Link Latenz in Frage gestellt, sondern dass das den DRAM beinhaltet. Und nein, tut es definitiv nicht. Wieso auch? Wieso sollte ich zum DRAM raus, wenn ich Daten aus z.B. dem L2$ des anderen CCD haben will? Macht keinen Sinn.

Das musste mal erklären, wie du das adressieren willst.
Software bekommt vom Cache nichts mit.
Da arbeitet man mit Speicheradressen.
2 Threads synchronisiert man über eine Variable und kommunizieren über Pipes.
Wenn man Glück hat, liegen die auf dem gleichen Core und die Variable steht schnell im L2 zur Verfügung.
Sind die 2 Cores auf dem gleichen CCX eben L3 ansonsten geht es über das RAM.

Hier noch mal der Code wie die Latenz gemessen wird:
https://github.com/ajakubek/core-latency/blob/master/main.cpp

CrazyIvan

2023-04-09, 07:47:42

@amdfanuwe

Also zu Beginn: Ich bin sicher nicht der Welt größter C++ Versteher. Aber wie Du schon richtig sagst, geht es im Grunde um die Methode operator() der Struktur LatencyBench, in der sich zwei Threads einfach nur ein Ping, Pong hin und her schicken. Das findet jeweils vermutlich sogar im L1 oder höchstens L2 statt.
Jetzt zu der Frage, warum nicht über den RAM: Hier vermute ich ganz stark, dass die Kohärenz-Mechanismen den eigentlichen Kommunikationskanal darstellen. Man misst also IMHO, wie lange es dauert, bis die Kohärenz zwischen den beiden Kernen und ihrem jeweiligen Cache-System wiederhergestellt ist - bei Cross-CCD dauert das eben länger.

Kann durchaus sein, dass das totaler Quatsch ist. Aber sind wir uns zumindest einig, dass allein schon anhand der Zahlen ein Hop über den RAM ausgeschlossen werden kann?
Beispiel Alder Lake aus dem AT-Review (https://www.anandtech.com/show/17047/the-intel-12th-gen-core-i912900k-review-hybrid-performance-brings-hybrid-complexity/6) (als Andrei und Ian noch echte Deep-Dives machten):

Worst Case C-2-C Latency im Gracemont-Cluster: 48,x ns
RAM Latency: 92,x ns

Als Sonntagslektüre: AMD verwendet IIRC das MOESI-Protokoll (https://de.wikipedia.org/wiki/MOESI) für die Cache-Kohärenz ;)

basix

2023-04-09, 11:40:08

Als Sonntagslektüre: AMD verwendet IIRC das MOESI-Protokoll (https://de.wikipedia.org/wiki/MOESI) für die Cache-Kohärenz ;)

Aus dem Artikel:
Es vermeidet das Zurückschreiben von modifizierten Cache-Lines, wenn andere CPUs diese lesen wollen. Stattdessen wird der aktuelle Wert bei jeder Veränderung zwischen den Caches direkt propagiert (siehe Zustand Owned).
So wäre es mMn ja auch sinnvoll. Dadurch entsteht nämlich folgender VorteiL:
Außerdem kann die Kommunikation zwischen zwei oder mehreren CPUs bzgl. Latenz und Übertragungsrate signifikant besser sein als zwischen CPU und Hauptspeicher. Bei Multicore-CPUs mit jeweils eigenen Caches pro Core ist dies meist der Fall.

Ich kenne mich mit den ganzen Kohärenz Geschichten usw. nicht gut aus. Aber ich nehme an, dass die CPU-Entwickler schon seit Äonen die Prozessor <-> Prozessor Latenz reduzieren wollen und entsprechende Techniken entwickelt haben. Deswegen scheint es mir sehr "dumm", via DRAM die Core-to-Core Latency zu messen. Und ob dieses Testprogramm so macht? Die Intel Zahlen sind signifikant tiefer als die DRAM Latenz. Klar, die haben einen Unified LLC und nicht mehrgeteilt wie bei AMD. Doch gerade wegen der Cache-Transparenz sollte die SW von all dem nichts mitbekommen (ausser der höheren Latenz).

CrazyIvan

2023-04-09, 12:36:26

Ja, genau.

davidzo

2023-04-09, 13:51:38

Mit IFoP machst Du da aber mal gar keinen Stich.
Nochmal: 64/32 GByte/s im üblichen Narrow Mode und das doppelte im seltenen Wide Mode. Ist noch ein Stück zu 300 Gbyte/s.
Bzgl. anderer Technologien bin ich bei Dir.
Gegenbeispiel: Die aktuellen Epycs haben weit über 300Gb/s Ifop Bandbreite.
Ist natürlich eine Frage wie breit man die Anbindung auslegt. Physisch ist das aber drin mit Info-R statt µ-bumps. Bei einer um 10x gestiegenen Density durch IFFT gegenüber dem bisherigen Epyc OPL (siehe navi31 Folie) wächst dabei nicht einmal der DIE für an.

Skysnake

2023-04-09, 13:58:52

Wenn du nicht explizit den RAM forciert. Also Non-temporal Stores verwendest, dann geht man IMMER durch die Cache Stufen durch. Das gleiche bei Loads. Das ist das Speichermodell von x86.

Was man jetzt nur noch unterscheiden muss ist wie die Cores miteinenader ihren Cahe Cohärenz traffic machen.

Bei geteilten L3 musst du im Prinzip nur über den L3 gehen bei nem store. Wobei bei x86 heutzutage dem Core bekannt ist, ob er die Cacheline exklusive hat oder nicht. Bei Single socket ist das aber alles nicht so schwer und schon alles altes Zeug. Multisocket ist da interessanter und auch noch nicht so ausgelutscht.

CrazyIvan

2023-04-09, 14:18:56

Gegenbeispiel: Die aktuellen Epycs haben weit über 300Gb/s Ifop Bandbreite.
Ist natürlich eine Frage wie breit man die Anbindung auslegt. Physisch ist das aber drin mit Info-R statt µ-bumps. Bei einer um 10x gestiegenen Density durch IFFT gegenüber dem bisherigen Epyc OPL (siehe navi31 Folie) wächst dabei nicht einmal der DIE für an.
Ja, jetzt shiftest Du aber Goalposts. Die EPYCs haben die >300 GByte/s Bandbreite über alle CCD-Verbindungen in Summe. Du sprachst von pro CCD im zitierten Post. Und natürlich kann man mit InFO mittlerweile kosteneffizient andere Späße betreiben. Wenn man 1 TByte/s pro MCD bei N31 schafft, dann sollte ein Viertel davon recht günstig darstellbar sein.

amdfanuwe

2023-04-09, 14:27:34

@amdfanuwe
Jetzt zu der Frage, warum nicht über den RAM: Hier vermute ich ganz stark, dass die Kohärenz-Mechanismen den eigentlichen Kommunikationskanal darstellen. Man misst also IMHO, wie lange es dauert, bis die Kohärenz zwischen den beiden Kernen und ihrem jeweiligen Cache-System wiederhergestellt ist - bei Cross-CCD dauert das eben länger.

Als Sonntagslektüre: AMD verwendet IIRC das MOESI-Protokoll (https://de.wikipedia.org/wiki/MOESI) für die Cache-Kohärenz ;)
Danke für die Sonntagslektüre.
Hat mich ein paar Stunden gekostet.
Offensichtlich lag ich falsch mit dem RAM Zugriff und bei einem Cache Miss wird erst in den anderen Caches die Cache Line angefragt.
Bin dann auch hier gelandet:
https://www.amd.com/system/files/TechDocs/24593.pdf
Seite 196:
To maintain memory coherency, external bus masters (typically other processors with their own
internal caches) need to acquire the most recent copy of data before caching it internally. That copy can
be in main memory or in the internal caches of other bus-mastering devices. When an external master
has a cache read-miss or write-miss, it probes the other mastering devices to determine whether the
most recent copy of data is held in any of their caches. If one of the other mastering devices holds the
most recent copy, it provides it to the requesting device. Otherwise, the most recent copy is provided
by main memory

amdfanuwe

2023-04-09, 14:39:29

Aus dem Artikel:

Deswegen scheint es mir sehr "dumm", via DRAM die Core-to-Core Latency zu messen.
Klappt aber erst mit dem MOESI Protokoll.
Weis aber nicht, wann das (bei AMD) eingeführt wurde.
Das MOESI-Protokoll ist eine komplizierte Variante des MESI-Protokolls. Es vermeidet das Zurückschreiben von modifizierten Cache-Lines, wenn andere CPUs diese lesen wollen. Stattdessen wird der aktuelle Wert bei jeder Veränderung zwischen den Caches direkt propagiert (siehe Zustand Owned).

basix

2023-04-09, 14:50:16

Hat AMD bei Zen 1 eine "verbesserte" MOESI Variante eingeführt und ist die Basis des Infinity Fabrics und den verteilten CCX Clustern:
https://www.cs.rice.edu/~johnmc/comp522/lecture-notes/COMP522-2019-Lecture5-Cache-Coherence-I.pdf
Distributed MOESI cache coherence Directory

MOESI gab es aber auch schon früher via HyperTransport. Wann genau weiss ich nicht, gibt aber auch Software Optimization Guides von 2014 wo MOESI erwähnt wird:
https://www.amd.com/system/files/TechDocs/47414_15h_sw_opt_guide.pdf

Hier Artikel von 2007 und 2001, die im Zusammenhang mit HyperTransport MOESI erwähnen:
https://picture.iczhiku.com/resource/eetop/whiDrjeiHfaZFmvC.pdf
https://www.eetimes.com/protocol-keeps-dual-processor-fed/

Skysnake

2023-04-09, 17:17:42

Ja MOESI ist schon ziemlich alt inzwischen

DozerDave

2023-04-12, 07:47:29

0ok_Ik3YqS0

+20% IPC?

w0mbat

2023-04-12, 08:44:12

Jim Keller schätzt ja +24% INT IPC für Zen 5.

latiose88

2023-04-12, 09:01:08

CrazyIvan

2023-04-12, 09:23:19

@latiose88

Ja, das ist ja schön, dass Du das wissen möchtest. Aber solche Basisfragen musst Du nicht in einem Forum fragen und schon gar nicht in diesem Thread. Für genau so etwas gibt es Google, Bing und Co.

Deine Neugier in allen Ehren: Aber sowohl ich als auch andere haben Dir das hier schon mehrfach mitgeteilt. Und wenn da nicht langsam mal ein Erkenntnisgewinn Deinerseits erkennbar wird, dann melde ich Dich einem Moderator - denn so langsam nervt es.

HOT

2023-04-12, 09:40:36

Jim Keller schätzt ja +24% INT IPC für Zen 5.

So eine Einschätzung halte ich für fundierter als manch andere, aber auch das kann trotzdem stark abweichen.

Der_Korken

2023-04-12, 10:07:44

Skysnake

2023-04-12, 10:51:25

Nightspider

2023-04-12, 11:04:17

MLID spricht zwar von early silicon aber betrachtet man die langen Produktionszeiten und das Zen5 im Best Case in 1Q24 auf den Markt kommt und im HPC Bereich eventuell schon eher gegen 4Q23 Farmen mit dem Genoa Nachfolger bestückt werden könnten, dann ist es vielleicht auch nur noch einige Monate hin bis zum Start der Massenproduktion.

Was der Leaker da in der Hand hatte könnte schon ein weitestgehend finales (Eng.) Sample gewesen sein, was ja auch der Clock von 3,85Ghz bei 64 Kernen (mehr als Genoa hat) untermauern würde.

Das würde auch die Vermutung bekräftigen, das Jim Keller durch seine Connections schon ziemlich genau weiß, wie schnell Zen5 in etwa wird.

Gerüchte gabs ja schon vor langer Zeit, das der zeitliche Abstand zwischen Zen4 und Zen5 geringer sein soll und wenn das IOD von Zen4 wiederverwendet wird, spart man sich auch ein paar Monate an Arbeit.
(Auch wenn ich es schade finden würde, wenn das Packaging noch keinen Schritt nach vorne macht. Aber am Ende wäre es egal, solange ein schöner Leistungssprung herauskommt)

Man könnte jetzt aber auch den Gedanken in den Raum werfen, ob AMD die N4 oder N3 Variante des Chiplets priorisieren müsste oder ob diese komplett parallel und gleichzeitig fertig werden.

Da N4 ein N5 Abwandlung ist, dürfte das V-Cache stacking eventuell übernommen werden können ohne größere Anpassungen, so das Zen5D mit minimaler Verzögerung kommt, falls der Aufbau gleich bleibt.

Integer bzw boolsche Arithmetik bzw bit Manipulation halt.

Braucht man vor allem für buisness Logik.

Muss dann aber auch mal eine dumme Frage stellen.

Als Raptor Lake erschien glänzte dieser vor allem in Spielen mit Raytracing auf Ultra, wo scheinbar noch zusätzliche CPU Last entsteht.

Sind das nicht auch mathematisch relativ simple Fälle, wo man vor allem Integerleistung benötigt?

Ich muss aber zugeben, das ich auch nicht weiß wodurch genau CPU seitig mehr Rechenleistung benötigt wird, wenn die GPU Raytracing berechnen muss.

basix

2023-04-12, 11:30:51

Gerüchte gabs ja schon vor langer Zeit, das der zeitliche Abstand zwischen Zen4 und Zen5 geringer sein soll und wenn das IOD von Zen4 wiederverwendet wird, spart man sich auch ein paar Monate an Arbeit.
(Auch wenn ich es schade finden würde, wenn das Packaging noch keinen Schritt nach vorne macht. Aber am Ende wäre es egal, solange ein schöner Leistungssprung herauskommt)
Für AMD macht es aber schon Sinn.
- Packaging Kosten
- Chiplet Reuse des IOD
- Time to Market
- Software Infrastruktur Reuse

Zen 6 könnte hinsichtlich Packaging interessanter werden (oder auch nicht).

Man könnte jetzt aber auch den Gedanken in den Raum werfen, ob AMD die N4 oder N3 Variante des Chiplets priorisieren müsste oder ob diese komplett parallel und gleichzeitig fertig werden.
Die N3 Variante wird Zen 5c sein. Anderer Markt. Das läuft soweit parallel, aber Zen 5c wird höchstwahrscheinlich später erscheinen.

Für Desktop (Ryzen oder Threadripper) wäre das zudem eine spannende Variante: 2x Core Count bei selber LLC-Menge. Oder bei Ryzen evtl. auch 1x Zen 5 CCD und 1x Zen 5c CCD (total 24 Kerne), damit die max. ST Performance nicht beeinträchtigt wird. Allerdings könnten die Taktraten bei Zen 5c aufgrund N3 ansteigen, im besten Fall sogar dorthin wo Zen 5 in N4 sein wird. Ist aber wohl nicht so wahrscheinlich.

Da N4 ein N5 Abwandlung ist, dürfte das V-Cache stacking eventuell übernommen werden können ohne größere Anpassungen, so das Zen5D mit minimaler Verzögerung kommt, falls der Aufbau gleich bleibt.
Davon würde ich jetzt ausgehen, ja. Und da N3E faktisch Null SRAM-Scaling mitbringt, könnte man das V-Cache Chiplet evtl. auch ohne Änderungen übernehmen.

BlacKi

2023-04-12, 11:50:03

AMD Zen5 allegedly tested with Cinebench R23

around 15% higher than the Genoa (Zen4)

this sample had 8 CCDs, so each chiplet would again have 8 cores

wären trotzdem 64mb l3 cache pro chiplet und verdoppelung per core.
https://videocardz.com/newz/early-dual-amd-zen5-cpu-system-scores-123k-points-in-cinebench

Nightspider

2023-04-12, 11:54:06

@Blacki:

https://www.forum-3dcenter.org/vbulletin/showthread.php?p=13279676#post13279676

Für AMD macht es aber schon Sinn.
- Packaging Kosten
- Chiplet Reuse des IOD
- Time to Market
- Software Infrastruktur Reuse

Naja, genauso gut könntest du sagen ein neuer Base IO könnte dann auch bei Zen6 wiederverwendet werden und wenn man den L3 aus dem CCD holt könnte man dort massiv Kosten senken, wenn man ein deutlich kleineres CCD belichten müsste.
L3 vom CCD rauszuholen würde Kosten senken.

Wobei das Video von MLID darauf hinweist, das sich an der L3 Größe wohl nichts ändern wird, was für den alten Aufbau spricht.

robbitop

2023-04-12, 11:59:41

War mein Bauchgefühl offenbar richtig. Keine wesentliche Veränderung im Cacheaufbau außer L1.
Wobei ich gehofft hätte, dass der L1 Cache deutlicher wächst.

Zossel

2023-04-12, 12:03:04

Hm was kann Int an Funktionen noch gleich mal?
Fp weiß ich ja und da ist dann sowas wie avx mit dabei. Aber bei int was kann das denn bei CPU so alles machen? Will ja wissen wie ich das einzuschätzen habe.

https://www.google.com/search?q=x64+assembly+tutorial

Oder besorge dir einen Arduinio mit einem AVR oder Cortex-M-irgentwas drauf und schreib mal ein paar Sachen in Assembler, ein 8-Bit AVR ist einfacher zum Einstieg.

Oder schau dir mal sowas an:

https://www.google.com/search?q=ttl+cpu

basix

2023-04-12, 12:20:17

Naja, genauso gut könntest du sagen ein neuer Base IO könnte dann auch bei Zen6 wiederverwendet werden und [...]
Klar wäre das so. Im Kontext mit den zeitnahen Zen 5 Release würde die Wiederverwendung des Zen 4 IODs aber Sinn machen. Noch mehr bei Siena, welcher später dran ist und bei Zen 5c nicht viel später als Zen 5 erscheinen könnte (abhängig von den N3 Chiplets)

Ausserdem hat man bei Zen 4 bereits alles neu gemacht (AM5, SP5, 3x IOD, Zen 4, Zen 4c). Da wäre es wohl effizienter, wenn man zumindest bei Zen 5 nur die zwei CCDs neu designed. Eines in N4 und eines im nigelnagelneuen N3 mit evtl. sogar 16C CCX Aufbau. Wenn Zen 5 ein so grosser Sprung sein wird ("Neudesign") sind diese drei Punkt wohl genug für die R&D Pipeline (Zen 5 Architektur, N3 Design, 16C CCX). Neben weiteren CPU-Designs für MI300 und Co.

CrazyIvan

2023-04-12, 12:53:13

Interessant finde ich auch seine Aussage bzgl. Zen5c. Er scheint sich recht sicher zu sein, dass man von 2x 8c CCX auf 1x 16c CCX wechselt.
Da mag ich aber noch nicht dran glauben.

robbitop

2023-04-12, 12:58:47

Ist das nicht bereits bei Zen 4c schon so? (16er CCDs)

mboeller

2023-04-12, 13:14:41

Wobei ich gehofft hätte, dass der L1 Cache deutlicher wächst.

Warum?

Beim L1 geht es ja, soweit ich das verstanden habe auch um die Latenz. Je größer der L1 ist, desto schwieriger wird es den Takt zu erhöhen und die Latenz niedrig zu halten. Auch deshalb wurden ja die "L0" eingeführt.

HOT

2023-04-12, 13:37:56

Die angeblichen Cache-Änderungen wären minimal. L2 und L3 pro Core bleiben gleich, L1 wächst von 64 auf 80kB. Das würde auf die Cove-Caches hinauslaufen mit 32kB L1I und 48kB L1D. Fände ich fast schon enttäuschend, nachdem das "die größte Änderung seit Zen 1" werden soll.

Es kann natürlich immer noch sein, dass die Cache-Ebenen anders verteilt sind, z.B. mit einem gemeinsamen L2 pro 8C und dem L3 auf dem IOD. Die Vorstellung eines gesharten 512MB-L3 realisiert durch 3D-Cache-Chiplets wäre verdammt geil, aber ich glaube nicht so recht dran, dass wir sowas extremes sehen werden. Auch wäre zwischen den 48kB L1 und 8MB L2 ein sehr großes Loch. Ein so großer L2 würde imho erfordern, dass man auch den L1 auf 2x128kB o.ä. vergrößert, da die bisherige Hitrate des privaten L1D doch relativ klein ist. Es klingt also eher nach Evolution statt einer Revolution.

Intel nachgemacht :D.
Ich glaub nicht daran, dass der L2$ geshared ist.

Aus den Leaks kann man aber noch mehr entnehmen:

1.) Das 16C CCD läuft bereits und dürfte N3 ohne alles sein. Der Yield dürfte bei den kleinen Größen relativ unproblematisch sein, das ist ja das große Problem bei N3, deshalb wills ja keiner haben. AMD hat hier offensichtlich zugeschlagen.
2.) Das N3-CCD wird nicht so viel nach dem N4-CCD erscheinen, wenn der Yield stimmt. Das ist das Fragezeichen.

Da beide CCDs bereits mit hohen Taktraten laufen (es gab ja schon Hinweise darauf, dass A0 schon problemlos war) wird 1H 24 problemlos sein als Launchfenster.

Bisschen knifflig. Zen5 wird ein großer Performancesprung werden und dürfte recht zeitig erscheinen, Zen6 wird CXL3.0 mitbringen, wie es aussieht, was ein sehr interessantes Feature ist. Ich glaub ich werd trotzdem Zen5 nehmen.

Das IOD wird nicht mehr als ne neue Rev. vom jetzigen sein, das wird die Speichertakte mit vielen belegten Bänken und ECC fixen, zudem wird man den Takt etwas mehr hochziehen, mehr passiert da nicht. Ich tippe ganz stark darauf, dass man mit dem neuen IOD low latency DDR5 6400 RAM optimal nutzen können wird. Hab da auch schon welchen im Auge ;). Das Server IOD wird komplett neu sein, vielleicht sogar N4, und soll ja auch CXL2.0 unterstützen, zudem hat man ja offiziellen Support für ECC DDR5 7200 im Auge bei AMD und MRDIMMs.

basix

2023-04-12, 15:35:47

Ist das nicht bereits bei Zen 4c schon so? (16er CCDs)

Laut dem MLID Video: Nein. 2x 8C CCX

Ob wahr? Keine Ahnung. Wir werden Zen 4c ja bald sehen.

Der_Korken

2023-04-12, 16:15:02

Warum?

Beim L1 geht es ja, soweit ich das verstanden habe auch um die Latenz. Je größer der L1 ist, desto schwieriger wird es den Takt zu erhöhen und die Latenz niedrig zu halten. Auch deshalb wurden ja die "L0" eingeführt.

Wenn Zen 5 die größte Änderung seit Zen 1 sein soll und diese sich auf einen in Summe 25% größeren L1 belaufen, könnte man mutmaßen, dass die Cache-Größen bis Zen 8 dann nicht mehr angefasst werden ;)

Ich glaube hier haben viele (inkl. mir) auf eine größere Zäsur in der Speicherhierachie gehofft, da diese ein Indikator für starke Performance-Zuwächse wären. Ein L1 mit 128kB und 6 statt 4 Takten würde bedeuten, dass der Kern breiter sein muss, um die Latenzen mit mehr Instruktionen in-flight zu kompensieren. Wenn die Cache-Hierachie so bleibt, wird man auch bei Zen 5 kein sinnvolles 3D-Cache-Modell mit mehr als 8 Kernen bekommen.

Das IOD wird nicht mehr als ne neue Rev. vom jetzigen sein, das wird die Speichertakte mit vielen belegten Bänken und ECC fixen, zudem wird man den Takt etwas mehr hochziehen, mehr passiert da nicht.

Hätte im Desktop ja auf InFO-R o.ä. gehofft. Den Uncore-Verbrauch finde ich bei AMD leider arg unsexy. DDR5-6000 läuft eigentlich gut genug, vor allem mit 3D-Cache. Man sieht ja heute schon, dass Subtimings regeln und >5200Mhz gar nicht mehr so viel bringt, wenn die Timings getuned sind.

amdfanuwe

2023-04-12, 17:05:16

Hätte im Desktop ja auf InFO-R o.ä. gehofft.
Könnte für Desktop zu teuer sein, jeder Cent zählt.

Im Grunde ist aber zur Anbndung nichts geleakt worden.
ZEN5 ES mit 64C, höherer IPC und höherem Takt.

Wenn AMD das ZEN5 Chplet erstmal an das Genoa I/O koppeln konnte ist das optimal für die Entwicklung. Die können sich damit erstmal voll auf das Chiplet konzentrieren.
In hinblick auf MI300 denke ich aber mmer noch, das sich bem I/O mehr tun wird.

AMD könnte auch mehrgleisig fahren zur weiteren Diversifizierung:
1) Genoa I/O für günstige Systeme bei denen es mehr auf Rechenleistung als auf Durchsatz ankommt
2) geteiltes I/O mit IF$ und breiterer Anbindung (wide oder InFO-R)für mehr Durchsatz
3) wie bei MI300 geteiltes I/O mit IF$, HBM und gestackten Chiplets.

V-Cache wäre zusätzliche Option bei allen Systemen.

Mit Bergamo und Siena sieht man ja schon, dass AMD weiter diversifiziert.
Mit zunehmenden Marktanteil und einem günstigen Baukastensystem lohnt sich weitere Diversifizierung.
Intel hat schließlich auch gefühlt für jede Anwendung ein SKU im Programm.

HOT

2023-04-12, 17:14:50

[...]
Hätte im Desktop ja auf InFO-R o.ä. gehofft. Den Uncore-Verbrauch finde ich bei AMD leider arg unsexy. DDR5-6000 läuft eigentlich gut genug, vor allem mit 3D-Cache. Man sieht ja heute schon, dass Subtimings regeln und >5200Mhz gar nicht mehr so viel bringt, wenn die Timings getuned sind.

Was meinst? Der ist doch nicht hoch. Das Ding gibts ja sogar für Mobil.

amdfanuwe
Vorsicht: I/O Consumer != I/O Server. Für Server wird man sicherlich ein neues I/O-Die am start haben, für Consumer aber bezweifel ich das. Da wird man sich mit ner Revision begnügen. Ist ja bei Milan/Zen3 auch so gewesen.

basix

2023-04-12, 17:21:13

Hätte im Desktop ja auf InFO-R o.ä. gehofft. Den Uncore-Verbrauch finde ich bei AMD leider arg unsexy.

Bei Dragon Range ist das anscheinend durch zusätzliche Power States (auch beim LPDDR5) deutlich niedriger. Wenn man das nun bei Desktop einführen könnte...

HOT

2023-04-12, 17:39:51

Mit fortschreitender Firmware wird das sicher kein Problem sein. Ich würde sowieso sagen, dass das Thema total überbewertet ist und eher uneffektive Boards daran schuld sind als das IOD.

CrazyIvan

2023-04-12, 17:58:46

Und ich würde das Gegenteil behaupten.
Auch glaube ich nicht, dass man mehrere Interconnect-Typen auf dem CCD implementieren wird oder gar, dass IFoP und InFO in irgendeiner Weise kompatibel zu einander gemacht werden können (außer via Intermediate Die, was aber den Sinn obsolet macht).
Ich hege immer noch Hoffnung für Zen4c und Zen5. Jemand müsste entweder das ES de-lidden, oder sich Mal die Verbrauchswerte des uncore ganz genau anschauen, oder Mal auf FCLK und Co. schauen. Naja, bis Bergamo wird es nicht mehr lange dauern.
Achja, dass die Cache-Hierarchie kaum angefasst wird, muss nix bedeuten. AMD ist da bereits super aufgestellt und kann womöglich ohne Weiteres am eigentlichen Kern schrauben.

HOT

2023-04-12, 18:26:55

Solange das niemand mal wirklich hinter dem VRM testet wird das leider immer ein Streitpunkt bleiben. Aber ich seh das gänzlich anders. "Tests" die einfach am EPS testen sind jedenfalls Mist und sagen überhaupt nichts über das IOD aus.

robbitop

2023-04-12, 18:52:43

Laut dem MLID Video: Nein. 2x 8C CCX

Ob wahr? Keine Ahnung. Wir werden Zen 4c ja bald sehen.

Ok aber 2x 8er ccx in einem ccd oder?

robbitop

2023-04-12, 18:55:40

Warum?

Beim L1 geht es ja, soweit ich das verstanden habe auch um die Latenz. Je größer der L1 ist, desto schwieriger wird es den Takt zu erhöhen und die Latenz niedrig zu halten. Auch deshalb wurden ja die "L0" eingeführt.
Wie schon von anderen gepostet. Je größer der L1 desto mehr threads in flight möglich was ein Indikator für eine uArch mit brutal gesteigerter ILP Extraction (ala Apple Cores) wäre.
Ist wahrscheinlich kein Muss aber ggf ein Indikator, dass die Breite jetzt nicht so krass zulegt.

Der Rest der Cachesituation ist IMO bereits eine gute Mischung aus Größe und Latenz (insbesondere mit vcache). Nachvollziehbar, dass AMD es so gelassen hat.

davidzo

2023-04-12, 19:22:33

Wie schon von anderen gepostet. Je größer der L1 desto mehr threads in flight möglich was ein Indikator für eine uArch mit brutal gesteigerter ILP Extraction (ala Apple Cores) wäre.
Ist wahrscheinlich kein Muss aber ggf ein Indikator, dass die Breite jetzt nicht so krass zulegt.

Wenn die L1 Größe ein Indikator für höhere ILP wäre, dann ist K7 sicher eine starke Architektur. ;D Der hatte immerhin 128kb L1 Cache (64+64).

Ich dachte das Out of order Execution Window wird durch die Größe des ROB bestimmt, also wieviele Instruktionen du in der Schwebe halten kannst ohne dass sie retired sind, bevor du sie zwangsweise wieder einordnen musst bzw. dabei keine neuen annehmen kannst. Zen4 kann bis zu 320 instructions umsortieren, danach kommt es zum stall. Golden Cove stallt erst bei 512 und der Apple M1 erst bei 630. Das ist sozusagen wie ein L0 für die execution pipeline.

basix

2023-04-12, 19:35:40

Ok aber 2x 8er ccx in einem ccd oder?

Würde ich mal annehmen, ja.

@Cache Diskussion: Neuordnung der Cache-Hierarchie wäre auch, dass man den L3 über mehrere CCDs und am besten CPU weit sharen kann ;D Der L3 wäre zumindest hinsichtlich Chipfläche einer der grössten Anteile der CCDs. Sharing würde sich also lohnen. Und da am weitesten Weg vom Core (L0, L1, L2, L3) auch am insensitivsten hinsichtlich zusätzlicher Latenz. Und evtl. der erste Schritt, wenn man in Richtung Infinity Cache (L4$, Cache auf IOD, etc.) gehen will (oder bei MI300 schon hat).

Ich dachte das Out of order Execution Window wird durch die Größe des ROB bestimmt, also wieviele Instruktionen du in der Schwebe halten kannst ohne dass sie retired sind, bevor du sie zwangsweise wieder einordnen musst bzw. dabei keine neuen annehmen kannst. Zen4 kann bis zu 320 instructions umsortieren, danach kommt es zum stall. Golden Cove stallt erst bei 512 und der Apple M1 erst bei 630. Das ist sozusagen wie ein L0 für die execution pipeline.
Bei den Instruktionen gibt es extrem viele Subcaches: ROB, MicroOpCache, L1I, ...

Wie sieht das bei den Daten aus? Sind das einfach die Register in den Execution Units oder könnte man dort noch etwas anderes machen, um die IPC zu steigern? Gerüchteweise 32kB -> 48kB L1D scheinen zumindest mehr Daten nahe beim Core halten zu wollen.

Der_Korken

2023-04-12, 19:35:57

Wenn die L1 Größe ein Indikator für höhere ILP wäre, dann ist K7 sicher eine starke Architektur. ;D Der hatte immerhin 128kb L1 Cache (64+64).

Der L1 im K7 konnte aber auch keine drei Loads pro Takt bzw. zwei 256Bit-Operanden pro Takt liefern bei < 1ns Latenz. Man hätte natürlich mmer gerne einen möglichst großen L1, weil Load-Operationen dann weniger stallen. Aber Intel und AMD war beiden der Tradeoff der größeren Latenz zu schlecht. Wenn ein Hersteller den L1 plötzlich stark vergrößern würde, dann nicht ohne Grund, denn das hätte man ja auch schon bei der jetzigen Architektur machen können. Deswegen meine Folgerung, dass ein großer L1 auf eine breite Architektur schließen lässt. robbitops hats glaube ich falsch rum formuliert: Nicht der L1 sorgt für mehr instructions in flight, sondern diese sind eine Voraussetzung, damit ein großer L1 funktioniert.

Objektiv betrachtet ist ein 20%-IPC-Uplift nach so kurzer Zeit eigentlich ziemlich nice. Ich bin nur etwas vom "größte-Änderung-seit-Zen-1"-Narrativ gehypt :D.

Edit:

@Cache Diskussion: Neuordnung der Cache-Hierarchie wäre auch, dass man den L3 über mehrere CCDs und am besten CPU weit sharen kann ;D Der L3 wäre zumindest hinsichtlich Chipfläche einer der grössten Anteile der CCDs. Sharing würde sich also lohnen. Und da am weitesten Weg vom Core (L0, L1, L2, L3) auch am insensitivsten hinsichtlich zusätzlicher Latenz. Und evtl. der erste Schritt, wenn man in Richtung Infinity Cache (L4$, Cache auf IOD, etc.) gehen will.

+1

Sowohl vor dem Hintergrund des immer schlechter skalierenden SRAMs auf neuen Prozesses als auch der Redundanz von Caches bzw. dem Druck die CCDs zu vergrößern macht ein LLC im IOD für mich immer mehr Sinn. Vielleicht ist es bei Zen 5 auch noch zu früh, aber langfristig sehe ich da viele Vorteile. Ein solcher Cache würde die Diskussion um CCX- oder CCD-Größen weitestgehend obsolet machen, weil sowieso alle an einem LLC hängen. Die Hoffnung auf 16C-CCDs entsteht ja gerade dadurch, dass man den L3 gerne über mehr Cores geshared sehen will. 3D-Cache löst das Problem nicht wirklich, wie man 7900X3D vs 7800X3D sieht.

CrazyIvan

2023-04-12, 20:13:02

@davidzo
Genau so ist es. Du weißt das, aber der Vollständigkeit halber: Der Reorder Buffer dient genau dazu, die Instruktionen "in flight" in der richtigen Reihenfolge zu behalten, obwohl sie innerhalb des Kerns in nahezu beliebiger Reihenfolge ausgeführt werden können. Im Anschluss werden sie wieder in die richtige Reihenfolge gebracht.

Obwohl der ROB absolut nicht alleinig für ILP verantwortlich ist, ist er der primäre Indikator bei der Betrachtung einer Architektur, wenn es um die Bewertung der ILP geht. Da er anscheinend eine sehr teure Struktur ist, sind die Entwickler sehr knausrig und spendieren anscheinend nie mehr, als unbedingt erforderlich.

basix

2023-04-12, 20:48:47

Sowohl vor dem Hintergrund des immer schlechter skalierenden SRAMs auf neuen Prozesses als auch der Redundanz von Caches bzw. dem Druck die CCDs zu vergrößern macht ein LLC im IOD für mich immer mehr Sinn. Vielleicht ist es bei Zen 5 auch noch zu früh, aber langfristig sehe ich da viele Vorteile. Ein solcher Cache würde die Diskussion um CCX- oder CCD-Größen weitestgehend obsolet machen, weil sowieso alle an einem LLC hängen. Die Hoffnung auf 16C-CCDs entsteht ja gerade dadurch, dass man den L3 gerne über mehr Cores geshared sehen will. 3D-Cache löst das Problem nicht wirklich, wie man 7900X3D vs 7800X3D sieht.

Ich bin ehrlich gesagt skeptisch, ob das komplette Auslagern des L3$ wirklich so sinnvoll ist. Man verliert Effizienz, Bandbreite, Latenz, Datenlokalität und verringert die Chipfläche hinsichtlich Ableitung der Verlustleistung enorm. Ich tendiere eher dazu, dass man mit möglichst geringer zusätzlicher Latenz auf den L3$ der anderen CCDs zugreifen kann. Das könnte dann allenfalls auch dazu dienen, die Cache-Menge pro Core zu reduzieren, ohne die Gesamtmenge zu reduzieren (z.B. 1/2 Cache/Core bei 2+ CCDs mit shared LLC).

Wie man das dann löst ist eine andere Frage. Das wurde die vergangenen Seiten breit diskutiert.

Was im IOD noch am ehesten Sinn machen kann ist ein L4$. Den L3 komplett rausnehmen aber nicht (ausser man geht auf 3D-Stacking von Cores und L3$). Wird interessant, wie die CPU Cores bei MI300 angebunden sind und wie sie den Cache im Base Die nutzen können. Das wäre nämlich so ein L4-Cache.

latiose88

2023-04-12, 20:53:31

ah ok das nun also nen vergrößerte L1 Cache machen wollen hat also bestimmt gewisse Gründe.Ich weis ja das nen größerer L1 Cache mit mehr Latenz hervorholt.Wie wird AMD das denn mit Zen 5 lösen das der erhöte Latenz nicht zu einem Flaschenhals wird.Welche Optionen hätte denn AMD damit und die IPC ist die Latenz empfindlich oder der Egal?

robbitop

2023-04-12, 20:56:15

Ich sehe das wie basix :up:

reaperrr

2023-04-12, 21:00:56

Obwohl der ROB absolut nicht alleinig für ILP verantwortlich ist, ist er der primäre Indikator bei der Betrachtung einer Architektur, wenn es um die Bewertung der ILP geht. Da er anscheinend eine sehr teure Struktur ist, sind die Entwickler sehr knausrig und spendieren anscheinend nie mehr, als unbedingt erforderlich.
Wobei man erwähnen sollte, dass Intel hier ab Ice Lake massiv spendabler als AMD war und in der Praxis trotzdem nur moderat höhere Real-World-IPC erzielt hat.

Ich meine, der ROB von ADL/RPL ist mal eben doppelt so groß wie der von Zen3 (512 vs. 256)...

Der_Korken

2023-04-12, 21:02:45

@basix:

Gegen zu viel Verlustleistung auf der CCD-Fläche würde mehr Effizienz helfen ;). Temperaturen sind bei Zen 4 nur dann ein Problem, wenn die einzelnen CCDs in einem Bereich betrieben werden, wo die Leistung schon lange nicht mehr mit dem Verbrauch skaliert (z.B. 7700X @140W). Wenn die Leistungsdichte die Hersteller dazu zwingt diese Betriebspunkte wegzulassen, wäre mir das ganz recht.

Bei einem L3-Sharing über mehrere CCDs hinweg sehe ich den Vorteil gegenüber einem zentralen L3 im IOD nicht so recht. Ab 3 CCDs ist die durchschnittliche Latenz kaum noch besser, aber die Komplexität steigt enorm an. Bei dem zentralen Ansatz könnte man theoretisch die CCDs wieder verkleinern (z.B. auf 6 Kerne), um Produkte feingranularer zusammenzustellen und einen geshareten L2 zu entschlacken (6 statt 8 Slices). Und ein L4 wäre viel zu groß und zu teuer. Imho muss ein Cache mindestens 4x so groß wie die vorige Stufe kombiniert sein und/oder sehr viele Clients verbinden, damit er sich lohnt. Also mindestens 16MB pro Core (!) extra, zusätzlich zu den 4MB L3.

robbitop

2023-04-12, 21:17:53

Naja alles was aus dem lokalen L3 hinaus geht (13 ns mit bis zu 96 MiB!) wird dann halt durch den zusätzlichen hop langsamer. 20-30 ns ggf. Wäre dann wie ein L4. Warum nicht?

Der_Korken

2023-04-12, 21:27:50

Ein 3D-L3-Cache macht einen L4 noch nutzloser. Die Hitrate wäre so schlecht, dass man sich die Zusatzkosten einfach sparen könnte. Die Desktop-Configs sind einfach nicht groß genug dafür. Bei Epyc wäre ein L4 sinnvoll, selbst wenn er nicht/kaum größer als die kombinierten L3s wäre, weil er einfach so viele Clients verbindet.

CrazyIvan

2023-04-12, 22:28:27

Wobei man erwähnen sollte, dass Intel hier ab Ice Lake massiv spendabler als AMD war und in der Praxis trotzdem nur moderat höhere Real-World-IPC erzielt hat.

Ich meine, der ROB von ADL/RPL ist mal eben doppelt so groß wie der von Zen3 (512 vs. 256)...

Ja, da hast Du recht. Man kann es auch so auslegen, dass Intel schlicht und ergreifend eine sehr unausgewogene Architektur designt hat ;)
Bei Apple ist jedenfalls das Verhältnis von ROB zu ILP/IPC deutlich ausgewogener, ebenso bei AMD.
Spannend ist ja auch, dass man nicht unendlich viel spekulativen ILP generieren sollte, da das wiederum zulasten der Effizienz geht.
Irgendwie hat Intel das "worst of both worlds" geschafft - und dabei haben sie die Coves seit Sunny schon ganz ordentlich verbessert.

CrazyIvan

2023-04-12, 22:48:01

Mit fortschreitender Firmware wird das sicher kein Problem sein. Ich würde sowieso sagen, dass das Thema total überbewertet ist und eher uneffektive Boards daran schuld sind als das IOD.
Mal noch was zu meiner Behauptung:
Im idle hat Dragon Range eine um 42% höhere Package Power als ADL (8,3w vs. 5,8w). Das dürfte ziemlich genau der IFoP-Aufpreis sein. Im Teillastbereich ist der Einfluss womöglich noch stärker.

https://www.notebookcheck.com/AMD-Ryzen-9-7945HX-in-der-Analyse-Zen4-Dragon-Range-ist-schneller-und-effizienter-als-Intel-Raptor-Lake-HX.700526.0.html

Der_Korken

2023-04-12, 23:41:29

8,3W wären am Desktop traumhafte Werte. Da ist selbst bei Zen 4 der ausgelesene Wert noch mindestens doppelt so hoch laut CB-Review. Ich habe mal irgendwo aufgeschnappt, dass IFoP ca. 3W pro Chiplet kostet, aber ich weiß nicht mehr ob sich das auf Zen 3 oder Zen 4 bezog. Zen 4 hat afaik zwei Links pro Chiplet, von denen man einen zum Strom sparen abschalten kann. Lass es also mal 1,5W pro Chiplet sein bei Dragon Range, das wäre relativ genau die Differenz zu Raptor Lake.

Trotzdem scheint sich Dragon Range im Idle nicht mit Ruhm zu bekleckern: https://www.notebookcheck.com/Asus-ROG-Strix-G17-G713PI-Gaming-Laptop-beeindruckt-mit-neuem-Ryzen-9-im-Test.698540.0.html

4h Surfen oder 2h45m Videos gucken mit einem 90Wh-Akku. "Ein Abschalten der dGPU hat im Übrigen nicht zu einer merklichen Verbesserung der Ergebnisse geführt." Natürlich sind solche Laptops darauf nicht optimiert, aber wenn AMD mit Zen 5 mehr Chiplet-Designs für Mobilgeräte umsetzen will, wäre das ein weiteres Argument für InFO-R - selbst wenn es nur 3W einspart.

Nightspider

2023-04-13, 00:02:55

Was im IOD noch am ehesten Sinn machen kann ist ein L4$. Den L3 komplett rausnehmen aber nicht (ausser man geht auf 3D-Stacking von Cores und L3$). Wird interessant, wie die CPU Cores bei MI300 angebunden sind und wie sie den Cache im Base Die nutzen können. Das wäre nämlich so ein L4-Cache.

Dann kann man auch gleich den L3 aus dem CCD rausnehmen, und den L2 aufblasen und vertikal darunter stapeln, damit die Latenzen minimal bleiben. 2 Layer davon und du hast die 5fache Menge an L2 bei gleicher Weglänge wie bisher.
Den großen L3 kannst du dann im oder am IOD haben. :)

Skysnake

2023-04-13, 00:58:02

Muss dann aber auch mal eine dumme Frage stellen.

Als Raptor Lake erschien glänzte dieser vor allem in Spielen mit Raytracing auf Ultra, wo scheinbar noch zusätzliche CPU Last entsteht.

Sind das nicht auch mathematisch relativ simple Fälle, wo man vor allem Integerleistung benötigt?

Ich muss aber zugeben, das ich auch nicht weiß wodurch genau CPU seitig mehr Rechenleistung benötigt wird, wenn die GPU Raytracing berechnen muss.
Keine Ahnung. Man kann sich da ja im Prinzip alle möglichen Spielereien ausdenken mit onloading auf die CPU, weil die Dinge eben effizienter abhandeln kann als die GPU.

Die Integer pipes machen halt noch das branching und die Berechnung der Speicheraddressen usw. Das ist immer nicht so einfach wie die FP Leistung zu bewerten.

Warum?

Beim L1 geht es ja, soweit ich das verstanden habe auch um die Latenz. Je größer der L1 ist, desto schwieriger wird es den Takt zu erhöhen und die Latenz niedrig zu halten. Auch deshalb wurden ja die "L0" eingeführt.
Jaein.

Ja je größer der Cache, desto schwieriger die gleiche Latenz bei gleicher Assoziativität.

Neben der Größte und der Latenz sind beim L1 aber auch noch die Anzahl der Ports und die breite dieser entscheidend. Nicht jeder L1 kann 2 Loads und 1 Store pro Takt machen. Und bei der Breite unterscheiden Sie sich auch teils deutlich.

Dazu kommt dann noch die Assoziativität des Caches. Beim L1 geht es wie bei allen Caches also um einen ganzen Blumenstrauß an Parametern.

Wie schon von anderen gepostet. Je größer der L1 desto mehr threads in flight möglich was ein Indikator für eine uArch mit brutal gesteigerter ILP Extraction (ala Apple Cores) wäre.
Ist wahrscheinlich kein Muss aber ggf ein Indikator, dass die Breite jetzt nicht so krass zulegt.

Der Rest der Cachesituation ist IMO bereits eine gute Mischung aus Größe und Latenz (insbesondere mit vcache). Nachvollziehbar, dass AMD es so gelassen hat.
Die Anzahl der Threads hat nichts mit der Größe des L1 zu tun.

HT/SMT sagt wieviele Threads man inflight halten kann. Die sind nämlich wirklich parallel ausführbar ohne die Registersätze zu sicher und laden. Also einen kontextswitch zu machen.

Der Memory Footprint der ausgeführten Threads/Prozesse ist entscheidend, wie effizient die Umschaltung zwischen denen im Rahmen des Kontext switches ist. Am Ende reicht dir aber schon ein Thread mit nem riesigen Footprint, der dir den cache trashed. Deswegen gibt es ja auch in aktuelleren CPUs auch die Möglichekit QOS beim Cache zu machen um wichtige Prozesse vor Aggressor Apps zu schützen.

Der L1 im K7 konnte aber auch keine drei Loads pro Takt bzw. zwei 256Bit-Operanden pro Takt liefern bei < 1ns Latenz. Man hätte natürlich mmer gerne einen möglichst großen L1, weil Load-Operationen dann weniger stallen. Aber Intel und AMD war beiden der Tradeoff der größeren Latenz zu schlecht. Wenn ein Hersteller den L1 plötzlich stark vergrößern würde, dann nicht ohne Grund, denn das hätte man ja auch schon bei der jetzigen Architektur machen können. Deswegen meine Folgerung, dass ein großer L1 auf eine breite Architektur schließen lässt. robbitops hats glaube ich falsch rum formuliert: Nicht der L1 sorgt für mehr instructions in flight, sondern diese sind eine Voraussetzung, damit ein großer L1 funktioniert.

Nö.

Ein größerer L1 kann auch mit nur einem Thread schon vorteile bringen. Es kommt ganz allein darauf an wie groß die OoO windows sind und wie viele heiße Daten ein Thread/Prozess hat.

CrazyIvan

2023-04-13, 06:51:30

Ich habe mal irgendwo aufgeschnappt, dass IFoP ca. 3W pro Chiplet kostet, aber ich weiß nicht mehr ob sich das auf Zen 3 oder Zen 4 bezog. Zen 4 hat afaik zwei Links pro Chiplet, von denen man einen zum Strom sparen abschalten kann. Lass es also mal 1,5W pro Chiplet sein bei Dragon Range, das wäre relativ genau die Differenz zu Raptor Lake.

Den Wert hast Du womöglich sogar von mir. Das ist nämlich der errechnete Wert, wenn man IFoP Bandbreite mit den kolportierten 1,5-2 pJ/bit multipliziert.
Der zweite Link spart nix, sondern doppelt obige Zahl noch einmal auf. Außerdem kommt der weder bei Raphael, noch Dragon Range zum Einsatz, sondern nur bei EPYC Genoa mit <=4 CCD.

Was man bei der Rechnung nicht vernachlässigen darf: Das ist der Nettoverbrauch direkt am Interconnect, der noch mit sämtlichen Ineffizienzen der Gesamtkette hochmultipliziert werden muss.

mksn7

2023-04-13, 09:08:51

Leonidas

2023-04-13, 12:11:33

Zen 5: Codenamen und Fertigung
Zen 5: Erster CB23-Wert
https://www.3dcenter.org/news/news-des-12-april-2023-0

HOT

2023-04-13, 14:13:26

Da ist wieder bei einigen News was durcheinandergegangen. Gemeint sind jeweils die c-Varianten, also Zen5c mit 3nm und Zen6c mit 2nm.
Zen5 kommt mit 4nm und Zen6 dürfte N3X sein.

"Powermanagement Project based on Zen5(3nm) processor for servers."

https://www.techpowerup.com/307182/amd-zen-5-nirvana-and-zen-6-morpheus-core-codenames-leaked-confirm-foundry-nodes

Es ist mMn ab Zen5 davon auszugehen, dass AMD vor allem 3nm 16C CCDs für Server verbauen wird und weniger die hochgetakteten 4nm 8c CCDs. Die wirds mMn nur noch für spezielle Produkte geben, Finanzwirtschaft z.B.

Der_Korken

2023-04-13, 14:17:01

Finds schade, dass die von den Künstlernamen weggehen. Da Vinci wäre doch was für Zen 5 gewesen :D.

Leonidas

2023-04-13, 15:18:15

Moment! Das sind die Kern-Codenamen. Nicht die Produkt-Codenamen. Sprich: "Da Vinci" ist weiterhin im Rennen, der Nachfolger-Codename von Raphael ist schlicht noch nicht bekannt.

Der_Korken

2023-04-13, 15:35:02

Da steht doch schon Granite Ridge in der Tabelle. Phoenix und Strix Point sind auch schon keine Künstlernamen mehr.

Leonidas

2023-04-14, 06:46:23

Stimmt. Nur noch für Zen 6 möglich - aber die Abkehr von Künstlern scheint es dennoch zu geben.

dildo4u

2023-04-22, 10:14:52

Infos zu den 2024 APU Maximal 40CU 256 Bit LPDDR5X Bus.(Ziel Mobile 4070 95 Watt)

https://abload.de/img/strixm3egs.png

-pQEdpMCrdU

HOT

2023-04-22, 11:38:54

Sieht schwer nach Apple-Weg aus.

BlacKi

2023-04-22, 11:41:45

ist rdna3,5 rdna3 done right?

dildo4u

2023-04-22, 11:56:57

Die aktuellen Modelle sind doch ok alle Gameing Handheld nutzten AMD weil es keine Konkurrenz gibt.

https://www.theverge.com/22579493/valve-steam-deck-gaming-handheld-pc

BlacKi

2023-04-22, 12:05:39

ich sehe das anders. wo ist denn rdna3 wirklich besser als rdna2?

die verbesserungen gehen lediglich auf die verbesserten fertigungsprozesse zurück.

dildo4u

2023-04-22, 12:08:47

Wie gesagt es fehlt aktuell Bandbreite selbst die RX6500 hatte extra Cache auch Intel soll l4 bringen weil LPDDR5X zu langsam ist.

https://www.computerbase.de/2023-04/intel-meteor-lake-grafikeinheit-bekommt-l4-cache-cpu-teil-exklusiv-den-l3/

amdfanuwe

2023-04-22, 12:27:21

Sieht schwer nach Apple-Weg aus.
Du meinst mit RAM on Package?
Hätte Effizienz Vorteile.
Allerdings dürfte die APU dann nicht für Sockel AM5 kommen. Die dicken PHYs für externen RAM wären ja überflüssig.

basix

2023-04-22, 13:37:32

Anscheinend wil AMD mit ihrer APU Strategie Intel, Nvidia (und Apple) gleichzeitig angreifen.

Mit "Strix Halo" geht man den Midrange dGPU Markt im Mobilbereich an. Wenn ~4070 Mobile stimmen (ausserhalb von RT) wäre das ziemlich beeindruckend. Die BOM wird deutlich niedriger sein (LPDDR5 anstatt GDDR, Single Chip vs. Dual-Chip) und zudem wird das deutlich kompakter umsetzbar. Was mir allerdings komisch vorkommt ist das 16C Chiplet. Macht für mich keinen Sinn. Entweder ist das Zen 5c mit 16C oder 2x Zen 5 Chiplet. Anhand der Angabe von 64 MByte L3$ müssten es mMn 2x Zen 5 Chiplets sein.

Das iGPU Chiplet mit 40CU, 32MByte IF$ und 256bit LPDDR5 ist hierbei aber der eigentliche Star. Ich schätze die Die Size auf ~220mm2, was für einen N4 Chip von den Kosten her noch ziemlich OK ist. Und bei den CPU-Cores kann man die bereits bestehenden Chiplets nehmen, womit die Kosten für die SKU nicht durch die Decke gehen. Was ich zwar noch cool finden würde wären 4-8 Zen 5c Cores direkt auf dem iGPU Chiplet, womit man bei der Energieffizienz noch was gewinnen könnte.

Du meinst mit RAM on Package?
Kann man machen. Denke aber, dass dies nicht auf dem Package sein wird. AMD ist nicht Apple, welche ihr Design von A-Z im Griff haben. Bei AMD muss das konfigurierbar/variabel bleiben.

Allerdings dürfte die APU dann nicht für Sockel AM5 kommen. Die dicken PHYs für externen RAM wären ja überflüssig.
Für AM5 macht die SKU keinen Sinn. Hier gibt es mit dem normalen Zen 5, Phoenix und dGPUs mehr als genug Optionen. Für kleine Kraftwürfel kann man Strix Halo immer noch verwenden. Aber dann halt nicht mit AM5.

MSABK

2023-04-22, 13:48:30

Das glaube ich erst wenn ich es sehe, wäre zu schön um wahr zu sein.

dildo4u

2023-04-22, 13:51:13

Das ist über 2 Jahre nach M1 Ultra wenn das nicht kommt stimmt gewaltig was nicht.

bbott

2023-04-22, 13:52:32

ist rdna3,5 rdna3 done right?
Würde ja sagen, weil wenn 3 ok wäre, ständ da wohl nur 3 nicht 3.5.

HOT

2023-04-22, 14:05:12

basix
Das das 16C 8+8c oder gar 4+12c ist dürfte klar sein.

Du meinst mit RAM on Package?
Hätte Effizienz Vorteile.
Allerdings dürfte die APU dann nicht für Sockel AM5 kommen. Die dicken PHYs für externen RAM wären ja überflüssig.
Klar, das Ding ist rein mobil.

mboeller

2023-04-22, 14:48:06

Was ich zwar noch cool finden würde wären 4-8 Zen 5c Cores direkt auf dem iGPU Chiplet, womit man bei der Energieffizienz noch was gewinnen könnte.

ich hoffe eher auf X3D.

basix

2023-04-22, 15:10:07

amdfanuwe

2023-04-22, 15:26:52

Bei dem ganzem muss man die Märkte betrachten:
Desktop CPU 170W TDP + 300+W GPU
Desktop Replacement CPU 55W + GPU
Mobile APU 45W Full HD iGPU
Mobile APU 15+
Mobile Low End (Portfolio aus älteren APUs)

Die Frage ist, wie kann AMD die Märkte mit maximalem Gewinn bedienen?
Bleibt als Phönix Nachfolger ein monolithisches Design oder bringt ein Chiplet Design einen Mehrwert? ( OK, bei 4nm dürfte der Vorteil noch nicht so gravierend sein, also erstmal monolithisch bleiben)
RAM on Package für eine Mobile Variante hätte seine Vorteile in Effizienz und vereinfachtem Design für die OEMs.
Was passiert noch hinsichtlich der C-Cores?
2+4c scheint noch mit ZEN4 anzustehen.
Wenn man viele Cores will, wieviele non-c Cores machen Sinn?
Reichen nicht generell 2 schnelle Cores und der Rest langsame (außer für Gamer)?

CrazyIvan

2023-04-22, 15:52:57

basix
Das das 16C 8+8c oder gar 4+12c ist dürfte klar sein.
Das ist überhaupt nicht klar.
Aufgrund der L3 Größe ist 2 x 8c Zen5 deutlich wahrscheinlicher - bin da ganz bei Amdfanuwe basix. Strix Mono scheint ja für beide Kernarten 2 MByte pro Kern zu haben. Und ganz nebenbei ist das ein weiteres Indiz dafür, dass es mit Zen5 für IFoP endgültig "Farewell" heißt.

CrazyIvan

2023-04-22, 16:09:26

Reichen nicht generell 2 schnelle Cores und der Rest langsame (außer für Gamer)?
2 erscheinen mir ganz allgemein etwas knapp. Aber 4 wie bei Strix Mono klingen für mich vernünftig.

mboeller

2023-04-22, 17:13:06

Wenn sie die Zen 5 Chiplets verwenden ist das ja ohne Probleme möglich. Nur was gewinnst du dort bei Strix Halo? dGPU willst nicht verwenden und für max. ~30 TFLOPs reicht Zen 5 wohl mehr als genug.

weniger GHz für die gleiche (Spiele-) Leistung. Mehr Headroom für die GPU oder längere Laufzeit und/oder leiser.

RBG

2023-04-23, 03:55:21

Für Strix Halo spricht auf jeden Fall die Möglichkeit das man der iGPU wohl mehr als 8 GB Speicher zuweisen kann. Ein echter Vorteil gegenüber den meisten dedizierten Laptop GPUs dieser Leistungsklasse.

HOT

2023-04-23, 08:11:36

Das ist überhaupt nicht klar.
Aufgrund der L3 Größe ist 2 x 8c Zen5 deutlich wahrscheinlicher - bin da ganz bei Amdfanuwe basix. Strix Mono scheint ja für beide Kernarten 2 MByte pro Kern zu haben. Und ganz nebenbei ist das ein weiteres Indiz dafür, dass es mit Zen5 für IFoP endgültig "Farewell" heißt.

Und wie das klar ist. Das sind keine 16 big Cores im mobile. Und schreib nicht so einen Mist, mit IFoP hat das nicht zu tun. Die grossen Zen 5 haben nach wie vor 8 Core CCDs. Das Produkt ersetzt nur eine GPU im mobilesegment durch ein deutlich energieeffizienteres Produkt.

Nightspider

2023-04-23, 08:42:50

Wieso ist in dem Schaubild von MLID von 96MB im GPU Part die Rede?

Wilde Spekulation: Ende 2024 könnte AMD vielleicht auch das N4 GPU Chiplet mit einem N3 Zen5c Chiplet paaren, falls der Cache Aufbau anders ist und der Last Level Cache im günstigeren GPU Part liegt. Deswegen vielleicht 96MB im Schaubild im GPU Chiplet?

Das das 16C 8+8c oder gar 4+12c ist dürfte klar sein.

c Cores killen dir die Effizienz beim Gaming. Games brauchen Cache.

Strix Halo soll wohl der Effizienz-King werden. Wieso sollte man bei dieser highend Gaming APU die Effizienz der CPU killen wollen?

my 2cents:

Fast schon schade das dann 6-9 Monate später vielleicht schon die 3nm GPUs im Mobile aufschlagen könnten.
Wenn AMD 1 Jahr nach Strix Halo den Nachfolger mit 3nm GPU und RDNA4 bringen sollte, dann könnte es richtig interessant werden.

Aber vielleicht beeindruckt der RDNA 3.5 GPU Part in N4 so sehr das trotzdem alle massiv begeistert sein werden.

25W Version für ein Steam Deck 2? ;D Und darauf dann direkt PS5 Games mit 60fps laufen lassen. ;D

robbitop

2023-04-23, 09:04:16

Naja high end. Das Ding hat 40 CUs. Wenn es dann H2 2024 erscheint ist das Einstiegsklasse/unteres Midrange gemessen an dGPUs (blackwell und rdna4 kommen auch h2 2024). Da ist überhaupt kein CPU Bottleneck zu erwarten.

IMO ist das für mobiles Gaming. Gaminghandhelds* und Notebooks. Bei letzterem gräbt man dann den Einstiegs dGPUs den Markt ab. Dann Geforce 4060 und kurz darauf 5050.

Intel will ja auch stärkere GPUs in die SoCs bauen. Gemeinsam wird es dann wahrscheinlich für NVs 107 Chips ggf das Ende im Notebook bedeuten.

*IMO sind 25W schon in der Praxis zu viel für diese Handhelds. Ja es passt rein und lässt sich kühlen aber es ist doch lächerlich, wenn unter 2h der Akku leer ist. Bei einem frischen Akku. Wenn der 1-2 Jahre alt ist sind es noch 1 h.

Für Handhelds sollte man IMO eher 4h beim Gaming (nicht alte Gurken wo der schnelle SoC rumidlet sondern top AAA Games!) anpeilen. Dazu darf das ganze Gerät dann nur 12,5 W ziehen. Also eher 5-7 W für den SoC. Und in dem Betriebspunkt sollte der SoC so effizient wie möglich sein.

Klar kann man sich mit 25W SoCs über lange Balken einen runterholen. Aber in der Praxis führt das dann dazu immer mit Kabel zu spielen (mobile Konsole?) oder die TDP massiv runterzudrehen bei neuen AAA Titeln (und dadurch ist ein Teil der Transistoren einfach verschwendet) oder alte Gurken und Emus zu spielen.
Für 5-7 W müsste man den SoC wohl gänzlich anders auslegen als alle SoCs die MLID angekündigt hat.
Ein IF$ würde Sinn machen da lokale Zugriffe energieeffizienzer sind. Und monolithisch weil effizienter. Und da eh keine besonders hohen Frameraten zu erwarten sind dann möglichst effiziente CPUs. Das könnten auch einfach Zen 5c sein wenn die energieeffizienter als Zen 5 bei 2-4 GHz sind. Und wahrscheinlich gingen maximal 8 CUs.

Ich kann mir gut vorstellen, dass Valve mittelfristig in die Richtung gehen wird. Nicht wesentlich schneller als Rembrandt aber energieefizienter. So kann man das Powerlevel vom Steamdeck länger halten und man muss auf keine großartig andere Powerlevel beim Profiling der Spiele acht geben aber man bekommt potenziell einen effizienteren Handheld.

HOT

2023-04-23, 09:09:57

Klar ist das nur mobile Gaming. Wenn das hat das Ding eher nur c-Cores, wegen der Effizienz. L3$ kann AMD ja soviel einbauen wie sie wollen, das hat ja damit gar nichts zu tun.
Ich denke aber, man wird einige Kerne mit höherem Takt fahren und einige mit nicht so hohem, gemischte Bestückung, so wie in little Pheonix oder eben Strix Point wäre optimal.

basix

2023-04-23, 09:32:37

weniger GHz für die gleiche (Spiele-) Leistung. Mehr Headroom für die GPU oder längere Laufzeit und/oder leiser.
OK, das stimmt. Die CPUs werden vermutlich aber nicht wahnsinng weniger verbrauchen, wenn sie eh bereits bei 3-4 GHz unterwegs sind. Ein Gewinn ist es aber sicher, da hast du recht.

Wieso ist in dem Schaubild von MLID von 96MB im GPU Part die Rede?

64 MByte L3$ = 2x 8C Zen 5 CCD
32 MByte MALL = Infinity Cache auf den GPU-Chiplet (exklusiv für die iGPU)

c Cores killen dir die Effizienz beim Gaming. Games brauchen Cache.

Strix Halo soll wohl der Effizienz-King werden. Wieso sollte man bei dieser highend Gaming APU die Effizienz der CPU killen wollen?

Ja. Zudem die Angabe von 64 MByte L3$ bei 16C. Zen 5c hätte 32 MByte bei 16C.

25W Version für ein Steam Deck 2? ;D Und darauf dann direkt PS5 Games mit 60fps laufen lassen. ;D
Vermutlich etwas teuer ;) Aber bei den 25W frage ich mich ob man das auch im Vollausbau bekäme (25-35W in kleinen und schmalen Notebooks ohne dGPU). Wäre ziemlich cool. Bei nur 8C und 20CU kann man gleich zu Strix Point gehen.

CrazyIvan

2023-04-23, 10:19:02

Und wie das klar ist. Das sind keine 16 big Cores im mobile. Und schreib nicht so einen Mist, mit IFoP hat das nicht zu tun. Die grossen Zen 5 haben nach wie vor 8 Core CCDs. Das Produkt ersetzt nur eine GPU im mobilesegment durch ein deutlich energieeffizienteres Produkt.

Was schreibst Du hier schon wieder für einen Senf zusammen - und vor allem - warum tust Du so, als wüsstest Du, worüber Du schreibst?
Ich baue Dir mal eine kleine Kausalkette zusammen. Wenn Du das in Bildform für niederschwelligen Konsum benötigst, gib Bescheid. Und natürlich handelt es sich dabei - wie zumindest bei mir immer - um ein IMHO:

Wie Du selbst schreibst, bleibt es auch bei Zen5 bei 8c CCDs
Die kolportierten 64 MByte L3 sind zufällig genau die zu erwartende Menge an Cache bei 2 Zen5 CCDs - wäre eines davon Zen5c, wären wir nach heutigem Kenntnisstand bei nur 48 MByte L3, da bei Zen5c ebenso wie bei Bergamo halbiert.
Aller Voraussicht nach wird es bei AMD absehbar kein 8c Zen[4/5]c CCD geben. Bergamo ist ein 16c CCD und in den Mobile-SoCs wie PHX2 und Strix Mono verbaut AMD halt monolithisch die Menge, die es für richtig hält.
Untermauert wird das dadurch, dass zum Beispiel im Desktop eine 8c Zen5 + 8c Zen5c SKU überhaupt keinen Sinn machen würde - dann doch eher 8c Zen5 + 16c Zen5c oder gar 2 * 16c Zen5c.
Strix Halo wird vermutlich InFO-RDL oder EFB für die D2D Verbindung verwenden - IFoP schließe ich bei den TDP-Angaben aus, da zu ineffizient.
Bleibt sich AMD treu, dann wird für Strix Halo genau das Zen5 CCD recycled, welches auch bei Turin und Granite Ridge zum Einsatz kommt. Das ginge genau nur dann, wenn man denselben physischen Interconnect verwendet. Und das wiederum würde (endlich) den Abschied vom IFoP bedeuten.

Und jetzt kannst Du Dich frei fühlen, mir im Rahmen einer Meinungsäußerung aufzuzeigen, wo ich mich womöglich irre.

robbitop

2023-04-23, 10:22:06

Wobei die Frage ist wozu man 16 Cores für gerade mal 40 CUs braucht.
Server APU?

Nightspider

2023-04-23, 10:26:07

Wenn der L3 im GPU Chiplet sitzt, werden die 16 Kerne sehr wenig Platz benötigen.

Aber irgendwie ist das Gesamtbild noch nicht rund.

CrazyIvan

2023-04-23, 10:40:16

@HOT
Und um hier noch einmal die Meta-Ebene zu bemühen...
Was mich an Deinem Diskussionsstil stört, ist folgendes: Du verkaufst Deine Aussagen, als wären sie Fakten. Und zwar nicht mit dem Mittel der Argumentation, sondern vielmehr, indem Du den Eindruck zu erwecken versuchst, als wärst Du entweder ein Insider oder gar ein Prophet.
Dabei bin ich mir nach knapp zwei Jahrzehnten schon ziemlich sicher, dass Du jedenfalls beides nicht bist, sondern Dir auch nur genau die selben öffentlich verfügbaren Informationen vorliegen, wie auch dem Rest der Welt. Und dann finde ich diese Form der Diskussionskultur schlicht und ergreifend anmaßend.

Verstehe mich nicht falsch: Jeder kann mal Quatsch schreiben - mache ich hier und andernorts ständig. Aber ich versuche nicht, den falschen Eindruck zu erwecken, dass ich mehr wüsste als alle anderen.

CrazyIvan

2023-04-23, 10:42:33

Wenn der L3 im GPU Chiplet sitzt, werden die 16 Kerne sehr wenig Platz benötigen.

Daran glaube ich ehrlich gesagt nicht. Das würde die Performance des L3 brutal ausbremsen - siehe die Diskussionen der letzten Wochen zu einem LLC bei AMD bzw. zu Intels SPR.
Ich denke, dass AMD auf absehbare Zeit bei den aktuellen L3-Größen on-die bleibt, und den Rest über V-Cache skaliert.

Nightspider

2023-04-23, 10:49:08

Ich kann es mir auch noch nicht vorstellen.

Wie gesagt, es ergibt noch nicht so richtig viel Sinn.

Complicated

2023-04-23, 11:00:24

Würde ja sagen, weil wenn 3 ok wäre, ständ da wohl nur 3 nicht 3.5.
Jede APU hatte bisher eine verbesserte Version der GPU-Architektur erhalten. Siehe die mit Vega und auch bei RDNA2. Daraus lässt sich kein Problem ableiten. Es zeigt lediglich, dass zu jederzeit die Iterativen Entwicklungen der IP in das nächste Produkt fließen.

Ich glaube eher der Schlüssel ist in dem 40CU Chiplet zu finden. AMD baut sicherlich kein GCD-Chiplet nur für diese teure Highend Notebook-Klasse. Also wo landet AMD mit einem 40CU-Chilpet bei diskreten GPUs?
- Es sind 8 CUs mehr als N33
- 2x40CUs (Ein 2xGCD Design) sind 16 CU weniger als 7900XTX und 4 CU weniger als 7900XT (N31)
- N32 soll ein kleineres GCD haben als N31, ein weiteres 60CU Chiplet? Oder direkt als 2xGCD geplant mit 2x40 CU? Das würde aber nicht wirklich zu dem 84CU Salvage passen für die 7900XT
- ein reines Chiplet mit 40 CU um mobile dGPUs komplett zu ersetzen? Also ohne Wiederverwertung bei dGPU.

Ich glaube bei der Betrachtung könnten auch die Rückschlüsse zum restlichen Aufbau der APU besser gezogen werden.

basix

2023-04-23, 12:18:20

Wobei die Frage ist wozu man 16 Cores für gerade mal 40 CUs braucht.
Server APU?

Wieso nicht? Bei nur 8C würde man in allen multithreaded CPU-Tests gegen Raptor Lake, Meteor Lake und Arrow Lake abstinken.

Ausserdem gibt es noch sowas wie Workstation-Anwendungen ;) Dort will man allenfalls mehr CPU-Cores und für CAD-Design usw. wäre die GPU-Leistungsklasse mehr als ausreichend und man grätscht in Nvidias Mobile Quadros rein. Ausserdem ist das doch gerade das grosse Thema bei Apples Chips: Content Creation / Arbeitsgerät

Ich glaube eher der Schlüssel ist in dem 40CU Chiplet zu finden. AMD baut sicherlich kein GCD-Chiplet nur für diese teure Highend Notebook-Klasse.
Wie oben geschrieben: Es gibt nicht nur Gamer ;) Auch Content Creation (siehe Apple) und Mobile Workstation (Industrie) sind ein grosses Thema. Fast keiner hat noch einen Tower als Arbeitsgerät. Notebooks & Mobile Workstations sind der Standard. Tower sind vereinzelt als lokale Simulationsrechner vorhanden und der Rest geht in die Cloud.

Heute sind das in eigentlich allen Workstation Rechnern bei uns in der Firma entweder APUs (Thin Notebooks) oder Nvidia Quadro. Kann AMD mit einer grossen APU die kleineren und mittleren Quadros angreifen: Riesiger Win!

Also wo landet AMD mit einem 40CU-Chilpet bei diskreten GPUs?
- Es sind 8 CUs mehr als N33
- 2x40CUs (Ein 2xGCD Design) sind 16 CU weniger als 7900XTX und 4 CU weniger als 7900XT (N31)
- N32 soll ein kleineres GCD haben als N31, ein weiteres 60CU Chiplet? Oder direkt als 2xGCD geplant mit 2x40 CU? Das würde aber nicht wirklich zu dem 84CU Salvage passen für die 7900XT
- ein reines Chiplet mit 40 CU um mobile dGPUs komplett zu ersetzen? Also ohne Wiederverwertung bei dGPU.
Dual-GCD sehe ich bei Strix Halo als ausgeschlossen an. Dafür ist das Ding einfach nicht ausgelegt (müsste ja massiv breite Interconnects zwischen den zwei GCDs haben, dazu noch Verdopplung aller Multimedia und IO-Sachen).

Interessant ist aber der Gedanke, das Ding als Standalone GPU zu benutzen. Mit LPDDR5 wäre das relativ günstig. USB4 und andere Sachen sind dann nutzlos aber wieso nicht. Gegenüber von z.B. N33 sehe ich den Vorteil mit Ausnahme LPDDR5 aber nicht unbedingt (Kosten für den Chip als dGPU). Da macht es am Schluss dann irgendwie doch viel mehr Sinn, beides N33 und auch die CPU mit Strix Halo komplett zu ersetzen (GPU-Chiplet + CPU-Chiplets). Mehr Performance und geringere Kosten in einem. Und wenn man eine Intel CPU mit einer dGPU koppeln will, nimmt man N33.

Nightspider

2023-04-23, 12:25:58

Da die Strix Halo GPU mit LPDDR5X arbeiten wird, wird es einige dedizierte Lösung werden und kein Chiplet, den wir aus den Desktop GPUs kennen.

Zeigt ja schon der skizzierte Aufbau von MLID und die RDNA 3.5 µArch.

basix

2023-04-23, 12:36:48

Ich sehe es auch als dedizierte Lösung an.

Damit kann man vermutlich ~80% des Mobile dGPU Marktes angreifen (alles bis ~100W) und spart zudem noch Kosten:
- LPDDR5 anstatt GDDR6 (günstiger und grössere Kapazitäten, da schlägt man auch die Quadros um Längen)
- Multimedia (Video & Display Engine) & IO-Sachen (PCIe, DPort, HDMI) sind nur 1x vorhanden anstatt 2x (1x auf APU, 1x auf dGPU) --> Die sind mittlerweile recht fett geworden und hat man z.B. bei N24 dramatisch abgespeckt
- Platzsparender auf PCB / im Gehäuse da nur 1x Chip. Mit den neueren LPDDR5 Packages könnte man sogar bei 4x Packages bleiben (max. 48 GByte DRAM) und trotz doppelt so breitem Speicherinterface nicht wesentlich mehr Platz benötigen (siehe Apple M1/M2 Pro, aber on PCB und nicht on-Package). Theoretisch wären bei 256bit sogar 2x Packages machbar, siehe M2 Max

CrazyIvan

2023-04-23, 12:44:19

mboeller

2023-04-23, 13:50:52

Wenn der L3 im GPU Chiplet sitzt, werden die 16 Kerne sehr wenig Platz benötigen.

Aber irgendwie ist das Gesamtbild noch nicht rund.

Wenn ich mich an das Video richtig erinnere steht in den Slides Gesamt-L3 "96MB". Nachgeschaut: im Video nach 19min 45sec (GPU mit 32MB IF$) + im Video bei 17min 40sec sieht man es in der Tabelle auch sehr schön.

IMHO 2x 32MB pro CCD + 32MB für die GPU macht damit am meisten Sinn.

Die 96MB im Chart selbst sind IMHO etwas irreführend. Ebenfalls im Video bei 17min 40sec

basix

2023-04-23, 14:05:59

@basix & Complicated
Ja, wirklich sehr interessante Thesen.
Und wenn wir schon dabei sind, warum dann nicht gleich GCD und MCD separat, sodass man das standalone mit einem anderen MCD verwenden könnte und der IF-Cache wiederum zusammen mit dem MC auf einem Legacy-Prozess landet?
Da das, was in dem Schaubild als CPU Die bezeichnet wird, vermutlich auch nicht genau ein Die sein wird, kann das auch auf den anderen "Die" zutreffen.
Ich vermute, das man hier das Konstrukt simpel halten will und die Effizienz Priorität hat. Da hat ein monolithischer Chip Vorteile. Wie gesagt, ich schätze das N4 GPU-Chiplet auf ~220mm2. Das ist machbar. Wenn man die GPU rauslöst, wären das in etwa 80mm2 und inkl. IF$ etwas mehr als 100mm2. Das könnte man evtl. machen: CPU CCDs, IOD, GPU-Chiplet inkl. Infinity-Cache. Das IOD ihne iGPU wäre dann etwas grösser als 100mm2. Was man dann allerdings verlieren würde: Display Refresh aus dem Infinity Cache und allgemein wird die Energieffizienz leiden, wenn die GPU was machen muss. Ein monolithisches IOD + iGPU Die hat hier schon Vorteile und die Chipgrösse ist wie gesagt nicht enorm gross.

MCDs wie bei N31 machen weniger Sinn, die CPU will ja auch an den Speicher angeschlossen werden und das mit möglichst geringer Latenz.

IMHO 2x 32MB pro CCD + 32MB für die GPU macht damit am meisten Sinn.

So interpretiere ich das auch.

CrazyIvan

2023-04-23, 14:21:04

@basix
Ja, stimmt schon. So wenig Segmentierung wie möglich macht hier wohl Sinn.
Finde es auch lustig, wenn behauptet wird, das MTL automatisch und allein aufgrund der Tile Architektur super effizient würde - das Gegenteil ist richtig.

basix

2023-04-23, 14:37:50

Grundsätzlich führen alle Chip-to-Chip Interfaces zu zusätzlichem Energiebedarf. Mit Tiles ist Binning allenfalls einfacher, was bei der Effizienz helfen kann. Was mehr ausmacht, ist dann stark abhängig von Design und Produkt. Automatisch effizient wird es aber definitiv nicht.

bbott

2023-04-23, 17:43:05

Jede APU hatte bisher eine verbesserte Version der GPU-Architektur erhalten. Siehe die mit Vega und auch bei RDNA2. Daraus lässt sich kein Problem ableiten. Es zeigt lediglich, dass zu jederzeit die Iterativen Entwicklungen der IP in das nächste Produkt fließen.

Ich glaube eher der Schlüssel ist in dem 40CU Chiplet zu finden. AMD baut sicherlich kein GCD-Chiplet nur für diese teure Highend Notebook-Klasse. Also wo landet AMD mit einem 40CU-Chilpet bei diskreten GPUs?
- Es sind 8 CUs mehr als N33
- 2x40CUs (Ein 2xGCD Design) sind 16 CU weniger als 7900XTX und 4 CU weniger als 7900XT (N31)
- N32 soll ein kleineres GCD haben als N31, ein weiteres 60CU Chiplet? Oder direkt als 2xGCD geplant mit 2x40 CU? Das würde aber nicht wirklich zu dem 84CU Salvage passen für die 7900XT
- ein reines Chiplet mit 40 CU um mobile dGPUs komplett zu ersetzen? Also ohne Wiederverwertung bei dGPU.

Ich glaube bei der Betrachtung könnten auch die Rückschlüsse zum restlichen Aufbau der APU besser gezogen werden.
Die wuden aber nicht mit .5 sondern mit + oder so gekennzeichnet, was in meinem Umfeld eine kleinere Verbesserung bedeutet als .5 ;-) Aber wir werden sehen :-)

Zossel

2023-04-23, 18:12:01

20 Jahre X64:

https://www.heise.de/hintergrund/20-Jahre-64-Bit-CPUs-von-AMD-Der-Sledgehammer-Opteron-zuendete-x86-64-8974232.html

amdfanuwe

2023-04-23, 23:09:48

Wo wir es letztens von Cache Latenzy hatten:
Hier ein Artikel von Chips and Cheese zum L3 V-Cache im Vergleich zum EDO RAM von Intel damals.
https://chipsandcheese.com/2023/04/23/amds-7950x3d-zen-4-gets-vcache/

dildo4u

2023-04-24, 07:20:57

Interessant das wir das alles erstmals nicht im Desktop sehen werden sowohl bei Intel und AMD gibt die fetten APU vermutlich erstmal nicht im Desktop oder vielleicht sogar nie.
Was meint ihr ist der maximale CU Count auf AM5 12/16? für RDNA3.5.

basix

2023-04-24, 08:39:08

Strix Point soll mit 16 CU kommen. Also 16. Danach wechselt man hoffentlich auf RDNA4 ;)

amdfanuwe

2023-04-24, 12:46:41

Interessant das wir das alles erstmals nicht im Desktop sehen werden
Wozu auch. Desktop braucht man eigentlich nur noch wenn man eine dicke GPU dazu stecken will, oder im industriellem Bereich andere Erweiterungskarten.
Für daheim gibt es mini PCs mit APU.

w0mbat

2023-04-26, 22:28:14

Neue Zen 5 Infos ab 12:20

3FDh9C59Z1A

Der_Korken

2023-04-27, 00:40:46

2-3MB L2-Cache: Klingt nach stacked L2, wenn die Latenz dabei nicht steigen soll. Habe ich mich schon vorher gefragt, ob das mit dem aktuellen Layout nicht möglich wäre.
7% IPC in MT durch größeren L2, aber nur 1% in ST: Die Begründung, dass ein Thread so viel Cache gar nicht voll bekommt, ist für mich Quatsch. Wenn, dann könnte man sagen, dass der L3-Pressur durch den großen L2 sinkt und somit bei MT der L3 besser mithalten kann bzw. weniger zum Flaschenhals wird.
Was ist eine Ladder Topology im Zusammenhang mit Caches? Glaube kaum, dass das bei 8 Kernen schon was bringt, wenn sowohl Intel als auch AMD ihre 8-Kerner am Ende mit einem Ring gebaut haben.
Bei 11:55 redet er über Intels Mesh, aber zeigt ein Bild mit Ringbus. Weiß er worüber er redet?

CrazyIvan

2023-04-27, 06:42:16

Wenn ich das bei Twitter so richtig mitbekomme, dann scheint sich Jim mit Formel 1 besser auszukennen, als mit Halbleitern :biggrin:

dildo4u

2023-05-12, 07:11:43

3FsUTYnQNOA

DozerDave

2023-05-12, 08:56:56

Habe das Video auch gesehen. Aber was ist die neuen Infos die präsentiert werden? Am Anfang wiederholt MLID nur was adored in seinem letzten Video gezeigt hat.

HOT

2023-05-12, 11:43:25

Das Video zeigt vor allem, dass im Server Zen5c in N3 vor Zen5 kommt, Zen5-Desktop weit vor beidem. Und Tom denkt, dass es die X3D erst als ARL-Antwort geben wird, weil AMD die vorher nicht benötigt um vorne zu sein. Fänd ich eher scheiße, muss ich halt bis ARL warten - hat natürlich auch sein gutes, denn dann kann man sich aussuchen ob Zen5X3D besser ist oder ARL ;). Wenn der X3D vorher gekommen wäre, hätte ich den sicher ohne zu fragen gekauft.

Edit: Sind ja jetzt neue News draußen. Zen5c wird wohl in N3 tatsächlich den Anfang machen im Servermarkt, aber im Desktop wirds wohl doch erst im H2 was. Offenbar hatte Tom recht und es gab 2 Varianten in Entwicklung, eine in N4 und eine in N3. Letztendlich hat sich offenbar N3 als sinnvoller herausgestellt, da N3 1/2 Jahr verzögerung hat, wird Zen5 wohl auch erst 2H 24 in N3 erscheinen, nicht in N4. Das würde auch den späten Launch der X3D besser erklären.

Also Zen5 (Granite Ridge)
Erscheinung 2H 24, nicht 1H 24
N3 nicht N4
ansoinsten alle Daten wie vorher spekuliert.

Strix Point ist offenbar die einzige Zen5-xPU in N4 und wird wohl in der Generation den Anfang machen in H1 24.

Leonidas

2023-05-15, 11:18:32

AMD Ryzen 8000 ("Granite Ridge")
Zen 5 CCDs ("Eldora")
Zen 5 CPU Cores ("Nirvana")
6 bis 16 Zen-5-Prozessorkerne
65 bis 170 Watt Verlustleistung ("TDP")
Bis zu 64 MiByte L3-Cache und 16 MiByte L2-Cache
Fertigung in N3E oder N3P bei TSMC
Release im 2. Halbjahr 2024

Quelle: PCGH (https://www.pcgameshardware.de/CPU-CPU-154106/News/AMD-Ryzen-8000-Granite-Ridge-Desktop-CPUs-1419743/), welche die hierzu passende AMD-Folie vorliegen haben wollen

basix

2023-05-15, 11:26:50

N3 für die Zen 5 CCDs wäre etwas überraschend. Hätte das nur für Zen 5c erwartet.

robbitop

2023-05-15, 11:27:54

Wobei sich PCGH im selben Artikel selbst widerspricht:

Die Eckdaten bestätigen sich nach und nach
Wie bereits zuvor spekuliert wurde, wird sich die Anzahl, der sogenannte Core Count, der zukünftig auf Zen 5 basierenden und in 4 Nanometern weiterhin beim weltgrößten Auftragsfertiger TSMC vom Band laufenden Prozessorkerne nicht ändern. Aus einem authentischen Dokument, welches dem Autor dieser Meldung entsprechend vorliegt, aber aus Gründen des Quellenschutzes nicht veröffentlicht werden kann, geht nun hervor, dass AMD Ryzen 8000 im Desktop die folgenden Eckdaten haben wird.

AMD Ryzen 8000 ("Granite Ridge")

Zen 5 CCDs ("Eldora")
Zen 5 CPU Cores ("Nirvana")
6 bis 16 Zen-5-Prozessorkerne
65 bis 170 Watt Verlustleistung ("TDP")
Bis zu 64 MiByte L3-Cache und 16 MiByte L2-Cache
Fertigung in N3E oder N3P bei TSMC
Release im 2. Halbjahr 2024

https://www.pcgameshardware.de/CPU-CPU-154106/News/AMD-Ryzen-8000-Granite-Ridge-Desktop-CPUs-1419743/

Was denn nun? 3nm oder 4 nm?

Die großen Leaker (die sich zugegeben auch oft genug stark geirrt haben!) sprechen von 4 nm für Desktop und 3 nm für eine Dense Version für Server. (wobei mir noch nicht klar ist, wie das zusammenpassen soll - Server und Desktop teilten sich bisher die CCDs - ggf. ist das 3 nm die ja für Zen 5c? das Wort "dense" würde dazu passen)

HOT

2023-05-15, 11:54:46

Derzeitiger Stand ist auf jeden Fall 3nm. 4nm ist nur die Strix-Point APU und das Strix Halo IOD.

Den Anfang macht Strix Point (N4), dann
- Zen5c Server (N3)
- Zen5 Desktop (N3e)
- Zen5 Server+Zen5 AI (N3e)
- Strix Halo (N4+N3(e))
- Zen5 X3D (N3e)

und schon sind wir in 25 ;).
- Zen5 Server X3D (N3e)
Ich wette, da gehts dann mit ner 3nm-Zen5-APU weiter.

Zen5c scheint "nur" N3 zu sein, während Zen5 non-c N3P oder e zu sein scheint, kein Wunder also, dass er später ist als der c.

iamthebear

2023-05-15, 12:33:03

Und du glaubst ernsthaft, dass AMD nur für eine APU Zen5 extra zusätzlich auf 4nm designed?

Wahrscheinlich ist:
.) PCGH hat sich vertippt und das hätte N4P heißen sollen
.) Client kommt in 4nm mit 8 Kernen pro CCD
.) Server kommt in 3nm mit 16 Kernen pro CCD

Auch möglich:
.) Die Leaks waren bs und Zen5 ist 3nm only wobei der Mainstream/Midrange Bereich weiterhin von Zen4 abgedeckt wird, denn um alles in 3nm zu machen fehlt AMD mit Sicherheit die Kapazität

Für den Gamingmarkt sieht es für Intel gar nicht mal so schlecht aus. Im Herbst kommt noch einmal ein kleiner Refresh. Damit sollte man sich die Gamingkrone holen bzw. zumindest für Gleichstand sorgen selbst wenn AMD noch mal ein paar MHz drauf legt.

Zen5 wird bei Launch dasselbe Problem haben wie Zen4, dass er ohne VCache nicht am Vorgänger vorbei kommt und bis Zen5 VCache launched sind wir schon in 2025 und bis dahin sollte Intel Arrow Lake schon am Markt haben.

Im Mobilebereich sollte man mit Meteor Lake zumindest so weit sein, dass einem die OEMs nicht alle zu AMD rennen für den 15W Bereich.

Das Einzige wo ich für Intel schwarz sehe ist der High End Serverbereich. Der dürfte wohl endgültig verloren sein.

HOT

2023-05-15, 13:17:36

Haben sie ja nicht. Das Gerücht war ja, dass AMD auf Nummer sicher gegangen ist und Zen5 sowohl für N4 als auch für N3 designt hat und genau das gibt die offizielle Roadmap ja auch wider. Es gibt hier also gar kein Problem.

Der_Korken

2023-05-15, 13:45:57

2H2024 ist aber ganz schön spät. Zen 4 hat sich ja schon etwas verspätet bzw. wurde lange für 1H2022 erwartet, aber das Team von Zen 5 hätte davon ja nicht betroffen sein müssen. Von Zen 2 auf 3 ging ja auch deutlich schneller als von 1 auf 2, obwohl 3 der größere Umbau in den Kernen war.

Für Intel wären das natürlich gute Nachrichten, weil sie dadurch Zeit hätten sich mit der eigenen neuen Architektur zu positionieren. Die IPC-Prognose für Zen 5 lag zuletzt auch "nur" noch bei gut 20%. Ausgehend davon, dass Raptor Lake in 1T schon jetzt leicht führt, wäre man mit einer weiteren Cove-Iterationen durchaus auf Augenhöhe. Bei der MT-Effizienz könnte es mit neueren Cove-Kernen, eigenen Voltage-Rails für die E-Cores und generell neuerer Fertigung auch schnell bergauf gehen. Bereits der RTL-R soll hier im gleichen Prozess nochmal ordentlich Effizienz bringen.

Auf mich wirkt das so, als würde AMDs Vorsprung langsam verpuffen, weil sei das Tempo der ersten Zen-Iterationen nicht mehr halten können und Intel im Gegenzug auch gute Fortschritte macht. Es war natürlich klar, dass es irgendwann so kommt, denn dafür ist Intel einfach zu groß und hat auch selber genug gute Leute. Aber als Hardware-Nerd hat man natürlich gehofft, dass Zen 5 der nächste große (und zeitnahe!) Wurf wird, der wieder alles andere in den Boden stampft :D

Wenn ich bis 2H24 warten muss, könnte das nächste System für mich auch gut wieder Intel werden, wo ich mir vor einem Jahr noch sicher gewesen wäre, dass meine nächste Plattform AM5 heißen würde.

amdfanuwe

2023-05-15, 13:46:07

Stand Müll.

Ich nehme eher an ZEN 5 erstmal 4nm und APU 3nm

basix

2023-05-15, 13:50:14

Die großen Leaker (die sich zugegeben auch oft genug stark geirrt haben!) sprechen von 4 nm für Desktop und 3 nm für eine Dense Version für Server. (wobei mir noch nicht klar ist, wie das zusammenpassen soll - Server und Desktop teilten sich bisher die CCDs - ggf. ist das 3 nm die ja für Zen 5c? das Wort "dense" würde dazu passen)

"Dense" ist für 4c/5c gemeint ja. Die initalen Gerüchte sprachen sogar von Zen 4D ;)

Bergamo- und Siena-Nachfolger setzen auf Zen 5c, weswegen das Stichwort Server dort schon Sinn macht. Kann auch gut sein, dass die "normalen" Zen 5 in gewissen Bereichen mit 5c ersetzt werden. Zen 5 ist eigentlich nur noch hinsichtlich max. ST Performance & HPC interessant (und natürlich Desktop). 4c/5c werden hinsichtlich Cores/$ oder Performance/$ bei vielen Anwendungen und Services auf Seiten Server vermutlich attraktiver sein. Die "Dense" Cores können halt zu geringeren Kosten produziert werden.

HOT

2023-05-15, 13:50:47

amdfanuwe
Strix Point ist in 4nm ja quasi bestätigt, auf jeden Fall aber sehr sicher.

Und ein Zen5 in N3P/e wasauchimmer hat sicherlich mehr zu bieten als in N4. Von daher sind die Performanceprognosen eh sehr vage.

basix

2023-05-15, 14:00:50

Strix Point / Halo und das normale Zen 5 CCD kommen mMn in N4 und nur Zen 5c in N3E. Ist nicht nur eine Frage von "es geht" sondern auch von der Verfügbarkeit. Apple wird kurzfristig fast alles an N3 wegfressen, da würde ich einen so breiten Release in N3 nicht anstreben. Bei N4/N5 wird aber massig Kapazität frei, da Apple eben wechselt.

HOT

2023-05-15, 14:02:50

Das ist falsch nach dem bisherigen Informationsstand.

- Strix Point ist eine monolithische 4nm-APU mit 12 Kernen, die Phoenix Point folgt.
- Strix Halo ist ein 4nm IOD, das 40 RDNA3+ CUs enthält und mit 256Bit RAM ausgestattet ist. Gepaart wird das IOD mit Zen5-Chiplet(s). Hier ist die Streitfrage nur, welche.

AMD gehört zu TSMCs Exklusivpartnern und hat vollen Zugriff auf N3. Apple ist dieses Jahr dran, AMD dann nächstes. N4 wird aus Kapazitätsgründen sicher nicht notwendig sein. Man könnte sich hier höchstens über Kosten unterhalten - aber bei 60-80mm²? Bitte...

basix

2023-05-15, 14:05:10

Und inwiefern widerspricht das von mir gesagte deiner Auflistung? Sehe deinen Punkt nicht.

Strix Halo wird mMn mit den normalen Zen 5 kommen. Hier geht es um maximale Performance.

AMD gehört zu TSMCs Exklusivpartnern und hat vollen Zugriff auf N3. Apple ist dieses Jahr dran, AMD dann nächstes. N4 wird aus Kapazitätsgründen sicher nicht notwendig sein. Man könnte sich hier höchstens über Kosten unterhalten - aber bei 60-80mm²? Bitte...
AMD muss unbedingt mehr Kapazität haben. Wieso sind alle APUs immer spät dran? Meistens ein Thema der Verfügbarkeit. Da ändert auch nichts dran, dass AMD Exklusivpartner ist. TSMCs Auftragsbücher sind voll.
Ach ja, Intel soll sich auch noch einen guten Teil N3 geschnappt haben (mit viel Geld)

N3 nützt bei Zen 5c, MI400 und anderen Data Center Produkten bedeutend mehr als bei Consumer Zen 5 CCDs. Das bringt man eher an der Konkurrenz vorbei, ohne allzu viel zu bezahlen zu müssen. Und hat den grössten wirtschaftlichen / technischen Impact (Konkurrenzfähigkeit).

iamthebear

2023-05-15, 15:11:03

Und ein Zen5 in N3P/e wasauchimmer hat sicherlich mehr zu bieten als in N4. Von daher sind die Performanceprognosen eh sehr vage.

Damit die Nodes nicht durcheinander kommen hier mal die aktuelle TSMC Roadmap:
https://cdn.wccftech.com/wp-content/uploads/2023/04/TSMC-Process-Technology-Roadmap-_1-gigapixel-low_res-scale-4_00x-Custom.png

Vom Zeitpunkt der Massenfertigung bis zum Release erster Produkte dauert es ca. 1 Jahr mit Ausnahme von Apple, da diese den Prozess mitentwickeln.

Das bedeutet in etwa:

N7: 2019 (Zen2)
N7+: 2020 (Zen3)
N5: 2021
N5P: 2022 (Zen4)
N4: 2023 (Zen4 APUs)
N3/N4P: 2024 (Zen5)
N3E: 2025 (Zen5 weitere Modelle???)
N2/N3P/N3X: 2026 (Zen6)
N2P/N2X: 2027

Zen5 kann 2024 nicht in N3P kommen. N3E wäre theoretisch noch möchlich aber auch unwahrscheinlich.
Deswegen meine Vermutung: PCGH hat N4P gemeint nachdem sievorher schon von 4nm gesprochen haben.

Aktueller Leak Stand bzw. das Einzige, was einigermaßen Sinn ergibt ist:
.) Server in N3, da dort ähnlich wie bei Smartphone ein niedriger Energiebedarf gefordert ist und keine hohen Spitzentaktraten erzielt werden müssen (die der Vanilla N3 vermutlich noch nicht schafft).
.) Desktop und High End Laptop in N4P, da hier in erster Linie hohe Spitzentaktraten gefordert sind und man mehr L3/Kern braucht, der mit 3nm sowieso nicht mehr skaliert.
.) Low End/Midrange Laptop: Wird vermutlich noch einige Zeit Zen3 + Zen4 bleiben da billiger und der 0815 Käufer durchschaut das neue Namensschema sowieso nicht.

KarlKastor

2023-05-15, 15:24:28

- Zen5c Server (N3)
- Zen5 Desktop (N3e)

Es wird garantiert rein gar nichts von AMD in N3 vanilla kommen.

CrazyIvan

2023-05-16, 08:38:54

Das halte ich auch für zumindest unwahrscheinlich. TSMC hatte gefühlt seit einem Jahrzehnt keine so großen Probleme mehr wie bei diesem Prozess.
N4 für das Zen5 CCD und N3e für Zen5c klingt für mich auch am realistischsten. Sicher wird AMD auch recht gut wissen, wie es bei Intel so aussieht und im Vergleich scheint das schlicht und ergreifend gut genug zu sein.

HOT

2023-05-16, 09:02:18

Es gibt keine Probleme mit N3 :freak:. Apple nutzt den Prozess ja, das Märchen hält sich aber auch echt hartnäckig.
Es gab 1/2 Jahr Verzögerung, das wars.

Finch

2023-05-16, 09:06:00

Es gibt keine Probleme mit N3 :freak:. Apple nutzt den Prozess ja, das Märchen hält sich aber auch echt hartnäckig.
Es gab 1/2 Jahr Verzögerung, das wars.

Die Frage ist, was Apple zahlt um mögliche schlechte yields zu kompensieren, andererseits ist das Volumen so große, dass ich bezweifle, dass es schlechte yields gibt. Ich denke du hast recht.

HOT

2023-05-16, 09:14:16

N3e/P/X sind leistungsfähiger als der ursprüngliche N3, das ist aber für Zen5c egal, hier zählt Packdichte und Stromverbrauch.

Leonidas

2023-05-16, 09:20:54

robbitop

2023-05-16, 09:33:11

Leonidas

2023-05-16, 09:38:41

CrazyIvan

2023-05-16, 10:07:36

@HOT
Ich folge bezüglich der N3-Thematik dem "Wo Rauch ist, da ist auch Feuer" Ansatz. Und Rauch gab es dazu viel mehr als bei vorherigen Prozessen.

HOT

2023-05-16, 12:10:20

Richtig, es gibt keine Gewißheit. Und Du bringst wieder ein gutes Gegenargument: Anfangs geringe (verfügbare) N3-Kapazitäten, deswegen schlecht geeignet für ein Haupt-Projekte. Wir müssen uns also doch überraschen lassen.
Das halte ich für Unsinn, weil die Produkte ja gestaffelt kommen. Klar, Apple belegt das erste halbe Jahr wieder 100% davon, dann aber werden die Produkte suksessive mehr werden, von AMD recht schnell, weil die auch Exklusivpartner sind.

@HOT
Ich folge bezüglich der N3-Thematik dem "Wo Rauch ist, da ist auch Feuer" Ansatz. Und Rauch gab es dazu viel mehr als bei vorherigen Prozessen.

wohl eher der "viel Lärm um nichts"-Ansatz.

iamthebear

2023-05-17, 13:07:17

Die 2 Hauptargumente, die für mich für 3nm Zen5c sprechen sind:

a) Diese werden in CPUs mit > 128 Kernen verwendet wo der Energieverbrauch ein sehr großes Kriterium ist. Und dieser ist bei 3nm eben deutlich besser.

b) Der Logikanteil ist höher. Selbst wenn die Zen5c etwas kompakter sind: 16 Kerne davon sind trotzdem größer als 8 Zen5 Kerne.

Weiters kommt noch hinzu, dass 3nm eventuell noch nicht in der Lage ist die Spitzentaktraten zu liefern wie es N4P kann.

Complicated

2023-05-17, 13:46:08

Klar, Apple belegt das erste halbe Jahr wieder 100% davon
Und hier liegt auch eines der Ziele des Chipletdesigns. Ebenso früh mit den Chipgrößen solche Yieldraten und Preispunkte zu erzielen, um diesen 6 Monate time-to-market-Vorteil ebenfalls zu nutzen. Hier könnte Zen5c die Kriterien als Chiplet möglicherweise erstmals erfüllen und die ersten Bestellungen für diese SKUs kompensieren das Yieldrisiko.

Schlußendlich arbeitet AMD genau darauf hin.

basix

2023-05-17, 13:48:50

Ich vermute inzwischen, dass MLID hier einer Verdrehung aufgesessen sind: Nicht Zen5c in 3nm und Zen5 in 4nm - sondern exakt umgekehrt. Warum?
- Zen5c steht zuerst in der Roadmap, macht sich schlecht bei einem jüngeren Fertigungsverfahren.
- Wieso die kleineren, taktschwächeren Kerne für die billigen Prozessoren im besseren Fertigungsverfahren?
- Wieso die größeren, taktstärkeren Kerne für die teuren Prozessoren im schlechteren Fertigungsverfahren?
- Das Argument 16c-CCD zieht nicht, denn wegen der Dense-Kerne dürfte es (unter angenommen gleicher Fertigung) nicht größer sein als das 8C-CCD. Wenn ich zwei gleich große CCDs haben, wieso ausgerechnet das unbedeutendere Projekt in der besseren Fertigung?

Die Timeline sieht in der Tat nicht wie erwartet aus. Aber wenn N3E ready ist und AMD Priorität auf dieses Projekt legt, wieso nicht? Zen 4/5c werden mMn viele der normalen Anwendungen abdecken und die anderen Kerne kommen primär bei Fällen hoher ST Performance zum Einsatz (z.B. Kernanzahl basierte SW-Lizenzen). Alles mit Container und Microservices (Grossteil der Cloud Anwendungen) ist bei den kleinen Cores oftmals mehr als gut aufgehoben. Dazu kommt evtl. noch dazu, dass der maximale Throughput auch inkl. AVX höher sein kann, da mehr Kerne vorhanden sind (falls die AVX Einheit nicht zurzückgestutzt wurde). Auch bei Standard-Servern in kleinen bis mittelgrossen Betrieben ist ein Zen 5c Core mehr als stark genug für den Betrieb der IT-Infrastruktur - und dabei pro Core billiger = weniger Server nötig = günstigere Infrastruktur.
Die kleinere taktschwächeren Kerne kommen in den teureren Server SKUs zum Einsatz und nicht bei "billigen" Consumer Produkten ;)
N4P / N4X ist afaik in etwa gleichauf mit N3E was Taktbarkeit anbelangt. Mit höheren Spannungen sollte N4 wegziehen
Bei 16C ist der Logikanteil wie von iambthebear angesprochen deutlich höher. Hier lohnt sich N3 eher, da faktisch Null SRAM Scaling vs. N5
Dann noch die Frage, ob das CCD und die Cores bei 8C in N3E fast schon zu klein werden würden (Power Density, Hot Spots) wenn man die Kerne taktmässig hochprügelt

KarlKastor

2023-05-17, 14:18:37

TSMC gibt die Performance von N3E mit +15-20% an, N4X mit +15% und N4P +11%. Jeweils gegenüber N5. Für den Desktop ist das wohl interessant.
Für Epyc ist aber die Effizienz interessanter wenn man wieder die Kernzahl erhöht. Und da macht N3E einen ordentlichen Sprung.

Nightspider

2023-05-17, 18:19:03

Ich ordne die PCGH Leaks jetzt auch eher als "unwahrscheinlich" ein und erwarte Zen5 noch im 2. Quartal 2024.

Es hieß immer das Zen5 schneller auf Zen4 folgen soll als Zen4 auf Zen3.

Mit den spekulierten 20-25% IPC Zuwachs und etwaigen Taktvorteilen könnte Zen5 im Durchschnitt in Games auch knapp vor Zen4D landen.

Und die V-Cache Varianten sollen ja zukünftig immer schneller auf die Architektur folgen.

Zen5D in 3Q24 halte ich für möglich, wenn aktuell alles rund bei AMD läuft.

Wie man am gecancelten Navi31 Refresh sieht, fokussiert sich AMD nach vorne, da sie genug Eisen im Feuer haben.

CrazyIvan

2023-05-17, 18:26:48

@basix
+1 zu allen Punkten - Danke, dass Du mir das Niederschreiben meiner eigenen Argumente ersparst :biggrin:

Ramius

2023-05-17, 19:01:48

Da es bei 3nm zu Verzögerungen kam wird AMD auf 4nm bei Zen5 setzen und nicht an dem riskanten Weg von 3nm festhalten. Klares Ziel von AMD war auf ausgereifte Prozesse zu setzen und keine Risiken bei der Prozessentwicklung zu nehmen. Wenn N4X +15% gegenüber N5 bietet und N3E nur 15-20% gegenüber N5, wieso dann auf N3E setzen? Interessant wären auch die Kosten für N4X und N3E.

amdfanuwe

2023-05-17, 19:45:50

Klares Ziel von AMD war auf ausgereifte Prozesse zu setzen und keine Risiken bei der Prozessentwicklung zu nehmen.
Seh ich auch so.
Auf der Roadmap stehen 4nm|3nm für ZEN5.

Bei ZEN3 7nm|6nm, 7nm CPU, 6nm APU
ZEN4 5nm|4nm, 6nm CPU, 4nm APU, ZEN4c ?
ZEN5 4nm|3nm, ?? 4nm CPU, 3nm APU, ZEN5c ??

Mal abwarten, wie Bergamo mit ZEN4c in 4 Wochen ausschaut.
Finde ich zumindest spannender ob sich beim I/O etwas ändert.

Zossel

2023-05-18, 07:55:07

Mal abwarten, wie Bergamo mit ZEN4c in 4 Wochen ausschaut.
Finde ich zumindest spannender ob sich beim I/O etwas ändert.

IO wird ja mit dem neuen Sockel halbiert, entsprechend dürfte IO angepasst sein.

CrazyIvan

2023-05-18, 09:38:33

IO wird ja mit dem neuen Sockel halbiert, entsprechend dürfte IO angepasst sein.
Er meint die Anbindung an das IOD - also ob es bei IFoP bleibt, oder (endlich) was neues kommt.

Zossel

2023-05-18, 11:50:24

Er meint die Anbindung an das IOD - also ob es bei IFoP bleibt, oder (endlich) was neues kommt.

Geht es um schneller, höher, weiter oder um ein neues Konzept?

amdfanuwe

2023-05-18, 12:39:46

Es geht mir um folgendes:
1) gleiches I/O wie Genua mit einfacher IF-Anbindung
2) eigenes I/O mit dual IF Anbindung, eigenes I/O für Siena
3) 2 x Siena I/O gekoppelt
4) 4 x I/O gekoppelt wie bei MI300 jedoch nicht gestacked.
5) I/O mit LLC (IF$)
6) Anbindung an I/O
7) Varianten mit HBM

Da ist für mich noch nichts geklärt.

AMD könnte zukünftig mit mehreren I/O Varianten fahren:
- Billige Variante wie bisher single Die mit IFoP
- Variante mit LLC (IF$)
- Varianten mit HBM

Dazu noch Mischbestückung mit CPU und AI-Chiplets sowie anderen Acceleratoren.

Wenn ich mir die Empfehlung mit 4 NUMA Nodes für Genoa hier ansehe, erscheinen mir eine Aufteilung des I/O auf 4 Chiplets mit IF$ durchaus möglich.
https://www.amd.com/system/files/documents/58004-epyc-9004-tg-cloud-datacenter.pdf
Vom Numa Modell mit einem Node pro quadrant verhielte sich das wie ein 4 Socket System.
83931
Habs mal versucht im Bild zu verdeutlichen.

Ein dual Socket Bergamo verhielte sich mit 8 NUMA Nodes Programmtechnisch wie ein 8 Sockest Server.
Bergamo könnte also gut als Ablösung der alten 4 und 8 Sockel Intel Server dienen mit 32 Core pro Node.

Also 4 Wochen vor Bergamo Release ist da noch nichts klar.
Einfach nur Bergamo mit Genoa I/O wäre für mich enttäuschend.

Edit:
Was mich auf solche Gedanken bringt ist folgende Passage aus dem obigen Dokument:
83933
Mit LLC pro Quadrant könnte für solche Chips zukünftig "LLC as NUMA Domain" die Empfehlung für die BIOS Einstellung sein.

Complicated

2023-05-18, 13:39:26

Es geht mir um folgendes:
1) gleiches I/O wie Genua mit einfacher IF-Anbindung
2) eigenes I/O mit dual IF Anbindung, eigenes I/O für Siena
3) 2 x Siena I/O gekoppelt
4) 4 x I/O gekoppelt wie bei MI300 jedoch nicht gestacked.
5) I/O mit LLC (IF$)
6) Anbindung an I/O
7) Varianten mit HBM

Da ist für mich noch nichts geklärt.

Die Antwort könnte sein, alles davon, je nach Use Case für den Zielmarkt.
Folgt man der Aussage von Mark Papermaster: https://www.tomshardware.com/news/amd-to-make-hybrid-cpus-using-ai-for-chip-design-cto-papermaster-at-itf-world
But what you'll also see is more variations of the cores themselves, you'll see high-performance cores mixed with power-efficient cores mixed with acceleration. So where, Paul, we're moving to now is not just variations in core density, but variations in the type of core, and how you configure the cores. It's not only how you've optimized for either performance or energy efficiency, but stacked cache for applications that can take advantage of it, and accelerators that you put around it.

amdfanuwe

2023-05-18, 14:01:08

Die Antwort könnte sein, alles davon, je nach Use Case für den Zielmarkt.
Alles wohl nicht.
MI300 und diese Folie von der letzten ISSCC
83934
deuten für mich auf zukünftig 4 gekoppelte I/O Dies hin.
Ob Bergamo da schon den Anfang macht oder erst MI300, mit ZEN 5 sollte es in die Richtung gehen.
Wenn AMD da eine Frontend Lösung hat für verschiedenste Systeme erscheint mir das umwälzender als ein paar Prozent mehr IPC auf den Cores.

CrazyIvan

2023-05-18, 14:26:16

Geht es um schneller, höher, weiter oder um ein neues Konzept?
Zusätzlich zu amdfanuwes Ausführungen glaube ich, dass AMD die Energieeffizienz des Interconnects verbessern wollen wird.
Im Serverbereich kann man so mehr Kerne in die gleiche TDP bei gleicher Frequenz packen, selbst wenn man am Rest nix ändert. Und im Mobile Bereich wird Chiplet damit überhaupt erst möglich, siehe auch MTL und Intel's Storytelling zu quasi monolitisch (DT-Replacements wie Dragon Range klammere ich an der Stelle gedanklich aus).

amdfanuwe

2023-05-18, 16:03:51

dass AMD die Energieeffizienz des Interconnects verbessern wollen wird.
Effizienz, Bandbreite und Kosten.
AMD hat IFoP , EFOB (MI250), Fan-Out Package (RDNA3), und 3D Metal on Metal stacking (V-Cache).
Unser Problem besteht darin, dass wir nicht abschätzen können wie die Kosten und der Yield dieser Package Arten ausfällt.

Ebenso wenig wissen wir, wie die AIE Anbindung bei ZEN5 kommt.
AIE mit im CCX?
eigenes Compute Chiplet?
im I/O?
Stacked wie V-Cache auf CCD oder I/O?

Zossel

2023-05-31, 11:49:57

Langsam wachen auch andere Hersteller auf:

https://www.heise.de/news/Server-Mainboards-fuer-Ryzen-7000-9069214.html

amdfanuwe

2023-05-31, 13:03:43

Hat aber nicht viel mit ZEN5 zu tun :-)

Nightspider

2023-06-05, 19:54:57

Neues Video von RGT:
(https://www.youtube.com/watch?v=mKBreMVbFjs)
Zen 6 wohl auf AM6

Zen5: ~19% IPC Gain + ~~3-4% mehr Takt = ~~22% mehr Leistung

Strix Halo: Name "Sarlak":

16 Zen5 Kerne, RDNA3.5, 20 WGP /40 CU
256 Bit LPDDR5X
32 oder 64 MB IF$ (seite Quellen sagen etwas unterschiedliches)

Imo wären 64MB aber zu viel für 20 WGPs. Außer man stacked billig den IF$ um bei einem Premium Produkt nochmal vielleicht 10-15% herauszuholen.

iamthebear

2023-06-05, 20:52:45

Zen 6 wohl auf AM6

Das bezweifle ich ganz stark

DDR6 steht bei Samsung zwischen 2026 und 2027 auf der Roadmap
DDR5 für 2020

Bis DDR6 zu massentauglichen Preisen verfügbar ist wird es Mitte bis Ende 2028 werden.

Wenn Zen5 Anfang 2024 kommt was mach AMD dann die nächsten 4+ Jahre?

Realistisch ist der Plan:
Zen5 in 2024 mit AM5
Zen6 in 2026 mit AM5
Zen7 (oder wie auch immer der Name sein mag) in 2027 mit AM6

Zen5: ~19% IPC Gain + ~~3-4% mehr Takt = ~~22% mehr Leistung

Wenn Zen5 in N4X gefertigt ist dann rechne ich eigentlich mit etwas höherer Taktrate aber dafür etwas weniger IPC.

Strix Halo: Name "Sarlak":

16 Zen5 Kerne, RDNA3.5, 20 WGP /40 CU
256 Bit LPDDR5X
32 oder 64 MB IF$ (seite Quellen sagen etwas unterschiedliches)

Also ich habe da noch einige Fragezeichen:
.) Für Mobile Konsolen wie Steam Deck zu energiefressend
.) Notebookmarkt hat man keinen. Zumindest nicht genug für so eine Entwicklung
.) Im Desktopmarkt hat man das Problem, dass das mit LPDDR komplett inkompatibel zu anderen System ist. Das wäre ein sehr mutiger Schritt.
.) Für Konsolen ist LPDDR5 ein Downgrade, die CPU aber deutlich stärker. Das macht wenig Sinn. Abgesehen davon sind PS/XBox immer stark modifiziert.

Imo wären 64MB aber zu viel für 20 WGPs. Außer man stacked billig den IF$ um bei einem Premium Produkt nochmal vielleicht 10-15% herauszuholen.

Die 6700 XT hatte 96MB mit 20 WGPs und die hatte noch eigenen GDDR6.
Um das schwache Speicherinterface zu kompensieren sehe ich 64MB eher als das Minimum an. Falls dieser auch noch von der CPU genutzt werden kann dann muss es noch mehr sein. Ein 64MB VCache Chiplet hat um die 33mm² in N7. Das ist jetzt nicht unbedingt so eine große Investition.

basix

2023-06-05, 21:36:14

Nightspider

2023-06-06, 00:52:48

Bei niedrigerer Taktrate ist eine höhere Dichte möglich bei Cache, hieß es doch mal.
Dann wäre es naheliegend das bei Zen4c die nicht benötigte Traktate für Dichte geopfert wurde.

Zossel

2023-06-06, 07:10:01

Ausblick auf höhere SRAM-Dichte bei Zen 5? Zen 4c packt den Cache deutlich dichter:
https://www.semianalysis.com/p/zen-4c-amds-response-to-hyperscale

Zen 5 müsste aber wohl den L3$ taktmässig entkoppeln (wie Intel)

Das scheint sich aber nicht auf die SRAM Zellen in den Caches zu beziehen: (Sind heutige Caches überhaupt dual-ported?)

https://substackcdn.com/image/fetch/w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F741b5e8f-787f-430d-813f-77882cc48724_673x382.png

Bzgl. dichterem SRAM deutet sich hier was an: https://www.google.com/search?q=cfet+sram

basix

2023-06-06, 14:01:02

Das scheint sich aber nicht auf die SRAM Zellen in den Caches zu beziehen: (Sind heutige Caches überhaupt dual-ported?)

Der L3$ ist global schon dichter. Zumindest sieht das auf den Die Shots so aus. Kann sein, dass dies primär durch dichter gepackte Kontrollogik zustande kam (wie beim L2$).
High Density Cells sind allenfalls auch eine Option, falls noch nicht verwendet.

Bzgl. dichterem SRAM deutet sich hier was an: https://www.google.com/search?q=cfet+sram
Jo. Wird mit hoher Wahrscheinlichkeit in die Richtung gehen, dass man SRAM und DRAM wie bereits NAND zu stapeln beginnt. Ob CFET, 3D-SOIC usw. sehen wir dann. 3D-DRAM ist auch bereits im Gespräch.

Gipsel

2023-06-06, 15:17:58

Das scheint sich aber nicht auf die SRAM Zellen in den Caches zu beziehen: (Sind heutige Caches überhaupt dual-ported?)Also meines Wissens nach seit ewigen Zeiten schon nicht. Also es werden keine dual-ported SRAM-Zellen (oder gar mit noch mehr Ports) benutzt, wenn es nicht gerade um eher kleinere interne Storage-Bereiche in der CPU geht (Register und sowas). Die Caches sind alle pseudo-multi-ported. Das heißt die Kontrolllogik bietet zwar ein Interface für mehrere Schreib-/Lesevorgänge pro Takt auf dem Cache an, die werden dann intern allerdings auf eine gewisse Anzahl an Bänken verteilt (Anzahl der Bänke ist typischerweise größer als die Anzahl der [Pseudo-]Ports), die jeweils alle nur eine Operation pro Takt unterstützen. Gibt es dabei eine Bank-Kollision, hat man halt Pech gehabt und muß warten, weil die eigentlichen SRAM-Zellen nur single-ported sind. Das war schon bei L1-Cache des K7 so (hatte 2 Pseudo-Ports und das war im Optimization Guide ausführlich beschrieben, wie man Bank-Kollisionen vermeidet, um die nutzen zu können). Die größeren L2- und L3-Caches besitzen genügend Gelegenheit, über eine größere Anzahl an Bänken die Wahrscheinlichkeit für Kollisionen relativ gering zu halten, so daß die Ersparnis durch die einfacheren und kleineren single-port SRAM-Zellen den überschaubaren Verlust an Performance locker aufwiegen.
Wie man da genau die Terminologie handhabt, darüber kann man vermutlich streiten. Früher(tm) nannt man sowas eben "pseudo dual/multi ported", heute läßt man das "pseudo" meist schlicht weg. Die Cache-Kontrollogik ist ja auch multi-ported, die SRAM-Zellen nur nicht.

Edit:
Im oben verlinkten Artikel schreiben die irgendwas davon, daß man von dual port 8T-SRAM-Zellen auf single port 6T-Zellen gehen würde. Das trifft bestimmt nicht für die Caches zu. Dort sind auch die 8T-Zellen nur single ported (man ist irgendwann zu K8 Zeiten mal von 6T auf 8T-Zellen gegangen). Die 8T-Zellen erlauben im Vergleich zu 6T nämlich den stabilen Betrieb bei geringeren Spannungen und niedrigerem Verbrauch (aus ähnlichen Gründen verwendet ja auch keiner mehr 4T-SRAM-Zellen, die gibt es ja auch), die Verwendung von 8T-Zellen bedeutet nicht dual Ports. Die kleineren Fertigungsprozesse haben nur (single ported) 8T-SRAM irgendwann vorteilhaft bzw. beinahe nötig (aus Stabilitäts- und Verbrauchsgründen) gemacht.
Diese angebliche Änderung von 8T dual ported auf die von TSMC entwickelten pseudo dual ported 6T Arrays (womit wir wieder bei einer ähnlichen Diskussion wie sind, was machen die eigentlichen SRAM-Zellen und was das drumherum) trifft also maximal auf irgendwelche SRAM-Arrays in den Kernen selber zu (mäßig beanspruchte Queues, whatever). Ich bin aber skeptisch, daß die von TSMC angewandte Technik (interne Taktverdopplung um im ersten Teil des Taktes zu lesen und im zweiten Teil zu schreiben) für low-power-Operation das Beste ist (es sei denn, man bleibt insgesamt bei relativ niedrigen Frequenzen, also wer weiß?).

latiose88

2023-06-06, 17:55:06

hm was hat es denn mit diesen pseudo-multi-ported aufsich und das mit den 6o der 8 T single oder Multie Ported?
Hat das mit der Missrate vom L1 zu L2 Cache usw zutuen?
ALso ich habe eine super geringe Missrate,die man kaum noch messen kann,weil ja weiter unter 1 % und so.Oder hat es mit was anderem Zutuen,das Bank-Kollision und so.Danke schon mal für die Info.

Achja was steht denn so alles über Zen 5 schon sicher fest,weil man liest irgenwie so wenig von Zen 5.

HOT

2023-06-06, 18:00:38

Das bezweifle ich ganz stark

DDR6 steht bei Samsung zwischen 2026 und 2027 auf der Roadmap
DDR5 für 2020

Bis DDR6 zu massentauglichen Preisen verfügbar ist wird es Mitte bis Ende 2028 werden.

Wenn Zen5 Anfang 2024 kommt was mach AMD dann die nächsten 4+ Jahre?

Realistisch ist der Plan:
Zen5 in 2024 mit AM5
Zen6 in 2026 mit AM5
Zen7 (oder wie auch immer der Name sein mag) in 2027 mit AM6

[...]

Nö, das würde ich nicht sagen. Wie sehen ja, dass AMD mittlerweile ca. 2 Jahre für eine neue µArch braucht. Zen4 dauerte so lange, Zen5 wird minimal kürzer brauchen, aber es bewegt sich zu einem 2 Jahreszyklus, ich denke, dass ist offensichtlich. Zudem wird Zen6 mit CXL kommen, was AMD schon länger angekündigt hat. Wir reden hier von CXL3.0 über PCIe5/6 und evtl. mit entsprechenden CXL-Connectoren auf dem Board (für persistenten Speicher sicherlich). Zen6 wird also einen neuen Sockel benötigen.

Daher würde ich eher sagen, dass AMD jetzt auf eine Art Tick/Tock umschwenkt, also
2024 Zen5 4nm AM5
2025 Zen5 Refresh 3nm
2026 Zen6 3nm AM6
2027 Zen6 Refresh 2nm

Mit den Chiplets ist das recht wenig Aufwand, das zu realisieren, aber der Ertrag wird entsprechend gut. Intel ist ja gezwungermaßen auf einem ähnlichen Trip, da Panther Lake ja offenbar gecancelt wurde, was bedeutet, auch Intel wird ARL refreshen.

latiose88

2023-06-06, 18:10:07

ok danke für deine schreiben,sollte mir das Zen 5 zu wenig mehrleistung aufzeigen,einfach auf Zen 5 Refresh warten.Aber sollte mir das ebenso nicht reichen,kann ich gleich auf die neuere Plattform umschwenken ,weil bei mir ist vor kurzen einer meiner Pcs ein Mainbaord kaputt gegangen.Dachte nun komme ich um einen neuen Pc schon langsam nicht mehr drum rum.Jedoch fand ich für 15 € um mein 10 Jahre altes System wieder zu beleben.Damit kann ich nun überbrücken.Wie lange das Mainbaod mit 1 Jahr händler Garantie wohl halten.
Aber gut,ich hoffe mal das es länger hält,weil will so wenig neue System Sprünge machen.Kaufe also erst wenn sicher ist,wie gut die jeweilige CPU an Leistung sein wird.
Ich sehe also wie es 2024 so sein wird.Kaufe also heuer nix mehr,es sei denn Zen 5 käme schon im Winter,wer weis.
Aber gut ,das wird sich schon noch zeigen wie viel noch mehr es dem Zen 3 davon rennen wird.
Bei meinem Fall war bisher der Takt das wo Leistung gebracht hatte.

Darum ist ja auch der 13900k mit 5,7 ghz vor dem 7950x mit 5,1 ghz.Es soll ja angeblich nen kleinen Takt Plus geben,also so auf 5,5 ghz Allcore oder sowas.Das wäre in der Tat interessant.
Einen Leistungsplus gibt es somit auf jedenfall kann man so sagen.

HOT

2023-06-06, 18:21:18

Zen5 wird 20%+ Mehrleistung bieten, wie es derzeit aussieht. Ein potenzieller Refresh hätte etwas mehr Takt und evtl. etwas niedrigere interne Latenzen, da wird der Leistungsgewinn eher überschaubar.

latiose88

2023-06-06, 18:28:00

Na mir hat wer geschrieben das der Sprung von N5P zu N4 sehr gering sein soll.Scheint wohl nur ne Vermutung zu sein.Das es angeblich nur durch die IPC Steigerung die ja nicht so hoch sein wird,erreicht werden soll.Aber das stimmt anscheinend nicht so.

davidzo

2023-06-07, 10:06:50

IPC hat mit der Fertigung nichts zutun.

Zen3 war sogar in derselben Fertigung wie Zen2 und trotzdem gab es eine 19% IPC Verbesserung, der größte Sprung seit original Zen. Zen5 könnte sogar noch ein größerer Sprung werden, da der Core durch die Bank breiter werden soll, während Zen3 nur behutsame Anpassungen bei der FP dispatch width, load store und branch ports hatet aber das frontend nicht groß angefasst wurde. Das war und ist weiterhin 4wide decode, 6wide dispatch, also maximal 6 IPC. mit Zen5 wird sich das ändern.

Die Fertigung bringt eher was bei der maximalen Taktrate und dem Energieverbrauch sowie der Diegröße/Kosten. Sieht man ja bei Zen4, der die größten Zuwächse durch den Takt hingelegt hat und nicht durch IPC Verbesserungen.
Die lediglich 66mm2 von zen4 in N5P sind außerordentlich klein, da ist sicher Luft nach oben.
Die geringe Diegröße macht ja jetzt eigentlich schon Probleme mit der energy density und Kühlung und limitiert den Takt. Es wäre für den Desktop sicher nicht falsch wenn der CCD wieder auf 80-90mm2 anwächst.

HOT

2023-06-07, 10:26:26

Das wird ja bei Zen5 sicherlich wieder der Fall sein in N4P/X. Cache-Größe bleibt ja gleich, nur die L3-Topologie soll sich ändern. Ein portenzieller Refresh in N3 wäre dann wieder einiges kleiner.

Der_Korken

2023-06-07, 10:56:44

Die lediglich 66mm2 von zen4 in N5P sind außerordentlich klein, da ist sicher Luft nach oben.
Die geringe Diegröße macht ja jetzt eigentlich schon Probleme mit der energy density und Kühlung und limitiert den Takt. Es wäre für den Desktop sicher nicht falsch wenn der CCD wieder auf 80-90mm2 anwächst.

Nachdem Zen4C endlich näher beleuchtet wurde, wäre ich mir gar nicht so sicher, ob solche "aufgebläten" Kerne überhaupt noch wichtig sind. Als Spieler wäre ich mit einem 7800X3D@5Ghz immer besser bedient als mit einem hypothetischen 7800X@5,7Ghz. Die Stromersparnis ist riesig, denn statt 1,4x Volt tun es plötzlich auch 1,1x Volt. Hätte man die Cores des 7800X3D als Zen4C realisiert, welche mehr als 5Ghz auch gar nicht erst schaffen würden, wäre die Verbrauchsersparnis wahrscheinlich immer noch größer (gegenüber einem 7800X) als die Flächenersparnis, sprich die Energiedichte sinkt. Eigentlich entstehen alle Wärmedichteprobleme im Desktop und auch nur, weil man im Jahre 2023 in 5nm immer noch Boost-Spannungen draufknallt, die ich meinem Core 2 von 2006 in 65nm nicht 24/7 zugemutet hätte. Selbst da waren 1,4V schon "viel" und nur unter OC zu sehen, von 1,5V ganz zu schweigen.

HOT

2023-06-07, 11:10:43

Du wirst auch immer hochgetaktete Varianten brauchen. Auch bei Zen5 wird es wieder Varianten mit 2 CCDs und 170W TDP geben. Zen4c wird sicherlich kaum 4GHz packen, vielleicht ein bisschen mehr, wenn man es darauf anlegt. Das ist zu wenig.
Bei Zen5c ist das ein bisschen was anderes, da dieser ja in N3 kommen soll. Ich würd man vermuten, dass wir 3 CCDs sehen werden:

Zen5 8C N4X/P
Zen5c 16C N3
Zen5 8C N3X (2025er Refresh)
Zen6 8C N3X (2026)
Zen6c N2 (2026)

basix

2023-06-07, 11:20:47

Für viele Workloads ist Zen 4c gut genug, da der L3$ nur in gewissen Anwendungen massiv Vorteile bringt (Spiele, Packer, Datenbanken, EDA, Compiler). Das gilt für Consumer, Workstations als auch Server. Ich habe ebenfalls schon hier oder im Zen 4 Thread geschrieben, dass Zen 4c den grossen Core in vielen Server-Anwendungen ablösen wird, ist einfach billiger (Siena kommt noch oben drauf). Mehr Takt und mehr Cache und somit der grosse Core wird dann nur noch selektiv verwendet.

Deswegen sehe ich bei Consumer in Zukunft einen Mix aus Zen "Big" und Zen "Cloud Native" als ziemlich sinnvoll an. Sinnvoller und einfacher als das, was Intel mit P- und E-Cores macht. Bei Zen 5 werden wir am Desktop wohl noch Big Cores Only sehen, doch bei Zen 6 könnte sich das ändern. Die wirtschaftlichen Vorteile durch die höhere PPA sind einfach enorm. Gleiche CCD-Chipfläche aber +50% Cores (z.B. 8+16C) sind schon eine Ansage. Und wenn man die L3$ der beiden CCDs zu einem grossen Unified LLC vereinen kann (direkter CCD to CCD Link?), fällt die geringere L3$-Menge bei 4c/5c/6c weniger stark ins Gewicht

Der_Korken

2023-06-07, 11:23:31

Ohne es zu testen, können wir nicht wissen wie viel Takt Zen4C schafft. Laut diesem Artikel hier taktet die volle Zen-4-Version als Epyc auch nur mit 3,7Ghz, während Zen4C auf 3,1Ghz kommt.

https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https:%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F9ef557e3-9436-407c-a915-6f6872be9f44_683x868.png

Hochgerechnet auf 5,7Ghz am Desktop wären es für Zen4C immer noch 4,8Ghz. Durchaus respektabel für 40% weniger Core-Area. Man kann und wird (da bestätigt) weiter zweigleisig fahren, aber ich bezweifle ein wenig, dass man das Hauptdesign nur für ein paar Desktop-Benches immer weiter aufbläht und Packdichte opfert.

Spätestens wenn ein Zen5C-Chiplet + Cache-Die kleiner sind als ein voller Zen5-Chiplet und ersterer trotzdem in Spielen schneller gibt es außer Geekbench- und Cinebench-ST keinen Grund letzteres noch zu bauen. Phoenix ist beim max. Takt auch schon deutlich abgespeckter gegenüber Desktop als das bei Zen 2 und 3 noch der Fall war, weil ST-Verbräuche von 30W+ einfach nicht mehr zeitgemäß in mobilen Geräten sind. Server braucht die hohen Boost-Clocks offenbar auch nicht, sonst würde man die vorhandenen Chips stärker ausfahren. Was bleibt also noch übrig?

amdfanuwe

2023-06-07, 11:39:28

SpielerZwei

2023-06-07, 12:01:49

Na ich zum Beispiel. Threadripper ist mir zu teuer, ich brauche aber viele Cores für Videoschnitt, Rendering und so weiter. Wobei vieles natürlich auch schon über die GPU läuft bzw. durch die GPU unterstützt wird. Hängt halt auch stark von der Software ab.
Ein 5800X kostet derzeit fast gleich viel wie ein 5900X. Da nehme ich die 4 Kerne mehr gerne mit.

Der_Korken

2023-06-07, 12:07:01

Wie viele Cores braucht man eigentlich im Desktop?
Ich meine, professionelle Nutzer können sich auch einen Threadripper leisten.
Gamer sind momentan mit 8X3D gut bedient.
Wer ist eigentlich die Zielgruppe für viele Cores im Desktop?

16 werden imho noch eine ganze Weile reichen. Dort ist man bei vielen Anwendungen auch schon in einem Bereich, wo die Performance durch mehr Kerne kaum noch zunimmt.

Weiß jemand, wie viel SMT in den großen CPUs mit 96 und 128 Kernen noch bringt und ob das genutzt wird? Ich hatte mich gefragt, ob Zen 5 nicht ein guter Zeitpunkt wäre SMT rauszuwerfen (sofern man es überhaupt vorhat), wenn man das Frontend stark ausbaut und auch sonst viele Sachen im Kern ändert. Bei Apple sieht man ja, dass man mit genug Frontend, ROB und L1$ auch einen breiten Kern ausgelastet bekommt. Mit Zen5C kann man sehr viel MT-Performance auf wenig Fläche unterbringen, d.h. wem ein Zen-5-Server wegen fehlendem SMT nicht genug Kerne bzw. MT-Leistung hat, bekommt sie mit Zen5C. Beim HPC meiner Uni wurde bzw. wird eventuell immer noch SMT deaktiviert wegen Sicherheitsproblemen, aber das waren damals alles Intel CPUs.

basix

2023-06-07, 12:28:33

Phoenix ist beim max. Takt auch schon deutlich abgespeckter gegenüber Desktop als das bei Zen 2 und 3 noch der Fall war, weil ST-Verbräuche von 30W+ einfach nicht mehr zeitgemäß in mobilen Geräten sind. Server braucht die hohen Boost-Clocks offenbar auch nicht, sonst würde man die vorhandenen Chips stärker ausfahren. Was bleibt also noch übrig?

Gibt immer Bedarf nach mehr Performance. Ob nötig kommt auf die Anwendung und den Use Case an. Ich kann mir gut vorstellen, das zukünftig der Grossteil der gesamten Compute-Arbeitslast über kleine Cores läuft. AMD könnte also deutlich mehr Zen 4c/5c/6c Cores verkaufen. Big Cores nutzt man dann selektiv dort, wo man profitiert. Kann je nach Anwendung >2x Performance ausmachen (Takt + Cache). Und für diesen Performance-Unterschied zahlt der Kunde auch. Durch AMDs Chiplet Ansatz und da sie das selbe Core Design für grosse und kleine Cores verwenden, ist auch der Design-Zusatzaufwand relativ gering. Sich hier also mit "Big" & "Little" differenzieren zu können macht sicher Sinn.

mboeller

2023-06-07, 12:57:19

latiose88

2023-06-07, 13:39:29

basix

2023-06-07, 13:54:12

wie groß sind eigentlich die 4c-Kerne im Vergleich zu den Gracemont (sp?)-Kernen von Intel bei gleichem Fertigungsprozess?

Klar die Fertigung ist unterschiedlich, aber ohne L2 scheinen die 4c laut semianalysis nur 1,43mm² groß zu sein, während das Intel-Pendant 8,66mm² groß ist (Cluster aus 4 Kernen, ohne L2) ... zumindest nach dem was ich auf die schnelle gefunden habe. Der Unterschied sollte also bei gleicher Fertigung nicht mehr ausschlaggebend sein (+/- 1mm²) in 5nm.

Meteor Lake mit Intel 4 ist die wohl bessere Vergleichsgrösse. Intel 4 ist nahe an TSMC N5P dran was Density und restliche Performance-Parameter angeht.

"Big" Cores inkl. L2$:
- Zen 4 = 3.84mm2
- Redwood Cove = 5.33mm2

"Little" Cores inkl. L2$:
- Zen 4c = 2.48mm2
- Crestmont 4C Cluster = 5.91mm2

Wenn ich tippen müsste:
Zen 4c bringt bei Multithreading mehr Performance pro Fläche auf den Boden als Intels E-Cores. Hat alle Big Core Vorteile (IPC, SMT) und zwei Big Cores sollten schneller sein als die vier E-Cores von Intel. Dazu noch der Vorteil, dass die ST Performance ebenfalls einiges höher sein sollte. Alles in allem sehe ich hier Win-Win-Win-Win auf Seiten AMD (PPA, Single Threaded Performance, Multi Threaded Performance, Designaufwand).

Hier die Die Shot Analyse von Meteor Lake:
https://www.semianalysis.com/p/meteor-lake-die-shot-and-architecture

Edit:
Ein einzelner Intel E-Core (Crestmont) ohne L2$ ist 1.05mm2 gross. Ein Zen 4c Core ohne L2$ 1.43mm2 ;)

Der_Korken

2023-06-07, 14:08:47

Ah OK was heißt denn ppa ausgeschrieben und was heißt das und diese wide decode und dispatch sind Dann die Aufgaben so viel pro Sekunde. Das heißt je mehr davon desto mehr Aufgaben bzw Instruktionen kann es aufnehmen und das andere also das Gegenstück ist dann erledigen. Und desto schneller werden dann die Programme oder irre ich mich dabei?

ppa = performance per area

Ansonsten sieht man hier ein wenig woraus so ein CPU-Kern besteht: https://twitter.com/Cardyak/status/1574401760411717634?cxt=HHwWhMC48eeDs9krAAAA

Der Dude hat auch einen Download-Link, wo man sich solche Block-Diagramme für viele andere Architekturen angucken kann. Auch das ist natürlich nur die halbe Wahrheit, da nicht sichtbar ist, welche Instruktionen wie lange brauchen oder wieviel Latenz haben oder ob es irgendwelche Abhängigkeiten oder shared ressources gibt, die man eingebaut hat, um Taktraten zu pushen und IPC zu opfern, etc.

Das heist der extra l2 cache kam bei mir nicht mehr an. Ob sich nun mit halben l3 cache Leistung kostet bei 16 vs 32 MB war das noch der Fall. Kann mir bei den sehr geringen missraten beim l1----) l2 cache durchaus vorstellen auch mit weniger Cache die gleiche Leistung zu haben. Denke mal allerdings das weniger l3 cache kleine Leistung kostet. Aber es die extra Kerne definitiv wieder ausgleichen können. Der geringer l3 kostet also so um die 10 % an Leistung. Die extra Kerne aber bringen mindestens 10 % an Leistung. Durch den Rest an Verbesserungen hätte ich also dennoch einen massiven Gewinn.
Und mal sehen. Der Gewinn bei RAM ist in meinem Fall auch nicht mehr so viel. Also kann ich gut auf extra Bandbreite verzichtet zum wohle der Rechenleistung.

Ob irgendein Cache eine Performance-Verbesserung in einer bestimmten Anwendung bringt, ist von außen erstmal völlig unvorhersehbar. Ein größerer L2 kann sehr viel bringen, er kann aber theoretisch sogar langsamer sein als der kleinere Cache, wenn der alte Cache schon die perfekte Größe hatte aber eine geringere Latenz als der große Cache. Dass alles so starr in Prozenten aufzurechnen wie du, wird nicht funktionieren. AMD selber beziffert den IPC-Gewinn von Zen 4 nach Anwendung übrigens so:

https://pics.computerbase.de/1/0/4/8/0/3-7c1cab386ec69bad/3-1280.4e3998b4.png

Gipsel

2023-06-07, 15:34:27

Meteor Lake mit Intel 4 ist die wohl bessere Vergleichsgrösse. Intel 4 ist nahe an TSMC N5P dran was Density und restliche Performance-Parameter angeht.

"Big" Cores inkl. L2$:
- Zen 4 = 3.84mm2
- Redwood Cove = 5.33mm2

"Little" Cores inkl. L2$:
- Zen 4c = 2.48mm2
- Crestmont 4C Cluster = 5.91mm2

[..]

Hier die Die Shot Analyse von Meteor Lake:
https://www.semianalysis.com/p/meteor-lake-die-shot-and-architecture

Edit:
Ein einzelner Intel E-Core (Crestmont) ohne L2$ ist 1.05mm2 gross. Ein Zen 4c Core ohne L2$ 1.43mm2 ;)Ich frage mich immer noch, was genau dieser E-Core ist, den intel als Beispiel für backside power delivery mit Intel4 zeigt:

https://substackcdn.com/image/fetch/w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F801b27ef-a97e-4ad2-b49c-6421d932c139_1591x1162.png
Ist beschriftet mit: "E-Core Implementation in Intel 4 with PowerVia (Backside Power) Technology” – Intel Corp, Paper T1-1 VLSI 2023"
Ein Crestmont ist es aber scheinbar nicht. Und der scheint auch etwas größer zu sein. Falls irgendwer an die komplette Präsentation bzw. das Paper rankommen sollte, bitte posten (ist ja erst in ein paar Tagen)!

latiose88

2023-06-07, 15:43:53

Ja stimmt da war was. Aber ich scheine dennoch eher total unbeeindruckt zu sein. Die meine Anwendung ist so auf cpu takt fokussiert das sogar 300 MHz weniger tskt gleich 5 % weniger Leistung ist. Das war bei Zen 3 noch nicht der Fall. Merkwürdig ist das es bei Zen 4 der Fall ist.
Bei Zen 3 hat 100 MHz takt Unterschied 1 % Leistung gekostet. Nun kostet es also anstatt 3 % dann 5%.
Und das Verhalten habe ich runter gebrochen weil der 7950x bei 142 Watt 4,8 GHz also von 5,1 GHz auf 4,8 GHz herunter getaktet hatte. Die Anwendung nahm es also übel.
Daurm ist auch der 13900k obwohl dieser eigentlich schlechter ist um sage und schreibe 5 % schneller als der 7950x. Und das nur weil dieser 5,7 GHz taktet hatte.
Der 13900k fraß dabei zwar 350 Watt bei meinem test aber er war schneller gewesen. Aber auch heißer. Das war nur ein kurzer test. Denke mal bei Langzeit wird der 13900k dann langsamer sein. Also so 1 Stunde Dauer läßt sieht es anders aus. Weil dann springt der auf über 100 Grad nach oben. Aber gut das ist ne andere Sache.
Ich will jedenfalls nur mit Luft kühlen und da sieht es dann für den 13900k sehr schlecht aus. Und auf Grund der unterschiedlichen erbennisse under windows 11 war Das auch nicht so prikelnd.
Auf jedenfall kam ich herunter gebrochen bei 3,9 GHz auf dem 7950x mit einem ryzen 9 5950x mit 3,8 GHz auf das selbe Level.
Und da ist davon sehe ich nix von den 5 % oder sowas an ipc.

Es lässt sich auch schlecht dir ipc durch 2 gleich starkennworkflow auch nur schwer berechnen.
Bei nur 1 Programm gab es jedoch nen Geschwindigkeits Boost das stimmt.
Die zweite Anwendung kostet also etwa 35 % an Leistung. Bei Intel dank des noch höheren taktes so 30 %.
Ist noch immer noch effizienter als wenn ich es nur einzeln hinter einander bei dem 16 Kerner laufen lassen.
Nur eines davon sind es so 40% aller Kerner ausgelastet.
Bei zwei komme ich so auf 85 % des 16 kernes

Und weil scheinbar wirklich nicht alle Kerne ausgelastet worden sind kam es auch darum zu merkwürdigen Verhalten unter windows 11. Unter Windows 10 sind es weiterhin 85 % Auslastung.

Ich finde es echt schade das die ipc bei mir zumindest nur im single Betrieb angekommen ist, aber nicht bei multicore Leistung. Da scheint wohl der takt verantwortlich zu sein.
Dank den 5,1 GHz gegenüber der 3,8 GHz bei mir sind es also 20 % mehrleistung durch den cpu takt. Erst als ich da mehr tining beim ddr5 drauf gegeben hatte gingen da weiter 2,5 % mehr dazu. Aber ist für mich kaum der Rede Wert.
Ich dachte jedenfalls ddr5 würde gegenuber ddr4 so viel bringen. Aber hier scheint es der Anwendung wohl egal zu sein.
Ich schaue jedenfalls ob man da noch mehr raus holen kann. Ich testen gerne alles durch ehe ich da mehr weiß. Ich finde schon wen der nen ryzen Zen 5 8000 16 Kerner haben wird. Darum wollte ich ja weil ich die Ergebnisse selbst testen durfte auch überspringen. Ich warte einfach ab.
Wenn alles breiter wird, dann kann ich auf noch mehr leistung hoffen. Wenn schon nicht noch mehr takt dann halt wo anderst.
Den Leistungs unterschied mit l3 cache 16 vs 32 MB war bei beiden 8 Kerner mit 10 % Leistungs unterschied gewesen.

Der 5700g hat zwar höheren takt gehabt als der 5800x aber dennoch verloren weil scheinbar der l3 Cache auch wichtig ist.
So war der 5800x bei 3,4 GHz gewesen und der 5700g bei 4, 2 GHz. Der takt unterschied reichte nicht aus um den fehlenden l3 Cache auszugleichen. Also kann man schon sagen der Cache scheint hier schon ne Rolle zu spielen.
Ob es bei einem 16 kerner auch so sein wird und ob das ausreicht um weniger l3 cache auszugleichen ist ne andere frage.

Ich kann nur sagen was mir so aufgefallen ist. Es mag sein das es sich bei anderen Anwendungen anderst sich verhält. Ich jedenfalls benutze kein Handbrake, kein adope und so zum videoumwandeln. Aber dennoch verhalten diese trotz selben codec unterschiedlich ist. Naja ihr habt freilich nichts zum vergleich da vorliegen habts.

Gipsel

2023-06-07, 15:47:19

Weiß jemand, wie viel SMT in den großen CPUs mit 96 und 128 Kernen noch bringt und ob das genutzt wird?Na klar bringt das was (anwendungsabhängig auch ganz ordentlich) und wird natürlich genutzt.
Ich hatte mich gefragt, ob Zen 5 nicht ein guter Zeitpunkt wäre SMT rauszuwerfen (sofern man es überhaupt vorhat), wenn man das Frontend stark ausbaut und auch sonst viele Sachen im Kern ändert. Bei Apple sieht man ja, dass man mit genug Frontend, ROB und L1$ auch einen breiten Kern ausgelastet bekommt.SMT wird im Schnitt immer mehr Performance bringen, als es Aufwand kostet. Auch Apple-CPUs würden merklich an MT-Performance zulegen, falls sie SMT implementieren würden. Einen zweiten Thread auf einen breiten Kern zu werfen ist quasi immer eine geeignete Methode, um einen breiten Kern besser auszulasten. Und vom Aufwand (Transistoren, Stromverbrauch) auch günstiger, als die selbe Performance in einen einzelnen Thread zu quetschen.
Mit Zen5C kann man sehr viel MT-Performance auf wenig Fläche unterbringen, d.h. wem ein Zen-5-Server wegen fehlendem SMT nicht genug Kerne bzw. MT-Leistung hat, bekommt sie mit Zen5C.Und noch mehr, wenn man auch bei Zen5c SMT nutzt. Das zu deaktivieren, kostet einfach MT-Leistung (bis auf überschaubar viele Ausnahmen).
Beim HPC meiner Uni wurde bzw. wird eventuell immer noch SMT deaktiviert wegen Sicherheitsproblemen, aber das waren damals alles Intel CPUs.Sicherheit ist ein völlig anderer Aspekt als Performance.

Der_Korken

2023-06-07, 16:14:37

Auch Apple-CPUs würden merklich an MT-Performance zulegen, falls sie SMT implementieren würden. Einen zweiten Thread auf einen breiten Kern zu werfen ist quasi immer eine geeignete Methode, um einen breiten Kern besser auszulasten. Und vom Aufwand (Transistoren, Stromverbrauch) auch günstiger, als die selbe Performance in einen einzelnen Thread zu quetschen.

Da man allerdings auch doppelt so viele Threads braucht, um die Performance abzurufen, ergibt sich das Problem, dass SMT weniger bringt, je mehr Kerne man hat. Wenn man unendlich viel Arbeit spawnen kann (deswegen meine Frage bezüglich Server und SMT), ist das natürlich egal, aber bei Desktop-Systemen scheint die Kernzahl schneller zu wachsen oder wachsen zu können als die benutzte Software. Bei Notebooks sind wir mittlerweile auch schon bei 16 Kernen, weil man so viel parallele Rechenleistung auch auf so kleinem Raum unterbringen kann, wenn man will.

Die Aussage, dass SMT relativ wenig Fläche kostet (afaik irgendwas um die 5%) stammt noch aus der Zeit der ersten modernen SMT-Architekturen, sprich Nehalem 2008. Natürlich wird hier im Forum niemand beantworten können, ob das immer noch so ist, aber da sich bei CPUs in der Zeit einiges getan hat, wäre es nicht undenkbar, dass sich das Kosten/Nutzen-Verhältnis verschoben hat. Theoretisch natürlich auch Richtung SMT statt weg davon.

Ein größeres Frontend bei Zen 5 in Kombination mit einem nicht verbreitertem Backend würde dazu führen, dass 1T/Core deutlich mehr zulegt als 2T/Core. Wenn ich mehr ILP extrahiere und die ALUs besser auslaste, hab ich weniger Raum, wo SMT noch Performance rausholt. Warum aber sollte das Backend nicht verbreitert werden? Eventuell weil es sehr teuer ist. Das Scheduling wird mit mehr Ports deutlich aufwändiger, man braucht nicht nur mehr Register, sondern mehr Lese/Schreib-Ports dafür und auch mehr Cache-Durchsatz. Es ist schon bemerkenswert, dass AMD seit Zen 1 keine weiteren ALUs mehr eingebaut hat. Ohne SMT könnte man bei 4-wide bleiben, da dort (wie man an SMT sieht) noch genug Rechenkapazität vorhanden ist. Ich will jetzt kein SMT-less-Zen5 heraufbeschwören, aber so abwegig kommt mir diese Entwicklung nicht vor.

davidzo

2023-06-07, 17:13:50

Deswegen sehe ich bei Consumer in Zukunft einen Mix aus Zen "Big" und Zen "Cloud Native" als ziemlich sinnvoll an. Sinnvoller und einfacher als das, was Intel mit P- und E-Cores macht.

Genau, ein 7950x3d mit 24 kernen, also AMDs Version von Intels 13900K, hätte ich gerne gesehen. 1x CCD mit 8C Zen4 und X3D cache + 1x CCD mit 16C Zen4C. In ST vielleicht nicht immer am schnellsten, dafür aber sehr wohl in games und in Multithreaded workloads mal eben 33% vor dem 7950x oder 13900K und das wahrscheinlich auch bei 125W TDP und noch niedrigerem Realverbrauch. - Wäre für mich aktuell die perfekte Desktop CPU.

Gipsel

2023-06-07, 17:32:40

Da man allerdings auch doppelt so viele Threads braucht, um die Performance abzurufen, ergibt sich das Problem, dass SMT weniger bringt, je mehr Kerne man hat.Für gut parallelisierbare Aufgaben hat man immer zu wenig Kerne. ;)
Wenn man unendlich viel Arbeit spawnen kann (deswegen meine Frage bezüglich Server und SMT), ist das natürlich egal,Wenn das nicht der Fall ist (oder zumindest häufig), brauchst Du keinen Server mit vielen Kernen. Oder dann schmeißt man das nicht auf so eine Maschine. Oder der Cloudanbieter packt einfach 32 der billigen 8Kern-Instanzen auf ein 64Kern-System (dann freut man sich über jeden Thread, den die physische CPU hat).
Die Aussage, dass SMT relativ wenig Fläche kostet (afaik irgendwas um die 5%) stammt noch aus der Zeit der ersten modernen SMT-Architekturen, sprich Nehalem 2008. Natürlich wird hier im Forum niemand beantworten können, ob das immer noch so ist, aber da sich bei CPUs in der Zeit einiges getan hat, wäre es nicht undenkbar, dass sich das Kosten/Nutzen-Verhältnis verschoben hat. Theoretisch natürlich auch Richtung SMT statt weg davon.Und genau das sollte man annehmen (SMT-Vorteil wurde größer). Ganz prinzipiell benötigt eine OoOE-CPU nur recht geringe Änderungen, um mehrere Threads zu verwalten. Und zwei Instruktionen aus zwei verschiedenen Threads sind nun mal per Definition unabhängig voneinander. Das ist also eine sehr billige Möglichkeit, mehr unabhängige Instruktionen in die Pipeline zu schaufeln (man kann sich quasi die Dependency Checks zwischen den 2 Threads in einem riesigen ROB sparen).
Ein größeres Frontend bei Zen 5 in Kombination mit einem nicht verbreitertem Backend würde dazu führen, dass 1T/Core deutlich mehr zulegt als 2T/Core. Wenn ich mehr ILP extrahiere und die ALUs besser auslaste, hab ich weniger Raum, wo SMT noch Performance rausholt.In typischem Code ist die tatsächlich in der Praxis erreichte IPC (oder ILP, egal) ewig weit von dem weg, was der Kern bei optimalem Code theoretisch erreichen könnte. So ein fettes Frontend und so fette Scheduler-Ressourcen kannst Du da gar nicht sinnvoll dranbasteln, als daß das anders wird. Ausnahmen gibt es eigentlich nur bei ganz wenigen inneren Schleifen von hochoptimiertem Code für ganz spezielle Anwendungen.
Warum aber sollte das Backend nicht verbreitert werden? Eventuell weil es sehr teuer ist. Das Scheduling wird mit mehr Ports deutlich aufwändiger, man braucht nicht nur mehr Register, sondern mehr Lese/Schreib-Ports dafür und auch mehr Cache-Durchsatz. Es ist schon bemerkenswert, dass AMD seit Zen 1 keine weiteren ALUs mehr eingebaut hat.Weil das halt oft nicht limitiert. Mit welchem Code kann man denn einen dauerhaften Durchsatz von 4 unabhängigen ALU-Instruktionen pro Takt erreichen? Die kannst Du doch mit der Lupe suchen. Mit Zen2 kam aber eine zusätzliche AGU, mit Zen3 eine zusätzliche Branch unit (und mehr Ports auf der FP-Seite). Also das Backend ist über die Zen-Iterationen schon moderat gewachsen. Der/die Scheduler können theoretisch bis zu 10µOps pro Takt auf der Integerseite und parallel noch 6µOps auf der FP-Seite handhaben (vom Frontend kommen aber maximal 6 MacroOps [einige davon werden dann in 2µOps gesplittet]), das ist gegenüber Zen1 ebenfalls eine merkliche Steigerung (6+4). Der Kern ist eigentlich schon gar nicht mal so schmal.
Irgendwo eine 5. ALU hinzuklatschen hilft eigentlich nur in irgendwelchen Cornercases, wenn die Instruktionen durch suboptimales Scheduling blöde auf die einzelnen (getrennten) Int-Scheduler verteilt sind und das dann von der Implementation billiger wird, als besseres Scheduling zu verbauen. Merke: Mehr ALUs können eventuell die Performance steigern, auch wenn vorher immer welche frei waren (also zu keinem Zeitpunkt alle Arbeit hatten). ;)
Sprich, das ist immer noch kein Argument gegen SMT.
Ohne SMT könnte man bei 4-wide bleiben, da dort (wie man an SMT sieht) noch genug Rechenkapazität vorhanden ist. Ich will jetzt kein SMT-less-Zen5 heraufbeschwören, aber so abwegig kommt mir diese Entwicklung nicht vor.Und was soll das bringen? SMT hilft beim 8wide (4 ALU, 3 AGU, 1 Branch) Integer + 6wide FP-Backend von Zen4 merklich beim MT-Durchsatz, weil ein einfacheres Scheduling für den gleichen MT-Durchsatz möglich ist. Ein breiteres Frontend ändert da gar nichts dran.
Ein breiteres Backend steigert die single-Thread-Leistung. Im Normalfall weniger, als der Kern breiter geworden ist (ein 25% breiterer Kern erhöht die Performance um weit weniger als 25%). Damit hat man tendentiell noch mehr ungenutzte Resourcen, die man mit SMT vergleichsweise günstig in MT-Leistung umsetzen kann.

Oder um Deine Eingangsfrage nach Zen5 und SMT zu beantworten: Nein, Zen5 ist kein geeigneter Zeitpunkt, um SMT rauszuwerfen. Meiner Meinung nach wird dies bei keinem in absehbarer Zukunft denkbaren CPU-Design für Desktop- oder Serveranwendungen der Fall sein, da SMT sowohl aus Performancesicht und auch bei der Kosten/Nutzen-Rechnung immer vorteilhaft bleibt.

basix

2023-06-07, 18:02:12

Genau, ein 7950x3d mit 24 kernen, also AMDs Version von Intels 13900K, hätte ich gerne gesehen. 1x CCD mit 8C Zen4 und X3D cache + 1x CCD mit 16C Zen4C. In ST vielleicht nicht immer am schnellsten, dafür aber sehr wohl in games und in Multithreaded workloads mal eben 33% vor dem 7950x oder 13900K und das wahrscheinlich auch bei 125W TDP und noch niedrigerem Realverbrauch. - Wäre für mich aktuell die perfekte Desktop CPU.

Jo, genau das.

Wenn Zen 5 eine entkoppelte L3$-Plane mitbringt (siehe Intel), dann fällt auch noch der ST Nachteil weg. Der Core könnte dann auch mit V-Cache den Maximaltakt fahren.
Das Scheduling sollte simpler als bei Intel ausfallen, generell kann man das "Thread Director" Schema aber abkupfern.

Bei den APUs sehen wir ja schon bald den ersten Hybriden aus Zen 4 und 4c ("Phoenix 2") und das wird mit Zen 5 noch ausgebaut. Ich nehme an, den Ausbau wird man mit Zen 6 weiterführen und evtl. in den Desktop bringen. Zu gross sind die Vorteile, als dass man es nicht macht. Bei Server ist es mMn wenig sinnvoll die Chiplet-Typen zu mischen. Das wird dort separiert bleiben. Einziges Problem beim ggemischten Setups: Time to Market. Beide Chiplets müssen gleichzeitig verfügbar sein. Die Produkteinführung müsste dann vermutlich gestaffelt ablaufen (z.B. zuerst nur die Big Cores und dann ein gemischtes Setup).

Oder um Deine Eingangsfrage nach Zen5 und SMT zu beantworten: Nein, Zen5 ist kein geeigneter Zeitpunkt, um SMT rauszuwerfen. Meiner Meinung nach wird dies bei keinem in absehbarer Zukunft denkbaren CPU-Design für Desktop- oder Serveranwendungen der Fall sein, da SMT sowohl aus Performancesicht und auch bei der Kosten/Nutzen-Rechnung immer vorteilhaft bleibt.
Wann kommt das bei ARM? Ein X4 oder dessen Nachfolger als auch die Big Cores bei Apple würden sicher davon profitieren. Zudem ist es evtl. auch energietechnisch interessant, wenn man zwei Threads auf einen starken Core mapt (SMT) und einen zusätzlichen Kern schlafen legen kann. Oder ist das mehr ein Problem auf SW-Seite, dass man SMT dann halt auch beachten muss.

HOT

2023-06-07, 18:23:07

Wenn die Kerne gleich schnell sind, braucht man keinen "Thread director". Einfach CPPC lassen und gut. Lassen sich doch problemlos dem Scheduler mitteilen die (vom Takt) schnellen Kerne.

basix

2023-06-07, 18:27:39

CPPC geht schon auch in diese Richtung, nur funktioniert das für gleich 8+ Cores und einen vermutlich doch recht ordentlichen Taktunterschied? Und je nach Cache-Sensitivität sind sie eben nicht gleich schnell (seieh Alderlake, Raptorlake und 7950X3D), was zusätzliche Scheduling Massnahmen nötig macht.

HOT

2023-06-07, 18:29:53

Das kommt darauf an, wie L3$ bei Zen5 überhaupt funktioniert. Lt. bisherigen Infos gibts ja ne neue Topologie. Ich denke nicht, dass man sowas braucht.

Gipsel

2023-06-07, 18:55:05

Wann kommt das bei ARM? Ein X4 oder dessen Nachfolger als auch die Big Cores bei Apple würden sicher davon profitieren. Zudem ist es evtl. auch energietechnisch interessant, wenn man zwei Threads auf einen starken Core mapt (SMT) und einen zusätzlichen Kern schlafen legen kann. Oder ist das mehr ein Problem auf SW-Seite, dass man SMT dann halt auch beachten muss.Da mußt Du ARM und Apple fragen. Aber wie schon gesagt, ist Performance oder auch Performance/Watt nicht immer das einzige Kriterium. Vielleicht hat man dort auch einfach mehr Bedenken wegen der möglichen Sicherheitsauswirkungen. Keine Ahnung. Aber aus Performancesicht würde sich das auch dort sicher lohnen.
Die ARM-ISA schließt SMT sicher nicht aus. Es gibt ja Eigendesigns von Leuten mit einer ARM ISA-Lizenz, die SMT in ihre ARM-Server-CPU-Linie eingebaut haben (https://en.wikichip.org/wiki/cavium/microarchitectures/vulcan) (und Nachfolger in 7nm (https://en.wikichip.org/wiki/marvell/microarchitectures/triton), beide jeweils mit SMT4 für einen vergleichsweise schmaleren Core als Zen4).

edit:
Looking at the impact of SMT, on average, we see that 4-way SMT improves the ThunderX2's performance by 32%. This ranges from 8% for video encoding to 74% for pathfinding. Intel meanwhile gets a 18% boost from their 2-way SMT, ranging from 4% to 37% in the same respective scenarios.
https://www.anandtech.com/Show/Index/12694?cPage=5&all=False&sort=0&page=8&slug=assessing-cavium-thunderx2-arm-server-reality