Zen 5 (3/4 nm, 2024)

[Nightspider]

Das Problem dürfte Latenz für den L3 sein. Je mehr Teilnehmer und je weiter weg desto langsamer wirds. Ggf für einen L4 sinnvoll.
Bisher kriegt man es ja sogar mit getrennten Chips (CCDs) auf die Reihe.
Die Anzahl der Teilnehmer dürfte meiner laienhaften Meinung nach nicht das Problem sein.

Durch die 3. Dimension kann man auf verschiedene weisen die Latenzen verbessern. Apple kriegt das ja sogar in 2 Dimensionen hin.

Möglich das sich die Cache-Aufteilung eh komplett ändert. IBMs Ansatz mit riesigem L2 ist ja auch sehr interessant.


Es macht aber auch Chiplet-verschränkte Topologien für den NoC möglich, die auf aktiven Interposern enorme Vorteile bieten und Platzersparnis

Ich würde übertrieben formuliert sogar sagen, das es kein Platzproblem mehr gibt durch die neuen Packaging-Verfahren.

Die Möglichkeiten sind so vielfältig das selbst die Firmen erstmal viel Grundlagenforschung betreiben müssen, welche von den unzähligen Möglichkeiten am meisten Potential haben könnte.

Vielleicht gibt es beim Genoa Nachfolger gar nicht mehr das typische Chiplet-Muster.

Vielleicht wird der Nachfolger aussehen wie ein Tetris-Stacking Monster, wo nur der Preis und das TDP Korsett die Anzahl der Kerne limitiert.

MI200 zeigt wohin es geht:

https://www.servethehome.com/wp-content/uploads/2022/08/HC34-AMD-Instinct-MI200-Series-Key-Innovations.jpg

[robbitop]

Über mehrere CCX wird der L3 Cache nicht genutzt und wäre auch viel zu lahm. L3 Cache Latenz ist grob 13 ns - accross ccx liegt man iirc bei 70-80 ns. Viel zu lahm.

Die Anzahl der Teilnehmer ist super relevant für den Interconnect und damit die Latenz. Alle Interconnects die viele Teilnehmer zulassen sind lahm. Aus dem Grund hat AMD ja die CCX eingeführt damit mit wenig Teilnehmern intern alles schnell bleibt.

IBMs virtueller L3 mit dem L2 wird auch immer langsamer je mehr hops man gehen muss. Insbesondere wenn man einen Chip verlässt.
Wie gesagt als L4 ggf sinnvoll aber als L3 eher nicht.

Ich denke Stacking ist da erstmal die Zukunft weil die Wege kurz bleiben und man über keine fabric muss.

[Complicated]

Ich denke der wichtigste Meilenstein der hier angestrebt wird, ist das Chiplet mit aktivem Interposer tauglich für Mobile zu machen. Wenn man den Stromverbrauch auf Level der monolithischen APUs bringen kann, dann erzielt AMD einen Durchbruch, der sich mal so richtig auszahlen könnte. Da könnten andere Jahre dafür brauchen um nachzuziehen auf Interconnect-Ebene.

Edit: Gut finde ich dabei, dass AMD mit den APUs die Effizienz der monolithischen Designs dennoch weiter puscht und sich somit die Messlatte intern auch immer aktualisiert, weil das tatsächlich mögliche bei monolithischen Designs als Referenz gilt.

[HOT]

Nach Zen5 wird aber das monolithische Design auch im Mobilmarkt zuende sein.

Zen6 muss halt günstig zu produzieren sein, das ist das Hauptproblem. Wie oben ja schon gezeigt, ist eine Lösung relativ problemlos machbar, die Technik ist grundsätzlich da. Das Problem sind die Kosten für die Produktion in dieser riesigen Menge, die der Consumermarkt erfordert. Bei einer MI200 ist das kein Problem, davon braucht man nur 1000e, nicht 1000000. Aber das Verfahren muss als echte, günstige Massenproduktion laufen und da ist Intel offenbar erheblich weiter als TSMC, da das ja für MTL-Mobil schon gemacht werden soll (wärend MTL im Desktop ja nur aus 2 Chiplets bestehen soll).
Bei AMD wird das also bei Zen5 definitiv nichts werden mit 3D-Stacking abseits des Caches. Aber ab Zen6 (und natürlich für RDNA4), also ab 2025, muss dann die Produktionskette auch bei AMD stehen, denn man wird ja gegen Produkte ankämpfen müssen, die bei Intel schon flächendeckend so produziert werden.

[Platos]

Nach Zen5 wird aber das monolithische Design auch im Mobilmarkt zuende sein.

Und warum bzw. wie? Gibts da irgendwelche Quellen dazu?

Um das umzusetzen, muss AMD erstmal den Energieverbrauch in den Griff kriegen bei den Chiplet-CPUs. Nicht umsonst haben sie monolithische im Mobilemarkt.

[Nightspider]

Das liegt einzig am Datenverkehr zwischen IO-Die und CCD übers Package.

(Mir fällt gerade nicht ein wie das Ding heißt wo die zwei Chips draufsitzen)

Wären die Chips gestacked hättest du diesen Verbrauch nicht.

[Complicated]

Dreh doch die Argumentation nicht um - da sind sich doch alle einig, dass AMD genau auf dem Weg dahin ist in der technischen Entwicklung. Oben wurden doch die Patente zu aktiven Interposern genannt.
Und warum bzw. wie? Gibts da irgendwelche Quellen dazu?

Um das umzusetzen, muss AMD erstmal den Energieverbrauch in den Griff kriegen bei den Chiplet-CPUs. Nicht umsonst haben sie monolithische im Mobilemarkt.
Ich denke der wichtigste Meilenstein der hier angestrebt wird, ist das Chiplet mit aktivem Interposer tauglich für Mobile zu machen. Wenn man den Stromverbrauch auf Level der monolithischen APUs bringen kann, dann erzielt AMD einen Durchbruch, der sich mal so richtig auszahlen könnte. Da könnten andere Jahre dafür brauchen um nachzuziehen auf Interconnect-Ebene.

[robbitop]

Ja noch nutzt man keine modernen Interconnects/Packaging Methoden für die Desktop Zens. Da ist schon noch mehr drin mit Stacking und CoWos und co.

[amdfanuwe]

Ihr denkt imo zu konservativ.

Seh ich auch so.
Grundlegend neue Architektur ergibt keinen Sinn ohne die Möglichkeiten neuer Packaging Verfahren auszunutzen.
Sieht man ja schon bei CDNA3 in welche Richtung es gehen kann.

[robbitop]

Es ist halt immer eine Balance. Die Packaging Technologien kosten ja auch Geld beim Einsatz. Je nach Produkt macht das Sinn und mal nicht. Je teurer jeder mm2 Silizium ist desto mehr Sinn macht es.

[Complicated]

Im Prinzip profitieren wir derzeit von den beiden verschiedenen Ansätzen bei Intel und AMD. Intel hat lange die Singelcore Performance nach oben getrieben und musste nicht vom Ringbus abweichen, so lange bis AMD nach einigen verschiedenen Ansätzen eine Lösung gefunden hatte um die Skalierung in die Breite zu ermöglichen mit Zen. Seit dem muß AMD an der Singlecoreleistung arbeiten um Intels Weiterentwicklungen zu matchen mit den Chiplets, doch Intel hat ebenfalls den Druck in die Breite mit den Cores zu gehen - die Antwort sind die E-Cores, die allerdings noch gar nicht bei der maximalen Anzahl angekommen sind, die AMD bieten kann. So nähern sich beide aus verschiedenen Richtungen dem selben Ziel an. Wichtig ist diesen Marathon auch Jahr für Jahr mit Produkten im Markt zu überleben, die der jeweiligen Konkurrenz auch Paroli bieten können - ich finde da halten sich beide respektabel. Bezahlen müssen wir es halt mit hohen Preisen.

[basix]

Ja noch nutzt man keine modernen Interconnects/Packaging Methoden für die Desktop Zens. Da ist schon noch mehr drin mit Stacking und CoWos und co.

CoWoS ist für Consumer-Produkte zu teuer, imho. InFO, welches wir vermutlich bei RDNA3 sehen werden, ist deutlich günstiger. Da kann man das IOD und die zwei CCD relativ nahe zusammenbringen und hat verglichen mit CoWoS nur geringe Effizienznachteile. Vor allem, da wir hier von nur ~200 GByte/s sprechen (DRAM -> CCD & CCD -> CCD) und nicht TByte/s

[amdfanuwe]

CoWoS ist für Consumer-Produkte zu teuer,
Consumer bekommen APU.
Spitzenleistung darf auch was teurer sein.
Ich könnte mir gut ein I/O Die inklusive 128MB Cache vorstellen, auf den dann 1 - 4 CPU Chiplets gestacked werden.

[basix]

Dennoch ist InFO die sinnvollere Wahl verglichen mit CoWos ;) OK, CoWoS-R ist allenfalls auch noch OK (RDL anstatt Si)

Schlussendlich ist es eine Kosten/Nutzen Frage. Und da ist das momentane MCM Konstrukt halt sehr gut. Sobald du mit Si-Interposern und 2.5D Stacking antanzt, steigen die Kosten enorm. Nur für was? Meteor Lake macht das zwar, nur ist das Intel und vorerst Mobile Only. Da bin ich nicht ganz sicher ob das bei denen kostenoptimal ist :rolleyes:

[Badesalz]

Bei einer MI200 ist das kein Problem, davon braucht man nur 1000e, nicht 1000000.Naja, nicht so ganz. Es sind meist Tausende pro Aufbau. Von diesen gibt es wiederum paar Tausend ;) Die Menge ist trotzdem weit überschaubarer als bei der Fußvolkware. Das stimmt schon.

@all
So allgemein find ich das aber alles schon bisschen irre. Eine 4090 ist zwar auch irre, bei der Leistung bekommt man aber trotzdem recht schnell eine Vorstellung welche Probleme bei welcher Software man damit lösen kann.

Die Hersteller von CPUs fangen aber an mit consumer produtcs Lösungen für Probleme anzubieten, die der consumer überhaupt nicht hat. Und nicht haben wird.
Wieviele 3D-Artists (sei es nur Hobby) kennt ihr?
Wieviele packen ("zippen") sich etwas zusammen, um mehr als nur bequem eine einzige Datei statt 7 zu verschicken? (wenn denn überhaupt).
Wer konvertiert stundenlang FLAC/AIFF/WAV nach MP3?
Wieviele Leute kennt ihr die Videoaufnahmen machen, die sich anschliessend auch die Zeit dafür nehmen wollen sie auch zu schneiden und in FormatXY zu konvertieren? Und wie oft machen sie das dann wenn denn?
Wieviele kennt ihr die in RAW knipsen, gegenüber denen die insgesamt Fotos machen?

[amdfanuwe]

Die Hersteller von CPUs fangen aber an mit consumer produtcs Lösungen für Probleme anzubieten, die der consumer überhaupt nicht hat. Und nicht haben wird.
Wieviele 3D-Artists (sei es nur Hobby) kennt ihr?
...
Wieviele kennt ihr die in RAW knipsen, gegenüber denen die insgesamt Fotos machen?
Eben, Consumer begnügen sich mittlerweile mit Smartphones oder Laptop.
Aber wieviele (Semi)Professionelle Fotografen, Künstler, Entwickler können (wollen) sich keine Profi Workstation leisten und sind froh über viele relativ günstige Kerne im Desktop. Wie viele Entwickler, Labore reicht die I/O Ausstattung eines modernen Desktop etc.
Gaming ist doch nur eine Einsatzvariante für einen PC. Können wohl einige nicht verkraften, dass dazu nicht mehr die teuerste CPU nötig ist.

[Windi]

Du vergisst die kleinen SKUs leiden bereits heute daran. Siehe 7600X vs 13600K. Dementsprechend gibt es bereits zeitnah Handlungsbedarf. Entsprechend müsste man alternativ für den gleichen Preis mehr Cores spendieren. Also der 8600X hätte dann 8 Cores.

Threadripper kann man vergessen. Viel zu teuer. Wenn Intel 8+32C im Mainstream anbietet bringt es nichts mit HEDT dagegen zu halten.
Wie man es auch dreht man muss in jeder SKU Kategorie in MT mit den Intel Pendants dagegenhalten können.
Ich würde nicht die momentanen Verkaufspreise vergleichen, wenn man Jahre in die Zukunft spekuliert. Der 7600X und 7700X sind momentan wahrscheinlich absichtlich so teuer, weil sie die 7900X und 7950X günstiger aussehen lassen sollen, die alten Zen3 Prozessoren nicht beim Abverkauf stören sollen und es sich eh nicht lohnt die Prozessoren zu verramschen, wenn die Platformkosten momentan so hoch sind. (Mainboards und DDR5)

Ich glaube nicht, das die 7600X und 7700X teurer in der Herstellung sind, als der 13600K. Wenn AMD wollte, könnten sie Intel sicherlich im Preis unterbieten. Aber momentan macht es halt keinen Sinn den Preis zu senken.
Wenn die Zeit gekommen ist, bringt AMD halt die 3DCache Modelle, die sie wieder in Führung bringen, senken den Preis der X-Modelle etwas und releasen die günstigeren nonX-Modelle.


Und in Zukunft:
Wenn Intel den 8+32C bringt, kann AMD immer noch mit dem 16C dagegen halten, vielleicht gewinnt er nicht jeden MT-Benchmark, aber er dürfte billiger und sparsamer sein. Die E-Kerne bekommt man bei Intel auch nicht geschenkt. Es sind halt 32 Stück, das kostet Fläche.
Und mit dem 16C + 3DCache Modell wird man sich sicherlich bei den Testseiten und Youtubern beliebt machen. (Auch wenn er wahrscheinlich recht teuer sein wird)
Zusätzlich können Co-Prozessoren von Xillinx bei manchen Berechnungen helfen. Man muss halt von Apple lernen.

[basix]

Bei 8+32C wären die 32 E-Cores in etwa so gross wie die 8P Cores. Wenig Fläche ist das nicht, in der Tat. Bei noch mehr E-Cores wird es dann aber langsam absurd. Sieht dann irgendwie nach einer unbalancierten Architektur aus, wenn die E-Cores mehr Fläche als die P-Cores beanspruchen.

Zur Performance von diesem 8+32C Konstrukt: Wohl etwa +50%, inkl. IPC Steigerungen. Arrow Lake soll 10-20% mehr IPC haben. Dafür vermutlich etwas geringerer MT-Takt, um im Power Budget zu bleiben. Bewahrheiten sich die Gerüchte von Zen 5 hinsichtlich Zen 1 IPC Steigerungen, wäre man mit 16C wieder auf ähnlichem Niveau wie das 8+32C Konstrukt von Intel. Hängt am Schluss von den Taktraten der Intel und AMD CPUs ab. Spannende Zeiten ;)

[HOT]

Schon 32 werden absurd sein. Da gibts ja bei kaum einer Software noch einen echten Mehrwert.

[Windi]

32 E-Cores scheinen eher so viel Platz wie 10 P-Cores zu benötigen.
Und AMDs Zen4 Kerne sind dagegen deutlich kleiner. (Das Chiplet hat ja gerade einmal 72mm²)

Selbst wenn Zen5 deutlich aufgebohrt wird, dürfte man mit einem 16 Kerner immer noch kleiner als ein 8+32C von Intel sein.

[Badesalz]

Aber wieviele (Semi)Professionelle Fotografen, Künstler, Entwickler können (wollen) sich keine Profi Workstation leisten und sind froh über viele relativ günstige Kerne im Desktop.Was für ein Markt soll das denn sein? Wobei direkt die Hälfte davon sich eh schon einen M1 Mac gekauft hat.

Übrigens hab ich selbst recht viel mit Foto und gar kurzen (max. paar Minuten) Videschnippeln zu tun. Nennen wir es: Bildanalytik. Selbst bin ich sogar ein RAW-Knipser. Und ich weiß nicht - auch ohne einen Mac - was du meinst...

Wie viele Entwickler, Labore reicht die I/O Ausstattung eines modernen Desktop etc.Labore, kommen mit zwei 530€ OptiPlex klar. Du guckst zu viel CSI.

[HOT]

32 E-Cores scheinen eher so viel Platz wie 10 P-Cores zu benötigen.
Und AMDs Zen4 Kerne sind dagegen deutlich kleiner. (Das Chiplet hat ja gerade einmal 72mm²)

Selbst wenn Zen5 deutlich aufgebohrt wird, dürfte man mit einem 16 Kerner immer noch kleiner als ein 8+32C von Intel sein.
Der Ertrag nimmt gigantisch ab. Alles über 32Threads skaliert nur ein winziger Teil der Consumer-Software überhaupt. Ich halte 32 Littles für Siliziumverschwendung. Viel viel besser 12C big und 16c little. Das würde Intel auch deutlich mehr Leistung bringen als dieser Schwachsinn mit den 32 Littles.

Alles über 32 Threads ist Verschwendung bei X86 im Desktop.

[amdfanuwe]

Alles über 32 Threads ist Verschwendung bei X86 im Desktop.
Hat sich Intel auch Jahrelang mit 8 Threads gedacht.
Da ist mir ein Überangebot an Threads im Markt lieber. Muss man ja nicht kaufen. Und wenn es keiner Kauft, hat sich das von alleine erledigt.

[Nightspider]

Hat sich Intel auch Jahrelang mit 8 Threads gedacht.

Nee das war Gewinnmaximierung.

[basix]

Ich halte 32 Littles für Siliziumverschwendung. Viel viel besser 12C big und 16c little. Das würde Intel auch deutlich mehr Leistung bringen als dieser Schwachsinn mit den 32 Littles.

+1

MT Performance wäre dann aber niedriger und man verliert ein paar Benchmarks ;)

[HOT]

+1

MT Performance wäre dann aber niedriger und man verliert ein paar Benchmarks ;)

Also ich glaube ein 12+16 ist in allen Benchmarks besser als ein 8+32 ;).

[robbitop]

Also ich als UnRaid User (für den Server) freue mich über die Core Explosion im Mainstreammarkt.
VMs, Dockers (z.B. Plex, Pihole, Ubiquity Wifi Controller usw) mögen Kerne. Die müssen auch nicht stark sein. Ob nun E Cores oder P Cores mit je 2 Threads. Genommen wird alles - ich hätte auch kein Problem mit 64 oder mehr E Cores. :D

[Gipsel]

Was hindert AMD eigentlich daran, ein Chiplet mit acht Zen5-Kernen zusammen mit einem Chiplet mit 16 Zen5c-Kernen in einer CPU zu verbauen? Instruktionssatz ist (anders als bisher bei intel) identisch und die Performance auch dichter zusammen als bei intels E- und P-Cores. Wären dann 24C/48T, wovon 8C/16T höher takten und leicht höhere IPC aufweisen, die restlichen 16C/32T sind dann eine Optimierung auf massiv parallele Anwendungen (z.B. 3D-Rendering) und sind dann quasi sowas wie die kleinen Workstation-CPUs auf AM5 (da Threadripper Pro jetzt nur noch die richtigen Dickschiffe hat).
Zum Vergleich: In Bezug auf Zen4c sagte AMD ja, daß die nur etwa halb so groß wie die Zen4-Kerne sind (vermutlich inkludiert dies bereits die bei Zen4c verkleinerten Caches), welche wiederum in etwa grob halb so groß wie intels GoldenCoves sind (das jetzt nur inklusive L2 ohne L3), was bedeuten sollte, daß ein Zen4c nicht so viel größer als ein E-Core sein sollte.

[HOT]

Die hält davon ab, dass das im Desktop, außer eben Robbis doch eher spezielle Anwendungsgebiete für den Mainstream, eben akut sinnlos ist. Da macht AMD doch lieber weiter 16 Zen5 Kerne mit 32 Threads. Das ist doch auch für alle besser. Wenn du wirklich mehr Kerne willst, kannst ja TR kaufen.
Ich denke, dass Intel sich total verrannt hat. E-Cores werden einfach keinen Vorteil mehr haben; wenn die P-Cores nicht mehr ganz soviel Saft brauchen, durch neue Fertigung oder neue Technik oder was auch immer, ist es doch viel viel besser grade bei x86ern, wenn man quantitativ wenige aber dafür sehr potente Threads hat, also so ein ARM-Style multi-milti-Kerner. Ich bin davon überzeugt, dass Intel da auch wieder hin zurück kommt. E Cores sind klasse für Mobil, aber im Desktop braucht man das nur, wenn man sonst zuviel aus der Steckdose zieht.

[Gipsel]

Die hält davon ab, dass das im Desktop, außer eben Robbis doch eher spezielle Anwendungsgebiete für den Mainstream, eben akut sinnlos ist. Da macht AMD doch lieber weiter 16 Zen5 Kerne mit 32 Threads. Das ist doch auch für alle besser. Wenn du wirklich mehr Kerne willst, kannst ja TR kaufen.
TR gibt es inzwischen nur noch als TR Pro (der normale Threadripper ist eingestellt worden), was für die meisten semiprofessionellen Anwender ziemlicher Overkill (und schweineteuer) ist. Eine kleine "AM5-Threadripper"-Variante wäre dagegen für diese Nische vermutlich beinahe perfekt. Also die Leute, die keine 64+ Kerne und auch den massiven IO-Teil (128 PCIe-Lanes!) nicht unbedingt benötigen. Ein 8C- in Kombination mit einem 16C-Chiplet (mit dann insgesamt 48 Threads) würde da gut reinpassen und durch die unterschiedlichen Chiplets auch bei typischen Desktop-Anwendungen gut performen. Das 8C-Chiplet boostet bei wenig threadlastigen Anwendungen sehr hoch (deutlich über 5GHz bei bis zu 16 Threads), bei massiven MultiCore-Anwendungen limitiert die TDP und der niedrigere Maximaltakt der 16C-Chiplets stört nicht mehr (alle 24 Kerne laufen dann z.B. nahe 4,6GHz).
Die Taktbeispiele sind jetzt an Zen4 orientiert. Das ginge mit Zen5 aber entsprechend ähnlich.

[amdfanuwe]

Was hindert AMD eigentlich daran, ein Chiplet mit acht Zen5-Kernen zusammen mit einem Chiplet mit 16 Zen5c-Kernen in einer CPU zu verbauen?
Du meinst: ein Chiplet mit 16 Zen5-Kernen zusammen mit einem Chiplet mit 32 Zen5c-Kernen :D
OK, Scherz.
Aktuell hindert sie, dass sie grad erst mal ZEN4 released haben und noch keine ZEN5 Chiplets zur Verfügung stehen.

Abgesehen davon denk ich, dass sich das Package bei ZEN5 ändert.
Wie stehen die Chancen, dass ZEN5 den IF$ im I/O Die hat und die ZEN5 CPU Chiplets darauf gestacked werden?
128MB Cache machen ja grad mal ~80mm² aus, dürfte dem I/O nicht weh tun.
Hätte auch den Vorteil, das bei Bestückung mit nur einem 8 Core Chiplet diesem der ganze Cache zur Verfügung steht.
Für die 6/8 Core billig CPUs hat man dann immer noch die APUs.

[basix]

Für P+E Cores würde sich das Konzept aus Zen 4 + 4c schon anbieten. 16C Zen 4 ist aber bereits extrem schnell in MT Szenarien. 8+16C wäre dann evtl. 40% schneller bei 230W (Zen 4c mit etwas geringerer IPC und Takt), TDP limitiert hier vermutlich nicht.

Doch wie viele Nutzer benötigen das? Wo gibt es sogar Nachteile durch das Mehr an Threads und die schwächeren Kerne?

Und was noch zu lösen wäre: Scheduling. Man müsste sowas wie den Intel Thread Director haben und für das meiste bevorzugt auf das Zen 4 CCD schedulen.

Deutlich "sexyier" für Desktop wäre mMn:
Die zwei Chiplets via InFO oder ähnlichem verbinden, damit man hinsichtlich Kommunikation untereinander nicht übers IOD gehen muss. Mehrere CCDs könnten so zu einem "Super-CCD" zusammengeschaltet werden. Geringere Latenzen und höhere Bandbreiten zwischen den CCDs, evtl. sogar virtuell verdoppelter L3$. Geringere Bandbreitenanforderungen / geringerer Energieverbrauch hinsichtlich CCD <-> IOD Kommunikation. Das steigert zwar nicht die Peak-MT Performance, sollte aber in vielen anderen Anwendungsfällen, wo es heute schlecht >1x CCD skaliert, helfen. Und wenn das sogar mit dem grösseren L3$ irgendwie klappt, gewinnt man vermutlich in mehr Anwendungen als man denkt. Spiele wie auch einige Produktivsoftware (siehe Milan-X) sprechen gut darauf an. Wäre also für Desktop, Spiele und Server ein Benefit. Mit Zen 4c Chiplets kann man das selbe machen. Ob dann Zen 4 + 4c auf der selben CPU immer noch von Bedarf sind? In 99% der Fälle wohl nicht ;) Wieso? Naja, wenn ich ein "Super-CCD" bauen kann, wieso nicht >2x CCDs so verschalten? :D Ein Bereich von 2-4x Stück würden sich anbieten. Wieso? Wäre für EPYC genau das richtige: z.B. 4x "x3-Super-CCDs" anstatt 12x 1 CCD. Am Desktop dann evtl. auch 3x CCDs miteinander verschaltet, was mit dann 24C die meisten zufrieden stellen dürfte ;)

[Dural]

Die E-Kerne werden immer effizienter sein, aus einem ganz einfachen Grund: Die sind klein wenn nicht geradezu winzig im Vergleich zu den P-Kerne die massiv mehr Fläche brauchen für etwas mehr Leistung.

Die Aufteilung in E und P-Kerne ist eigentlich ziemlich genial, gerade wenn wir von CPUs reden die 32-64 Kerne und mehr haben. Man kann auf eine überschaubare Fläche sehr viele Kerne reinpacken, und für Anwendungen die nicht so gut mit vielen Kernen Skalieren kann man richtig fette P-Kerne einbauen.

[HOT]

Ja, aber über welche MT-Anwendungen reden wir hier. Wir reden hier bei Intel von 8 starken Kernen und 16 schwachen kernen, die einen 16C AMD, der nur mittelstarke Kerne bietet, eben nicht überbietet grade im MT, und meine Kritik ist, dass das mit 32 E-Cores nicht effizienter wird, sondern viel, viel uneffizienter. Und selbst wenn Intel mit ARL die MT-Krone erobern würde, bei gleichstarken P-Kernen von AMD und Intel ist trotzdem beim Löwenanteil der Anwendungen, vor allem aber Spielen, 16 P Cores besser. Ihr verrent euch hier völlig. Das hat ausschließlich den Vorteil, dass Intel Chipfläche sparen kann.
Es ist doch so, dass Intel dieses E-Cores-Desing ja nur deshalb aus dem Hut gezaubert hat, weil die P-Kerne in 10nm einfach furchtbar viel Strom brauchen und furchtbar fett sind. Wenn wir jetzt auf 5nm runtergehen, entschärft sich das Problem doch schon. Sicherlich wird Intel hier auch was dazubasteln, aber das bleibt dann ja trotzdem evolutionär. Spätestens in 20A wird man sich die Frage stellen müssen, warum man überhaupt noch E-Cores verbaut. Wir reden hier von x86. Wir reden hier davon, dass die 6C eigentlich immer noch die optimalen Spieleprozessoren sind beispielsweise. Wir reden von 32 fucking Threads!

Und noch was: AMD scheint das ja zu teilen! AMD hat keine Schrierigkeiten damit 16 P-Cores auf einen Träger zu pappen. Die hätten auch keine wirklichen Probleme 24 P-Cores auf den Träger zu pappen. Die Cores sind klein genug und hinreichend effizient in sich, man kann es also problemlos über die TDP regeln. Warum um alles in der Welt, sollte man solche schwachsinnigen E-Cores-Experimente wagen, wenn man doch alle Mittel hat? AMD hat die TRs ja genau deshalb eingestellt, weil es eben viel zuwenig Leute wie Robbi gibt, die eine solche Nachfrage auch haben. Und jetzt macht ihr daraus ein Problem für AMD? So ein Unsinn!

[Der_Korken]

Der Vorteil von E-Cores ist ja unter anderem, dass man auf Fläche und Verbrauch bei den P-Cores weniger Rücksicht nehmen muss. Intels Problem war ja nie, dass deren P-Cores zu langsam waren, sondern dass sie zu viel Strom verbraucht haben (und vielleicht auch zu viel Fläche, wobei sie beim SoC dafür imho viel besser sind). In ST hui, in MT pfui, sozusagen. Genau dieses Problem lösen die E-Cores.

Bei AMD war kompromisslose ST-Leistung nie das Design-Ziel, sondern sie haben immer auch Größe und Verbrauch im Blick behalten. Dadurch haben sie seit fast 3,5 Jahren 64 Kerne im Server-Bereich, was Intel bis heute nicht erreicht hat und auch nächstes Jahr wohl zumindest nicht übertrumpfen wird. Also quasi: MT hui, ST pfui.

Nun bleibt aber ST-Leistung immer noch wichtig und sei es nur, weil man in der Praxis Anwendungen hat, die nur bis 8 Kerne (oder so) skaliert. AMD könnte sich entscheiden Z5 (Zen 5) krass in die Breite zu bauen, um die ST-Krone gegen Intel zu behaupten, aber dadurch könnten sie gegenüber Z4 (Zen 4) an Flächen- und Energieeffizienz verlieren. Für Desktop-Systeme würde ich mittlerweile sagen, dass letzteres egal ist, weil ein 7950X mit 9W pro Kern bestens versorgt ist, der Sockel aber theoretisch 14W erlauben würde. Bei der Flächeneffizienz könnte AMD aber trotzdem interessiert sein, E-Cores einzuführen. Statt 8xZ5 auf ein Chiplet zu packen, werden es 4xZ5+8xZ4c (jeweils ein Z5 oder zwei Z4c an einem L3-Slice). Damit würden die Chiplets gegenüber 8xZ4 eventuell nicht mal wachsen (im Gegensatz zu einem reinen Z5-CCD), man hat aber die ST-Leistung von Z5 und die MT-Leistung von 12xZ4. Da würde für die meisten die Single-CCD-Lösung dicke reichen und für Power-User oder Hochgeschwindigkeitsgamer, die unbedingt mehr P-Cores wollen, hätte man noch 8+16 am Start. AMD scheint auch bei RDNA3 voll auf performance per area zu setzen. Langfristig ist das nicht dumm, da die Produkte bereits heute immer teurer und der Käuferkreis immer kleiner wird.

[HOT]

Ah du weisst also jetzt schon, dass MTL und ARL SC schneller ist als Zen5? Läufts darauf hinaus? Ich glaub, dass das purer Unsinn ist. AMD wird einfach den besten Core entwickelt haben, den sie entwickeln konnten. Sicherlich legt man vorher fest, dass der auch ökonomisch sein muss. Das tat Intel auch, nur funktionierte der Prozess nicht wie er sollte. Die Littles sind ja nicht von Anfang an geplant worden, sondern wurden aus der Not geboren. Also: Busted!

[robbitop]

Was hindert AMD eigentlich daran, ein Chiplet mit acht Zen5-Kernen zusammen mit einem Chiplet mit 16 Zen5c-Kernen in einer CPU zu verbauen? Instruktionssatz ist (anders als bisher bei intel) identisch und die Performance auch dichter zusammen als bei intels E- und P-Cores. Wären dann 24C/48T, wovon 8C/16T höher takten und leicht höhere IPC aufweisen, die restlichen 16C/32T sind dann eine Optimierung auf massiv parallele Anwendungen (z.B. 3D-Rendering) und sind dann quasi sowas wie die kleinen Workstation-CPUs auf AM5 (da Threadripper Pro jetzt nur noch die richtigen Dickschiffe hat).
Zum Vergleich: In Bezug auf Zen4c sagte AMD ja, daß die nur etwa halb so groß wie die Zen4-Kerne sind (vermutlich inkludiert dies bereits die bei Zen4c verkleinerten Caches), welche wiederum in etwa grob halb so groß wie intels GoldenCoves sind (das jetzt nur inklusive L2 ohne L3), was bedeuten sollte, daß ein Zen4c nicht so viel größer als ein E-Core sein sollte.
Man müsste schauen, dass der Scheduler von Windows auch entsprechend "aware" ist und die Frage ist, wie wichtig Intels Hardware "Thread Director" ist und ob man sowas auch hat/haben will, oder?

[Zossel]

Was hindert AMD eigentlich daran, ein Chiplet mit acht Zen5-Kernen zusammen mit einem Chiplet mit 16 Zen5c-Kernen in einer CPU zu verbauen?

Ob es dafür signifikant Kundschaft geben würde wenn man auch 2*8*Zen5-non-c kaufen könnte?

Bei Intel wird man ja zwangsbeglückt.

[Zossel]

Eine kleine "AM5-Threadripper"-Variante wäre dagegen für diese Nische vermutlich beinahe perfekt.

Es waren doch 2 Server-Sockel für DDR5 von AMD geplant, denke das wird sich auch in den Threadripper Varianten niederschlagen.

[amdfanuwe]

AMD hat die TRs ja genau deshalb eingestellt, weil es eben viel zuwenig Leute wie Robbi gibt, die eine solche Nachfrage auch haben.
TR wurde nicht eingestellt. Du erinnerst dich an Corona und Chipmangel? Da hat AMD eben erst mal die lukrativeren Märkte bedient. Gibt ja deshalb auch jetzt erst Threadripper auf ZEN3 Basis.

Für Server soll es ja auch mit ZEN4 eine kleiner Plattform geben mit 6 Kanal SI, denke da wird auch was für Threadripper dabei sein.

Edit: da war Zossel etwas schneller.

[robbitop]

Man könnte ja alles mixen. Zen5+Zen5 CCD; Zen5+Zen5C CCD; Zen 5C+Zen5C CCD

[robbitop]

TR wurde nicht eingestellt. Du erinnerst dich an Corona und Chipmangel? Da hat AMD eben erst mal die lukrativeren Märkte bedient. Gibt ja deshalb auch jetzt erst Threadripper auf ZEN3 Basis.
Naja jetzt gibt es nur noch Threadripper PRO der deutlich teurer als bis dato ist und nur bei OEMs als fertiges System zu kaufen ist. Ist irgendwie schon was anderes.

[Lehdro]

Solange AMD die MT Performance im selben Maße steigern kann (auf den Gesamtleistung im MT bezogen) wie Intel noch mehr baugleiche E-Cores hinzufügt wird das Rennen zu AMDs Gunsten ausgehen:

- weniger Kerne mit vergleichbarer MT Leistung = bessere Skalierung über die Breite der Anwendungen, Amdahls Law (https://de.wikipedia.org/wiki/Amdahlsches_Gesetz#:~:text=Das%20amdahlsche%20Gesetz%20(benannt%201967,von%20Pro grammen%20durch%20parallele%20Ausf%C3%BChrung.)
- Intel muss schon jetzt immer alles voll ausfahren gegen Zen 3/4, kann also nie die Verbrauchseffizienz von vielen Kernen gegenüber weniger Kernen mitnehmen (mehr Kerne, dafür aber alle niedriger getaktet klappte bisher nie gegen AMD)
- AMD hat derzeit mindestens immer die doppelte Menge an "echten" Kernen um dort Taktraten und IPC Steigerungen mitzunehmen, Intel muss 2x Architekturen implementieren, weswegen sie beim Refresh derzeit nur weiter aufs "Gaspedal" (Power + Anzahl E-Cores) drücken können -> langfristig muss die IPC von beiden Kernarten mitwachsen und zwar im sinnvollen Verhältnis zueinander
- AMD hat jederzeit volle Kompatibilität, Intel musste schon auf Features verzichten wegen E-Cores (AVX512) -> jeder Fortschritt bei den P-Cores hinsichtlich Instruktionen will mit den E-Cores überlegt/abgestimmt sein

[HOT]

TR wurde nicht eingestellt. Du erinnerst dich an Corona und Chipmangel? Da hat AMD eben erst mal die lukrativeren Märkte bedient. Gibt ja deshalb auch jetzt erst Threadripper auf ZEN3 Basis.

Für Server soll es ja auch mit ZEN4 eine kleiner Plattform geben mit 6 Kanal SI, denke da wird auch was für Threadripper dabei sein.

Edit: da war Zossel etwas schneller.
Hallo? Klar wurde der klassische TR eingestellt. TR Pro zählt nicht, das ist ein anderer Markt.

Man könnte ja alles mixen. Zen5+Zen5 CCD; Zen5+Zen5C CCD; Zen 5C+Zen5C CCD

Nein, es ist schlichtweg Quatsch! Warum sollte man einen c nehmen, wenn man auch einen normalen nehmen kann? Es ist einfach Unsinn. Und wird ja auch nicht passieren, wir kennen ja die Folien. Nichtmal im Mobilbereich wird der c erwähnt.

Lehdro
Und das alles trotz dem großen Problems, dass die inter-CCD-Latenzen bei Zen4 langsam kritisch werden, wie man am 7900X gut sieht. Wäre das Ding monolithisch, würde der mit Intel bei mehr Anwendungen einfach den Boden abwischen. So hat Intel Glück im Unglück und kommt mit den 8 P-Cores aus.

[Zossel]

Der Vorteil von E-Cores ist ja unter anderem, dass man auf Fläche und Verbrauch bei den P-Cores weniger Rücksicht nehmen muss. Intels Problem war ja nie, dass deren P-Cores zu langsam waren, sondern dass sie zu viel Strom verbraucht haben (und vielleicht auch zu viel Fläche, wobei sie beim SoC dafür imho viel besser sind). In ST hui, in MT pfui, sozusagen. Genau dieses Problem lösen die E-Cores.

Ich kann mir nicht vorstellen das es keine Szenarien gibt wo unterschiedliche Cores in einer Scheduling-Domain nicht ziemlich üble Performance-Regressions produzieren.

[robbitop]

Also in MT sind 7970X und 13900K ziemlich genau on par. Wenn man davon ausgeht, dass beide ihre uArchs grob im gleichen Maße steigern können, würde es wohl dabei bleiben wenn keiner seine Kernanzahl erhöht. Aber bei der nächsten E Core Verdopplung wird das Pari eben verschoben.
Zen 4 konnte einen so großen Sprung in MT machen, weil man jetzt alle Kerne so hoch takten kann (dank mehr TDP Budget und dank grundsätzlich taktfreudigeren Kernen). Die Maßnahme ist jetzt abgehakt und mit der hat man die E Core Verdopplung von 8 auf 16 kompensiert (bzw leicht unterkompensiert da ADL langsamer in MT war als der 5950X und der 7970X nun gerade mal pari ist).

Wenn man das (MT Benchmarks) komplett vernachlässigt braucht man natürlich nichts zu machen. Die Frage ist, wie wichtig AMD das Gewinnen von MT Benchmarks ist (auch wenn die wenig repräsentativ zum Nutzungsverhalten der allermeisten User sind). Schon der 16C und der 13900K sind für die meisten User in MT überdimensioniert und 8c/16t sind mehr als ausreichend.

[Gipsel]

Und was noch zu lösen wäre: Scheduling. Man müsste sowas wie den Intel Thread Director haben und für das meiste bevorzugt auf das Zen 4 CCD schedulen.
Man müsste schauen, dass der Scheduler von Windows auch entsprechend "aware" ist und die Frage ist, wie wichtig Intels Hardware "Thread Director" ist und ob man sowas auch hat/haben will, oder?Die Performance-Charakteristik z.B. von Zen4 und Zen4c ist sehr ähnlich (anders als bei intel). Und mit bevorzugten Kernen kommt der Windows-Scheduler ja jetzt auch schon klar. Das komplette CCD mit den "full fat" Kernen wird halt schlicht bevorzugt mit Threads bedacht (und darin gibt es eben noch die 1 oder 2 Kerne, die den Maximalboost schaffen). Ich sehe da kein größeres Problem.

[robbitop]

Nein, es ist schlichtweg Quatsch! Warum sollte man einen c nehmen, wenn man auch einen normalen nehmen kann? Es ist einfach Unsinn. Und wird ja auch nicht passieren, wir kennen ja die Folien. Nichtmal im Mobilbereich wird der c erwähnt.
Weil die C cores deutlich kleiner sind und man mehr Cores pro Fläche schafft und wahrscheinlich sind sie auch effizienter.

Man muss mal sehen wo und ob man es einsetzt. Ich habe es wie du auch noch auf keiner Roadmap gesehen.

Es geht hier glaube ich nicht unbedingt darum, dass das definitiv passiert sondern um die Möglichkeit zu diskutieren und was dann passieren würde.

Es wäre (zum xten mal wiederholt) schön für die Diskussionskultur wenn du aufhören würdest, anderer Leute Posting als "Quatsch" zu titulieren (insbesondere wenn mit Substanz diskutiert wird und nicht inhaltlich definitiv und belegbar falsch). Du hast dich (wie wir alle auch) schon oft genug geirrt um dir diese Überheblichkeit leisten zu können, definitive Aussagen zu treffen. Man kann ja gern schreiben "meiner Meinung nach ist es unwahrscheinlich, weil ...".

[Zossel]

Und was noch zu lösen wäre: Scheduling. Man müsste sowas wie den Intel Thread Director haben und für das meiste bevorzugt auf das Zen 4 CCD schedulen.

Der Intel Thread Director interpoliert auch nur aus der Vergangenheit in die Zukunft, und das kann übelst daneben liegen.

[HOT]

Also in MT sind 7970X und 13900K ziemlich genau on par. Wenn man davon ausgeht, dass beide ihre uArchs grob im gleichen Maße steigern können, würde es wohl dabei bleiben wenn keiner seine Kernanzahl erhöht. Aber bei der nächsten E Core Verdopplung wird das Pari eben verschoben.[...]
Nein, nur bei wenigen Anwendungen. Irrelevant im realen Leben.

Weil die C cores deutlich kleiner sind und man mehr Cores pro Fläche schafft und wahrscheinlich sind sie auch effizienter.

Man muss mal sehen wo und ob man es einsetzt. Ich habe es wie du auch noch auf keiner Roadmap gesehen.

Es geht hier glaube ich nicht unbedingt darum, dass das definitiv passiert sondern um die Möglichkeit zu diskutieren und was dann passieren würde.

Es wäre (zum xten mal wiederholt) schön für die Diskussionskultur wenn du aufhören würdest, anderer Leute Posting als "Quatsch" zu titulieren (insbesondere wenn mit Substanz diskutiert wird und nicht inhaltlich definitiv und belegbar falsch). Du hast dich (wie wir alle auch) schon oft genug geirrt um dir diese Überheblichkeit leisten zu können, definitive Aussagen zu treffen. Man kann ja gern schreiben "meiner Meinung nach ist es unwahrscheinlich, weil ...".

Woher weiss du das, dass die c-Cores soviel kleiner sind, dass sich das überhaupt lohnt? Das sind keine E-Cores, sondern Zen4, die auf den Usecase bei 2,5GHz-Server-Workloads optimiert sind. Woher kommt diese irrige Annahme, dass das überhaupt so geht? Ich denke vielmehr, dass du dann eine CPU hättest, die in etwa die gleiche Fläche hat und 4 Zen4c-Kerne mehr hat, die superniedrig getaktet sind. Wo soll denn da bitte der Vorteil sein?

Der Intel Thread Director interpoliert auch nur aus der Vergangenheit in die Zukunft, und das kann übelst daneben liegen.

Jo und warum sollte man sich so ne Hypothek aufladen, wenn sich das ganz einfach vermeiden lässt? Ich versteh diese Zen4c-Verfechter einfach nicht...

[Zossel]

Die Performance-Charakteristik z.B. von Zen4 und Zen4c ist sehr ähnlich (anders als bei intel). Und mit bevorzugten Kernen kommt der Windows-Scheduler ja jetzt auch schon klar. Das komplette CCD mit den "full fat" Kernen wird halt schlicht bevorzugt mit Threads bedacht (und darin gibt es eben noch die 1 oder 2 Kerne, die den Maximalboost schaffen). Ich sehe da kein größeres Problem.

/dev/glaskugel anywhere?

[Gipsel]

Woher weiss du das, dass die c-Cores soviel kleiner sind, dass sich das überhaupt lohnt?Weil AMD das gesagt hat. Und soviel niedriger taktet Zen4c offenbar nicht.
/dev/glaskugel anywhere?Ist ja quasi der gleiche Kern, nur auf minimal niedrigeren Maximaltakt ausgelegt (etwas dichteres Layout, etwas effizienter im Sweetspot) und halbierten L2-Cache (L3 pro Kern eventuell auch). Da ist keine Glaskugel nötig. Genausowenig wie beim Windows-Scheduler, der auch jetzt schon mit bevorzugten Kernen klarkommt.

[HOT]

Weil AMD das gesagt hat. Und soviel niedriger taktet Zen4c offenbar nicht.
Ist ja quasi der gleiche Kern, nur auf minimal niedrigeren Maximaltakt ausgelegt (etwas dichteres Layout, etwas effizienter im Sweetspot) und halbierten L2-Cache (L3 pro Kern eventuell auch). Da ist keine Glaskugel nötig. Genausowenig wie beim Windows-Scheduler, der auch jetzt schon mit bevorzugten Kernen klarkommt.

AMD bringt nicht mal die doppelte Anzahl unter, sonst hätte Bergamo 192 Kerne, hat er aber nicht. Das ist also in keiner Weise vergleichbar mit Intel. Die sind vielleicht um 25%-Punkte kleiner. Man hat ja 16C pro Chiplet offenbar, aber nur noch 2 Pro "Kanal" am IOD. Es ist und bleibt völlig sinnlos im Desktop und in den Folien steht es nirgendwo anders drin außer bei Bergamo+Nachfolger, also wird das auch wohl kaum passieren.

[robbitop]

Nein, nur bei wenigen Anwendungen. Irrelevant im realen Leben.
Benchmarks halt. Muss man sehen, wie wichtig AMD die sind. Für das reale Leben ist schon AMDs 12C und 16C völlig sinnlos. Und trotzdem hat man die im Programm. Was denn nun?



Woher weiss du das, dass die c-Cores soviel kleiner sind, dass sich das überhaupt lohnt? Das sind keine E-Cores, sondern Zen4, die auf den Usecase bei 2,5GHz-Server-Workloads optimiert sind. Woher kommt diese irrige Annahme, dass das überhaupt so geht? Ich denke vielmehr, dass du dann eine CPU hättest, die in etwa die gleiche Fläche hat und 4 Zen4c-Kerne mehr hat, die superniedrig getaktet sind. Wo soll denn da bitte der Vorteil sein?


Cachereduktion und man kann die design libs auf density statt auf Takt optimieren. Und AMD hat es ja auch gesagt, dass im Gesamtergebnis dadurch die C Cores deutlich kleiner sind.

[Der_Korken]

Ah du weisst also jetzt schon, dass MTL und ARL SC schneller ist als Zen5? Läufts darauf hinaus?

Habe ich nicht geschrieben. Die Frage, die sich stellt ist, ob Intel bei der ST-Leistung einen Vorteil daraus ziehen kann, mit Fläche und Energie verschwenderischer umgehen zu können, weil diese beiden Metriken über die E-Cores ausgebügelt werden. Bei Zen 2 und 3 hat AMD es unerwartet (zumindest aus meiner Sicht) geschafft, Intel bei der ST-Leistung zu überholen ohne dafür viel opfern zu müssen. Die Architektur war frisch und in Hinblick auf die nachfolgenden Schritte geplant, während Intel in ihrer Marktsegementierungspolitik gefangen war und sich nur mit einem Skylake-Aufguss nach dem anderen zu helfen wusste. Mit den Cove-Architekturen hat Intel wieder an Fahrt aufgenommen, d.h. man kann nicht mehr einfach so davon ausgehen, dass AMD an allen Fronten wieder Schritt für Schritt davonzieht.


- weniger Kerne mit vergleichbarer MT Leistung = bessere Skalierung über die Breite der Anwendungen, Amdahls Law (https://de.wikipedia.org/wiki/Amdahlsches_Gesetz#:~:text=Das%20amdahlsche%20Gesetz%20(benannt%201967,von%20Pro grammen%20durch%20parallele%20Ausf%C3%BChrung.)

Das ist für den Desktop ein guter Punkt. Als Zen 1 neu war, hatte man eine lange Durststrecke aus Quadcores hinter sich. Dann wurde innerhalb kurzer Zeit auf 16 Cores erhöht, ohne dass die Software (im Desktop hauptsächlich Spiele) hätten nachziehen können. Aktuell ist der Nutzen von >16 Kernen im Desktop relativ gering, d.h. strategisch braucht man hier erstmal wieder schnellere Kerne.

Da AMD aber ihren Fokus aktuell stark auf performance per area shiftet, würden für mich E-Cores zur Flächeneinsparung gut reinpassen. Anwendungen, die schnelle Kerne brauchen, brauchen i.d.R. nicht 16 gleich schnelle Kerne.

Ich kann mir nicht vorstellen das es keine Szenarien gibt wo unterschiedliche Cores in einer Scheduling-Domain nicht ziemlich üble Performance-Regressions produzieren.

Das ist das große Aber. Ich habe keine Ahnung, wie das Scheduling bei sowas läuft, deswegen gehen alle meine Spekulationen immer von einem perfekten Scheduling aus :D.

Woher weiss du das, dass die c-Cores soviel kleiner sind, dass sich das überhaupt lohnt? Das sind keine E-Cores, sondern Zen4, die auf den Usecase bei 2,5GHz-Server-Workloads optimiert sind. Woher kommt diese irrige Annahme, dass das überhaupt so geht? Ich denke vielmehr, dass du dann eine CPU hättest, die in etwa die gleiche Fläche hat und 4 Zen4c-Kerne mehr hat, die superniedrig getaktet sind. Wo soll denn da bitte der Vorteil sein?

AMD hat selber gesagt, dass Z4c etwa halb so viel Fläche pro Core braucht wie Z4. Was genau sie dafür bezahlen, werden wir erst in Reviews sehen. Maximaler Takt wird sehr wahrscheinlich dazu gehören um generell dichter zu packen, dazu eventuell noch halbierte FPU-Breite und kleinerer L2 (eventuell sogar <512kB). Und natürlich ist das effizienter (entweder Fläche oder Energie oder beides) als einfach Z4-Kerne runterzutakten. Sonst würde AMD das nicht entwickeln und etliche Monate vor Release bereits auf Events ankündigen, wenn das so wenig bringen würde.

[robbitop]

AMD bringt nicht mal die doppelte Anzahl unter, sonst hätte Bergamo 192 Kerne, hat er aber nicht. Das ist also in keiner Weise vergleichbar mit Intel. Die sind vielleicht um 25%-Punkte kleiner. Man hat ja 16C pro Chiplet offenbar, aber nur noch 2 Pro "Kanal" am IOD. Es ist und bleibt völlig sinnlos im Desktop und in den Folien steht es nirgendwo anders drin außer bei Bergamo+Nachfolger, also wird das auch wohl kaum passieren.
Genoa verbaut 12 CCDs um auf seine 96C zu kommen, Bergamo verbaut 8 CCDs mit (jeweils 16C) um auf 128C zu kommen. Jetzt könnte man natürlich fragen, warum AMD keinen 192C Bergamo launcht. Aber pro CCD sind es doppelt so viele Cores.

[HOT]

Ich glaub ich muss euch die Folien noch mals in Erinnerung rufen:

Server:
https://www.planet3dnow.de/cms/65472-amd-financial-analyst-day-2022-alle-praesentationen/4/

Consumer:
https://www.planet3dnow.de/cms/65472-amd-financial-analyst-day-2022-alle-praesentationen/8/

Steht da irgendwo Zen4c oder Zen5c? Wo? Wo???


Genoa verbaut 12 CCDs um auf seine 96C zu kommen, Bergamo verbaut 8 CCDs mit (jeweils 16C) um auf 128C zu kommen. Jetzt könnte man natürlich fragen, warum AMD keinen 192C Bergamo launcht. Aber pro CCD sind es doppelt so viele Cores.

Aber die CCDs sind größer!!!
Warum wohl sonst?!?!?

Seht doch mal das offensichtliche! Die 2x stehen für "Cloud container Desity", das ist Marketing, das heißt doch nicht, dass die nur halb so groß bei den Chiplets sind, das sind sie garantiert nicht, sonst wären es 192 :freak:

...]

Da AMD aber ihren Fokus aktuell stark auf performance per area shiftet, würden für mich E-Cores zur Flächeneinsparung gut reinpassen. Anwendungen, die schnelle Kerne brauchen, brauchen i.d.R. nicht 16 gleich schnelle Kerne.


[...]
Wie kommst du auf das schmale Brett?

[amdfanuwe]

Jetzt könnte man natürlich fragen, warum AMD keinen 192C Bergamo launcht.
TDP

[HOT]

TDP
Nein. Das wäre nur ne Sache des Taktes und da wären 192 Kerne im Vorteil.

[robbitop]

Aber die CCDs sind größer!!!
Warum wohl sonst?!?!?

Seht doch mal das offensichtliche!
AMD hat selbst gesagt die C Cores sind nur etwa halb so groß.
Ich wüsste jetzt keine genaue Die Size - und ich wüsste nicht, dass die veröffentlicht wurde. Also bitte liefere Belege für diese Aussage.

Das heißt nicht, dass AMD mittelfristig zwangsweise die C Cores im Desktop oder mobile einsetzt. Aber vielleicht ja doch eines Tages. Und vielleicht ja doch schon eher. Weiß man nicht - nicht alle SKUs werden auf Roadmaps vorher gezeigt. Kann man aber trotzdem drüber spekulieren.

Es sind doppelt so viele Cores pro CCD. Und die CCD Strategie macht vor allem bei kleinen Dice Sinn. Der Bergamo CCD wird wahrscheinlich nicht wesentlich größer als der Genoa CCD sein.

TDP
Sehr viel wahrscheinlicher als Fläche - jap. Oder ggf. ist das am Markt noch nicht gefragt.

[HOT]

AMD hat selbst gesagt die C Cores sind nur etwa halb so groß.
Ich wüsste jetzt keine genaue Die Size - und ich wüsste nicht, dass die veröffentlicht wurde. Also bitte liefere Belege für diese Aussage.

Das heißt nicht, dass AMD mittelfristig zwangsweise die C Cores im Desktop oder mobile einsetzt. Aber vielleicht ja doch eines Tages. Und vielleicht ja doch schon eher. Weiß man nicht - nicht alle SKUs werden auf Roadmaps vorher gezeigt. Kann man aber trotzdem drüber spekulieren.
[...]
Steht so nicht im Foliensatz. Das war bestimmt dieses Cloud-Density-Gedöns. Und "nur etwa" kann auch trotzdem größer sein. Es gibt außer Größe keinen vernünftigen Grund, warum man nicht 192 verbauen sollte bei gleichem IOD und Sockel, da gehe ich jede Wette ein.
Es ist aber auch völlig wurscht, es ist im Desktop schlichtweg irrelevant. für 99,9% der Desktop-User wäre es eher von Nachteil, wenn man ein Zen4 und ein Zen4c-Chiplet verbaut, das ist der springende Punkt. Damit könnte man zwar Intel klarer schlagen im pur-MT, aber handelt sich nen Haufen Probleme ein und das Problem stellt sich ja auch gar nicht, da MTL ja offenbar weiterhin 8+16 ist und das fängt man mit einem 16C Zen5 ein (wenn alles so läuft wie geplant). Es gibt genau 0 Grund für einen Zen5c im Desktop, das schreibe ich doch die ganze Zeit. Um ARL kann AMD sich mit Zen6 kümmern, wie der aussieht, steht in den Sternen (das mit dem 8+32 glaub ich i.Ü. auch nicht, das war mit Sicherheit auch Blödsinn).

[Gipsel]

AMD bringt nicht mal die doppelte Anzahl unter, sonst hätte Bergamo 192 Kerne, hat er aber nicht. Das ist also in keiner Weise vergleichbar mit Intel. Die sind vielleicht um 25%-Punkte kleiner. Man hat ja 16C pro Chiplet offenbar, aber nur noch 2 Pro "Kanal" am IOD. Es ist und bleibt völlig sinnlos im Desktop und in den Folien steht es nirgendwo anders drin außer bei Bergamo+Nachfolger, also wird das auch wohl kaum passieren.Im kleineren SP6-Sockel (gleiche Größe wie SP3 mit ein paar Pins mehr) werden es mit Zen4c doppelt soviel Kerne wie mit Zen4 ;). Ich würde mal stark vermuten, daß die Platzverhältnisse nicht unbedingt das Limit darstellen. Im größeren SP5 limitiert vielleicht die TDP? Vermutlich wären 192Kerne dort nicht deutlich schneller, nur teurer. Man hat dort ja ein exorbitantes IO-Die mit 12 DDR5-Kanälen und 128 PCIe5-Lanes, was bei Volllast selber wohl schon locker 100W fressen dürfte. Ein wenig was sollte für die Kerne dann ja schon noch übrigbleiben (128Kerne bei 2,3W/Kern oder 192Kerne bei 1,5W/Kern ist vermutlich performancetechnisch kein allzu großer Unterschied).

[robbitop]

Consumer:
https://www.planet3dnow.de/cms/65472-amd-financial-analyst-day-2022-alle-praesentationen/8/

Steht da irgendwo Zen4c oder Zen5c? Wo? Wo???



Zen 5 ist gerade mal eine SKU gezeigt worden auf der einen Folie - den Rest hat man offen gelassen. Take a chill pill und komm mal runter in einen sachlichen Diskussionsstil.

[robbitop]

Es ist aber auch völlig wurscht, es ist im Desktop schlichtweg irrelevant. für 99,9% der Desktop-User wäre es eher von
99,9% der User brauchen keinen 12C oder 16C - schon gar nicht 2019 als man das mit Zen 2 gebracht hat. Warum hat man das dann gemacht? Ein 24C in 2024 finde ich jetzt weniger unangemessen als ein 16C in 2019...

[HOT]

99,9% der User brauchen keinen 12C oder 16C - schon gar nicht 2019 als man das mit Zen 2 gebracht hat. Warum hat man das dann gemacht? Ein 24C in 2024 finde ich jetzt weniger unangemessen als ein 16C in 2019...
Vielleicht legen die ja extra für dich einen Zen5+Zen5c auf, ich wette ne Bierkiste dagegen.

[Savay]

Hängt doch wohl davon ab was Intel bringt.

Technisch spricht IMHO jedenfalls erstmal sogar weniger dagegen als gegen Intels Ansatz mit den viel brachialer kastrierten E-Cores. :tongue:


Das ist das große Aber. Ich habe keine Ahnung, wie das Scheduling bei sowas läuft, deswegen gehen alle meine Spekulationen immer von einem perfekten Scheduling aus :D.

Also das 2. CCD bei den Dual CCD CPUs ist auch heute schon auf weniger Takt gebinnt und mehr auf geringere Stromaufnahme/Thread optimiert als das erste mit den Prime Kernen.
(pro Kern wohl locker 1/2 der Stromaufnahme)

Theoretisch ist das "Problem" also heute schon vorhanden, da scheinen die Regressions aber eher durch Latenzen und Abhängigkeiten zu kommen, was bei klassischen MT Workloads wohl eher sekundär ist.

[Gipsel]

Steht so nicht im Foliensatz.Wurde in der Ryzen 7000 Vorstellung gesagt (https://www.youtube.com/watch?v=WcH_7xsYtUk&t=1225s) (also daß Zen4c-Kerne nur halb so groß wie Zen4-Kerne sind).

Aber eigentlich sind wir ein wenig OT damit. Eigentlich geht es ja um Zen5. Der einzig erwähnenswerte Punkt in diesem Zusammenhang ist vielleicht, daß AMD durchaus die Option besitzt, durch Mischbestückung von normalen CCDs und solchen mit der dichteoptimierten c-Version intels Aufblähen des Corecounts mittels E-Cores zu kontern, sollten sie dies als nötig erachten. Niemand sagt voraus, daß das unbedingt so kommen wird. Und auch wenn Du den Markt als klein ansiehst, intel tut es offenbar nicht (32E-Cores sind schon eine Ansage). Und es gibt sicher auch heute schon Leute, die diese Nische als attraktiv ansehen würden (zwischen Desktop und Threadripper Pro gibt es heute eine riesige Lücke).

[robbitop]

Vielleicht legen die ja extra für dich einen Zen5+Zen5c auf, ich wette ne Bierkiste dagegen.
So oft wie du dich schon geirrt hast, würde ich an deiner Stelle keine Wetten abschließen. :D

Aber mal ehrlich: Spekulationsforum. Leben und Leben lassen und für alles aufgeschlossen sein anstatt verkrampft an seiner Meinung festzuhalten. Verstehe das ehrlich gesagt null.

Hängt doch wohl davon ab was Intel bringt.

Technisch spricht IMHO jedenfalls erstmal sogar weniger dagegen als gegen Intels Ansatz mit den viel brachialer kastrierten E-Cores. :tongue:


So ist es. Möglich wäre es. Ob sie es machen? Muss man sehen.

Wurde in der Ryzen 7000 Vorstellung gesagt (https://www.youtube.com/watch?v=WcH_7xsYtUk&t=1225s) (also daß Zen4c-Kerne nur halb so groß wie Zen4-Kerne sind).

Aber eigentlich sind wir ein wenig OT damit. Eigentlich geht es ja um Zen5. Der einzig erwähnenswerte Punkt in diesem Zusammenhang ist vielleicht, daß AMD durchaus die Option besitzt, durch Mischbestückung von normalen CCDs und solchen mit der dichteoptimierten c-Version intels Aufblähen des Corecounts mittels E-Cores zu kontern, sollten sie dies als nötig erachten. Niemand sagt voraus, daß das unbedingt so kommen wird. Und auch wenn Du den Markt als klein ansiehst, intel tut es offenbar nicht (32E-Cores sind schon eine Ansage). Und es gibt sicher auch heute schon Leute, die diese Nische als attraktiv ansehen würden (zwischen Desktop und Threadripper Pro gibt es heute eine riesige Lücke).This :up:

[Der_Korken]

Ich glaub ich muss euch die Folien noch mals in Erinnerung rufen:

Server:
https://www.planet3dnow.de/cms/65472-amd-financial-analyst-day-2022-alle-praesentationen/4/

Consumer:
https://www.planet3dnow.de/cms/65472-amd-financial-analyst-day-2022-alle-praesentationen/8/

Steht da irgendwo Zen4c oder Zen5c? Wo? Wo???


Guckst du hier:

https://pics.computerbase.de/1/0/3/8/0/7-0fdd851fd2413076/3-1080.64b1e522.png

oder hier

https://pics.computerbase.de/1/0/3/4/9/4-26fca00e5d9474fc/2-1080.246ccb2b.jpg


Aber die CCDs sind größer!!!
Warum wohl sonst?!?!?


Informationen über CCD-Größe hat AMD afaik nie veröffentlicht in Bezug auf Zen4c. Es gibt nur die mündliche Aussage aus einer der AMD-Präsis zu der halbierten Core-Größe. Abgesehen davon wäre diese Aussage selbst dann nicht falsch, wenn die CCDs größer werden, da ja auch noch L3-Cache drauf ist. Wenn der nicht pro Core halbiert wird, muss der Die logischerweise größer werden.


Wie kommst du auf das schmale Brett?

Workloads, die haufenweise worker threads spawnen, müssen bereits jetzt damit klar kommen, dass nicht alle items gleich lange brauchen, damit es nicht so leicht ist vorher die genaue Bearbeitungsdauer zu schätzen. In Spielen ist die Last relativ heterogen. Zen 3 ist hier deswegen so viel schneller als Zen 2, weil sich ein Kern den gesamten L3 (32MB) schnappen kann. Die Inter-Core-Kommunikation spiele hier weniger eine Rolle, da sich Cezanne mit nur 16MB L3 eher wie Zen 2 als Zen 3 verhielt. Offensichtlich gibt es also einen oder wenige Threads, die sehr latenz- und vermutlich auch ST-limitiert sind und die Gesamt-Performance stark steigt, wenn man genau diese Threads beschleunigen kann. Oberhalb von 4 schnellen P-Cores vermute ich daher, dass man den Rest auch mit E-Cores auffüllen kann.

[...] und das fängt man mit einem 16C Zen5 ein (wenn alles so läuft wie geplant). Es gibt genau 0 Grund für einen Zen5c im Desktop, das schreibe ich doch die ganze Zeit.

Erstens würde man Z5 zeitlich eher mit Z4c paaren und zweitens habe ich oben erklärt, dass AMD den ganzen Stunt versuchen könnte, weil sie die gleiche reale Performance wie 16xZ5 z.B. mit 20% kleineren CCDs erreichen, wenn sie Z5 und Z4c mischen. Ob es so kommt weiß keiner, deswegen spekulieren wir hier.

[Savay]

Abgesehen davon wäre diese Aussage selbst dann nicht falsch, wenn die CCDs größer werden, da ja auch noch L3-Cache drauf ist. Wenn der nicht pro Core halbiert wird, muss der Die logischerweise größer werden.

Soweit ich weiß hängen bei Zen erstmal L3 Slices jeweils zunächst am Kern und es ergibt sich erst durch das Zusammenfügen zu einem CCX die gesamte L3 Größe.
Also je 4 L3 Slices pro CCX für Zen 1/2 und 8 Slices in einem CCX für Zen3/4.
Das sieht man IMHO ganz gut wenn man mal die Dieshots von Renoir und Matisse nebeneinander legt und die CCX vergleicht.

Es kann also sein, dass "Kern" in dem Zusammenhang durchaus den L3 mit meint, da ich kaum glaube, dass Zen4C hier großartig geändert wurde. :wink:

[Zossel]

Soweit ich weiß hängen bei Zen erstmal L3 Slices jeweils zunächst am Kern und es ergibt sich erst durch das Zusammenfügen zu einem CCX die gesamte L3 Größe.
Also je 4 L3 Slices pro CCX für Zen 1/2 und 8 Slices in einem CCX für Zen3/4.
Das sieht man IMHO ganz gut wenn man mal die Dieshots von Renoir und Matisse nebeneinander legt und die CCX vergleicht.

Seit ZEN3 gibt es IMHO keine Unterschiede in den Latenzen bei Zugriff von welchem Core egal wohin in den L3.

[Savay]

Seit ZEN3 gibt es IMHO keine Unterschiede in den Latenzen bei Zugriff von welchem Core egal wohin in den L3.

Das nicht, das liegt aber ja bis Zen2 daran, dass der L3 vorher auf 2 CCX aufgeteilt war?!
Innerhalb des selben CCX gibt es halt keine Unterschiede, gab es afair bei Zen1/2 auch nicht.

[robbitop]

Es wird nicht auf den L3 aus anderen CCX zugegriffen. Immer nur auf den eigenen L3. Warum? Weil es viel zu langsam wäre.

[basix]

Im kleineren SP6-Sockel (gleiche Größe wie SP3 mit ein paar Pins mehr) werden es mit Zen4c doppelt soviel Kerne wie mit Zen4 ;). Ich würde mal stark vermuten, daß die Platzverhältnisse nicht unbedingt das Limit darstellen. Im größeren SP5 limitiert vielleicht die TDP? Vermutlich wären 192Kerne dort nicht deutlich schneller, nur teurer. Man hat dort ja ein exorbitantes IO-Die mit 12 DDR5-Kanälen und 128 PCIe5-Lanes, was bei Volllast selber wohl schon locker 100W fressen dürfte. Ein wenig was sollte für die Kerne dann ja schon noch übrigbleiben (128Kerne bei 2,3W/Kern oder 192Kerne bei 1,5W/Kern ist vermutlich performancetechnisch kein allzu großer Unterschied).

Ich denke, dass Zen 4c CCD wird 3x IFOP Links anstatt 2x IFOP-Links aufweisen. Dann passt das besser hinsichtlich Bandbreite, CCD Anzahl und das, was das IOD liefern kann. Platprobleme oder TDP sehe ich jetzt auch eher weniger als Grund.

Es wird nicht auf den L3 aus anderen CCX zugegriffen. Immer nur auf den eigenen L3. Warum? Weil es viel zu langsam wäre.
Deswegen mein Vorschlag eines "Super-CCD", wo man mehrere CCDs via InFO / CoWoS-R zusammenschalten kann. Dann könnte der "Remote-L3$" schneller und effizienter angesprochen werden. Mit dann halt z.B. 15ns anstatt 10ns aber verglichen mit DRAM-Latenzen immer noch deutlich besser.

[Hammer des Thor]

Es wird nicht auf den L3 aus anderen CCX zugegriffen. Immer nur auf den eigenen L3. Warum? Weil es viel zu langsam wäre.


Ich dachte das genau das passiert wenn die SW nicht darauf optimiert ist wie manche Spiele wo der 5900X viel lahmer ist als nen 8 oder 6 Kerner aus der gleichen Serie?

[Lehdro]

Ich dachte das genau das passiert wenn die SW nicht darauf optimiert ist wie manche Spiele wo der 5900X viel lahmer ist als nen 8 oder 6 Kerner aus der gleichen Serie?
Nein, wenn das passiert wurden Threads auf den jeweils anderen CCD (und/oder wieder zurück) verschoben. Ist klar dass es dann auch vermehrt zu Cache-Misses und damit langsameren Zugriffen über das DDR Interface kommt.

[Zossel]

Nein, wenn das passiert wurden Threads auf den jeweils anderen CCD (und/oder wieder zurück) verschoben. Ist klar dass es dann auch vermehrt zu Cache-Misses und damit langsameren Zugriffen über das DDR Interface kommt.

Zeig mir mal die Stelle im Linux-Kernel wo das passiert, und insbesondere in den Kerneln die noch nichts von CCDs wussten.

[mksn7]

Zeile 6132: https://github.com/torvalds/linux/blob/master/kernel/sched/fair.c




Oder auch eine ganz andere Stelle, ich hab den source jetzt nicht komplett gelesen, vielleicht wird per default auch ein anderer scheduler verwendet, oder diese Funktion ist für einen Spezialfall, oder was auch immer. War jetzt halt einfach eine dumme Frage, was genau willst du mit dieser source location anfangen?

Wenn ein thread runnable ist, sucht der scheduler einen freien Kern aus, nach allen möglichen Kriterien. Ein Kriterium ist schon länger, dass der core bevorzugt wird auf dem der thread vorher schon lief, aber vielleicht ist der jetzt busy.

Und so wird halt dann vielleicht ein Kern ausgewählt der auf dem anderen CCD liegt. Umgedreht macht es Sinn, ein Kernel der von CCDs weiß, bevorzugt einen Kern im gleichen CCD.

Ich finde das aber weniger dramatisch als es oft angenommen wird. 16MB L3 cache lassen sich in unter 1ms wieder aus dem DRAM befüllen, und so oft wird da nicht hin- und herverschoben.

Interessanter sind vielleicht geteilte Datenstrukturen, die von threads auf unterschiedlichen CCDs modifiziert werden. Die müssen jeweils den Umweg über den DRAM machen.

[basix]

Bitte, bitte, sowas für Zen 5 um mehrere CCDs zu einem "Super-CCD" zu verbinden:
https://videocardz.com/newz/amd-radeon-rx-7000-rdna3-infinity-links-operate-at-9-2-gb-s-10x-higher-bandwidth-density-than-ryzen-infinity-fabric

Ein 7950X pumpt ~1.5 TByte/s über den L3$. Bei Zen 5 werden es evtl. ~2.0 TByte/s
5.3 TByte/s sind es bei N31. Könnte also machbar sein.

[Der_Korken]

Bitte, bitte, sowas für Zen 5 um mehrere CCDs zu einem "Super-CCD" zu verbinden:
https://videocardz.com/newz/amd-radeon-rx-7000-rdna3-infinity-links-operate-at-9-2-gb-s-10x-higher-bandwidth-density-than-ryzen-infinity-fabric

Was soll das bringen? Besser als ein monolithischer Chip für alles kann es nicht werden und wo da die Latenzen hingehen, sieht man an Skylake-X. Man wird es vielleicht nutzen, um den Verbrauch zu reduzieren. Wobei AMD da gerade im Idle-Bereich wahrlich andere Baustellen hat.

[basix]

Das CCD kann man ja im grossen und ganzen so lassen wie es ist. Man erhält prinzipiell eine zusätzlich Skalierungsebene und muss nicht für alle CCD <-> CCD Transfers den Umweg übers IOD nehmen.

Core-to-Core Latenz zwischen den CCDs würde einiges sinken und man kann den zweiten L3$ als "far-L3$" verwenden. Mit dann halt 15-20ns anstatt 10ns. Netto immer noch ein Gewinn. Insbesondere mit V-Cache (aber auch ohne) kann man die Kosten von grossen L3-Caches über mehr Workloads amortisieren. Und es steigert die Speicher-Bandbreite, die ein paar wenige Cores verwenden können. In gewissen Szenarien ebenfalls Performance steigernd. Energieverbrauch kann ebenfalls verbessert werden (reduzierte Umwege übers IOD)

[Der_Korken]

Schnelle Latenzen auf fremde L3-Caches bringen nur was, wenn man dorthin nicht nur lesen, sondern auch schreiben kann. Nach dem aktuellen Modell ist es nicht möglich, dass die Daten eines Cores in einen fremden L3 verdrängt werden, sondern immer nur in den eigenen und von dort werden sie komplett gelöscht. Wenn, dann müsste man einen IBM-ähnlichen Ansatz verwenden, bei der fremde L3-Caches jeweils als L4-Cache fungieren. Das müsste man natürlich mit einem sinnvollen load-balancing versehen, damit sich zwei CCXs nicht ständig Daten hin- und herschieben, sondern dass der mit der größeren Cache-Pressure auch "mehr" bekommt. Und es muss lokal bekannt sein, auf welchen fremden L3 man zugreifen muss. Alles andere wäre viel zu ineffizient. Alles andere als trivial.

Zudem glaube ich nicht, dass ein direkter Zugriff auf einen fremden L3 in nur 15-20ns möglich sein soll. Allein den zweiten Cache zu durchsuchen dauert mindestens nochmal genauso lange wie den eigenen zu durchsuchen, dazu die Latenzen über das IF. Ich würde eher mit 30ns+ rechnen, also 20ns+ auf den reinen L3. Und da ist dann die Frage, ob man bei einem L3-miss parallel im RAM guckt. Falls nein, erhöht eine "L4"-Query die RAM-Latenzen mal eben um saftige 20ns+. Ich weiß nicht, ob es wirklich zielführend ist, mit allen Mitteln um die Nachteile des CCX Designs drumrum zu bauen, um es irgendwie so hinzubiegen als wäre alles ein Chip, wo ein Kern theoretisch alle Ressourcen für sich allein nutzen kann.

Edit: Sorry wenn ich diese Speku-Threads gelegentlich missbrauche, um irgendwelche kruden Design-Ideen zu posten, aber hier schauen gelegentlich Leute vorbei, die wesentlich mehr (bzw. überhaupt) Ahnung von Chipdesign haben. Wäre es eigentlich denkbar, einen virtuellen L0-Cache für Daten zu designen? Bei einer Vergrößerung des L1D müsste man den TLB-Lookup abschließen, bevor man das richtige Cache-Set suchen kann, weil der Cache nicht mehr virtually-indexed-physically-tagged sein kann. Das wäre erstmal eine starke Regression bei den Latenzen, d.h. man müsste den L1D schon massiv vergrößern, um diesen Malus zu amortisieren. Was wäre, wenn man parallel zum TLB einen virtuellen L0D hat, der vielleicht 2-4kB groß ist und die selbe Latenz wie der TLB hat (1 Takt für den L1-TLB?). Der bräuchte keine besonders große Hitrate und könnte auch write-through sein. Der Zweck ist nur die durchschnittliche Lese-Latenz auf den L1D zu drücken. Bei einem Hit wird der L1 gar nicht durchsucht und das Ergebnis des TLB-Lookups verworfen. Eventuell braucht man den doppelt, damit es bei SMT keine Konflikte gibt. Bei einem Kontextwechsel wird der Cache komplett invalidiert.

[basix]

Naja, ich sehe es eher so, dass es dann eben ein "Unified-L3$" wäre. V-Cache erhöht die Latenz auch nicht um +20ns. Der Core weiss nur, dass die eigenen 32 MByte etwas näher dran sind als der Rest und legt bevorzugt im "lokalen L3$" die Daten ab (Data Locality). Ob ein L4$ hier besser wäre? Kann ich nicht beurteilen.

Dass das System damit komplexer wird als heute ist klar. Doch ich sehe potentiell einige Vorteile.

[Der_Korken]

Naja, ich sehe es eher so, dass es dann eben ein "Unified-L3$" wäre. V-Cache erhöht die Latenz auch nicht um +20ns. Der Core weiss nur, dass die eigenen 32 MByte etwas näher dran sind als der Rest und legt bevorzugt im "lokalen L3$" die Daten ab (Data Locality). Ob ein L4$ hier besser wäre? Kann ich nicht beurteilen.

Der 3D-Cache funktioniert komplett anders als ein zweiter L3-Cache auf einem anderen Chip. Er ist im Prinzip nur eine Erweiterung eines bereits vorhandenen Chips, z.B. indem man die Anzahl der Cache-Sets erhöht oder die Cache-Sets vergrößert. Die Anzahl der zugreifenden Kerne erhöht sich aber nicht und durch die 3D-Struktur verlängern sich die Wege auch nicht so stark als würde man einfach einen flächenmäßig 3x so großen Cache bauen.

Es ist aber etwas völlig anderes zwei L3-Caches zu mergen mitsamt der Teilnehmer. Bei Zen 2 auf Zen 3 hat man sowas gemacht. Die Latenz ist von 39 auf 46 Takte gestiegen und die Bandbreite pro Core hat sich dennoch halbiert. Das war der Preis, den man zahlen musste, um den Merge auf dem selben Silizium zu realisieren. Sowas über mehrere Chips hinweg zu machen, könnten Latenzen und Stromverbrauch komplett eskalieren lassen. Afaik shared Intel den L3 bei Sapphire Rapids über vier Chips. Beim Launch kann man sich mal angucken was da für Latenzen rauskommen, aber ich meine mich an Leaks zu erinnern wo die L3-Latenzen fast schon auf RAM-Niveau waren. Für Consumer-Modelle völlig unbrauchbar.

[iamthebear]

Der Großteil der verkauften CPUs hat nur 1 CCD. Da wäre ein Unified L3 zusätzlich zu den 32MB im CCD etwas sinnbefreit.
Ich denke, dass sich bei Zen5 vom grundlegenden Aufbau nicht so viel ändern wird falls dieser in N4X gefertigt wird.

Ab 3nm kann ich mir vorstellen, dass man den L3 aus dem CCD komplett verbannt und stattdessen z.B. in N6 entweder oben drauf stacked oder ähnlich wie bei N31 daneben hin setzt.

[amdfanuwe]

Schaun wir mal, wie CDNA3 wird, könnte schon auf die verwendete Technik bei ZEN5 hindeuten.
Da sieht es ja so aus, dass der Infinity Cache im Base Die ist und CPU sowie GPU Chiplets gestacked werden.

[Nightspider]

oder ähnlich wie bei N31 daneben hin setzt.

Bei CPUs ist das ganze ja latenzkritischer, deswegen würde ich aktuell "daneben" ausschließen.

Der Weg wäre länger und für gleichmäßigere Distanzen von den Cores müsste der Cache an mehreren Flanken sein, wie bei N31 aber dann hat man das Problem, dass es wieder Cores gibt, die von der gegenüberliegenden Seite auch auf bestimmte Files zugreifen werden, wo die Distanz dann dann sogar noch größer ist.

Die zentrale "Buchfaltung" wie bei V-Cache Gen1 ist halt sehr elegant wegen den Distanzen.
Noch bessere wäre nach aktuellem Wissensstand nur noch den Cache darunter zu setzen, nicht darüber.

[amdfanuwe]

Noch bessere wäre nach aktuellem Wissensstand nur noch den Cache darunter zu setzen, nicht darüber.
128MB Cache in den I/O Die im billigem Node und 1 bis 4 CPU Chiplets gestacked.
Gut für Gaming bei Bestückung mit nur einem 8C CCD.
Obwohl, die dürften in N3 zu klein werden, gibt es wohl eher 16C Chiplets.

Ist halt nur die Frage, ob sich das günstiger realisieren lässt als die aktuelle Lösung.

[basix]

Hier was von Gipsel zu dem Thema:
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=13166890#post13166890

[robbitop]

RGT hat heute im Video ein paar Dinge zu Zen 5 gesagt. Wahrscheinlich mit Vorsicht zu genießen.

1. deutlich breiterer Decoder
2. deutlich größerer L1 cache
3. weiterhin 8c CCX
4. Unified L2 Cache pro CCX
5. Infinity Cache als LLC der von allen CCDs genutzt werden kann und gestackt werden kann

Für letzteres müsste man IMO die CCDs ganz nah an den IOD heran bringen - analog N31 GCD/MCD Verbindung.

https://www.youtube.com/watch?v=oNdVsxcahMM&t=1090s

[Gipsel]

RGT hat heute im Video ein paar Dinge zu Zen 5 gesagt. Wahrscheinlich mit Vorsicht zu genießen.

1. deutlich breiterer Decoder
2. deutlich größerer L1 cache
3. weiterhin 8c CCX
4. Unified L2 Cache pro CCX
5. Infinity Cache als LLC der von allen CCDs genutzt werden kann und gestackt werden kann

Für letzteres müsste man IMO die CCDs ganz nah an den IOD heran bringen - analog N31 GCD/MCD Verbindung.

https://www.youtube.com/watch?v=oNdVsxcahMM&t=1090sDas könnte hinhauen, wenn AMD die Caches umnumeriert (wie bei den GPUs, da wurde aus dem L1 auch der L0 [man hat quasi einen zusätzlichen L1 in der Hierarchie dazwischen geschoben]). Es gibt dann z.B. für jeden Kern 32kB L0-D (über die Schwierigkeit dies zu erhöhen und den Zusammenhang mit den VIPT-Vorteilen wurde ja schon öfter diskutiert, aber vielleicht macht man irgendwann den Sprung), gefolgt von 1-2MB L1-Cache ebenfalls pro Kern und dann kommen 32-64MB geteilter L2 für den CCX und optional Infinity-Cache obendrauf. :freak:
Aber keine Ahnung. Irgendwas müßte man dann vermutlich gegen die gesteigerte Latenzen eines durch 8 Kerne geteilten Caches tun (wenn es nicht quasi nur ein umbenannter L3 ist).

Edit: Falscher Thread? Fixed.

[Der_Korken]

Hm, bei einem L2 für das ganze CCX hätte ich eher damit gerechnet, dass man die CCX-Größe wieder auf 4 halbiert, um die Latenzen kleiner zu halten. Dadurch dass man dem ganzen noch einen L3 für alle CCX nachschaltet, müssten die CCXs trotzdem nicht über den RAM kommunizieren. So wird die Latenz des L2 eher vergleichbar mit dem aktuellen L3, was schon sehr langsam wäre.

Bisher waren die Latenzen von L3 minus L2 wie folgt:
Zen 1+: 23 Takte für 8MB, 4 Clients und 4,3 Ghz
Zen 2: 27 Takte für 16MB, 4 Clients und 4,7 Ghz
Zen 3: 34 Takte für 32MB, 8 Clients und 4,9 Ghz
Zen 4: 36 Takte für 32MB, 8 Clients und 5,7 Ghz

Ich hätte wie gesagt eher sowas Zen-1-artiges erwartet, wo sich je 4 Kerne einen 8MB-L2 teilen mit <30 Takten Latenz. Der L1 müsste dann irgendwas in Größenordnung 128-256kB sein, denn mit den alten 32kB hätte man latenztechnisch ein zu großes Loch. Da bekomme ich ein wenig Bulldozer-Vibes, wo man einen im Vergleich zum L1 geradezu riesigen L2 hatte aber dafür mit viel zu viel Latenz (das war sicher nicht der Hauptgrund warum BD lahm war, aber das Cache-Design war trotzdem sehr weird). Mit einer Config wie 16MB an 8 Kernen wäre das noch extremer.

Vom Kostenpunkt her würde es für AMD Sinn machen den L3 aus den CCDs zu verbannen, weil er ab 5nm nicht mehr gut mit dem Prozess skaliert. Eine Möglichkeit wäre gewesen den L3 komplett in ein gestacktes Chiplet auszulagern, aber anscheinend will AMD das wohl anders lösen. Ein auf den IOD gestackter Cache hätte dagegen den Vorteil, dass er von allen CCXs genutzt werden kann.

Bei letzterem stellt sich natürlich die Frage wie man 1-CCD- und 2-CCD-Modelle bestückt. Die Kosten verlagern sich von den Cores hin zum IOD, denn ohne L3 wären die CCDs sicherlich noch kleiner (sagen wir mal so 60mm²), während der IOD bereits heute 120mm² hat und mit Base-L3 und gestackten L3 irgendwas Richtung 150-200mm². Bei vollbestücktem Cache wäre kostentechnisch zwischen 8C und 16C dann nicht mehr viel Unterschied. Das ist gut für teure Modelle mit vielen Cores aber schlecht für die Lowend-Modelle mit wenig Cores. Wäre interessant wie AMD sowas ausbalancieren würde.

[amdfanuwe]

aber schlecht für die Lowend-Modelle mit wenig Cores.
Low-End wird mit APUs bedient.
Wie groß wäre eigentlich der Cache auf dem I/O?
96MB einfach, 192MB mit Stack?
Gäbe direkt gute Gaming Performance für 6 und 8 Core.
Für 24 und 32 Core braucht es dann den 3D Stack.

[Der_Korken]

Low-End wird mit APUs bedient.
Wie groß wäre eigentlich der Cache auf dem I/O?
96MB einfach, 192MB mit Stack?
Gäbe direkt gute Gaming Performance für 6 und 8 Core.
Für 24 und 32 Core braucht es dann den 3D Stack.

Mit "Lowend" meinte ich eigentlich die 6- und 8-Kerner, also was aktuell 7600X und 7700X sind (war etwas missverständlich). Die sind für ihre Rechenleistung schon relativ teuer, sowohl im Vergleich zu Intel als auch im Vergleich mit den 12- und 16-Kernen. Das liegt sicherlich auch am IOD. Da hat ein 7700X ca. 2/3 der Silizium-Kosten eines 7950X.

Ansonsten würden 96MB L3 im Base-Die ausgehend von Vermeer ca. 100-120mm² Fläche brauchen. Never ever wird das so gebaut. Ich würde eher auf 32MB tippen, mit Stack dann 96MB oder 128MB, je nachdem was Zen 4 mit 3D-Cache haben wird. Höher müssen sie nicht pushen, solange Intel nicht nachzieht. Der Ertrag durch zusätzlichen Cache nimmt immer weiter ab, aber die Kosten steigen trotzdem.

[Nightspider]

Das der L3 ausgelagert wird hatten hier ja schon einige vermutet, das ist einfach der nächste logische Schritt.

Alte Fertigungsverfahren werden auch ein Stück weit billiger mit der Zeit und AMD könnte doppelte Menge an V-Cache an die CPU klatschen ohne das es viel teurer wird als bei Gen1.
Gibts irgendwo Schätzungen, wie teuer ein N6 Wafer 2024 sein wird im Vergleich zu 2022?

[amdfanuwe]

gefolgt von 1-2MB L1-Cache ebenfalls pro Kern und dann kommen 32-64MB geteilter L2 für den CCX und optional Infinity-Cache obendrauf. :freak:
Wenn man schnellen Zugriff auf den Infinity Cache im I/O hat, braucht es keinen so großen L2.
Der L3 ist ja nur so groß, um die langsamen RAM Zugriffe abzufangen.

Bei ZEN4 braucht es 8x32Byte/Cycle = 256 Byte/Cycle für den Zugriff auf L3.
Bei RDNA3 (hab die Folie etwas angepasst) haben wir 384 Byte/CLK für den Zugriff auf ein MCD.
Sollte ein Infinity Fanout Link für ein 8Core CPU Chiplet also reichen um den LLC in den I/O zu legen.
Ebenso gut könnte ein I/O 4 IFoL haben an die Wahlweise CPU oder GPU Chiplets angeschlossen werden. 2 IFoL reichen ja für ein GPU Chiplet wie N33.

Wie wird das bei EPYC aussehen? Mit 12 oder 16 IFoL dürfte es eng werden.
Bin gespannt, wie AMD das löst.
Wird ja echt spannend, was AMD mit CPU, GPU, FPGA etc. Chiplets zusammenstellt, die an ein I/O mit unified Infinity Cache angeschlossen sind.

[CrazyIvan]

@robbi
Danke für die Zusammenfassung. Das Interconnect-Thema ist wirklich ungeheuer spannend. Ich erwarte mir da von MI300 neue Erkenntnisse. Wenn dort CPUs mit GPUs kombiniert werden, dann wird das wohl hoffentlich auf einen neuen CPU Interconnect hinauslaufen - oder doch heterogen?
Ich tippe auf Bergamo bei MI300 mit INFO-R.
Zu den Caches habe ich keine echte Meinung. Zwei Ebenen für den per-CCX-Scope macht für mich aber irgendwie wenig Sinn. Und ja, für einen IOD-LLC braucht es INFO-R artige Bandbreite, Latenz und Nähe.

Bezüglich der Anordnungsbeziehungen fallen mir wieder meine Schaubildchen ein, die ich vor einiger Zeit aus Langeweile gemacht hatte. Es ging mir dabei darum, wie man mit möglichst wenigen gleichen Dies dieselbe CCD Anzahl sehr nah an das IOD bringt, um Info-R / EFB nutzen zu können. Randbedingung war, dass die derzeit belegte Fläche auf dem Package nicht überschritten wird. Als Die-Größe habe ich die aktuellen verwendet, was zugegeben nicht sehr realistisch ist. Aber etwas Platz für Vergrößerung würden die Packages noch hergeben.

Just for fun:
81791

81792

[basix]

Ich hatte mal was ähnliches aufgezeichnet, wo man 4x Zen 5 Cores an einen gemeinsamen "Ringstop" hängt. Das Verbindungsdiagramm sieht von da dann ähnlich aus wie bei einem Zen 1/2 CCX, wo man jeweils eine Direktverbindung zu den anderen Cores hatte. Hier hätte man eine Direktverbindung zu den anderen 4C-Clustern.

Das hat folgende Vorteile:
- Relativ geringer Verdrahtungsaufwand zwischen den Ringstops, da nur 4 Teilnehmer
- Im Durchschnitt kürzere Core-to-Core Wege, da 4C geclustert werden
- L2$ kann pro 4C-Cluster Unified sein, kann aber auch privat bleiben

Das wären dann aber eher 16C pro CCD und nicht nur 8C. Ohne L3$ und ohne I/O wäre ein 8C CCD sehr klein, ausser Zen 5 würde riesig anwachsen. Evtl. kombiniert man auch zwei Cluster und es entstehen 2x 8C CCX pro CCD (linke und rechte Seite). Das ist dann aber ein ganz anderes Konzept.

Von dem Konzept ausgehend, kann man dann wieder den Weg Zen 2 -> Zen 3 beschreiten und wieder auf 8x Ringstops gehen. Dann mit 32C pro CCD. Allenfalls ist das auch schon bereits das Konzept für Zen 5c und nicht erst Zen 6. Ist mMn halt eine elegante Variante, um den Core Count weiter zu steigern, ohne die Komplexität des CCX massiv zu erhöhen. Man bleibt bei 4-8 Teilnehmern, was sich als +/- optimal erwiesen hat. Und trotzdem kann man mit den Core Count deutlich nach oben treiben, weil man nun eben 4C-Cluster als Teilnehmer hat und nicht einzelne Cores.

[Der_Korken]

Zum Thema shared L2 über 8 Kerne könnte man vielleicht nochmal das Cache-Konzept von IBM rauskramen. Jeder Kern hat auf seinen eigenen Cache-Slice einen schnelleren, priorisierten Zugriff, kann aber auch Cache Lines in fremde L2-Slices verdrängen. Dazu muss natürlich die Cache-Last pro Slice getrackt werden, sodass Prozesse mit viel Last ihren Slice behalten können, während Prozesse mit wenig Last einen (mglw. großen) Teil ihres Slice für andere Prozesse zur Verfügung stellen. Das würde das große Latenzloch zwischen einem privaten L1 und einem über 8 Kerne geshareten L2 deutlich verkleinern und auch Größen von 16 bzw. 32MB erlauben. Nach außen hin stellt sich das CCX nach wie vor als Einheit dar mit einem gemeinsamen LLC. Man muss das Konzept ja nicht wie IBM über Chipgrenzen hinweg implementieren, wo ein CCX noch Daten an ein anderes CCX auslagert. Dafür ist stattdessen der L3 auf dem IOD da.

[basix]

Eine Art Priorisierung des eigenen L2-Caches wird ja sowieso stattfinden. Datenlokalität als Stichwort. Der "eigene" L2$ wird hier also automatisch priorisiert, da am nächsten dran. Der Prozess mit dem grössten Bedarf und/oder der höchsten Priorität darf dann immer noch unter dem Gartenzaun durch zu den anderen Cores und dort etwas von deren Cache abgrasen.

Bei dem Ansatz, wie auch du ihn beschreibst, müssen die L1$ auch nicht wirklich grösser werden. Die L2$-Latenz sinkt effektiv ja nicht. Durch den L3$ direkt unter dem Core hat man allenfalls sogar noch einen Latenzvorteil, da die Strecken im Schnitt kürzer werden.

[Der_Korken]

Naja, bei 16MB sind es 2MB pro L2-Slice, d.h. die Latenz wird gegenüber den 1MB L2 von Zen 4 nochmal steigen. Bei 32MB sind es sogar 4MB pro Slice. Da außerdem noch fremder Traffic auf dem Cache sein kann, wird es vermutlich nochmal schlechter als wenn das ein komplett privater L2 mit 2MB oder 4MB wäre. Bezüglich L1 hast du natürlich nicht Unrecht, aber sofern AMD da in mittelferner Zukunft Bedarf für mehr L1 sieht, wäre Zen 5 der richtige Zeitpunkt das alte VIPT-Prinzip aufzubrechen und den L1 zu vergrößern. Einmal losgelöst von VIPT kann man den L1 in Zukunft viel leichter nach Bedarf anpassen.

[robbitop]

Zur Cachedebatte:

Ich frage mich, ob das überhaupt nötig ist, denn im Prinzip benennt man die Caches ja fast um.
Man vergrößert den L0 um den Latenzhit des neuen vergrößerten L1 zu kompensieren.
Der L1 wird vergrößert, damit der große, gesharte und wahrscheinlich langsamere L2 nicht nachteilig ist.
Der L2 wird geshart damit der L3 vom CCD runter kann.

Im Prinzip könnte man auch alles so lassen, ggf den L3 etwas verkleinern und dafür dann das IOD dann per Fanout deutlich näher an das CCD heranbringen und die Latenz zum IOD deutlich verbessern und dann einen L4 inkl VCache Option auf dem IOD bringen.

Die Umbenennung macht im Endeffekt auch nicht viel anders. Je größer ein Cache desto mehr steigt die Latenz. Entsprechend muss man halt mit mehreren Levels die komplette Range abdecken so gut wie möglich.

Was auch auffiel ist, dass der doppelt so große L2 Cache kaum Performance laut der AMD Slide gebracht hat. Entsprechend ist man eigentlich mit den Caches schon recht gut unterwegs gewesen. Jetzt geht es wahrscheinlich primär darum, das ganze besser zu skalieren und auf Kosten zu optimieren.
Großer Cache runter von den CCDs und auf den IOD (weil der mit top notch Prozessen nicht mehr so gut schrumpft und damit mehr Kerne was von dem großen Cache haben und man den nicht pro CCD bieten muss). Ob man jetzt dafür alles umstrukturieren muss? Kleinerer L3 (8-16 MiB ohne VCache pro CCX) und dafür Einführung eines relativ schnellen, großen L4 mit VCache im IOD ist am Ende nicht viel anders, oder?

-----------


Zum eigentlichen Core:

Es wurde ja von AMD auf einem Anandtechinterview (vor > 1 Jahr) ja schonmal angekündigt. Er wird deutlich breiter. Ich frage mich, wie sehr man sich an Apples Designphilosophie orientiert hat. Und was davon überhaupt viel bringt. Breiter Decoder, riesen großer ROB, mehr Execution Units usw.

[HOT]

Das könnte hinhauen, wenn AMD die Caches umnumeriert (wie bei den GPUs, da wurde aus dem L1 auch der L0 [man hat quasi einen zusätzlichen L1 in der Hierarchie dazwischen geschoben]). Es gibt dann z.B. für jeden Kern 32kB L0-D (über die Schwierigkeit dies zu erhöhen und den Zusammenhang mit den VIPT-Vorteilen wurde ja schon öfter diskutiert, aber vielleicht macht man irgendwann den Sprung), gefolgt von 1-2MB L1-Cache ebenfalls pro Kern und dann kommen 32-64MB geteilter L2 für den CCX und optional Infinity-Cache obendrauf. :freak:
Aber keine Ahnung. Irgendwas müßte man dann vermutlich gegen die gesteigerte Latenzen eines durch 8 Kerne geteilten Caches tun (wenn es nicht quasi nur ein umbenannter L3 ist).

Edit: Falscher Thread? Fixed.

Hm, die machen das ja nur, um damit was zu bezwecken und der Zweck kann eigentlich nur sein, die Hierarchie zu optimieren, also möglichst wenig Cache pro Level mit möglichst viel Effekt zu bringen. Da Zen5 einen recht großen Kern haben dürfte in N4, wird man wohl auf einem CCD nicht mehr 32MB L3$ sehen. Ich nehme an, das sieht eher wie folgt aus:

32kiB L0D, 64kiB L1I und 128kiB L1D. Darüber dann ein unified L2$ mit 16MB, also 2 MB pro Kern. Der IF$ dürfte dann als ein separates (stackbares) N6-Die realisiert werden mit 64MB-Kapaztät (oder 128MB beim Stacking), das exakt zwischen die beiden CCDs platziert werden kann und ein MCM wie bei RDNA3 ermöglicht. Die OEM und Billiglösungen kommen dann einfach ohne den IF$ aus, haben ja eh nur ein CCD, das wäre dann so ne Art Propus. Die CCDs müssten 3 Links besitzen, von dem einer mit dem IOD und 2 mit dem Cache-Die verbunden werden, die CCDs würde also quasi hochkant stehen über dem IOD, ein sehr schmales, in etwa so langes Cache-Die zwischen den CCDs. Das hätte außerdem den Vorteil, dass die CCDs wieder näher an der Kühlermitte wären. AMD könnte also weiterhin ein 2-Chiplet für billig anbieten, das IOD kann recycled werden, das Ganze bleibt ein billiges MCM und man kann dann bis zu 5 Chiplets (2 CCD. 2 Cache im Stack und ein IOD) verbauen. Als Bonbon obendrauf könnte man auch unterschiedliche CCDs verbauen um 24 Kerne zu erreichen, also Zen5 mit Zen5c kombinieren und 3 CCX zu schaffen, wovon das Zen5-CCD priorisiert wird. Die CCX wären ja alle latenzarm miteinander verbunden.

[Der_Korken]

Ich weiß nicht, ob da unbedingt ein L0D "eingeführt" werden muss, durch den quasi die Cache-Bezeichnung nur um eins nach unten rutscht. Vielleicht will man bewusst nicht vier Cache-Stufen haben, weil jede Cache-Stufe auch die nachfolgenden verlangsamt. Apple hat in ihrer Architektur auch nur zwei Stufen bzw. drei, wenn man den SLC mitzählt, an dem auch andere Teile als die Cores hängen (könnte bei AMD auch so werden, wer weiß). Imho braucht man irgendeine neue Idee, irgendeinen neuen Trick, wenn man bei der Speicherhierachie irgendwas rausholen will. Der gestapelte Cache, der einen Kapazitätsgewinn ohne Latenzzunahme ermöglicht, ist ein Beispiel für etwas neues, was man vorher nicht hatte. Davor war z.B. der Micro-Op-Cache von Sandy Bridge etwas neues, das viel gebracht hat. Und davor die Integration des Speichercontrollers auf der CPU, um große Caches ein Stück weit obsolet zu machen (K8 vs Netburst). Vielleicht sehen wir bei Zen 5 irgendetwas neues, wodurch es plötzlich viel Sinn ergibt nur noch eine private Cache-Stufe zu benutzen und von oben etwas "aufzurücken", die Hierachie also flacher (und einfacher) zu machen.

[amdfanuwe]

Vielleicht sehen wir bei Zen 5 irgendetwas neues, wodurch es plötzlich viel Sinn ergibt nur noch eine private Cache-Stufe zu benutzen und von oben etwas "aufzurücken", die Hierachie also flacher (und einfacher) zu machen.
Das neue wäre der unified Infinity Cache auf den alle angeschlossenen Devices zugreifen.
Also anstatt großer lokaler Caches für CCX und GPU, die auf Kohärenz achten müssen, gibt es neu den infinity Cache der den RAM kapselt und beschleunigt.
81796
GPU steht hier eher für Accelerator. Man muss ja auch an APU bzw. EPYC denken.
Kohärenz Probleme hat man mit dem IF Cache auch nicht. Das tritt erst wieder in Multi Socket Systemen auf.
Durch die schnelle Anbindung lassen sich auch andere Cache Strategien fahren.

[davidzo]

"slow" und "fast" sind ein bisschen zu simplifizierend. Meinst du damit die Bandbreite, oder die Latenz?

Es sind eher vier Parameter:
1. Latenz
2. Größe
3. Assoziativität
4. Bandbreite

"Fast" bedeutet in meiner Welt mehr Bandbreite. Das nützt einem aber nur bei Vektorloads etwas, in 95% der Alltagslasten ist das völlig wumpe.

Ich denke dass der L1 Cache auch massiv anwachsen wird wenn Zen5 wirklich einen Unified L2 bekommt. In etwa so wie beim M1.
Apple verwendet beim M1/2 auch einen shared L2 von 12/16mb. Die Parallelen zu dem was hier skizziert wird sind offensichtlich. Mit 5,6ns ist dieser gigantische L2 bei Apple nichtmal besonders langsam. Zen4s privater L2 ist zwar doppelt so schnell, aber mit 1Mb auch nur 1/16 groß.

Der M1 hat einen extrem schnellen 3 cycle L1 mit massiver Größe (128kb data + 256kb instruction). Zen4 hat aktuell mit 32+32kb nur ein sechstel und ist sogar ein cycle langsamer.
Dem M1 fehlen aber auch rund 2Ghz an Takt. Also so ganz wird Zen5 nicht das Hochtakt Cachedesign aufgeben denke ich.
Apple hat die Assoziativität verringert um den großen cache möglich zu machen, AMD könnte einen ähnlichen Weg gehen. Bereits Phenom hatte ja einen größeren L1 Cache (64+64) mit extrem niedrigen Latencies, aber eben auch geringer Assoziativität. AMD kennt sich damit also bestens aus.

Ganz so extreme Größen wie bei Apple werden wir denke ich nicht sehen, aber 8MB L2 halte ich für möglich, dazu 128+128kb L1. Die Assoziativität muss sich beim L2 massiv erhöhen, daher glaube ich kaum dass man unter 5ns kommt, aber wesentlich besser als die 10ns der bisherigen 32mb L3 wird man schon sein. Der L1 müsste weiterhin nah an 1ns liegen damit die performance nicht leidet.
Der L3 auf dem i/o DIE für alle CCDs würde dann genau die Aufgabe des Apple System Level Caches übernehmen und es wäre wohl auch leichter diesen auch für die IGP nutzbar zu machen.

[Der_Korken]

Der M1 hat einen extrem schnellen 3 cycle L1 mit massiver Größe (128kb data + 256kb instruction). Zen4 hat aktuell mit 32+32kb nur ein sechstel und ist sogar ein cycle langsamer.
Dem M1 fehlen aber auch rund 2Ghz an Takt. Also so ganz wird Zen5 nicht das Hochtakt Cachedesign aufgeben denke ich.


Bei den absoluten Latenzen ist Zen 4 deutlich schneller beim L1, 3Takte/3,5Ghz = 0,86ns, 4Takte/5,7Ghz = 0,7ns. Das muss man erstmal rausholen.


Apple hat die Assoziativität verringert um den großen cache möglich zu machen, AMD könnte einen ähnlichen Weg gehen. Bereits Phenom hatte ja einen größeren L1 Cache (64+64) mit extrem niedrigen Latencies, aber eben auch geringer Assoziativität. AMD kennt sich damit also bestens aus.


Afaik hat der L1 bei Apple ebenfalls 8-fache Assoziativität. Der Grund warum Apple auf 128kB gehen konnte, ist afaik dass sie 16kB statt 4kB Pagesize verwenden. Dadurch funktioniert VIPT mit 8-way bis 128kB, bei Intels und AMDs Architekturen eben nur bis 32kB (Intel war gezwungen für 48kB auf 12-way zu gehen). Das ist also genau der Sweetspot. In dem Moment, wo man VIPT sowieso nicht mehr benutzt, wäre AMD wesentlich freier in der Wahl der L1-Größe. Mit den Phenom-Caches kann man das aber imho nicht mehr vergleichen, erstens wegen Takt und zweitens wegen Bandbreite.

Ich würde mal tippen, dass man 128kB L1D nicht unter 6 Takte realisieren kann in den Taktregionen von Zen 4. Ich würde sogar eher mit 7 Takten rechnen. Bei Skylake (256kB) und Zen 3 (512kB) brauchte der L2 jeweils 8 Takte zusätzlich zum L1, ohne auf den TLB warten zu müssen. Bei Intel sind es 5 Takte für 48kB, ebenfalls ohne effektive TLB-Wartezeit. Bei einem L1 ohne VIPT geht mindestens ein Takt verloren, um den phyischen Tag aus dem TLB zu bekommen. Das wäre aber schon ein hartes Brett diesen Latenzzuwachs zu verstecken ...

[amdfanuwe]

beinahe überlesen
"slow" und "fast" sind ein bisschen zu simplifizierend. Meinst du damit die Bandbreite, oder die Latenz?

Es sind eher vier Parameter:
1. Latenz
2. Größe
3. Assoziativität
4. Bandbreite

"Fast" bedeutet in meiner Welt mehr Bandbreite. Das nützt einem aber nur bei Vektorloads etwas, in 95% der Alltagslasten ist das völlig wumpe.


Kann leider nur simplifizieren, da ich von den Cache Details keine Ahnung hab. Da stammen meine Kenntnisse noch aus der Jahrtausendwende :-)
Bei Assoziativität klingelt es nur ganz weit hinten im Hirn und keiner macht das Licht an.

Mit fast mein ich sowohl Bandbreite als auch Latenz bei einem Hit.
10 fache Bandbreite zwischen Chiplet und I/O sollten sich schon bemerkbar machen. Da macht es kaum einen Unterschied ob der Cache auf dem Chiplet oder dem I/O ist.
Die Details übelasse ich euch Profis, aber schön zu lesen, dass sich AMD damit Apples Ansatz nähert.
Wesentlich finde ich dabei, dass alle Einheiten, also auch Beschleuniger und CXL? damit auf einen unified Cache zugreifen und es dadurch weniger Probleme mit der Kohärenz gibt. Oder lieg ich da falsch?

[davidzo]

Bei den absoluten Latenzen ist Zen 4 deutlich schneller beim L1, 3Takte/3,5Ghz = 0,86ns, 4Takte/5,7Ghz = 0,7ns. Das muss man erstmal rausholen.

"Deutlich" würde ich das nicht nennen. Immerhin liegen bei Apple auch weitere 320kb unter 1ns, während bei AMD nur die ersten 64kb in den Genuss einer knapp 20% geringeren Latenz kommen und der Rest mit der 2,5ns Latenz des L2s leben muss.
Auch muss man bedenken dass Apples gigantischer ROB massiv dabei hilft Latenzen zu maskieren. Der ist fast doppelt so groß wie Zen4 und letzterer wurde gerade erst aufgebohrt. Der L1 des m1 muss also gar nicht so niedrigre latenzen haben um so eine hohe ILP zu extrahieren.

Ein weiterer Hebel der einen größeren L1 ermöglichen würde ist natürlich wenn man im Gegenzug mehr Entries im bereits jetzt vorhandenen L0 bzw. Mop Cache ermöglicht.



Afaik hat der L1 bei Apple ebenfalls 8-fache Assoziativität. Der Grund warum Apple auf 128kB gehen konnte, ist afaik dass sie 16kB statt 4kB Pagesize verwenden. Dadurch funktioniert VIPT mit 8-way bis 128kB, bei Intels und AMDs Architekturen eben nur bis 32kB (Intel war gezwungen für 48kB auf 12-way zu gehen). Das ist also genau der Sweetspot. In dem Moment, wo man VIPT sowieso nicht mehr benutzt, wäre AMD wesentlich freier in der Wahl der L1-Größe.

ja, das hatten wir hier schon vor einer Weile als Architekturellen Vorteil für ARM festgestellt, allerdings würde ich das auch nicht überbewerten. Wenn das wirklich ein großes Problem wäre, dann würden AMD und Intel x86 um eine neue pagesize erweitern. Das würde da schon irgendeinen Weg geben.


Mit den Phenom-Caches kann man das aber imho nicht mehr vergleichen, erstens wegen Takt und zweitens wegen Bandbreite.

natürlich war das mit der Technik der damaligen Zeit, optimiert auf Integer Workloads nur mit gerade ausreichend Bandbreite für die Fähigkeiten der damaligen FPUs. Mit moderner Fertigung und Transistorbudget haben solche caches natürlich eine höhere Busbreite und entsprechend mehr Bandbreite. Aber Bandbreite ist eh meistens nicht das Problem abseits von Vektor Workloads.
Ich meine aber das Konzept eines großen L1-Caches mit sehr niedriger Assizoziativität. Das ist immer noch sehr kompetitiv. Du würdest dich wundern dass es besser sogar performen würde als Golden Coves 48kb L1, 5 cycle Cache: https://chipsandcheese.com/2022/02/11/going-armchair-quarterback-on-golden-coves-caches/



Ich würde mal tippen, dass man 128kB L1D nicht unter 6 Takte realisieren kann in den Taktregionen von Zen 4. Ich würde sogar eher mit 7 Takten rechnen. Bei Skylake (256kB) und Zen 3 (512kB) brauchte der L2 jeweils 8 Takte zusätzlich zum L1, ohne auf den TLB warten zu müssen. Bei Intel sind es 5 Takte für 48kB, ebenfalls ohne effektive TLB-Wartezeit. Bei einem L1 ohne VIPT geht mindestens ein Takt verloren, um den phyischen Tag aus dem TLB zu bekommen. Das wäre aber schon ein hartes Brett diesen Latenzzuwachs zu verstecken ...

Zen1 hatte auch eine 64kib L1-i und das nur 4-way. Wahrscheinlich auch nur ein PIPT Cache.
Ich bin mal gespannt ob wir irgendwann mal eine funktionierende mainstream VIVT Implementierung sehen.

[Der_Korken]

Auch muss man bedenken dass Apples gigantischer ROB massiv dabei hilft Latenzen zu maskieren. Der ist fast doppelt so groß wie Zen4 und letzterer wurde gerade erst aufgebohrt. Der L1 des m1 muss also gar nicht so niedrigre latenzen haben um so eine hohe ILP zu extrahieren.


Apples Architektur ist was das angeht schon irgendwie ein Mysterium. Wenn man Zen 3/4 und Golden Cove vergleicht, würde man meinen, dass eine extrem breite Architektur mit riesigen Buffern zum Verstecken von Latenzen auch zu deutlich schlechterem Perf/W und Perf/Area führt. Apple ist dann aber plötzlich eine krasse Ausnahme dieser Regel. Wo kommen eigentlich die ganzen Instruktionen her, die man in >512-große ROBs füllt? Dazu müsste man immer weiter "in die Zukunft" lesen, über immer mehr Branch-Instruktionen. Dadurch nimmt die Wahrscheinlichkeit, dass eine gelesene Instruktion überhaupt behalten wird, exponentiell ab mit der Anzahl an übergangenen Branches. Und verworfene Instruktionen bedeuten Energieverschwendung und Verschwendung von Buffer-Spaces. Das klingt für mich erstmal sehr ineffizient. Eigentlich will man hier einen optimalen OoO-Execution-Plan haben, bei dem Branches (und deren dependencies) schneller aufgelöst werden als andere Instruktionen, damit man immer möglichst wenig spekulativ rechnen muss.


Ich meine aber das Konzept eines großen L1-Caches mit sehr niedriger Assizoziativität. Das ist immer noch sehr kompetitiv. Du würdest dich wundern dass es besser sogar performen würde als Golden Coves 48kb L1, 5 cycle Cache: https://chipsandcheese.com/2022/02/11/going-armchair-quarterback-on-golden-coves-caches/


Ja, das ist schon interessant. Ich glaube aber trotzdem nicht, dass man nur durch Absenken der Assoziativität so krasse Speedups hinbekommt. Von 5 auf 3 Cycles runter bei knapp 6 Ghz - wenn das so einfach ginge, hätten Intel und AMD das doch längst gemacht.


Zen1 hatte auch eine 64kib L1-i und das nur 4-way. Wahrscheinlich auch nur ein PIPT Cache.
Ich bin mal gespannt ob wir irgendwann mal eine funktionierende mainstream VIVT Implementierung sehen.

Stimmt, Zen 1 hatte tatsächlich 64kB L1I. Der muss deutlich schlechtere Latenzen gehabt haben als der L1D. Eventuell war es aber nicht so schlimm, weil es noch den µOp-Cache gibt und Instruktionen in der Regel sehr viel linearer angfragt werden (-> prefetching). Zu VIVT hatte ich weiter oben mal laut gedacht, dass man einen größeren L1D eventuell durch einen sehr kleinen 1-cycle-VIVT-readonly-L0D beschleunigen könnte, der bei Lesezugriffen parallel zum L1TLB queried wird. Durch die geringe Größe könnte man ihn wegen SMT doppelt anlegen und bei jedem context swich flushen. Schreibzugriffe sollten aus Sicht eines Kerns nicht so latenzkritisch sein, weil sich der Kern bei einem read-after-write theoretisch den Wert wieder aus der Store-Queue rausziehen kann?

[robbitop]

Laienfrage: Kann man denn einfach eine neue pagefile size bei einer ISA einführen und dann den L1 Cache bei gleicher Assoziativität vergroßern oder muss entsprechend alles an Software dafür neu kompiliert werden? Wenn letzteres der Fall ist, dann ist es halt nicht mal eben eingeführt. :)

[Zossel]

Laienfrage: Kann man denn einfach eine neue pagefile size bei einer ISA einführen und dann den L1 Cache bei gleicher Assoziativität vergroßern oder muss entsprechend alles an Software dafür neu kompiliert werden? Wenn letzteres der Fall ist, dann ist es halt nicht mal eben eingeführt. :)

Für den größten Teil des Userspace ist das transparent.

Allerdings haben 4K den Charme das das zu den Pagesizes der GPUs und zu den Blockgrößen von Platten passt.

[NC]

Allerdings haben 4K den Charme das das zu den Pagesizes der GPUs und zu den Blockgrößen von Platten passt.Page size von Platten ist eigentlich 512byte und von SSDs 16KB. wobei beide Seiten versuchen 4KB zu emulieren um die page size der OS zu matchen.

[Zossel]

Page size von Platten ist eigentlich 512byte und von SSDs 16KB. wobei beide Seiten versuchen 4KB zu emulieren um die page size der OS zu matchen.

Partitionierst du deine Platten so das Partitionen auf Grenzen anfangen wo mod 4 !=0 gilt?

[CrazyIvan]

Partitionierst du deine Platten so das Partitionen auf Grenzen anfangen wo mod 4 !=0 gilt?
Ich verstehe zwar den Satz, nicht aber, worauf Du hinaus willst.

[Zossel]

Ich verstehe zwar den Satz, nicht aber, worauf Du hinaus willst.

Ist auch 8 statt 4. War schnell unterwegs.

Ansonsten ist mod die Abkürzung für modulo, also der Rest einer Division.

Und darum geht es etwas ausführlicher: https://en.wikipedia.org/wiki/Partition_alignment

[CrazyIvan]

Jaja, schon klar. Aber wieso sollte NC auf Mod 4 != 0 alignen? Das war doch gerade seine Aussage.
Bestimmt alles nur ein Fall von Lost in Translation ;)

[Nightspider]

Da Zen5 einen recht großen Kern haben dürfte in N4....

Zen4 Chiplets sind wie groß? 73mm² ? Zen5 Chiplets könnten noch kleiner werden.

Wenn AMD 2024 noch mit N4 bei solchen kleinen Chips ankommt für ihre wichtigsten Kerne, fresse ich einen Besen.

[basix]

Zen4 Chiplets sind wie groß? 73mm² ? Zen5 Chiplets könnten noch kleiner werden.

Wenn AMD 2024 noch mit N4 bei solchen kleinen Chips ankommt für ihre wichtigsten Kerne, fresse ich einen Besen.

Zen 5 / 5c wird mit N4 & N3 angegeben. Und N3(E) bietet nur relativ geringe Vorteile hinsichtlich Performance und ist erst Ende 2023 ready.

Meine Prognose:
- Zen 5 = N4(X)
- Zen 5c = N3x

[HOT]

Zen4 Chiplets sind wie groß? 73mm² ? Zen5 Chiplets könnten noch kleiner werden.

Wenn AMD 2024 noch mit N4 bei solchen kleinen Chips ankommt für ihre wichtigsten Kerne, fresse ich einen Besen.
Guten Hunger dann :D.
https://www.planet3dnow.de/cms/65427-amd-zen-4-mit-ipc-plus-von-8-bis-10-zen-5-in-2024/

Was steht auf der Folie? Zen5 in 4 und 3nm. Was kommt zuerst bei Zen5? Das CCD. Also ist es doch sehr unwahrscheinlich, dass das gleich auf N3 setzen wird ;). Ich mein, man kann das gerne glauben, aber ich finds einfach unrealistisch. Erschwerend hinzu kommt, dass N3(e) nicht leistungsfähiger ist als N4X, letzterer aber deutlich billiger sein dürfte. basix hat da sicherlich recht.
Ich würd auch sagen:
Zen5-CCD -> N4X
Zen5c-CCD -> N3x
Zen5-APU -> N3e

[amdfanuwe]

Zen5-CCD -> N4X
Zen5c-CCD -> N3x
Zen5-APU -> N3e
Zen4(c) kommt in N5,Zen4 APU in N4
denke Zen5(c) kommen entsprechend in N4, nur die APU in N3.

[Nightspider]

Hmmm, die Folie hatte ich gar nicht mehr auf dem Schirm.
Sieht ja dann wirklich danach aus, das ihr Recht habt.

Aber dann hoffe ich, das wenigstens der Release schon zeitig ist. Zen4 kam ja schon sehr spät und es gab ja schon Gerüchte Zen5 würde zeitiger kommen.
An der Prozessreife wird es ja dann nicht liegen.

2Q24 wäre top.

[HOT]

Jo, so siehts aus. Ich würd das mal in etwa so zusammenspekulieren (Korrektur):

Zen4 CCD -> N5
RDNA3 GCD -> N5P
Zen4c CCD -> N5(P?) H1 23
Zen4 APU -> N4 Q3 23
Zen4 APU (PHX2) -> N4 Q4 23
evtl. N31 Refresh (?) -> N4P mit alten Masken oder neuer Revision H2 23
Phoenix Refresh -> N4 H1 24
Zen5 CCD -> N4X H1 24
Zen5c CCD -> N3e H2 24
Zen5 APU -> N3e H1 25
(RDNA4 GCD -> N3P) H2 24 oder H1 25
(Zen6 oder Zen5 Refresh CCD -> N3X) H1 oder H2 25

usw.

Bei AMD ging das bisher relativ streng nach Reihenfolge. H1 24 für Zen5 wäre dann ohne Verzögerungen, also B0.

[CrazyIvan]

Zen4 APU -> N4 Q3 23
Zen5 CCD -> N4X H1 24
Zen5 APU -> N3e H2 24

Mit Zeile 1 meinst Du den Desktop? Mobile Vorstellung sollte ja zur CES erfolgen, mit Verfügbarkeit in Frühjahr/Sommer.
Gehen wir eigentlich von einer weiteren Zen4 APU zwischen Phoenix Point und Strix Point aus? Anderenfalls müsste ja Zen5 noch in 2023 kommen.

[basix]

Ich würde davon ausgehen, dass es noch eine weitere APU auf Basis Zen 4 geben wird oder zumindest einen Refresh von Phoenix. Zen 5 wird im besten Fall in H1/2024 auftauchen

[HOT]

Ich würde davon ausgehen, dass es noch eine weitere APU auf Basis Zen 4 geben wird oder zumindest einen Refresh von Phoenix. Zen 5 wird im besten Fall in H1/2024 auftauchen
Stimmt.
Und die Mobilhersteller mögen Phoenix Point schon im H1 bekommen, aber verfügbar ist da nix vor Q3.
Also ist Strix Point sogar erst für 1H 25 zu erwarten.

Ich denke übrigens, dass Zen5c tatsächlich in N3e kommt, da die Performance des Prozesses für das Produkt keine große Rolle spielt, Strom aber sehr wohl. Für ein Zen5 CCD ist N4X optimal, für Zen5c aber nicht.

[CrazyIvan]

Und die Mobilhersteller mögen Phoenix Point schon im H1 bekommen, aber verfügbar ist da nix vor Q3.
Also ist Strix Point sogar erst für 1H 25 zu erwarten.

Du spielst auf die schlechte Verfügbarkeit der letzten Generationen an? Bei Renoir und Cézanne war es ganz klar ein Thema der Produktionskapazität, bei Rembrandt bin ich mir da mittlerweile nicht mehr so sicher.
Zu erst dachte ich, dass die OEMs primär die Business Segmente bedienten. Mit Blick auf die katastrophalen Marktanteile für AMD im Mobile erscheint mir das aber wenig schlüssig. Ich glaube daher an eine Kombination nachfolgender Faktoren, die zur schlechten Verfügbarkeit von Rembrandt geführt haben: Die OEMs hatten sicher hohe Restbestände der Vorgängergenerationen, das Validieren neuer Designs hat viel Zeit gekostet, die Plattformkosten aufgrund DDR5 waren im Vergleich sehr hoch und auch deshalb war ADL in den meisten Segmenten die bessere Wahl (aus OEM Sicht).

[Nightspider]

Mit Blick auf die katastrophalen Marktanteile für AMD im Mobile erscheint mir das aber wenig schlüssig.

Der Marktanteil von AMD ist bei Laptops doch stark gestiegen.

Rembrandt ist in der Tat aber schon bisschen seltsam. Ich könnte mir aber auch vorstellen, das AMD die Vorgaben deutlich gestrafft hat und deswegen Rembrandt nicht von jedem Honk in jedem Trashbook verbaut werden darf. Anders kann ich es mir kaum erklären, das es so wenig Modelle gibt.

[MSABK]

Der Marktanteil von AMD ist bei Laptops doch stark gestiegen.

Rembrandt ist in der Tat aber schon bisschen seltsam. Ich könnte mir aber auch vorstellen, das AMD die Vorgaben deutlich gestrafft hat und deswegen Rembrandt nicht von jedem Honk in jedem Trashbook verbaut werden darf. Anders kann ich es mir kaum erklären, das es so wenig Modelle gibt.

Quasi wie Zen4 Premium und da sind die Absatzzahlen eingebrochen dNn.

[CrazyIvan]

Der Marktanteil von AMD ist bei Laptops doch stark gestiegen.

-9,1 Prozentpunkte in einem Quartal bzw. 37% des eigenen Marktanteils verloren ist nicht weniger als ein Desaster.
https://m.3dcenter.org/news/die-marktanteile-fuer-x86-prozessoren-im-dritten-quartal-2022

[Nightspider]

Oha, die Zahlen kannte ich noch nicht, das ist in der Tat heftig.

Die N4 APUs dürften wieder sehr interessant werden, dank besserem Fertigungsprozess.

Aber AMD muss eben auch liefern. Stückzahlen.

[Daredevil]

Wird die Zahl nicht ein wenig verzerrt, wenn man nur Intel und AMD entgegen stellt?
Weil Apple greift offenbar ordentlich was ab.
https://images.ifun.de/wp-content/uploads/2022/10/pc-shipment-q3-2022.jpg

[robbitop]

IMO liegt es nicht am SoC selbst. Die sind seit Renoir phantastisch. Intel hat wahrscheinlich alles mit Rabatt und Knebelverträgen vermint. Da kann der SoC noch so gut sein.

[CrazyIvan]

@Daredevil
Definitiv ein sehr gewichtiger Punkt. Und es zeigt einmal mehr, dass Kaufentscheidungen eben nicht primär auf Basis der präferierten Plattform getroffen werden. Apple Produkte stellen für einen sehr großen Teil des Gesamt-Notebook-Marktes eine sehr verlockende Alternative dar.

[MSABK]

Apple hat halt mit dem M1 Air ein konkurrenzloses Produkt zu einem starken Preis. Dann kommt Intel mit ihrer Macht und Bundelverträgen. Da kommt dann Amd und darf sich keinerlei Fehler erlauben.

[Zossel]

Weil Apple greift offenbar ordentlich was ab.

Weniger als ein Zehntel ist für dich ordentlich?
Für mich ist das Kinderkacke.

[davidzo]

Weniger als ein Zehntel ist für dich ordentlich?
Für mich ist das Kinderkacke.

13,5% ist mehr als ein zehntel ;)
Und btw, hier gehts nach Stückzahlen und nicht nach Umsatz oder gar Marge. Beim ASP wie auch der Lebensdauer der Produkte liegen Macs eher nochmal ein stück vorne. Wenn du Marktanteile nach Umsatz zählst, entspräche das eher Richtung 20% und damit wäre Apple vielleicht sogar Nummer 1 vor Lenovo nach Umsatz.

[w0mbat]

- weiterhin 8C-CCX
- breiteres design
- 20%+ mehr 1T IPC
- größerer L1 cache
- shared L2 cache
- vielleicht "L4 cache" für APUs (LLC aka Infinity Cache?)

1b5c0_RYnNo

[amdfanuwe]

- weiterhin 8C-CCX

- größerer L1 cache
- shared L2 cache
- vielleicht "L4 cache" für APUs (LLC aka Infinity Cache?)

https://youtu.be/1b5c0_RYnNo
Gibt wohl L3/IF$ im I/O.
Würde mich auch nicht wundern, wenn bei 24C und 32C die Chiplets über dem I/O gestacked werden, wie beim MI300.
Für die Bandbreite sorgen dann Infinity FanOut Links wie bei RDNA3

[Der_Korken]

24 oder 32C auf AM5 halte ich für eine fragliche Entscheidung. Der Käuferkreis ist so klein, dass ich nicht glaube, dass AMD beim Rest der Produkte zu Kompromissen bereit wäre, nur um eine Option auf 24-32C zu haben. Generell ist AM5 imho bereits eine zu teure Plaattform, um im Mainstream-Markt hohe Stückzahlen zu erreichen. Wenn AMD 32C bringen will, sollten die eher über ein HEDT-Revival nachdenken. Die Lücke zu Servern wird immer größer, weil bei letzteren die hohe Breite genutzt werden kann, im Desktop aber nur sehr bedingt. Da wäre also Platz für eine Plattform dazwischen.

Ansonsten sind die Spekulationen nicht wirklich neu. Wenn ein CCX bei 8C bleibt (und nicht etwa auf 4 schrumpft, die Möglichkeit bestünde ja auch) und trotzdem bereits der L2 über alle Cores shared, muss der L1 mehr oder weniger die Aufnahme übernehmen, die bisher der L2 hatte. Falls nicht, hätte man ein rieseiges "Loch" wie bei Bulldozer damals (16kB L1, 2MB L2). Spannend wird, wie AMD die Latenzen in den Griff kriegen will. Ein L3 auf dem IOD als LLC für die iGPU fände ich sehr sexy. Das würde bei der iGPU für einen massiven Boost sorgen. Dadurch dass RDNA3 so schwach ausfällt, lässt sich AMD sich von Meteor Lake gar die Butter vom Brot nehmen.

P.S. Ich hoffe Idle- und Teillastverbrauch werden endlich besser. Ich will keine mit 1,5V boostenden und >40W bei ST-Spikes saufenden Kerne mehr sehen.

[maximus_hertus]

Generell ist AM5 imho bereits eine zu teure Plaattform, um im Mainstream-Markt hohe Stückzahlen zu erreichen

Theoretisch und Praktisch müsste es wie bei AM4 Chipsatz-lose Systeme möglich sein. Und DDR5 wird immer günstiger.

Mich würde es nicht wundern, wenn wir noch im Sommer AM5 Boards für 110-120 Euro sehen. 32GB DDR5 (Standard, kein Fancy RGB OC) für unter 100 Euro. Ryzen 7600 für ca. 220 Euro. Macht dann rund 400-450 Euro für ein Komplettpaket aus Board, CPU und RAM.

Klar, immer noch nicht "Low-Budget" Kompatibel, aber für nicht wenige der Punkt, bei dem man dann zuschlagen kann.

Inflation, Eurokurs und Co. sorgen leider dafür, dass es erstmal wohl keinen Ryzen x600 für 130 Euro, passendes Board und RAM für je 50-60 Euro gibt / geben wird. Dazu sind die Anforderungen an die Boards / Stromversorgung gestiegen.

Auf der "positiven" Seite -> Man kann eine solche Plattform relativ lange nutzen, so dass der (Kauf)Mehrpreis zumindest zum Teil wieder relativiert wird.

[MSABK]

Theoretisch und Praktisch müsste es wie bei AM4 Chipsatz-lose Systeme möglich sein. Und DDR5 wird immer günstiger.

Mich würde es nicht wundern, wenn wir noch im Sommer AM5 Boards für 110-120 Euro sehen. 32GB DDR5 (Standard, kein Fancy RGB OC) für unter 100 Euro. Ryzen 7600 für ca. 220 Euro. Macht dann rund 400-450 Euro für ein Komplettpaket aus Board, CPU und RAM.

Klar, immer noch nicht "Low-Budget" Kompatibel, aber für nicht wenige der Punkt, bei dem man dann zuschlagen kann.

Inflation, Eurokurs und Co. sorgen leider dafür, dass es erstmal wohl keinen Ryzen x600 für 130 Euro, passendes Board und RAM für je 50-60 Euro gibt / geben wird. Dazu sind die Anforderungen an die Boards / Stromversorgung gestiegen.

Auf der "positiven" Seite -> Man kann eine solche Plattform relativ lange nutzen, so dass der (Kauf)Mehrpreis zumindest zum Teil wieder relativiert wird.

Schon ja. Aber solange es AM4 gibt wird es AM5 schwer haben. Die Masse kauft nunmal kein 180€ „Billig“ Bord. Wenn Intel da was hat im unteren Bereich dann werden die Stückzahlen dort gemacht. Amd rettet aktuell bissi der 5800x3d. Man kann da quasi für 450€ cpu, ram, board eines der schnellsten Syteme bauen.

Ich bleibe dabei, AM5 ist stand jetzt eine HEDT Plattform und somit eher Nische.

[amdfanuwe]

24 oder 32C auf AM5 halte ich für eine fragliche Entscheidung. Der Käuferkreis ist so klein, dass ich nicht glaube, dass AMD beim Rest der Produkte zu Kompromissen bereit wäre, nur um eine Option auf 24-32C zu haben.
Ja, den meisten Käufern reichen 4 Core (Office) oder 8 Core (Gaming). AMD hat aber auch noch andere Käufer.
Mit einem flexiblen Baukasten kann man alle Bedienen ohne zu teuer zu werden.

Ich denke daher, mit ZEN 5 findet ein Paradigmenwechsel statt.
Bisher teilten sich mehrere Cores in einem CCX den L3 Cache.
Bei mehreren CCX hat man das Problem der Kohärenz.
Indem der Cache sozusagen vor den Speicher geschoben wird, ergibt sich das Problem nicht mehr in den Maßen. Der IF$ stellt einen kohärenten unified Cache dar, der den Speicher für alle beschleunigt.
Dadurch wird es auch möglich verschiedene Compute Units miteinander zu verbauen.
82668
Mit ZEN 5 bringt AMD ein von den Compute Units unabhängiges Frontend für Speicheranbindung ( egal ob DDR, GDDR, HBM, CXL ) und Kommunikation untereinander.
Durch den IF$ auf dem I/O kann dann die Cachestruktur auf den Chiplets entsprechend kleiner ausfallen.
Mit EFOB, Infinity FanOut Links, Metal to Metal stacking hat AMD nun die nötigen schnellen Verbindungsmöglichkeiten.

RDNA2 war der Testfall für IF$.
RDNA3 für Infinity FanOut Links.
MI250x für schnelle Verbindung zwischen 2 großen Chips.
Warten wir mal Bergamo ab, ob da eventuell schon der I/O für die Genoa Variante aus 2 Chips besteht.
MI300 packt dann alles zusammen, mehrere I/O mit IF$ und verschiedenen Compute Chiplets.

[davidzo]

- breiteres design
- größerer L1 cache
- shared L2 cache
- vielleicht "L4 cache" für APUs (LLC aka Infinity Cache?)


Wie zu erwarten bedient man sich des Apple-Kochbuchs oder kommt zufällig auf ein ähnliches Konzept: Großer L1, shared L2 und ein großer system level cache. Der hieße dann aber wahrscheinlich L3 und nicht L4.

Spannend wird, wie AMD die Latenzen in den Griff kriegen will.

So wie Intel und Apple auch -> OoO Ressourcen vergrößern um die Latenzen zu kaschieren: "L0" caches, queues und buffers wie ROB, Load-queue, store-queue, Register für Int und FP. Mehr reordering Capacity kommt besser mit höheren Latenzen zurecht.

Für +20% mehr IPC muss man wohl auch die issue-width endlich mal vergrößern die seit Zen1 noch bei 4x festklebt. In interviews hatte AMD ja auch angedeutet dass man ab zen5 breiter wird, das sehe ich also als gesetzt an, eventuell ne zusätzliche Alu oder l/s Einheit. Zum breiteren decoder kommen die üblichen leichten Verbesserungen bei µop$, BTB, TLB und branch predictor.
Eine soviel breitere µArch kostet natürlich erheblich mehr Transistoren, was mich nicht unbedingt optimistisch in bezug auf den Verbrauch und Taktbarkeit stimmt.


P.S. Ich hoffe Idle- und Teillastverbrauch werden endlich besser. Ich will keine mit 1,5V boostenden und >40W bei ST-Spikes saufenden Kerne mehr sehen.
Der shared L2 ist eigentlich keine gute Idee für den Teillastverbrauch. Bei Alderlake/Raptorlake ist es nicht selten effizienter für Hintergrundaufgaben die big cores zu verwenden weil man dann nicht ein ganzes quadcore E-core-Cluster wecken muss. Multicore Effizienz in allen Ehren, aber bei Teillast sind die E-Cores leider nicht selten ineffizient.
Und dass eine breitere Architektur mit breitbandigen Caches höherer latenz und großen OOO ressourcen viel schlucken kann sieht man ja bei Golden Cove. Und bei Intel sitzen auch keine Anfänger - wüssten sie wie es anders geht, dann hätten sie es gemacht. Wenn AMD nicht zufällig auf ein paar Apple-Geheimnisse gestoßen ist, klingt das alles eher nach einem Rezept für eine tolle High performance CPU und nicht nach besserer Effizienz bei Teillast. Da bleiben wohl noch der M1 Icestorm und bei x86 Renoir/Zen2 das Maß der Dinge.

[Zossel]

Und dass eine breitere Architektur mit breitbandigen Caches höherer latenz und großen OOO ressourcen viel schlucken kann sieht man ja bei Golden Cove. Und bei Intel sitzen auch keine Anfänger - wüssten sie wie es anders geht, dann hätten sie es gemacht. Wenn AMD nicht zufällig auf ein paar Apple-Geheimnisse gestoßen ist, klingt das alles eher nach einem Rezept für eine tolle High performance CPU und nicht nach besserer Effizienz bei Teillast. Da bleiben wohl noch der M1 Icestorm und bei x86 Renoir/Zen2 das Maß der Dinge.

Die CPUs die zum glotzen von Medien gedacht sind werden abgespeckt.
Und die CPUs für richtige Computer sind eben fetter, Apple hat ja keine CPUs für richtige Computer.

[vinacis_vivids]

Zen 5 mit 32C/64T bei 6,x Ghz AllCore 🙈
Ich freue mich drauf, hoffe TSMC macht 3nm Silizium billiger bzw. nicht so teuer. So ein Rechenmonster gepaart mit 128GB RAM ist schon ein geiles Spielzeug.

[davidzo]

Die CPUs die zum glotzen von Medien gedacht sind werden abgespeckt.
Und die CPUs für richtige Computer sind eben fetter, Apple hat ja keine CPUs für richtige Computer.

LOL, die haben mal eben die fetteste CPU auf dem Markt. Der M2Ultra hat mehr als doppelt soviele Transistoren wie Intels größte jüngst gelaunchte Sapphire Rapids CPU und immer noch deutlich mehr als AMDs neueste Genoa CPUs mit Sockeln so groß wie sechs deiner Desktop Spielzeuge.
Per DIE ist das noch viel brutaler. Jedes einzelne Chiplet ist bei Apple fetter als alle vier SRs Chiplets zusammen genommen, die wiederum größer sind als alles was AMD an CPU DIEs jemals produziert hat. Davon kann Intel wie auch AMD auf dem Desktop nur träumen.
Klar, der Großteil sind GPU und spezifische Accelerator, ist aber bei SR nicht soviel anders. Und die CPU-Cores sind natürlich trotzdem sehr fett. Und erst recht das Speichersystem. Schon der M1max als NotebookCPU hat mal eben eine 8channel DRAM Anbindung wie AMD Milan. Der Ultra hat 25% mehr Speicherkanäle als Genoa.

Und bei der ST und MT Leistung angeht distanziert der M1Ultra mit 16+4C den damaligen Spitzenreiter 5950X deutlich (GB5 1,7 + 23K vs 1,6 + 16K), vor allem Multithreaded. Und auch der M2Ultra mit 16+8C wird den 13900k abledern (GB5 1,9K + 27K vermutlich, vs 2,2K + 25K), bei etwa einem Drittel des Verbrauchs.

Nein, wenn wir von fetten CPUs für richtige Computer sprechen, dann sprechen wir auf jeden Fall auch über Apple CPUs. Oder meinst du ohne 350Watt
Boostmodell und 1200Watt+ Netzteile wären das in 2023 keine "richtigen Computer"?

Und was das glotzen von Medien angeht, wozu braucht man wohl mehrere 8K ProRes Encoder in der CPU? Die typischen 15W intel "Netbooks" mit quadcore tigerlake oder den 2+8 Bremsen von consumer CPUs haben sowas jedenfalls nicht.

[ElectricLeaf]

Zen 1 hat in vielen Bereichen +50..70% zugelegt.
[/LIST]
Zen 1 war von der IPC auf dem Niveau von Haswell;D:P

[ElectricLeaf]

13,5% ist mehr als ein zehntel ;)
Und btw, hier gehts nach Stückzahlen und nicht nach Umsatz oder gar Marge. Beim ASP wie auch der Lebensdauer der Produkte liegen Macs eher nochmal ein stück vorne. Wenn du Marktanteile nach Umsatz zählst, entspräche das eher Richtung 20% und damit wäre Apple vielleicht sogar Nummer 1 vor Lenovo nach Umsatz.
Wäre auch lächerlich wen ein Macbook um 2000€ eine Haltbarkeit wie ein Acer um 500€ hätte. Wobei wie war das nochmal mit den Macbook Air mit Lüfter ohne Heatpipe.;D

[Zossel]

wie sechs deiner Desktop Spielzeuge.

Ich meinte eigentlich Server. Welche ist das den genau, beim googlen danach wird es sehr unübersichtlich.

[Zossel]

Wäre auch lächerlich wen ein Macbook um 2000€ eine Haltbarkeit wie ein Acer um 500€ hätte. Wobei wie war das nochmal mit den Macbook Air mit Lüfter ohne Heatpipe.;D

Das alles verklebt und verlötet ist der Haltbarkeit eher abträglich. Damit entfällt die Möglichkeit eine alte Möhre noch für wenig Asche wieder flott zu machen.
Damit ist das eher ein Wegwerfprodukt wie Handys.

Und dann noch die ewigen Wechsel der CPU Architektur on top.

[ElectricLeaf]

Amd ist außen vor mit der integration von Pluton,
nur wenige kapieren das, wir haben durch den Security Chip in Hardware noch nie soviele IP Adressen für die FTP Szene geleakt.

Also soll jedes Oper weiter auf amd und pluton setzen, auf sowas ist eine Linux Distrie zu installieren nahezu schwer,
Aber Pluton gibt denn Adressbereich frei und somit den FTP Scannern freien lauf.

Hauptsache ich bin nicht bei dem Bösen Intel, aber gut 89% in FTP Server mittels Serverzugrief sind von AMD.

[Zossel]

Amd ist außen vor mit der integration von Pluton,
nur wenige kapieren das, wir haben durch den Security Chip in Hardware noch nie soviele IP Adressen für die FTP Szene geleakt.

Also soll jedes Oper weiter auf amd und pluton setzen, auf sowas ist eine Linux Distrie zu installieren nahezu schwer,
Aber Pluton gibt denn Adressbereich frei und somit den FTP Scannern freien lauf.

Hauptsache ich bin nicht bei dem Bösen Intel, aber gut 89% in FTP Server mittels Serverzugrief sind von AMD.

Kannst du das noch mal neu formulieren.

[latiose88]

hm wie sicher ist das mit den größeren L1 Cache und das der µop$ sowie die Ausführungseinheiten größer werden wirklich?

Und ist halt noch ne andere Frage,wird die CPU dann teuer sein als die jetztige? ich bin nämlich am sparen.Habe ja gewiss bis so September 2024 Zeit zu sparen.Aber 1500€ für CPU.Ram und Mainbaod sammt neues Gehäuse ist halt echt eine herausforderung.Da ist halt ganz schön gesalzen und das obwohl ich dann zu der Onbard GPU nur setzen will.Wir werden ja sehen wie teuer das dann sein wird.

[Der_Korken]

Das einzig sichere ist, dass es eine Architektur mit dem Namen "Zen 5" gibt, die irgendwann 2024 aufschlagen wird. Alles andere ist Spekulation und Gerüchte. Dass der L1$ größer wird und das Backend verbreitert, erscheint logisch, denn diese Dinge sind seit Zen 1 nicht angerührt worden. In irgendeine Richtung muss Zen 5 expandieren. Größerer µOp-Cache, mehr Load/Store, Zero-Bubble-Branch-Prediction, neue Scheduler, mehr L2, mehr Takt hat AMD mittlerweile durch.

[latiose88]

ok verstehe es bleiben also nicht viele sachen übrig die man noch groß Erweitern kann.Und das alles kostet ja auch Transistoren.Verstehe.Und das wiederum kostet eben auch Fläche.Die ist ja begrenzt.Alternativ könnte AMD ja die CPUS größer werden lassen für mehr Leistung.Was aber dann den Preis weiter nach oben treiben lassen würde.Nun es bleibt spannend ,wie AMD das handhaben wird.

[amdfanuwe]

Wenn mehr Cores nichts mehr bringen, kommen halt mehr Beschleuniger ins Spiel.
AVX 512, AI Cores, FPGA ...

[latiose88]

stimmt AI Cores gibt es ja auch noch und diese Beschleuniger funktioniert ohne das Programm es unterstüzen muss und wenn das auch nichts mehr bringt,was kommt denn dann noch ?

[Der_Korken]

Alternativ könnte AMD ja die CPUS größer werden lassen für mehr Leistung.Was aber dann den Preis weiter nach oben treiben lassen würde.

Was meinst du mit "größer werden lassen"? Mehr Transistoren für jeden Kern? Das wird sehr sicher passieren, aber die spannende Frage ist, wofür die Transistoren genutzt werden. Wenn das so einfach wäre, hätte man nie in so viele Kerne expandiert, sondern hätte einfach nur ein paar davon immer größer und schneller gemacht.

[latiose88]

stimmt ab einen gewissen Punkt wird das immer größer werden der Transistoren auch nix mehr bringen.Und ab einer gewissen Anzahl an Kernen ebenso nix mehr.Ich weis ja das die Threadripper einen doppelten Ryzen entsprechen.
Spannend wird es wenn die Software sehr spziell ist oder wenn sie nicht die ganze CPU mit allen Futures voll ausfüllen kann.Da werden sich die Hardware Hersteller sicherlich auch noch was einfallen lassen.Wenn sowas wie SMT,AVX und Ramtakt nicht oder teilweise einfach nicht wirken,dann wird es mit sicherheit noch andere Wege geben die helfen.
Es wird bestimmt auch der Aufbau des Kerns also die Eigenschaften also die Einheiten wie unter Cache wo es ja auch noch gibt.Also die Alternativen Prefetchen die in so CPUS noch schlummern. Die machen ja die Vorarbeit das es dann die CPU voll Abarbeiten kann.Also sprich das Vorsortieren für die Arbeit.Das hat AMD ebenso noch nicht angerührt.BIn gespannt wie viel das so bringen wird. Ich werde freilich alles was so eine CPU kann versuchen herauszuholen.

Was ich herausgefunden habe so matamatische Sachen wie Mixed Refernz beim Umwandeln bringt AVX dazu minimal schneller zu werden.Die Bandbreite beim Ram scheint es auch Programme zu geben wo ab einer gewissen Bandbreite eben auch nix mehr geht.
Also ich sehe schon immer mehr bremsen und Grenzen kommen da auf einen zu.
Ich erlebe gewiss auch noch wo eine Verbesserung bei CPU auch nix mehr bringen wird.Wer sagt das es ne Unendliche Steigerung bei Software gibt nur durch ne CPU.Sowas kann es einfach nicht geben.

[amdfanuwe]

sondern hätte einfach nur ein paar davon immer größer und schneller gemacht.
Hat man doch anfangs gemacht.
8,16, 32 Bit
FPU, MMU integriert.
Cache
MMX, SSE, ...
Dann ging da nicht mehr viel und man fing mit dual Core an.
Dann lange Quad Core.
64 Bit, Crypto, AVX

Wenn man sich an die ersten CPUs erinnert, die konnten noch nicht mal int mul und int div.
Ich hatte auch damals mit Z80 und 1kByte RAM Spass.

[reaperrr]

Größerer µOp-Cache, mehr Load/Store, Zero-Bubble-Branch-Prediction, neue Scheduler, mehr L2, mehr Takt hat AMD mittlerweile durch.
Naja, was heißt "durch". Es ist ja nicht so, dass man diese Dinge nur einmal verbessern kann und dann sind sie perfekt.
Den µOp-Cache noch weiter zu vergrößern würde z.B. sicher durchaus noch was bringen, v.a. wenn man auch an anderen Stellen aufbohrt. Gleiches gilt für mehr Load/Store-Einheiten.
Und wenn man z.B. auf 5-wide issue gehen sollte wie Intel es bereits getan hat, müsste man auch den Scheduler wieder anpassen.

[ChaosTM]

3nm, 2nm, 1nm -> Ok-ish ?

wtf happens now?

0,5nm oder 500 picometer ist der WALL!
Unter der Atombreite von 1 geht nichts mehr

abgesehen davon dass es jetzt schon richtig teuer ist.
<2 nm wird um mehrere Größenordnungen teuerer -> siehe internetz

[ElectricLeaf]

Kannst du das noch mal neu formulieren.
Nein leider, seit ich mein neues Hobby gefunden habe kann ich das schwer neu formulieren. :freak:

[davidzo]

Ich meinte eigentlich Server.
Naja, merkt man ja schon am Wort, dass die "Server" ohne "Clients" gar nicht existieren würden.:wink:

Dass der L1$ größer wird und das Backend verbreitert, erscheint logisch, denn diese Dinge sind seit Zen 1 nicht angerührt worden.
Der L1$ wurde seitdem sogar verkleinert. Zen1 hatte einen 64kb L1-I Cache 4-way. Zen2 hat einen symmetrischen D+I Cache mit je 32kb 8-way.

Die Vergrößerung würde ich nicht so sehen dass es jetzt mal "an der Zeit wäre", sondern vielmehr um den erheblichen Latenznachteil eines großen shared L2 auszugleichen. Vielleicht ergeben sich die L1 Gerüchte auch nur aus dem Gerüchte des großen shared L2 das schon länger im Umlauf ist.

Klingt jedenfalls alles nicht nach einem Cache-System welches besonders gut für gaming ist, sondern eher nach einer effizienzten Multicore CPU für Datacenter.

[Der_Korken]

Hat man doch anfangs gemacht.

Natürlich, aber irgendwann hat es nicht mehr so viel gebracht.

Naja, was heißt "durch". Es ist ja nicht so, dass man diese Dinge nur einmal verbessern kann und dann sind sie perfekt.
Den µOp-Cache noch weiter zu vergrößern würde z.B. sicher durchaus noch was bringen, v.a. wenn man auch an anderen Stellen aufbohrt. Gleiches gilt für mehr Load/Store-Einheiten.
Und wenn man z.B. auf 5-wide issue gehen sollte wie Intel es bereits getan hat, müsste man auch den Scheduler wieder anpassen.

Die genannten Sachen werden sicherlich weiter wachsen, aber den wahrscheinlichsten Bottleneck stellen imho die Sachen dar, die schon lange nicht mehr skaliert wurden. Der µOp-Cache und BTB nehmen schon beträchtlich viel Fläche auf dem Core ein. Natürlich kann man immer noch mehr verbauen, genauso wie man auch einfach immer noch mehr Cache draufschmeißen kann, aber irgendwann stimmt der Ertrag vs. Investment nicht mehr, wenn man nur einseitig erweitert.

Vor allem ergeben sich auch neue Probleme: Je größer das out-of-order-window, desto mehr Branches befinden sich in diesem Fenster und desto geringer die Wahrscheinlichkeit für die hinteren Operationen, dass sie überhaupt ausgeführt werden. Beispiel: Alle 10 Ops kommt ein Branch, der zu 90% korrekt predictet wird. Betrachtet man die nächsten 20 Operationen, werden (vereinfacht) 10 davon sicher ausgeführt, die nächsten 10 aber nur zu 90%. Macht im Schnitt 95%. Bei einem 40er Fenster wären es 10x100%, 10x90%, 10x81% und 10x73%, im Schnitt nur noch 86%. Zusätzlich zu den verdoppelten Ressourcen, um das Fenster in den Buffern zu halten, sinkt die Effizienz deutlich, weil öfter misspredictet wird.

Bezüglich 5-wide issue: Ist AMD nicht eigentlich eh schon "6-wide", weil sie 4xINT und 4xFP gleichzeitig können und 6-way dispatch?

Die Vergrößerung würde ich nicht so sehen dass es jetzt mal "an der Zeit wäre", sondern vielmehr um den erheblichen Latenznachteil eines großen shared L2 auszugleichen. Vielleicht ergeben sich die L1 Gerüchte auch nur aus dem Gerüchte des großen shared L2 das schon länger im Umlauf ist.

Klingt jedenfalls alles nicht nach einem Cache-System welches besonders gut für gaming ist, sondern eher nach einer effizienzten Multicore CPU für Datacenter.

Naja, niemand hat AMD gezwungen den L2 auf CCX-Ebene hochzuziehen. Der Schritt bedeutet ja, dass unterhalb des L3 eine Cache-Ebene wegfällt (und der L3 dadurch L2 heißt). Wäre die alte Aufteilung besser, würde AMD es einfach so lassen. Anscheinend ist AMD aber der Meinung, dass eine Cache-Stufe reicht. Auch das hat gewisse Vorteile, denn zu viele sequentiell durchsuchte Cache erhöhen auch immer die Latenz der gesamten Hierachie.

Bei Apple klappt die Aufteilung ganz gut, aber sie haben nur 4 Kerne pro L2 (= kleinere L2-Latenz) und der L1 kann länger VIPT nutzen (= größerer L1 bei gleicher Latenz möglich verglichen mit AMD/Intel), sodass das Loch bei denen nicht so groß ausfällt. Jemand hatte hier schon gesagt, dass der langsamere L1 durch ein massiv größeres out-of-order-window aufgefangen werden könnte, aber wie oben geschrieben, handelt man sich dadurch wieder andere Nachteile ein. Vielleicht ist das auch das Puzzle-Stück, das Zen 5 mitbringt (z.B.: Bessere branch predictiors oder die Fähigkeit Branch-Evaluationen priorisiert abzuarbeiten, sodass sich das Fenster an "sicheren" Instruktionen durchgehend erhöht) und AMD stellt als Konsequenz das Cache-System um.

Ob die Arch für Spiele schlecht ist oder nicht, finde ich schwer zu sagen. Golden Cove ist quasi auch eine "fette, träge" Architektur mit großen Caches und Latenzen (verglichen mit z.B. Zen 3), aber trotzdem laufen Spiele hervorragend. Bei Raptor Lake mit mehr L2 und L3 sogar umso besser. Auf Firestorm kann man leider keine AAA-Titel nativ testen, das wäre aber interessant.

[robbitop]

Alles hier gesagte nur größer und breiter zu machen mag high level so stimmen. Aber versucht haben das schon viele und heraus kamen nicht immer schnelle und/oder sparsame Designs. Zuletzt ist Samsung mit der M Serie ja gescheitert. Was Apple gemacht hat erscheint high level sinnvoll ich wette aber dass da viele Details total anders gemacht worden sind die high level nicht auftauchen.
Wahrscheinlich ist das was Apple gemacht hat nicht besonders einfach - ansonsten hätten es längst schon andere gemacht. Muss man mal schauen wie das Ergebnis dann bei AMD und Intel aussieht.

Die Apple Cores sind auch in Spielen nicht gerade schlecht wenn man Translation Layer und niedrigen Takt bedenkt. Da stimmt taktnormiert schon vieles extrem gut. Wie leicjt sich das auch mit hohen Taktraten umsetzen lässt steht auf einem anderen Blatt.

[iamthebear]

Beim L3 macht der Trend zu einer Vergrößerung ja Sinn. Man hat mehr Transistoren zur Verfügung, bei Spielen werden pro Frame mehr Daten benötigt während DRAM Latenzen und Bandbreite/Kern gleich bleiben.

Beim L1 sehe ich diese Notwendigkeit allerdings nicht unbedingt. Hier ist die Transistoranzahl ja sekundär. Da geht es rein um das Abwegen von Größe vs. Latenz.
Wird die L1 Latenz erhöht muss ein Weg gefunden werden diese zu kaschieren.

Ich weiß nicht, ob Apple hier unbedingt ein guter Vergleich ist. Das ist ein Design, das für 3-3,5GHz ausgelegt ist und seine Performance in erster Linie durch massive Parallelisierung holt.
Ich bin sehr skeptisch, ob dieselben Konzepte auch bei einem 5-6GHz Design funktionieren würden.

[latiose88]

Apropo Cache,stimmt es das der Inhalt von L2 Cache auch im L3 zu finden ist und der Inhalt von L1 auch auf L2 Cache zu finden?
Und was ich verstehe das das alles teile vom Ram im Cache ist.Alles vom Ram muss ja nicht im Cache sein,dann wäre ja der Ram überflüssig.
Ich weis jedenfalls das bei mir der extra L3 Cache keinen Gewinn gebracht hatte.

Bin aber auch gespannt wie Festplatte hier einen Einfluss hat.Soweit ich es richtig verstanden habe,Festplatte hat auch den Inhalt des Rams drinnen ist.Das wiederum ein teil im Cache.
Es ist interessant je weniger man an Speicher braucht desto weniger Effekt hat der Cache der CPU an Leistung. Wenn das so ist,müsste eine Verkleinerung wohl auch kein Negative Wirkung auf die Leistung haben,ist aber nur ne Vermutung von mir.

[reaperrr]

Alles hier gesagte nur größer und breiter zu machen mag high level so stimmen. Aber versucht haben das schon viele und heraus kamen nicht immer schnelle und/oder sparsame Designs.
Dasselbe kann man aber auch über Designs sagen, die auf schlankere Kerne und dafür höhere Taktraten ausgelegt waren (ich sag nur Bulldozer).

Natürlich muss man aufpassen, dass die Balance stimmt, es bringt natürlich nichts, die IPC um 20% zu erhöhen, wenn dadurch der Verbrauch je MHz so durch die Decke geht, dass man dafür 20% niedriger takten (oder die TDP deutlich erhöhen) muss.

Um manche Dinge wie z.B. eine fünfte INT-ALU wird AMD aber nicht mehr lange herumkommen, weil Intel der Gerüchteküche nach eben auch eher auf IPC- als Taktsteigerungen setzt.

Ich meine, wenn MTL 15% IPC auf RTL draufpackt, muss Zen5 schon über 20% IPC zulegen, nur um an MTL ranzukommen, und ARL soll nochmal 20% auf MTL draufpacken.
Im Prinzip muss Zen5 in Sachen Real-World-IPC soviel bringen wie Zen3+4 zusammen, also einen Sprung wie von Zen2 zu Zen4 (oder noch besser, wie von Zen1 zu Zen3). Und dabei auch noch die Taktraten halten oder weiter steigern...

Bin selbst gespannt, ob AMD das so hinbekommt.

[MSABK]

Abwarten was bei Intel am Ende rauskommt und auch bei welchem Verbrauch. Für wann ist Zen5 angepeilt?

[Der_Korken]

Apropo Cache,stimmt es das der Inhalt von L2 Cache auch im L3 zu finden ist und der Inhalt von L1 auch auf L2 Cache zu finden?
Und was ich verstehe das das alles teile vom Ram im Cache ist.Alles vom Ram muss ja nicht im Cache sein,dann wäre ja der Ram überflüssig.
Ich weis jedenfalls das bei mir der extra L3 Cache keinen Gewinn gebracht hatte.

Bin aber auch gespannt wie Festplatte hier einen Einfluss hat.Soweit ich es richtig verstanden habe,Festplatte hat auch den Inhalt des Rams drinnen ist.Das wiederum ein teil im Cache.
Es ist interessant je weniger man an Speicher braucht desto weniger Effekt hat der Cache der CPU an Leistung. Wenn das so ist,müsste eine Verkleinerung wohl auch kein Negative Wirkung auf die Leistung haben,ist aber nur ne Vermutung von mir.

1. Bei AMD ist der Inhalt des L1 auch im L2. Bei Intel ist das afaik nicht zwingend so.
2. Der Inhalt des L2 ist weder bei Intel noch bei AMD im L3 (Aussagen gelten immer jeweils für die aktuellen Architekturen)
3. Alles was in einem Cache ist, ist immer auch im RAM. Aus logischer Sicht existieren Caches gar nicht (wörtlich übersetzt sind das versteckte Speicher), d.h. jedes System ist auch ohne Caches funktionsfähig.
4. Der RAM-Inhalt ist nicht auf der Platte. Der RAM heißt Hauptspeicher, weil er die höchste Instanz ist. Betriebssysteme können aber bei Bedarf Teile des RAMs auf die Festplatte verschieben. Dadurch kann man Anwendungen ein größeren RAM vorgaukeln als physisch vorhanden ist. Das ist aber alles so weit von der CPU entfernt, dass es keine Rolle spielt.
5. Weniger RAM-Bedarf einer Anwendung heißt nicht, dass Cache weniger bringt. Hier gibt es keine direkte Kausalität.


Ich meine, wenn MTL 15% IPC auf RTL draufpackt, muss Zen5 schon über 20% IPC zulegen, nur um an MTL ranzukommen, und ARL soll nochmal 20% auf MTL draufpacken.
Im Prinzip muss Zen5 in Sachen Real-World-IPC soviel bringen wie Zen3+4 zusammen, also einen Sprung wie von Zen2 zu Zen4 (oder noch besser, wie von Zen1 zu Zen3). Und dabei auch noch die Taktraten halten oder weiter steigern...

Bin selbst gespannt, ob AMD das so hinbekommt.

Die Zeit, wo AMD einfach Schlag auf Schlag an Intel heran bzw. vorbeigezogen ist, ist definitiv vorbei. Intel musste von Zen 1 bis Zen 3 alles mit Skylake bekämpfen, danach haben sie erst mit Rocket Lake wieder gleichgezogen und sind mit Golden Cove an AMD vorbei, inklusive an Zen 4. Intel hat soll mit Arrow Lake (?) eine komplett neue Architektur im Ofen haben. Ich hoffe nur, dass AMD ihren Kurs aufrecht erhalten kann. Ein grober Schnitzer und sie könnten wieder auf die Verliererstraße geraten wie damals gegen Conroe. Zumindest auf dem Desktop, im Server scheint AMD mir dagegen zu fest im Sattel zu sein.

[latiose88]

Ok danke dir,das erklärt auch warum L3 Cache der Anwendung egal ist.Kein Wunder also.
Bei ner Steigerung der Anwendung Leistung spielt es also keine so große Rolle ob L1 oder L2 Cache größe erhöht wird.Vorausgesetzt es wird auch an anderer Stelle wo notwendig ist auch erhöht.
Es ist echt Interessant das ganze.Da kann ich aber echt auf vieles hoffen.

Und wenn das mit Intel stimmen sollte,dann werde ich die starke Leistungssteigerung endlich mal so richtig spüren.Bei AMD denke ich mal werden gewiss noch eine weitere Zen Generation bringen auf den aktuellen Sockel.Also nicht nur Zen 5 sondern vielleicht auch Zen 6.
Es ist wohl also echt besser zu warten,sofern man nicht unbeding die Mehrleistung braucht oder der Abstand zu wenig ist.Das hat schon was mit 60% schneller als ein Ryzen 9 5950x.Da lohnt sich dann auch wirklich der Aufwand für mich.Bis dahin heißt es wohl gut sparen,weil kann mir nicht vorstellen das dies alles günstig sein wird.
Das hat alles auch seinen Preis der ganze Aufwand.

[CrazyIvan]

@latiose88
Bei Caches unterscheidet man grundsätzlich zwischen inklusiven oder exklusiven/victim Caches. Gemeint ist damit, ob beispielsweise der Inhalt des L1 Caches auch im L2 zu finden ist oder eben nicht. Die Entscheidung für oder gegen beide Varianten ist komplex und von vielen Faktoren abhängig. Beispielsweise macht es Sinn, dass der L3 bei AMD IIRC inklusiv ist, weil dadurch auch andere Kerne des gleichen CCD auf diese Daten zugreifen können. Exklusive Caches haben den Vorteil, dass insgesamt schlicht mehr verschiedene Daten in einer der Cache Hierarchien vorgehalten werden.

[Complicated]

Ich glaube von den feuchten Träumen von 15% IPC uplift sollte man sich bei MTL verabschieden. Zumindest nicht zu viel erwarten bei nur 6 PCores im Desktop
https://www.notebookcheck.net/Flagship-Meteor-Lake-22-core-CPU-apparently-canceled-as-Intel-could-market-MTL-S-towards-prospective-Core-i5-i7-gamers.676446.0.html

[bbott]

Hatte nichtmal AMD gesagt der IPC uplift von Zen 4 (oder 3?) zu Zen 5, soll größer als von Bulldozer zu Zen 1 (40%)?!

[reaperrr]

Ich glaube von den feuchten Träumen von 15% IPC uplift sollte man sich bei MTL verabschieden. Zumindest nicht zu viel erwarten bei nur 6 PCores im Desktop
https://www.notebookcheck.net/Flagship-Meteor-Lake-22-core-CPU-apparently-canceled-as-Intel-could-market-MTL-S-towards-prospective-Core-i5-i7-gamers.676446.0.html
Das Thema hatten wir doch gerade die letzten Seiten...:rolleyes:

Nur zur Info, Ice Lake hatte sogar 18% mehr IPC als SKL/CFL, ist trotzdem nicht im Desktop erschienen, weil Taktraten und Ausbeute zu schlecht waren.

Unabhängig davon ob MTL nun 15% mehr IPC hat oder nicht, sagt das canceln von Modellen meist mehr über erreichbare Taktraten und Yieldrate aus, und nur wenig bis nichts über die IPC.

[Der_Korken]

Hatte nichtmal AMD gesagt der IPC uplift von Zen 4 (oder 3?) zu Zen 5, soll größer als von Bulldozer zu Zen 1 (40%)?!

AMD hat das bestimmt nicht gesagt. Warum sollten sie das tun? Theoretisch können ja noch Dinge schief gehen und dann stehen sie mit so einer Zusage blöd da.

Das Gerücht tauchte u.a. hier auf: https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-67-februar-2021

Mit Originalquelle: https://chipsandcheese.com/2021/02/05/amds-past-and-future-cpus/

they have said that the jump [to Zen 5 from 4] from will be about as much as Piledriver to Zen 1 design goal, which if you recall to earlier in this article was 40%. I was told from a 3rd source that Zen 5’s original design goal was 2.5 to 3 times the IPC of Zen 1

Wenn man sich die anderen Vorhersagen anschaut, sollte man da aber wohl nicht so viel drauf geben:

Zen 3+ looks to be a small IPC gain on base Zen 3, having been told “It’s more than Zen+ was [over Zen 1] but not much” which I interpret to mean around a 4 to 7% IPC gain along with customary clock gains -> Zen 3+ (wenn man Ryzen 6000 so nennen will) hatte keinen IPC-Uplift.

However, the most interesting thing to me is that Zen 3+ on desktop may be the first AM5 CPU.

-> Rembrandt wurde nie für den Desktop released.

I was told that the IO die for Zen 3+ desktop is using “Not quite [the same] IOD as Zen 4 but uses Zen 4 IP” -> Ein solches Produkt scheint mir nie geplant gewesen zu sein. Da hätte AMD ein CCD und ein IOD-Design in 2021 fallen gelassen, damit das Gerücht überhaupt stimmen kann.

I was told from a trusted source that a Genoa engineering sample (Zen 4 server chip) was 29% faster than a Milan (Zen 3) chip with the same core config at the same clocks. -> Im Nachhinein völliger FUD, sofern man AVX512-Benchmarks nicht mit in den Durchschnitt einrechnet. In diesem Fall wäre aber jede IPC-Angabe von Zen 5 genauso eine Phantasiezahl, wenn dort z.B. ein Bench auf einer dedizierten NPU 5-10x so schnell wie auf Zen 4 lief und den Schnitt damit völlig verfälscht.

[reaperrr]

Hatte nichtmal AMD gesagt der IPC uplift von Zen 4 (oder 3?) zu Zen 5, soll größer als von Bulldozer zu Zen 1 (40%)?!
Nein, AMD selbst hat noch garnichts konkretes zu Zen5 gesagt.

Außerdem war der IPC uplift bei Zen 1 ggü. Excavator am Ende offiziell über 50%. Das halte ich für extrem unwahrscheinlich, wenn sogar RGT "nur" von 22-30% ggü. Zen4 spricht.

[latiose88]

nun das kann schon stimmen,wenn Zen 4 zu Zen 5 40 % wären,dann hieße es ja von Zen 4 auf Zen 5 20 % Mehrleistung.Das ist realistisch und joa das wäre echt was.Aber damit würde es dennoch weit weniger Mehrleistung haben als manche Erwartet hätten.Scheinbar kann man nicht mehr so viel mehr Steigern ,weil ist bestimmt auch teuer um mehr zu erreichen.Hier scheint wohl auch auch die Fläche nicht groß genug zu sein um noch mehr zu erwarten.Wer weis vielleicht wird ja der Chip auch größer,trotz Shrink.Das ist alle gut möglich.Ist halt nur ne Theorie.

[Langlay]

wenn Zen 4 zu Zen 5 40 % wären,dann hieße es ja von Zen 4 auf Zen 5 20 % Mehrleistung..

https://abload.de/img/giphymddr4.gif

[latiose88]

Achso ups Es waren ja von 50 % gewesen und keine 40 % naja so kann man sich halt mal irren.

[KarlKastor]

Die Posts werden immer wirrer.

[latiose88]

Ja ich gebe zu ich habe wohl ein Gerücht mit dem anderen zusammen gemischt gehabt. Das eine gesucht besagt das Zen 5 so viel sein soll wie von Bulldozer zu Zen 1 was ja 50 % sind und dann das andere Gerücht 40 % auf Zen 3. Naja ich scheine die wirklich durcheinander gewürfelt zu haben. Und dabei kam es dann wirr rüber.

Ich finde halt das mit den 40 % von Zen 3 aus plasiebler weil Zen 4 hat ja schon 20 % mehr als Zen 3. Also ist das schon korrekt.

[robbitop]

Die Zeit, wo AMD einfach Schlag auf Schlag an Intel heran bzw. vorbeigezogen ist, ist definitiv vorbei. Intel musste von Zen 1 bis Zen 3 alles mit Skylake bekämpfen, danach haben sie erst mit Rocket Lake wieder gleichgezogen und sind mit Golden Cove an AMD vorbei, inklusive an Zen 4. Intel hat soll mit Arrow Lake (?) eine komplett neue Architektur im Ofen haben. Ich hoffe nur, dass AMD ihren Kurs aufrecht erhalten kann. Ein grober Schnitzer und sie könnten wieder auf die Verliererstraße geraten wie damals gegen Conroe. Zumindest auf dem Desktop, im Server scheint AMD mir dagegen zu fest im Sattel zu sein.
Naja nur Raptor Cove (nicht Golden Cove!) schlägt Zen 4 und auch nur hauchdünn. Mit x3D wird man zumindest in Spielen einen gesunden Sprung nach vorn machen. Und auch Golden Cove hatte mit Zen 3x3d auch ordentlich zu knabbern.

Ja Intel legt jetzt auch wieder regelmäßig neue uArchs vor. Aber: die Situation um AMD ist nun eine andere. Dort wird nicht mehr gepennt und rumgepimmelt und bescheuerte Experimente gemacht. Da ist alles auf Execution getunt (jetzt könnte man mit der Zen4 Verschiebung argumentieren aber das lag auch stark an externen Dingen wie der Pandemie und der Entwicklung der DDR5 Preise und Verfügbarkeit). Was an neuen Sachen nicht bis zur Deadline fertig ist kommt konsequent nicht mehr in den jeweiligen Core sondern muss zum nächsten warten.
Intel hat natürlich 10x so viel Ressourcen wie AMD. Aber ich erwarte ehrlich gesagt ein Schlag auf Schlag Abtausch. Es sei denn es gibt einen CEO Wechsel der schlecht ausgeht.
Selbst wenn AMD mal eine uArch verkacken sollte geht man davon nicht mehr unter. Und es ist dann auch nicht so als wenn man dann einen größeren Rückstand aufholen müsste. Die Ingenieure sind auf beiden Seiten die talentiertesten der Industrie die sicherlich auch gut informiert bleiben. Wenn man dann die nächste uArch aufsetzt kann man die Targets höher setzen weil das Transistorbudget dank dann wieder neuerer Fertigungsprozesses wieder größer ist.
Das war für AMD zu Zen vor allem so schwer, weil man so ausgeblutet war und auch erstmal die ganze Organisation neu aufbauen musste und alte kleinkarierte Denkmuster dank Jim wegfegen musste. Und aufgrund der anfangs anämisch kleinen Truppe konnte man mit dem Zeitbudget eben nicht alles in Zen 1 einbauen was man wollte. Man musste dann auch auf execution umstellen. Jetzt hat man ja mehrere leapfrogging teams. Solange man da nicht locker lässt, sehe ich AMD nicht in Gefahr wenn man mal eine Gen versemmelt.
Ich habe auch den Eindruck, dass die Entwicklung fokussierter ist als zuvor. Verbesserungen werden validiert bevor sie implementiert werden. Ein bulldozer würde es in der Form nicht mehr so wahrscheinlich geben. Auszuschließen ist sowas natürlich nie.

Aber ja: Intel ist aufgewacht (das war ja klar weil AMD seit Zen immer gefährlicher wurde) und nun muss man mit einem Gegner konkurrieren, der wieder regelmäßig abliefert und nachlegt.

Ich nenne das gesunden Wettbewerb, der für uns Endkunden super ist. Solange der Schlagabtausch ungefähr auf Augenhöhe bleibt.

[latiose88]

Naja auch bei Anwendung ohne spielen ist Intel nur minimal vor AMD. Das ist noch lange keine ausrede. Intel kann sich nie mehr wieder ausruhen auf dem Punkt wo es mal war. Was sind schon 7 % Vorsprung. Diese kann man bei CPU relativ schnell übertreffen. Für mich sind das keine Welten mehr dazwischen. Und Intel hat es auch nur dank extremer Taktraten geschafft aber nicht durch reine ipc Steigerung. Das wird mit der nächsten Generation wohl anderst laufen. Für AMD ist es jedoch gut so.

Selbst wenn sie die Desktop mal versemmln sollten, haben sie ja noch die Server sparte und der Konsolen Deal wo sie auch dann noch Geld machen wenn der mainstream scheitern sollte. Darum geht es ja auch jetzt amd besser als Intel. Also bei den wirtschaftlichen aussichten gesehen.

[robbitop]

Auch die Sparten hängen an der Güte der IP die AMD vorzuweisen hat. :)

[w0mbat]

Zen 4 ist sowohl Alder Lake (Golden Cove) als auch Raptor Lake (Raptor Cove) deutlich überlegen. Man muss sich ja nur einmal die benchmakrs anschauen: der 16 Kerner 7950X schlägt den 24 Kerner 13900K und verbraucht dabei über 20% weniger Energie. Und dank Chiplet-Architektur ist er auch in der Produktion günstiger.

Schneller - Effizienter - Günstiger
Besser geht es nicht für AMD. Intels großes Problem ist, dass ihre P-Kerne zwar wirklich schnell sind (sieht man im ST, wo man leicht vor AMD liegt), aber eben auch rießig groß sind und extrem viel Energie verbrauchen. Die E-Kerne sind mMn deutlich besser, aber im ST halt auch sehr viel langsamer. Mehr als acht P-Kerne lassen sich für Intel schwer handhaben und man kann zwar viele E-Kerne für MT-Leistung dran pflanzen, ändert aber nichts an der Flächen- und Energieinffizienz des Gesamtsystems.

AMD ist aktuell in der deutlich besseren Position und mit Zen 5 kommt wohl eine größere architektonische Änderung, während es bei Intel einen Raptor Lake refresh geben wird und Meteor Lake für mobile.

Klar, vielleicht ist Zen 5 voll der Reinfall und MTL extrem gut, aber wenn dem nicht so ist, bekommt Intel immer mehr Problem. Zen 4 X3D wird auf jeden Fall Intels letzte Bastion, gaming, angreifen. Und wenn man bedenkt, dass Zen3D vor dem RPL launch an der Spitze war, hatte Intel jetzt gerade mal vier Monate auf dem Thron.

[ryan]

Zen 4 ist sowohl Alder Lake (Golden Cove) als auch Raptor Lake (Raptor Cove) deutlich überlegen. Man muss sich ja nur einmal die benchmakrs anschauen: der 16 Kerner 7950X schlägt den 24 Kerner 13900K und verbraucht dabei über 20% weniger Energie. Und dank Chiplet-Architektur ist er auch in der Produktion günstiger.



Es sind keine 24 Golden Cove Kerne. Wenn du Zen 4 als besser darstellen lassen willst, musst du das etwas anders angehen. In Anbetracht der Tatsache, dass Zen 4 mit einem fullnode Vorsprung läuft, erscheint mir Golden Cove nicht so schlecht.


AMD ist aktuell in der deutlich besseren Position und mit Zen 5 kommt wohl eine größere architektonische Änderung, während es bei Intel einen Raptor Lake refresh geben wird und Meteor Lake für mobile.



Das wird AMD typisch wieder sehr rosig gesehen. Zen 5 kommt in 2024 und nicht in 2023.

[w0mbat]

Ich habe in meinem Text speziell P- und E-cores angesprochen, verstehe deinen Hinweis auf Kernanzahl daher nicht. Zumal die Raptor Lake P-cores auf Raptor Cove basieren, und nicht auf Golden Cove.
Und in deinem zweiten Zitat habe ich doch sehr eindeutig einfach über die nächste Generation gesprochen. Auch hier ist dein Hinweis auf zeitliche Unterschiede seltsam. Das hat nichts mit "AMD typisch rosig" zu tun.

Mein Beitrag war faktisch korrekt, ist auch für dich i.O. ihn einfach mal so stehen zu lassen, ohne "Intel typisch" sich angegriffen zu fühlen ;)

Aber klar, ein RPL-refresh sollte Ende 2023 kommen und damit deutlich vor Zen 5. Wenn Wir Glück haben wird es doch relativ schnell noch einen 6P MTL für den Dekstop geben, mal schauen.

[ryan]

Ich habe in meinem Text speziell P- und E-cores angesprochen, verstehe deinen Hinweis auf Kernanzahl daher nicht.


Du hast explizit Golden Cove und Raptor Cove gennant und dabei von 24 Kernen gesprochen.



Und in deinem zweiten Zitat habe ich doch sehr eindeutig einfach über die nächste Generation gesprochen. Auch hier ist dein Hinweis auf zeitliche Unterschiede seltsam. Das hat nichts mit "AMD typisch rosig" zu tun.


Du stellst Zen 5 gegen Raptor Lake refresh und MTL (der womöglich gar nicht für Desktop erscheint). Das ist eine rosige Sichtweise. Wir kennen weder den genauen Erscheinungstermin von Zen 5 noch den Erscheinungstermin von ARL.

[iamthebear]

Zen 4 ist sowohl Alder Lake (Golden Cove) als auch Raptor Lake (Raptor Cove) deutlich überlegen. Man muss sich ja nur einmal die benchmakrs anschauen: der 16 Kerner 7950X schlägt den 24 Kerner 13900K und verbraucht dabei über 20% weniger Energie. Und dank Chiplet-Architektur ist er auch in der Produktion günstiger.

Die Idee dahinter ist:
1 P Core kann 2 Threads abarbeiten (SMT)
2 E Cores können auch 2 Threads abarbeiten bei weniger Platz/Energiebedarf

Man sollte also CPUs mit gleicher Threadanzahl vergleichen

Was die Kosten angeht so sind diese bei Intel deutlich geringer weil man eine eigene Fertigung hat.

Bei Intel ist ein großer Posten die Forschung. Das sind Fixkosten.
Die Fertigung ist ein relativ kleiner Posten vor allem in einem fallenden Markt wo die Fabs ohnehin teilweise leer stehen.

AMD hat was die Fertigung angeht keine Fixkosten für die Forschung, bekommt diese allerdings anteilig von TSMC auf die Waferkosten drauf geschlagen inkl. einer fetten Marge für den Gewinn.

[w0mbat]

Die Idee dahinter ist:
1 P Core kann 2 Threads abarbeiten (SMT)
2 E Cores können auch 2 Threads abarbeiten bei weniger Platz/Energiebedarf
Versuchst du gerade echt mir die Idee hinter big.LITTLE zu erklären? Wir sind hier im 3DC, nicht auf ComputerBILD ;)

Man sollte also CPUs mit gleicher Threadanzahl vergleichen
Wieso soltle "man" dass?


Was die Kosten angeht so sind diese bei Intel deutlich geringer weil man eine eigene Fertigung hat.
Ich verstehe dein Argument, wäre damit aber sehr vorsichtig. Man muss sich ja nur mal die Margen von Intel und AMD anschauen. Intel muss die ganzen Entwicklungskosten selber schlucken und Raptor Lake hat ein ca. 260mm² großes monolitisches die, was verglichen mit zwei ca. 70mm² Zen4-CCDs + 125mm² 7nm I/O-die viel teuer in der Produktion ist.

Dazu kommt dann noch, dass AMD die CCDs über verschiedene Produktgruppen hinweg nutzt, Intel damit aber aktuell nur 13900, 13700 & 13600K bedient. Der Kostenvorteil liegt eindeutig bei AMD, und nicht bei Intel wie du behauptest.


Bei Intel ist ein großer Posten die Forschung. Das sind Fixkosten.
Die Fertigung ist ein relativ kleiner Posten vor allem in einem fallenden Markt wo die Fabs ohnehin teilweise leer stehen.

Die Kosten fallen aber trotzdem an und man muss diese auch in die Produktionskosten mit einrechnen.


AMD hat was die Fertigung angeht keine Fixkosten für die Forschung, bekommt diese allerdings anteilig von TSMC auf die Waferkosten drauf geschlagen inkl. einer fetten Marge für den Gewinn.
Klar hat AMD auch Fixkosten für die Fertigung, viele neue Technologien werden in Kooperation mit TSMC entwickelt. Ist bei so engen Partnerschaften immer so.

[latiose88]

Wenn man es genau nimmt dann sind es 16 e Kerne und 8 mit ht 32 Threads und keine 24 Threads.Wenn man schon vergleicht dann richtig.Sonst könnte man ja auch behaupten 16 Thrads AMD bei einem 16 Kerner.
Da würden gewiss beide an Leistung verlieren wenn man bei Intel HT und bei AMD SMT abschalten würde.Am ende sind sie sich dennoch sehr nahe.
Nur das halt AMD um einiges Sparsamer ist bei Multicore.Bei idle ist jedoch Intel der Gewinner.Man muss immer die Pro und Contra sehen.
Sicher ist das Intel mit einem Refresh daher kommen wird.Damit wird Intel an Leistung heraus holen können,aber es wird abstriche bei den Kernanzahl geben. Und das ist klar Intel kann mit einem 6 P mit 16 E Kernen nichts zerreisen also fällt zurück.
Selbst wenn Intel da drauf IPC drauf hauen sollte von 15% ist er immer noch langsamer.Dueliert sich bestimmt dann mit einem 12 Kerner von Zen 5.Da hilft die IPC Steigerung garnix wenn Kerne weniger werden.Aber eines ist klar,die Intel CPUS werden deutlich sparsamer werden.ABer gegen AMD kommen sie dennoch bei Leistung pro Watt keinen Stich machen.

Und das wird am Ende bei den kosten beide gleich dastehen.AMD spart durch die Kleineren Chips Geld ein.Muss zwar bei TSMC Geld zahlen aber aufgrund der kleineren CPUS spart sich AMD was ein.Oder kann halt mehr davon Produzieren.Es gleicht sich echt aus.
Intel mag zwar ne eigene Fabs haben,diese kosten jedoch Unterhalt wie Strom und Wartung sollte mal was sein.Klar kann das interen Produzieren dies wieder etwas ausgleichen aber nicht alles.

Auch Intel wird das ganze was kosten.Zumal Wirtschaftlich Intel angeschlagen ist.Um dies zu Fertigen braucht Intel auch viel mehr Mitarbeiter,als ob die Umsonst arbeiten würden.Was AMD ja nicht braucht.

Ich betrachte also das gesammte.Dürften sich also beide nix nehmen.

Klar ist so spannend bei CPU war es schon lange nicht mehr.Es kann nur gut für uns alle sein der Schlagabtausch.
Und je nach Usercase ist das eine oder andere im Vorteil.Wer also nur 3-4 Stunden Vollast hat bei CPU hat schon mal beim Stromverbrauch AMD als Gewinner.Bei 1 Stunde Vollast und anonsten nur Idle wäre Intel wohl die bessere Wahl,auch wenn es Stromkosten bei Last nicht gut ist.

So war bei meinen Tests der 13900k bei 350 Watt gewesen.Der 7950x auf 200 Watt Vollast.Idle kann AMD aufgrund des IO DIE leider nicht gut Punkten. So war es mir nicht möglich gewesen den 5950x auf unter 20 Watt im Idle zu bringen.Der 7950x kann leider bei Spannung nur noch wenig gesenkt werden und damit würde ich bei dieser CPU weit weniger Strom einsparen können.

Ich hoffe AMD löst diese Problem durch Tricks,weil ich will ja beide Vorteile haben,idle und MC Last und so.
So kann ich mich also nur zwischen gute Idle oder gute Multore Last sparsamkeit Entscheiden.
Ist irgendwie unbefriedigend,aber was kann man da schon machen.Klar könnte ich nun einen 8 Kerner von AMD nehmen und da die Vorteile bei Idle haben,aber dann würde ich jedoch die Multicore Leistung Verlieren.

Wie es weiter gehen wird bei AMD das wird sich zeigen.Ich habe auch was von 2024 gelesen.ALso noch 1 Jahr warten.Mich stört das nicht,weil hatte ja eh vor erst 2025 einen neuen Pc zusammen zu bauen.Dann ist mein Pc 5 Jahre alt,aber im grund wenn man es genau nimmt auch noch kein richtiges Alter für einen Pc.Die meisten werden wohl 10 Jahre alt wohl als richtig ALt bei PC sehen.

Jedoch je nach dem wie gut sich das ganze Entwickelt kann es mich durchaus zum Aufrüsten animieren.Kommt allerdings auf das Gesammte drauf an.

[amdfanuwe]

Was die Kosten angeht so sind diese bei Intel deutlich geringer weil man eine eigene Fertigung hat.

Bei Intel ist ein großer Posten die Forschung. Das sind Fixkosten.
Die Fertigung ist ein relativ kleiner Posten vor allem in einem fallenden Markt wo die Fabs ohnehin teilweise leer stehen.

Wie kommst du denn darauf?
Meinst du, nach interner Verrechnung wollen die FABs keinen Gewinn ausweisen?
Und die Fixkosten für die FABs teilen sich auf die Intel Produkte auf, ebenso wie TSMC die Kosten auf die Produkte aufteilet.
Nur hat TSMC mehr Kunden, die sie auch noch bei neuen Techniken unterstützen und die Kunden können über den Preis verhandeln.
Zudem rechnet sich eine FAB auch nur, wenn sie ausgelastet ist.
Deshalb auch Intels Bemühungen als Fertiger aufzutreten.

Also eher Advantage TSMC.
Mal sehen, ob Intel noch die Kurve kriegt.

[robbitop]

TSMC zieht mittlerweile utopische Margen. Pro mm2 wird ein top notch tsmc Prozess sicherlich nicht günstig sein. Wäre nicht überrascht wenn Intel das intern billiger bekommt.

[w0mbat]

Intels Margen sind da relativ eindeutig ;)

[Der_Korken]

Zen 4 ist sowohl Alder Lake (Golden Cove) als auch Raptor Lake (Raptor Cove) deutlich überlegen. Man muss sich ja nur einmal die benchmakrs anschauen: der 16 Kerner 7950X schlägt den 24 Kerner 13900K und verbraucht dabei über 20% weniger Energie. Und dank Chiplet-Architektur ist er auch in der Produktion günstiger.


Bei Volllast-Verbrauch und Produktionskosten magst du Recht haben, beim Rest sehe ich aber nicht wo Zen 4 deutlich überlegen sein soll. Selbst bei den Kosten sollte man bedenken, dass ein 7700X z.B. den vollen 120mm² 6nm IOD mitschleppen muss. Ein 13600K ist zwar >200mm² groß, aber nur in Intels N7-Äquivalent (10nm) und inklusive bereits deaktivierter Einheiten (6+8 alleine wäre kleiner). Bei AMD kommen noch 70mm² in 5N dazu. Ich weiß nicht, ob das so viel billiger ist. Der 7950X schon eher, weil AMDs Kerne klein und der SoC riesig ist (bei Intel ist es eher andersrum).

Ansonsten ist Raptor Cove wie du schon sagst bei ST leicht vorne. Aber auch die B-Noten wie Idle-Verbrauch und Teillast-Effizienz sehe ich eher bei Intel.

Mehr als acht P-Kerne lassen sich für Intel schwer handhaben und man kann zwar viele E-Kerne für MT-Leistung dran pflanzen, ändert aber nichts an der Flächen- und Energieinffizienz des Gesamtsystems.


Für Server mag das ein Problem sein, aber für Consumer sehe ich nicht wo die Limitierung auf 8 P-Cores in den nächsten Jahren ein großes Problem darstellen sollte. Ich finde eher, dass Intels Trennung von P- und E-Cores hier perfekt in das Anforderungsprofil von Normalnutzern fällt. Selbst den damals spekulierten 6+16-MTL hätte ich ziemlich attraktiv gefunden, denn wenn ich wirklich mehr als 6 Kerne brauche, dann ist die Arbeit normalerweise so gut parallelisiert (oder zumindest so heterogen), dass man überschüssiges auf die E-Cores schieben kann, ohne dass diese irgendeinen Main-Thread auf den P-Cores ausbremsen. Für Server muss Intel sich natürlich was einfallen lassen.

AMDs Position ist in sofern komfortabel, dass sie für die Server-Märkte mit hohen Margen die wesentlich bessere Architektur haben. Aber "deutlich überlegen" würde ich das nicht nennen.

[Windi]

TSMC zieht mittlerweile utopische Margen. Pro mm2 wird ein top notch tsmc Prozess sicherlich nicht günstig sein. Wäre nicht überrascht wenn Intel das intern billiger bekommt.

AMD nutzt aber meist nicht die neuste Technik.
Apple war letzens anderthalb Jahre früher dran, mit deutlich größeren DIEs.
Mit den winzigen Chiplets (die ruhig ein paar Fehler haben dürfen und dann teildeaktiviert verwendet werden können) hätte AMD 2 Jahre früher sein können. Aber sie setzen halt eher auf den Mainstream.

TSMC hat so viele Kunden, da machen die kleinen Chiplets von AMD kaum etwas aus. Deshalb glaube ich auch nicht, das AMD so viel für die Fertigung bezahlt.

[Zossel]

TSMC hat so viele Kunden, da machen die kleinen Chiplets von AMD kaum etwas aus. Deshalb glaube ich auch nicht, das AMD so viel für die Fertigung bezahlt.

???????????????????????????????????????????

[davidzo]

Die Zeit, wo AMD einfach Schlag auf Schlag an Intel heran bzw. vorbeigezogen ist, ist definitiv vorbei. Intel musste von Zen 1 bis Zen 3 alles mit Skylake bekämpfen, danach haben sie erst mit Rocket Lake wieder gleichgezogen und sind mit Golden Cove an AMD vorbei, inklusive an Zen 4.
Das sehe ich nicht so.
Zen4 umfasst auch X3D CPUs, das darf man nicht vergessen. AMDs Namensschema ist unglücklich und sollte eine Stelle nach unten korrigiert werden (R7 => i5, R5 => i3), oder zumindst Threadgleiche CPUs gegeneinander gestellt werden. Aber wenn man die preislichen Konkurrenten nimmt ist Zen4 in fast allen Metriken absolut Konkurrenzfähig zu RKL:
MT Performance
ST Performance
Gaming Performance
Energy efficiency

Intel hat sich diesen Gleichstand aber extrem teuer erkauft. Der DIE ist groß, die Fertigung teuer und die Margen im Keller. Die Verteuerung der Rohstoffe und Energie trägt ihr übriges dazu bei die Kostenstruktur weiter zu verschlechtern.
Ein offensichtliches Problem ist auch der ausufernde Stromverbrauch durch die breite Architektur in veralteter Fertigung. Das bedeutet dass sich die Ergebnisse auf dem Desktop nur schwer in den Mobile übertragen lassen werden, wo AMD mit Dragon und Phoenix die besseren karte in der Hand hält. Nebenbei werden auch OEM-PCs niemals die Leistungen erreichen die in Bench-Maschinen gemessen wurden, was das Image von Intel im channel nachhaltig schädigen könnte.

Für Erbsenzähler und Anleger waren die Skylake-Generationen hervorragendend gewirtschaftet, Golden Cove dagegen ist eine totale Katastrophe. Pat kann da nur die Stange halten indem er mit zurückgewonnenen Marktanteilen argumentiert.

ZEN4 als Chiplet Architektur ist einfach wirtschaftlicher herzustellen.

Und das wird einer der Hauptgründe sein wieso man drängt MTL in den markt zu erlassen selbst wenn die internen Performanceziehle nicht erreicht werden. Die Chiplet-Architektur von MTL und ARL sind im Moment Intels größte Hoffnung auf eine erneuerte Profitabilität in der Fertigung und das wissen auch die Anleger. Alleine schon um die Anleger zu beruhigen wird man deswegen MTL launchen müssen.

Leider ändert auch das pünktliche Erscheinen von Golden Cove nichts am fehlenden Track record von Intels neuer Fertigung bzw. Produktlaunches. GLC war ein Refresh und MTL hat völlig andere Vorraussetzungen.
Bloß weil es nach Alderlake plötzlich schlag auf schlag ging bei Intel, würde ich nicht so optimistisch sein und das als das neue normal annehmen. Ich halte es für realistischer weiterhin von erheblichen Verzögerungen und Underperformance neuer Nodes bei Intel auszugehen.


Was die Kosten angeht so sind diese bei Intel deutlich geringer weil man eine eigene Fertigung hat.

Lass uns doch mal auf die Zahlen gucken:

Die Rohertragsmarge (englisch gross margin) bedeutet klipp und klar Kosten der Produktion, ohne jegliche Investitions- und Entwicklungskosten. Die lag bei Intel Jahrzehntelang bei 60% und mehr, aber im Q4 2022 nur noch bei 39% und bei AMD bei 43%. Beide sind gesunken, aber bei Intel ist sie im langfristigen zeitlichen Ablauf im absoluten Keller.
Wenn man jetzt die Investitionskosten mit hineinrechnet kommt Intel auf eine operative Marge von -8,2% während AMD auf -3% kommt. Beide befinden sich also wie man sieht in einer Investitionsphase bzw. auch einer Konjunkturschwäche des PC-Marktes.

Bei Volllast-Verbrauch und Produktionskosten magst du Recht haben, beim Rest sehe ich aber nicht wo Zen 4 deutlich überlegen sein soll.

Wie gesagt, ZEN4 läuft eh noch mit angezogener Handbremse, der DIE ist aber auf 3D V-Cache schon vorbereitet. Damit gewinnt Zen4 dann wohl gaming recht deutlich. Zen4 mag dann nicht in allen Benchmarks (ST?) die beste Leistung haben, ist aber sehr ausgewogen und sehr modular, bietet avx512 im Desktop, etc.
Es ist schon eine Leistung wenn ein in vielen Bereichen nur 2/3 oder gar halb so breiter Core eine ähnliche End-performance aufweist wie ein fetter Golden Cove Core. Der wesentlich geringere Energiebedarf zeigt ja auf dass Golden Cove anscheinend viel potential auf dem Tisch lässt, oder einfach auch durch die veraltete Fertigung gebremst wird.

[Windi]

Natürlich wird AMD einiges an TSMC zahlen. Die werden sicher nichts geschenkt bekommen.

Aber ich glaube nicht daran, das die kleinen CPU-Chiplets so unglaublich viel Geld in die Kassen von TSMC spülen.
Da gibt es ganz andere Kunden, die viel mehr Wafer als AMD bestellen. Auch sind die Teils deutlich früher dran.

Das ist halt der Vorteil von TSMC. Nicht ein Kunde allein muss den ganzen Gewinn erwirtschaften oder die gesamten Forschungskosten tragen. Wer dort in der Masse mit schwimmt, wird nur einen kleinen Teil der Kosten übernehmen müssen.

[Zossel]

Aber ich glaube nicht daran, das die kleinen CPU-Chiplets so unglaublich viel Geld in die Kassen von TSMC spülen.
Da gibt es ganz andere Kunden, die viel mehr Wafer als AMD bestellen. Auch sind die Teils deutlich früher dran.

AMD ist einer der großen Kunden von TSMC, neben z.b. Qualcomm und Apple.

[latiose88]

@davidzo

Was heißt denn die Abkürzung GLC, etwa golden cove?

[HOT]

Intel hat mit einem monolithischen Die in einem bewährten Prozess nen Stich gelandet und schon sind sie wieder vorne? Komische Diskussion... Was ist mit mobile, server, ponte veccio? Nichts als Verzögerungen, schlechte Produkte... Und die Monolithen sind obendrein noch teuer, wie schon ausgeführt.

[Windi]

AMD ist einer der großen Kunden von TSMC, neben z.b. Qualcomm und Apple.

Das Beste was ich gerade gefunden habe:
https://www.computerbase.de/2021-03/tsmc-umsatz-apple-amd-huawei/

Ja, aber 10% halte ich nicht für sehr viel. Und dabei sind auch noch GPUs und Konsolenchips, die viel größer und teurer sind. Selbst wenn AMDs CPU Sparte weiter wächst, dürften sie noch eine Weile unter der 10% Marke bleiben.

Es ging ja um die Fertigungskosten der CPUs und da hilft es AMD sicherlich, das sie nur einen kleinen Teil der Forschungskosten von TSMC einbringen müssen.

[latiose88]

@hot

Ja bei einer sparte haben sie mal nen Stich gemacht aber es nützt Intel nix weil wenn es gut gewesen wäre hätte Intel keinen so massiven Einbruch erlitten gehabt.
Muss sogar Mitarbeiter entlassen. Wenn es gut wäre, wäre so ein Schritt nicht nötig gewesen. Es zeigt also ein klares Bild das ganze ab.
Kann man ja auch bei kämpfen so sehen. Nur weil wer mal getroffen hat, hat dieser Person noch lange nicht den Kampf gewonnen. So sehe ich das.

@windi bezog sich die 10 % also auf cpu und gpu? Also bei CPU ist AMD momentan bei 18 %, bei gpu stimmt es allerdings mit den 10 % Marktanteil. Also so. Schlecht geht es AMD also doch nicht wie du so geschrieben hast. Und hat ja auch weniger personal und somit weniger Unterhaltskosten an sich gegenüber Intel. Also kommt AMD mit weniger Geld weiter als Intel und selbst wenn AMD mal nur die Hälfte von dem was Intel zu Hochzeiten mal Umsatz gemacht hätte machen würde, könnten AMD weit mehr Geld zusammen bekommen als es Intel könnte. Aber nur in der therorie.

[HOT]

Das Beste was ich gerade gefunden habe:
https://www.computerbase.de/2021-03/tsmc-umsatz-apple-amd-huawei/

Ja, aber 10% halte ich nicht für sehr viel. Und dabei sind auch noch GPUs und Konsolenchips, die viel größer und teurer sind. Selbst wenn AMDs CPU Sparte weiter wächst, dürften sie noch eine Weile unter der 10% Marke bleiben.

Es ging ja um die Fertigungskosten der CPUs und da hilft es AMD sicherlich, das sie nur einen kleinen Teil der Forschungskosten von TSMC einbringen müssen.

Voooorsicht, das sind Umsätze.
1.) hat AMD eher günstige Verträge und
2.) nutzt AMD keine state-of-the-Art-Prozesse, das fängt jetzt erst mit N4 bei Phoenix so langsam wieder an.

Wenn Apple 1/4 des Umsatzes ausmacht ist das in 21 N5(P) gewesen, AMD war nur (ausschließlich) mit N7 unterwegs (Rest war ja GloFo!). Heute ist AMD mit N6 und N5 zusätzlich unterwegs. Die werden damals schon einen Großteil der N7-Fertigung belegt haben.
Auch bei Mediatek und Qualcomm wird der Umsatz die Stückzahlen ordentlich verzerren, den auch die hatten Produkte in Top-Prozessen aktiv.

[robbitop]

Naja Zen 4 und RDNA3 sind ja schon N5P. Das ist doch leadijg edge. N4 ist doch dieser halfnode der auch noch costouts mitbringt so wie 6 nm zuvor.

[Windi]

Voooorsicht, das sind Umsätze.
Ja, ich weiß, aber leider hatte ich keine besseren Zahlen gefunden.

1.) hat AMD eher günstige Verträge und
2.) nutzt AMD keine state-of-the-Art-Prozesse, das fängt jetzt erst mit N4 bei Phoenix so langsam wieder an.

Wenn Apple 1/4 des Umsatzes ausmacht ist das in 21 N5(P) gewesen, AMD war nur (ausschließlich) mit N7 unterwegs (Rest war ja GloFo!). Heute ist AMD mit N6 und N5 zusätzlich unterwegs. Die werden damals schon einen Großteil der N7-Fertigung belegt haben.
Auch bei Mediatek und Qualcomm wird der Umsatz die Stückzahlen ordentlich verzerren, den auch die hatten Produkte in Top-Prozessen aktiv.
Genau das habe ich doch gesagt. AMD hat eher günstige Verträge, weil sie bis jetzt nicht die allerneuste Technik verwenden. Und deshalb müssen sie nicht so viel von den Forschungskosten mittragen, wie es andere Unternehmen vielleicht tun.

Ich glaube aber nicht daran, das AMD Anfangs einen Großteil der 7nm Fertigung ausgelastet hat. Nicht nur Apple hatte schon deutlich vor AMD 7nm verwendet. Damals gab es viele Meldungen, das alle möglichen Smartphone-, Bitcoin-, und Spezial-Chips in 7nm gefertigt wurden. Da war AMD einfach nur einer von vielen weiteren. Außerdem mussten Anfangs nur die kleinen CPU-Chiplets gefertigt werden, das war wohl keine Herausforderung für TSMC.

[HOT]

Richtig. Anfangs natürlich nicht, da war N7 ja auch das Beste, was man buchen konnte. Aber seit Zen3 und RDNA2 wird man schon viel von N7 belegt haben. Da wurden ja auch die Konsolen in maximalen Massen produziert.
Und N5 würd ich nicht als bleeding edge sehen. N5P wird ja wenn dann sowieso wieder nur für RDNA3 genutzt. Auch das Zen5-CCD wird ja offenbar wieder nicht auf N3 setzen sondern auf N4, vielleicht N4X. AMD wird irgendwann wieder bei bleeding edge ankommen, weil die Prozesszyklen schlichtweg länger werden.

[robbitop]

Ich finde nichts offizielles dazu. Aber AMD sagte eine "enhanced version of 5nm". Das und, dass die Description von TSMC bei N5P diese als "N5 Performance enhanced version" tituliert lässt N5P als wahrscheinlicher für Zen 4 dastehen IMO.

[HOT]

Ich finde nichts offizielles dazu. Aber AMD sagte eine "enhanced version of 5nm". Das und, dass die Description von TSMC bei N5P diese als "N5 Performance enhanced version" tituliert lässt N5P als wahrscheinlicher für Zen 4 dastehen IMO.
AMD hat auch N7 damals an seine Bedürfnisse angepasst. Nur N10 war N7P. Das wird bei N5 ähnlich sein. Ich glaub nicht, dass AMD N5P überhaupt nutzt. Ich denke, das wird alles ein teil-customisierter N5 sein, genau wie NVs 4N.

[robbitop]

Ich würde sagen, man weiß es nicht sicher. Vergangenheit ist nicht immer repräsentativ für die Gegenwart oder Zukunft. :)

[latiose88]

Das liest sich ja nur als Mini Sprung und kein großer. Oder ist die fertigung minimal schärfer dann von n5 zu n4 zu wechseln?

[robbitop]

4 nm ist kein extrem großer Sprung ggü 5nm. Aber man braucht auch nicht immer einen großen Sprung in der Node. Wenn das Design selbst deutlich mehr Perf/W bringt.
Zen 3 hatte ja auch nur den gleichen node wie Zen 2 und war doch deutlich schneller pro Core. Oder Alderlake und Rocketlake nutzten noch immer 10 nm wie auch Tigerlake und Icelake.

[Zossel]

Das Beste was ich gerade gefunden habe:
https://www.computerbase.de/2021-03/tsmc-umsatz-apple-amd-huawei/

Ja, aber 10% halte ich nicht für sehr viel.

Reicht aber nach den Daten aus dem Link für den 2. Platz nach Apple.

[davidzo]

4 nm ist kein extrem großer Sprung ggü 5nm. Aber man braucht auch nicht immer einen großen Sprung in der Node. Wenn das Design selbst deutlich mehr Perf/W bringt.
Zen 3 hatte ja auch nur den gleichen node wie Zen 2 und war doch deutlich schneller pro Core. Oder Alderlake und Rocketlake nutzten noch immer 10 nm wie auch Tigerlake und Icelake.


Wenn die Gerüchte mit 25mrd Transistoren stimmen wäre das eine massive Steiegrung bei der Density: https://www.techpowerup.com/303245/amd-ryzen-7040-series-phoenix-point-mobile-processor-i-o-detailed-lacks-pcie-gen-5#:~:text=Built%20on%20the%204%20nm,transistor-count%20of%2025%20billion.

Ich halte das Gerücht aber aus Gründen für Unsinn.
Weder die Kerne (+58% Transistoren zwischen Zen3 und Zen4), noch die IGP (fast identisch zur 680m) noch der SOC (immer noch 28x PCIe lanes) legen eine Verdopplung des Transistorcounts gegenüber Rembrandt nahe.
Wenn Rembrandt 13Mrd hat, dann fände ich selbst 20Mrd schon viel.

Interessant wird dann der Quervergleich zum Apple M2. Ebenfalls 8 Kerne (4big, 4little), aber nur 8T, dafür eine GPU die auf dem Papier mehr FP32 Rohleistung hat als die 680m und weniger als die 780m mit dual-issue CUs. Beide sind in einem 5nm Derivat gefertigt, beide können mit ähnlicher TDP betrieben werden.

Praktisch sind sowohl der M1 als auch M2 bisher deutlich sparsamer als der durchschnittliche 6800U und die GPU ist in den wenigen Vergleichstiteln (SOTR?) meist schneller, weil die 680m bei 15Watt ins Taktlimit rennt. Allerdings hat Apple dort sowohl den Fertigungs-Vorteil als auch fast die doppelte Menge an Transistoren auf dem Chip.

Es sieht so aus als wenn AMD auch mit TSMC 4nm weiterhin nicht an die Densities anknüpfen kann die Apple bereits in 5nm bei M2 erreicht, aber so drastisch viel größer soll der Chip nun auch wieder nicht werden (145 vs 178mm2 wenn die Gerüchte stimmen).

[robbitop]

Der Link ist ja zu Zen 4 APU nicht zu Zen 5.

Die Schlussfolgerungen, die du ziehst (rembrandt vs phoenix) habe ich für mich auch schonmal gezogen. Wird bestimmt interessant wenn wir die wahren Zahlen von AMD bekommen.

Density ist im mobile Bereich meist höher, weil dort nicht so hohe Taktraten gefahren werden. Entsprechend ist die Layoutoptimierung wohl eine andere.

[davidzo]

Der Link ist ja zu Zen 4 APU nicht zu Zen 5.


Richtig, es ging ja auch gerade um die Frage ob AMD nun Cutting Edge benutzt wenn sie Phoenix in N4 bringen. Aber ja, das ist für die Zen5 Diskussion nur von periphärem Interesse, da hast du wohl recht.

2.) nutzt AMD keine state-of-the-Art-Prozesse, das fängt jetzt erst mit N4 bei Phoenix so langsam wieder an.



Wenn Zen5 als Chiplet für den Desktop wirklich in N4 und nicht N3 kommt, dann wird es knapp mit einer großen Verbreiterung der Cores. Es sei denn der Cache schrumpft / wird ausgelagert. Der Corecount ändert sich wohl sowieso nicht, erst recht nicht in 4nm.





Density ist im mobile Bereich meist höher, weil dort nicht so hohe Taktraten gefahren werden. Entsprechend ist die Layoutoptimierung wohl eine andere.

Phoenix und der Apple M2 sind beides Mobile Prozessoren mit fast identischem Designziel (15-28Watt Klasse).

[robbitop]

Naja M2 ist auch in Tablets die keine aktive Kühlung haben wo man sustained eher deutlich unter 10 W liegt. Und die APUs haben auch SKUs bis hoch zu 45? W. Die Skalierung ist schon etwas anders. Und dazu kommen auch drastisch andere Taktraten von GPU und CPU die das schon allein erfordern - unabhängig davon ob mobile oder nicht.

[HOT]

Richtig, es ging ja auch gerade um die Frage ob AMD nun Cutting Edge benutzt wenn sie Phoenix in N4 bringen. Aber ja, das ist für die Zen5 Diskussion nur von periphärem Interesse, da hast du wohl recht.



Wenn Zen5 als Chiplet für den Desktop wirklich in N4 und nicht N3 kommt, dann wird es knapp mit einer großen Verbreiterung der Cores. Es sei denn der Cache schrumpft / wird ausgelagert. Der Corecount ändert sich wohl sowieso nicht, erst recht nicht in 4nm.
[...]

Wie kommste denn darauf? Etwas mehr Packdichte wirds ja geben und das Chiplet kann ja knapp 90mm² statt 67mm² haben. Das reicht doch dicke für Logik.

[Windi]

Reicht aber nach den Daten aus dem Link für den 2. Platz nach Apple.

Aber nur wenn ich mit Gesamt-AMD vergleiche. Wenn ich die GPUs und die Konsolen-Chips abziehe, dann lande ich deutlich unter 10%.
Und ich halte es für einen deutlichen Vorteil, wenn AMD nur für 10% der Forschungskosten zahlen muss.
Intel muss für die gesamten Forschungskosten selbst aufkommen.

[latiose88]

Ja selbst wenn es auf 100 mm² steigen würde.Ist immer noch günstiger als bei Intel und damit könnte man dann massiv die Leistung steigern.Für neue Instruktionen wird dann auch mehr Transistoren frei.Aber alleine schon der wechseln von 5n zu 4n macht etwas Platz um mehr unter zu kriegen.Wie sich AMD also entscheidet einfach alles weiter zu machen oder einfach mehr Transistoren drauf klatschen für noch mehr AVX 512 und weitere unter Instruktionen für noch bessere Auslastung der CPU,das wird sich erst noch zeigen.
Spannend wird zudem auch wieviel Real Leistung am Ende bei den jeweiligen Anwendung wirklich ankommt.Weil ja jede Anwendung sei es Games,VIdeoumwandeln usw auch Unterschiedliche Einheiten einer CPU anspricht.
Ich informiere mich jeden Tag,damit ich ja auch nix verpasse wenn es so weit ist.

[HOT]

2x 100mm² würde knapp mit dem Package. 2x 90 wird noch grade so gehen.

[Complicated]

https://overclock3d.net/news/cpu_mainboard/amd_s_said_to_become_tsmc_s_largest_5nm_customer_in_2023/1
Taiwanese media has reported that AMD is expected to become TSMC's largest 5nm customer in 2023, with expected 5nm production levels reaching 200,000 wafers in Q4 2022. AMD's Ryzen, EPYC, and Radeon product lines are all moving to TSMC's 5nm lithography node, creating huge demand for TSMC's 5nm fab space. AMD's growth has also created increased demand for AMD's products, placing more pressure on TSMC to produce enough 5nm wafers to keep up with demand, as much of AMD's growth has been limited by their production capabilities in recent years.

In 2023, AMD is expected to become TSMC's 3rd largest customer, with recently acquired companies like Xilinx and Pensando adding to AMD's already large silicon orders. AMD has presented a strong roadmap at their 2022 Financial Analysts Day, signalling increasing market share within the enterprise PC market and server markets.
Apple und Qualcomm sind wohl noch davor. Es gab aber auch Gerüchte Intel würde bei 3nm zu den Top 3 gehören. Bei 3nm gibt es scheinbar auch eine Bewegung beim Preis:
https://www.techspot.com/news/97269-tsmc-may-cut-3nm-wafer-prices-entice-amd.html
Last November, DigiTimes reported that TSMC planned to charge $20,000 per 3nm wafer – a 25 percent hike over 5nm because of the extensive EUV lithography process involved in manufacturing. Apple accepted the price increase to secure 3nm chips for its upcoming iPhone 15, but it seems other companies like AMD, Nvidia, Qualcomm, and MediaTek backed off for the time being. Apple is TSMC's main customer for N3.

The Taiwan-based company started mass-producing N3, its first 3nm process node, at the end of 2022. The more stable and efficient N3E node is expected to follow later in 2023 and may be less expensive to produce. That might enable TSMC to lower prices, but they could also cut the price of N3 if they wanted to drive larger volumes.

[Zossel]

Aber nur wenn ich mit Gesamt-AMD vergleiche. Wenn ich die GPUs und die Konsolen-Chips abziehe, dann lande ich deutlich unter 10%.

Diese Unterscheidung wirkt sehr willkürlich auch mich, kannst du den Grund dieser Unterscheidung erläutern.

Und ich halte es für einen deutlichen Vorteil, wenn AMD nur für 10% der Forschungskosten zahlen muss.
Intel muss für die gesamten Forschungskosten selbst aufkommen.

10% "Forschungskosten" zu 20% Marktanteil im X64 Markt der durch ein Duopol geprägt ist wäre ein interessanter "Vergleich". So *könnte* ein Schuh daraus werden.

Ergänzung: Hier steht 1/3 Marktanteil: https://www.reuters.com/technology/amd-wins-nearly-third-processor-market-arms-climb-slows-analyst-report-2023-02-09/

[Windi]

Diese Unterscheidung wirkt sehr willkürlich auch mich, kannst du den Grund dieser Unterscheidung erläutern.
Weil es hier doch die ganze Zeit um Intel CPUs vs. AMD CPUs geht. Und ob die Eigenfertigung von Intel billiger ist, als die Fremdfertigung von AMD.
Wenn ich hier noch GPUs, Konsolenchips und in Zukunft Xilinx mit einfließen lasse, verfälscht das doch die ganze Betrachtung.
Dann gibt es bei Intel noch dutzende andere Chips, die teilweise sogar bei TSMC gefertigt werden.


10% "Forschungskosten" zu 20% Marktanteil im X64 Markt der durch ein Duopol geprägt ist wäre ein interessanter "Vergleich". So *könnte* ein Schuh daraus werden.

Ergänzung: Hier steht 1/3 Marktanteil: https://www.reuters.com/technology/amd-wins-nearly-third-processor-market-arms-climb-slows-analyst-report-2023-02-09/
Hier sieht man doch das Problem. Es wird Gesamt-AMD mit dem Teilbereich X86 verglichen.

Die über 30% Marktanteil von AMD kommen anscheinend nur dank der Konsolenchips zu Stande, die ungefähr 1/3 ausmachen. Einem Markt, in dem Intel gar nicht aktiv ist.

[amdfanuwe]

Dann gibt es bei Intel noch dutzende andere Chips, die teilweise sogar bei TSMC gefertigt werden.

Warum nur??
Anscheinend ist Fremdfertigung billiger als Eigenfertigung.

[Zossel]

Die über 30% Marktanteil von AMD kommen anscheinend nur dank der Konsolenchips zu Stande, die ungefähr 1/3 ausmachen. Einem Markt, in dem Intel gar nicht aktiv ist.

Welche Eigenschaften haben Konsolenchips das diese nicht die Fixkosten pro verkaufter Einheit bei Intel senken könnten?

[Complicated]

Keine Ahnung warum man AMD Konsolen raus nehmen sollte und Intel alle Märkte, die AMD nicht bedient, sowieso immer schon mit enthalten waren. Intels TAM liegt deutlich über dem von AMD. z.B. bedient AMD 4-Sockel Server nicht. Nimmt auch keiner aus der Statistik. Die Idee ist schon merkwürdig. HEDT sollten wir dann auch raus nehmen und wieder rein wenn Intel wieder soweit ist?

[latiose88]

Ja das isn't ein unlogischer Gedanke. Also kann man das auch gleich alles drinnen lassen. Alles andere wäre ja unfäier Vergleich.

Diese Gedanken wäre so wie OK du bist stärker also trägst du weniger und du bist schwächer du trägst dann mehr als du eigentlich könntest.
Logisch wäre es OK du bist stärker also trägst du mehr und der andere schwächer also weniger. Aber genau dieser Gedanke wäre eben nicht drinnen wenn mann bei amd was raus nimmt und bei Intel es so lässt. Was hält eben keinen Sinn ergibt wie mein Beispiel was ich damit meinte.
Klar ist amd noch immer hinten aber da brauchen wir nicht durch statistik zusammen murksen ja nicht auch noch unterstreichen.

[Zossel]

Weil es hier doch die ganze Zeit um Intel CPUs vs. AMD CPUs geht. Und ob die Eigenfertigung von Intel billiger ist, als die Fremdfertigung von AMD.
Wenn ich hier noch GPUs, Konsolenchips und in Zukunft Xilinx mit einfließen lasse, verfälscht das doch die ganze Betrachtung.
Dann gibt es bei Intel noch dutzende andere Chips, die teilweise sogar bei TSMC gefertigt werden.


Hier sieht man doch das Problem. Es wird Gesamt-AMD mit dem Teilbereich X86 verglichen.

Die über 30% Marktanteil von AMD kommen anscheinend nur dank der Konsolenchips zu Stande, die ungefähr 1/3 ausmachen. Einem Markt, in dem Intel gar nicht aktiv ist.

Ich nehme einfach das Verhältnis der Waferfläche X64 zu Non-X64 bei Intel und AMD gleich an :-)

Angenommen, AMD bringt ARM-Chiplets die mit den bisherigen IO-Dies verbaut werden, zu was zählen dann die IO-Dies?
Oder FPGAs mit X64-Cores?

[maximus_hertus]

Die über 30% Marktanteil von AMD kommen anscheinend nur dank der Konsolenchips zu Stande, die ungefähr 1/3 ausmachen. Einem Markt, in dem Intel gar nicht aktiv ist.

Die erste Xbox hatte eine Intel CPU drin ;)

Vergesst nicht Tesla. Das sind mal eben über 1 Millionen AMD Chips (in 2022). Dazu Steamdeck und Co. Alles zusammen genommen ist das auch nicht übel (Stückzahl). Es sind nicht nur die Konsolen.

Gerade bei Tesla kann das Stückzahlen-technisch in 2023 und darüber hinaus regelrecht explodieren.

Intel hat mittlerweile ein Automotive Team, dass Dritthersteller unterstützt, damit diese ihre Chips in Intel Foundrys fertigen. Intel selbst hat anscheinend nicht die Ressourcen, um eigene APUs anzubieten bzw. gehört dazu noch mehr als nur die reine Hardware.

Am Ende ist es imo egal, in was ein x86 Chip verbaut wird. AMD zeigt, dass es in Konsolen sinnvoll geht und wenn Intel das nicht kann oder möchte, ist das ja nicht AMDs "Schuld". In allen Märkten, bei denen x86 mit im Spiel ist, hat AMD knapp 1/3 der ausgelieferten Chips geliefert.

Richtig ist aber auch, dass man natürlich nicht die Augen schließt und auch die Teilbereiche (Clients, Server, etc.) auch einzeln betrachtet, um einen Gesamtüberblick zu erhalten bzw. Trends zu erkennen.

[Complicated]

Ich glaube die Grafiken hier geben einen guten Einblick was AMD vor hat und in welchem Kontext Martkanteile sich verschieben könnten wenn es nach AMDs Planungen geht (Stand Mitte 2022):
https://www.computerbase.de/forum/attachments/1654855839970-png.1226674/

https://www.computerbase.de/forum/attachments/1654855713550-png.1226673/

[davidzo]

Einem Markt, in dem Intel gar nicht aktiv ist.

Lol, trotzdem zählt der Konsolenmarkt natürlich dazu, zumal der jetzt seit einem guten Jahrzehnt x86 dominiert ist. Sony und Microsoft scheinen recht zufrieden damit zu sein auf dem Ökosystem der vorherigen generation aufzubauen so dass ich mittelfristig nicht mit einem Architekturwechsel rechnen würde. Das ist halt Intels eigene Schuld dass man da 0% Marktanteile hat. Man ist ja durchaus bestrebt da wieder mit zu mischen, aber bisher hatte man halt meistens das schlechtere Angebot. Es ist ja nicht so als wenn Intel es nie in Konsolen geschafft hat. Das war nur eben sehr selten (xbox). Die xbox 360 hat man verloren weil man beim pricing zu arrogant war. Und ab der Übernahme von ATI durch AMD waren APUs halt immer das bessere Gesamtpaket. Die absurden Investitionen der letzten Jahre in ein eigenes Intel Grafik Ökosystem muss man aber auch vor dem Hintergrund sehen dass man gerne wieder bei Konsolen mitmischen würde.

[Windi]

Es ging mir nur darum zu zeigen, dass AMDs CPU Sparte nur einen kleinen Teil der Kundschaft von TSMC ausmacht. Und deshalb muss die CPU Sparte auch nur einen kleinen Teil der Forschungskosten und des Gewinns von TSMC finanzieren.

Natürlich lassen die anderen Sparten von AMD auch bei TSMC fertigen, aber das bleibt halt getrennt. Jede Sparte muss ihre Kosten selbst tragen und danach dann die Endkundenpreise ihrer Produkte bestimmen.

Und bei der CPU Sparte sieht es momentan so aus, das man recht kleine Chiplets in einem etwas älteren Fertigungsprozess fertigen lässt. Das dürfte halt recht günstig sein.

[Complicated]

"Etwas" älterer Prozess verglichen mit wem? AMD produziert CPUs in den neuesten, verfügbaren Prozessen. Nur Apple ist früher unterwegs, was halt 25% Aufpreis kostet bei 3nm, Zen5 wird wohl nach den Preisverhandlungen darauf kommen. Nvidia ist ebenso bei 5nm wie AMD (nennt sich 4N (for Nvidia) und AMD hat auch seinen Custom-5nm. Intel hat noch keine eigenen EUV-Prozess und will Meteor Lake auf TSMC 5nm bringen und/oder im Intel4. Da kommt der Zen43D im TSMC 4N+ früher.
https://www.hardwareinside.de/wp-content/uploads/2022/08/Zen4-768x216.jpg

[davidzo]

Würde ich auch denken, aber anscheinend haben die Herstellungspreise kräftig angezogen. In Q4 22 ist AMD von 50% Rohertragsmarge auf 43% gesunken. Mit den gestiegenen Investitionskosten in neue Architekturen und Fertigungsstufen steht ein operatives Minus von 3% im Raum. Und die PC-Abnahmekrise war da erst am Anfang. Das wird noch schlimmer kommen und da sehe ich für AMD wenig Spielraum die Preise weiter zu senken.

Ich wundere mich sowieso dass schon lange nicht mehr auf Ryzen3000 Niveau kommen. Damals wurde eine 7nm 1-Chiplet CPU für durchschnittlich 200€ verkauft. Ryzen 5000 war trotz gleicher Fertigung und ähnlicher die-size die längste Zeit viel teurer, von Zen4 brauchen wir gar nicht reden. Die Waferpreise sind wohl nicht mehr das was sie mal waren.

[Windi]

Ich habe es extra mit dem Wort "etwas" ein wenig relativiert.

Es ist halt nicht der neuste Prozess. Neben Apple haben auch andere im Smartphone-Bereich den Prozess schon länger verwendet. Die waren teils über ein Jahr früher dran und der Chip war teils deutlich größer.

[Zossel]

Ich habe es extra mit dem Wort "etwas" ein wenig relativiert.

Es ist halt nicht der neuste Prozess. Neben Apple haben auch andere im Smartphone-Bereich den Prozess schon länger verwendet. Die waren teils über ein Jahr früher dran und der Chip war teils deutlich größer.

Low-Power (Telefone) ist früher dran als High-Performance. Total Normal, und Intel fehlt dieser Markt um seine Prozesse einzufahren.

[reaperrr]

Würde ich auch denken, aber anscheinend haben die Herstellungspreise kräftig angezogen. In Q4 22 ist AMD von 50% Rohertragsmarge auf 43% gesunken. Mit den gestiegenen Investitionskosten in neue Architekturen und Fertigungsstufen steht ein operatives Minus von 3% im Raum. Und die PC-Abnahmekrise war da erst am Anfang. Das wird noch schlimmer kommen und da sehe ich für AMD wenig Spielraum die Preise weiter zu senken.
Ich denke eher, AMD musste anfangen den Händlern (evtl. sogar rückwirkend) Rabatte zu geben, um noch halbwegs was loszuwerden, weil der Channel noch zu viel Zen3 auf Lager hatte.
RDNA2-Preise musste AMD auch senken, das bedeutet dann halt, dass man zwar höhere Stückzahlen loswird, aber halt pro Stück weniger Umsatz und damit Marge macht.


Ich wundere mich sowieso dass schon lange nicht mehr auf Ryzen3000 Niveau kommen. Damals wurde eine 7nm 1-Chiplet CPU für durchschnittlich 200€ verkauft. Ryzen 5000 war trotz gleicher Fertigung und ähnlicher die-size die längste Zeit viel teurer, von Zen4 brauchen wir gar nicht reden. Die Waferpreise sind wohl nicht mehr das was sie mal waren.
Wozu Preise senken, solange die Nachfrage das Angebot übersteigt (bezogen auf 7nm-Produkte insgesamt)?
Das war bis Ende '21, teilweise einschließlich Q1/22 nämlich noch der Fall.
Zumal es phasenweise nicht genug Substrat gab.

Erst als die Mining-Nachfrage eingebrochen ist, haben die Preise angefangen sich auf das Niveau von vor Beginn des Mining-Booms einzupendeln. Die aktuellen Konsolen sowie RDNA2 und Zen3 wurden halt direkt in den Beginn des Mining-Booms hinein released, deshalb gab es ca. ~18 Monate schlicht keinen Anlass für AMD, Preise zu senken, da es nur Marge gekostet und kaum mehr (phasenweise sogar weniger) Umsatz gebracht hätte.

Jetzt mussten sie die Preise halt senken, weil die Nachfrage für die zuvor bestellten Wafermengen plötzlich zu niedrig war und man sonst Gefahr liefe, auf zu vielen Zen3 sitzen zu bleiben und bei Zen4 auch nicht genug Stückzahlen zu verkaufen.

Wäre die Gesamt-Nachfrage hoch geblieben, wäre Zen3 nur gerade so weit im Preis gesunken wie nötig, um mit den Mainstream-Raptoren konkurrieren zu können, gleiches mit Zen4 vs. HighEnd-Raptoren.
Und wahrscheinlich wäre der A620-Chipsaz für AM4 dann auch erst später erschienen.

[robbitop]

Mir ist auch nicht ganz klar, warum B Chipsatz Mainboards auf einmal so teuer sind. Zu AM4 Zeiten gab es die hinterher geschmissen unter 100 EUR. Auf einmal ist B ein (aus Kostensicht - ATX Boards erst ab 200 EUR? wow...) High End Chipsatz. Obwohl es noch einen B-E, einen X und einen X-E darüber gibt. What the ...? Und jetzt wird mit dem A-Chipsatz der vorher Entry Level Müll war und fast hinterher geschmissen wurde damit geworben, dass Boards dann für ~130...150 EUR verfügbar werden? Ist doch klar, dass die Nachfrage dann sinkt, wenn die Plattform auf einmal wesentlich teurer wird. Der RAM ist ja auch teurer (was nicht in AMDs und Intel's Händen ist). Intel war zumindest so weitsichtig um bei der So1700 Generation beides anzubieten (DDR4 und DDR5) - weil der neuere RAM in der Übergangszeit immer teurer ist. Das war zu Skylake ja auch schon so (DDR3+4).

[latiose88]

Ja nur das halt amd Angst hatte den Fortschritt mit einer neuen Plattform einzubremsen. Und ob es dann auch bei der Entwicklung mehr gekostet hätte ne andere Frage.

Was ich mich auch frage, kann man mit einem A620 mainbaord auch so cpus wie einen ryzen 9 7950x verwenden oder hat man dann massive Leistung Einbrüche oder startet sogar der PC nicht einmal.
Wenn man dann auf die letzen 5 % verzichten kann wäre das villeicht ja ne Option. Und dann auch noch große Funktionen auch nicht braucht. Dieses Problem wird auch mit Zen 5 nicht vom Tisch sein.
Ich werde also um das Problem nicht drum rum kommen.
Wenn man also nen sparsames system sucht, nicht zu teuer und auch gut für 16 Kerne geeignet ohne unnütze Funktionen die man auch in Zukunft nicht braucht. Das wird alles noch ne übergeordnete Rolle spielen.

Wenn also AMD mit der 700 mainbaord Reihe nicht besser macht die Sache dann wird es auch da nicht so gut aussehen mit den verkaufszahlen.
Ne cpu alleine macht also ne Plattform nicht automatisch beliebter. Es kommt halt auf das gesammte drauf an.

Wenn ich sowas schon lese mit A620 kann man keine Spannung bei der CPU senken dann ist das schon was negatives für mich. Aber genau diese wäre ein Pluspunkt gewesen. Man kann es bei der Beschneidung echt total übertreiben.

[Complicated]

Mit nicht passendem BIOS zur CPU kannst Du mit AM5 über USB das passende direkt einspielen - dies ist eine gravierende Änderung zu allen bisherigen Plattformen. Mein AM4 MSI X570 Pro hat es auch schon eingebaut: USB BIOS Flashback
https://www.anandtech.com/show/17585/amd-zen-4-ryzen-9-7950x-and-ryzen-5-7600x-review-retaking-the-high-end/2
Native BIOS Flashback Support

With AMD slated to support the AM5 platform through at least 2025, this time around the company is more actively planning around the future of the platform. In particular, AMD is taking a stab at motherboard forward compatibility, which was increasingly an issue for AM4 over its six-year reign.

The big breaker there was that, even when supported by the chipset, older boards required newer BIOSes to support newer generations of CPUs. Thus the only way to make an old board work with a newer CPU was to flash it with a newer BIOS, which in turn required a working CPU to begin with – a catch 22 situation that ultimately resulted in AMD developing a loaner kit program which rented out older AM4 CPUs that customers could use to flash their older boards if they didn’t already have a new CPU for it (e.g. they just bought it off the shelf).

Ultimately, the more elegant solution to the problem is to allow BIOS flashing without a working CPU (or BIOS), which does an end-run around the whole problem. That exists today in the form of USB BIOS Flashback features; however flashback has been a motherboard-level feature that’s normally only found on select high-end motherboards and has to be implemented by the motherboard vendor itself. So for the AM4 generation, it was not a universal (or even widely available) option.

For the AM5 platform, AMD is taking matters into their own hands to make USB BIOS Flashback a universal feature. Ryzen 7000 chips will be able to support USB BIOS Flashback mode across the board and regardless of the BIOS currently installed. As a result, users will always be able to flash an updated BIOS to their AM5 boards, regardless of the CPUs supported by or the operational status of the current motherboard.

[davidzo]

Mir ist auch nicht ganz klar, warum B Chipsatz Mainboards auf einmal so teuer sind.

Sind die Preise für die Chipsets denn bekannt?

Weil sonst würde ich eher vermuten dass es um die Motherboards an sich geht. Der Aufpreis kam ja bereits mit dem x570 Chipset und PCIe 4.0. Der günstigere B550 kam lange zeit gar nicht, stattdessen nur ohne PCIe Gen4 der B550A und B520.
Günstige B350 und A320 boards kommen mit vier Layern aus und X370 und x470 hatten nur selten mehr als sechs Layer. Bei x570 sind 8 Layer Standard und selten auch mal 10. Zusätzlich zu den Layern kommen zum Teil neue low-loss Materialien zum Einsatz die es bisher nur im Server-Bereich gab. Das ist alles nicht wirklich billiger geworden in den letzten Jahren.


Da der B650 eine Art aufgebohrter X570 ist und sogar über die doppelte nutzbare Anzahl an PCIe Gen4 Lanes verfügt wie der alte Highend Chipsatz, wundert mich auch gar nicht wieso er das Preissegment des x570 beerbt.
Es sind einfach zwei teurere Optionen dazu gekommen.

50-100$ B350 -> B450 PCIeGen3 4-6Layer
100-150$ B550 -> A620 PCIeGen4+3 6 Layer
200-300$ X570 -> B650 PCIeGen4 all 6-8Layer
250-400$ B650E -> PCIeGen5+4 8-10Layer
300-600$ X670E -> PCIe Gen5 8-10Layer

Wir brauchen einfach einen neuen Lowcost Chipsatz der auch auf den guten alten 4 layer Platinen funktioniert! Selbst der A620 Chipsatz entspricht ja schon eher dem B550 als dem A520. Der betreibt die Chipset PCIlanes zwar nur mit 3.0, schreibt allerdings für die CPUlanes 4.0 Geschwindigkeit vor. Das klingt eher nach 6Layer Platinen.

An die Kosteneffizienz eines B450 bei dem ein mATX board kaum 50€ kostet wird die neue Plattform wohl niemals gegen an kommen. Dazu ist bräuchte es 4-Layer und eine günstigere VRM Auslegung, die mit der standard-TDP von 170W(230W Turbo)wohl kaum möglich ist.
Die extreme Kostenoptimierung von AM4 verdanken wir noch bristol ridge. Damals war AMD praktisch nur mit APUs unterhalb von 100€ eine ernsthafte Alternative zu Intel, entsprechend kostengünstig musste die Plattform sein.

[HOT]

Mit Promontory 22 könnte es evtl. B650-Bretter mit nur 6-8 Lagen geben, der soll ja die Integration vereinfachen. Mal schauen. Momentan scheinen ja auch B650-Bretter alle 8 Lagen zu haben. Die E sind allerdings alle teuer. Ich halte den B650E für absoluten Schwachsinn. Entweder soll das Board angemessen billig sein, oder es ist High-End, warum sollte man sich aber dort mit USB und PCIe-Lanes einschränken? Mit 2 Promontory hat man netto 8 4.0 Lanes mehr, weil die Zusätzgeräte an den freien 3.0 Lanes hängen und nicht wie beim B650 an 4.0 Lanes.

[Zossel]

An die Kosteneffizienz eines B450 bei dem ein mATX board kaum 50€ kostet wird die neue Plattform wohl niemals gegen an kommen. Dazu ist bräuchte es 4-Layer und eine günstigere VRM Auslegung, die mit der standard-TDP von 170W(230W Turbo)wohl kaum möglich ist.

Ob DDR5 und PCIe >=4 mit 4 Layern geht?

Und diese Spiele-VRMs wirken ziemlich übertrieben auf mich, wenn man das mit Server-VRMs vergleicht.
230W wären bei 90% Wirkungsgrad "lediglich" 23W Abwärme bei Bauteilen die für hohe Temperaturen ausgelegt sind.

[Zossel]

Mit Promontory 22 könnte es evtl. B650-Bretter mit nur 6-8 Lagen geben, der soll ja die Integration vereinfachen.

Warum gibt es so wenig µATX Bretter? Das würde einiges an Platinenfläche sparen.

[MSABK]

Mir ist auch nicht ganz klar, warum B Chipsatz Mainboards auf einmal so teuer sind.

Weil AM5 stand jetzt eine HEDT Plattform ist, günstige Bosrds sind alleine wegen der 170W TDP nicht möglich.