Zen 6 (Olympic Ridge, Medusa Point/Halo & Venice, Morpheus-Kerne, 2/3 nm, 2026)

[bbott]

Nur für die Desktop-CPUs wird AMD kaum ein extra CCD in N2X statt N2P entwickeln, dafür ist dieser Markt viel zu klein...
Das CCD wird wohl aber auch für Notebooks bzw. APUs verwendet. Es scheint sich einiges zu ändern bei Zen 6, sodass ich es nicht für in Stein gemeißelt halte, denn noch eher für unwahrscheinlich.

[w0mbat]

Bei Zen 5 ist das Server CCD auch nicht 100% identisch mit dem Desktop CCD. Anderes Stepping.
Sicher? Wieso sollte man ein anderes Stepping verwenden? Wenn es transistor- oder metal-layer Updates gibt, will man das in allen Fertigungslinien einführen.

[HOT]

Server CCD waren doch bisher immer andere Steppings als die Consumer-Produkte.
Milan war auch B1 und die Consumer-Chips B0 und B2.

[w0mbat]

Also gleicher Chip, nur andere Maske, oder wie muss ich mir das vorstellen?

[amdfanuwe]

Gabs beim 5000er ZEN3. B2 wurde wohl fällig wegen X3D, der dann ja auch ziemlich spät kam. B0 müsste noch eine Macke gehabt haben, wodurch er die Qualitätskriterien für Server nicht schaffte aber für Desktop tauglich war. Natürlich werden dann erst die produzierten B0 und B1 abverkauft bevor nur noch B2 verwendet wird.
Seid mal sicher, da geht es um reine Kostenkalkulation. Aus Spass wird da kein Cent mehr als nötig ausgegeben.

[HOT]

B2 hatte damit nichts zu tun, das war reine Yield-Optimierung IIRC. X3D kam aus politischen Gründen zu spät. Neue Maske wäre neue Revision, also C0 beispielsweise.

[amdfanuwe]

Stepping identifiers commonly comprise a letter followed by a number, for example B2. Usually, the letter indicates the revision level of a CPU's base layers and the number indicates the revision level of the metal layers. A change of letter indicates a change to both the base layer mask revision and metal layers whereas a change in the number indicates a change in the metal layer mask revision only.
https://en.wikipedia.org/wiki/Stepping_level
Wenn für Server ein neues Stepping erforderlich war, ist da auch direkt eine Yield optimierung mit eingeflossen. Bei einer Revision wird ein komplett neuer Maskensatz fällig, bei einem Stepping eben nur einige für die Metalllayer.

[Lehdro]

B2 hatte damit nichts zu tun, das war reine Yield-Optimierung IIRC.
Das ist nur ein Nebeneffekt, den man dann halt mitnimmt. B2 hat den Verbrauch deutlich runtergeschraubt, was die Wärmebelastung bei X3D reduziert und ebenso die Voltages eindämmt. Beides wichtige Punkte um das Taktdefizit möglichst gering zu halten. Die TSVs wurden dabei auch optimiert, denn wie der Name schon sagt, gehen die auch durch bis in die Metal Layer.
Wichtiges Indiz: Es gibt bis auf ein paar Prototypen KEINE B0 X3Ds oder Milan-X. Nur B2.

X3D kam aus politischen Gründen zu spät.
Das Milan-X und X3D fast zeitgleich kamen, widerspricht der Theorie. Ebenso das B2 quasi zeittechnisch kurz davor rauskam. B2 kam über 1 Jahr nach Zen 3 B0, was verdammt spät für reine Yield Optimierung ist. Vor allem wenn man bedenkt wie gut und eingefahren 7nm damals schon für TSMC und AMD war.

Neue Maske wäre neue Revision, also C0 beispielsweise.
Revision: Änderungen am Silicon Layer z.B. A0 -> B0
Stepping: Änderungen am Metal Layer z.B. B0 -> B2 (Metal layer spin)

[y33H@]

oder A0 zu B0, kommt auf's Unternehmen an ...

[HOT]

Es gibt keine sichtbaren Änderungen im Verhalten zwischen B0 und B2, weder Verbrauch noch Takt; das schließt nicht aus, dass rein statistisch B2 besser ist, wäre ja auch schlimm wenn nicht. Aber IIRC war es wirklich nur aufgrund des Yields, B2 hat besseren Yield als B0 und das ist ein sehr gewichtiger Grund.

y33H@
Bei AMD ist das aber so bei CPUs jedenfalls.

[dildo4u]

Open SIL Support für Zen 6 angekündigt (Venice 2026,Medusa 2027)


https://wccftech.com/amd-confirms-opensil-support-zen-6-ryzen-medusa-cpus-1h-2027-epyc-venice-2026/

[HOT]

Kommt offenbar post-Launch, das heißt, es wird auch AGESA dazu geben.

Ich fänd mal interessant, ob AMD mit "Phoenix-CPU" und "Medusa-CPU" die Generation beschreibt (also Phoenix -> Zen4 und 5) oder ob da konkrete APUs mit gemeint sind... vielleicht sogar beides, Pheonix als Entwicklungsplattform und ausgerollt auf all diese CPUs und APUs...

[aceCrasher]

Open SIL Support für Zen 6 angekündigt (Venice 2026,Medusa 2027)


https://wccftech.com/amd-confirms-opensil-support-zen-6-ryzen-medusa-cpus-1h-2027-epyc-venice-2026/
Jetzt stellt sich natürlich die Frage, ob Medusa allgemein erst H1 2027 kommt, oder ob erst dann Open SIL unterstützt wird und es vorher bereits einen Release mit AGESA gibt.

[HOT]

Steht doch drin. OpenSIL für nach dem Release eingeführt.

[horn 12]

https://www.youtube.com/live/YdZxQiO4qj4

RDNA 5 erst 2027
Zen 6 "gecancelt"
und RDNA 4 Refresh 2026 (womöglich Jänner - Februar)

[Skysnake]

Warum sollte Zen 6 gecancelt sein? Das ist doch reines klick bait

[ChaosTM]

Die "RTX 5090 Effectively EOL" Meldung ist auch etwas seltsam und ich hab keine Lust mir MLID 100+min lang anzutun.

Aber vielleicht kommt ja eine RTX 5900 Superduper mit massenweise Speicher für AI Enthusiasten.

[dildo4u]

Er hat es falsh zitiert das Video spricht von Delay.

[robbitop]

Ggf gibt es dann für die 5090 auch eine super Version? Schon seltsam weil es in dem SKU Segment keinen Wettbewerber gibt und die 5080 (auch mit super) weiter genug weg ist von der Performance.

[HOT]

Es gibt also keine N2P-Variante für Desktop, sondern erst die N2X-Variante würde ich sagen ist die korrekte Aussage.

[w0mbat]

Ich bin mir relativ sicher, dass sich bei Zen 6 überhaupt nichts geändert hat. Keine Verzögerung, kein anderer Prozess, keine neuen Pläne.

Venice hatte vor Monaten sein tape-out. Das wäre nicht passiert, wenn N2 nicht ready ist. Und wenn Venice kommt, kommt Medusa auch. Wieso sollte AMD von N4P direkt auf N2X gehen? Wieso soll Medusa in N2X kommen, Venice aber in N2P?

Das hat AMD bisher immer anders gemacht.

[ryan]

Das wäre typisch nach MLID Drehbuch geschrieben. Erst bringt er viel zu optimistische Performance und Marktstart Videos, nur um dann später mit delay und Flop Videos weiteren Content draus ziehen zu können. Einen weiteren Vorteil hat es, er selber liegt dann nie falsch. Nicht etwa seine optimistischen Vorhersagen sind falsch gewesen, sondern der Hersteller hat gefloppt oder etwas verschoben.

[w0mbat]

Er hat aber offensichtlich auch gute Quellen.

[HOT]

Hat sich ja auch nichts geändert, das sag ich ja die ganze Zeit ;). Seine Quellen berichten ihm dann es könnte eine Desktop-Variante in 26 geben und er macht daraus es wird in 26 eine geben und das ist schlicht falsch. So funktioniert das immer. Nicht seine Leaks sind schlecht, er hat den beschissensten Trackrecord in Interpretation, den man nur haben kann für so nen Podcast. Seine Leaks sind fast immer richtig, seine Schlussfolgerungen fast immer falsch.

[w0mbat]

Die 2nm HPC node scheint aber wohl doch etwas spaeter zu kommen als urspruenglich geplant. Betrifft nicht nur AMD, sondern alle. Die Frage ist, warum Venice in N2P und Medusa in N2X? Unterschiedliche CCDs = auch unterschiedliches packaging?

Vielleicht soll Medusa wirklich hauptsaechlich ueber den Takt skalieren. Dann wuerde das Warten auf N2X Sinn ergeben.

[aceCrasher]

Die 2nm HPC node scheint aber wohl doch etwas spaeter zu kommen als urspruenglich geplant. Betrifft nicht nur AMD, sondern alle. Die Frage ist, warum Venice in N2P und Medusa in N2X? Unterschiedliche CCDs = auch unterschiedliches packaging?

Vielleicht soll Medusa wirklich hauptsaechlich ueber den Takt skalieren. Dann wuerde das Warten auf N2X Sinn ergeben.
Vielleicht war das gezeigte Venice CCD in N2P ja die Variante mit c-Kernen? Bei Zen 4/5 gan es ja auch ein „normales“ CCD und eins mit mehr c-Kernen.

Bei Zen 5 war das c-Kern CCD in 3nm und das normale in 4nm wenn ich mich richtig erinnere.

Man hätte dann halt das normale CCD für Desktops und reguläre Epycs in N2X und das c-Kern CCD für high-core count Epycs in N2P, da dort maximaler Takt eh nicht das Ziel ist.

[HOT]

Unwahrscheinlich, da die eh später kommen. Das wird schon das 12C-CCD gewesen sein.
Wenn die N2-HPC-Variante (Es gbit ja von vielen Prozessen eine Mobil und eine HPC-Konfiguration) später kommt, kommen wie gesagt alle CPUs, auch NVL, später. Ich halte diese ganze N2P/X-Geschichte eh für Unsinn. Es kann sein, dass Intel N2P in Standardkonfiguation nutzt, wie ARL ja auch, aber AMD wird N2 HPC sicherlich wie alle Iterationen vorher customisieren und den von Anfang bis Ende durchproduzieren. Bisher wurde N7 in 2020 customisiert, N5 von Anfang an und Phoenix machte in custom-N4 IIRC sogar Probleme anfangs. Sie werden standard N2 ebenso customisieren, wie die Varianten zuvor.

Interessanterweise ist das bei dedizierten GPUs nicht so, RDNA1 war standard N7P, RDNA2 AMDs custom N7, RDNA3 AMDs custom N5 und RDNA4 N4P standard wenn ich recht erinnere. Nur bei Medusa und RDNA5 scheint AMD den N3P-Weg zu gehen, ob man da noch Hand an legt, keine Ahnung aber für das CCD wäre es überraschend, wenn AMD zusammen mit TSMC hier nicht selbst Hand anlegen würde. Ich denke, N2"X" wird einfach ein Missverständnis gewesen sein - vielleicht hat bei AMD mal jemand die Andeutung gemacht, dass der eigens angepasste Prozess quasi ein N2X ist.

[iamthebear]

Zu dem Zeitpunkt als MLID das erste Mal den N2X Leak brachte war das schon für 2027 auf der Roadmap. Ich halte das für Schwachsinn genauso wie die "7GHz".

[HOT]

7GHz ist auch Unsinn, seh ich ähnlich. Wenn wir die 6GHz zuverlässig überschreiten wäre ein ein großer Fortschritt.

[w0mbat]

Ich faende 7GHz geil. Vor allem haut mehr Takt halt immer durch. Das waere ein wuerdiger Nachfolger fuer den 5800X3D.

[HOT]

Das wäre eher Zen4 auf Zen3. Unmöglich ist das nicht, ich halte es nur für Unwahrscheinlich. Sagen wir mal so, die Skepsis könnte durch einen glaubhaften Leak ausgeräumt werden. Und ein Sprung von 5,6 auf 6,6GHz wäre schon 1 GHz, das ist schon krass wenn das klappt.

[mboeller]

7GHz ist auch Unsinn, seh ich ähnlich. Wenn wir die 6GHz zuverlässig überschreiten wäre ein ein großer Fortschritt.

die ganzen 7GHz-Gerüchte beziehen sich IMHO auf das hier:
https://www.notebookcheck.com/Snapdragon-8-Elite-Gen-6-Geruechte-deuten-auf-Leistungssprung-und-starke-Effizienz-hin.1149114.0.html

+18% für N2P gegenüber N3E. Macht dann eben ~7GHz. Ich gehe nicht davon aus, dass AMD das macht.

[Badesalz]

Kommt ihr denn mit 6.4Ghz/allcore und kurzzeitigen 7Ghz Boost auf einzelnem Core klar, wenn die anderen im CCD grad <50% Last fahren? ;)

Abstand max. allcore zu max. core soll jedenfalls schrumpfen.

[Nightspider]

die ganzen 7GHz-Gerüchte beziehen sich IMHO auf das hier:

Nee die kommen alle von MLID und seinen angeblichen, internen AMD Quellen.

[Sonyfreak]

Dazu kommt aus meiner Sicht, dass es AMD derzeit gar nicht nötig hat, bei den CPUs das maximal Mögliche auf den Markt zu bringen. Viel sinnvoller ist es doch, der Kundschaft jede Generation sichtbare, aber nicht übertrieben große Fortschritte zu verkaufen.

mfg.

Sonyfreak

[Badesalz]

Intel wird sich mit dem 300er versuchen aufzubäumen. Zen6 und Zen7 dienen dazu ihnen den Spaß am aufmucken endgültig zu nehmen und sich mit ihrer neuen Rolle abfinden, statt die Leute und den Markt weiter auf den Arm zu nehmen.

Der endgültige Verlust der Hybris würde denen keineswegs schaden. Genauso wie uns allen eine 50:50 Marktverteilung. Momentan tun sie immernoch so als wenn sie auf irgendwelchen Throns mit irgendwelchen Kronen sitzen würden.

[ChaosTM]

Dazu kommt aus meiner Sicht, dass es AMD derzeit gar nicht nötig hat, bei den CPUs das maximal Mögliche auf den Markt zu bringen. Viel sinnvoller ist es doch, der Kundschaft jede Generation sichtbare, aber nicht übertrieben große Fortschritte zu verkaufen.

mfg.

Sonyfreak


In diese Falle ist Intel vor 10+ Jahren getappt, als man glaubte es gäbe keine Konkurrenz mehr.
Ich hoffe Lisa ist nicht so dumm und ruht sich auf dem kleinen (bei Spielen großen) Vorsprung aus.
Aber sie ist mit Jensen verwandt, solche Fehler sollten ihr nicht passieren.


Intel ist auch nicht mehr der Hauptgegner. Der kommt schleichend aus der ARM Ecke..

[Nightspider]

Dazu kommt aus meiner Sicht, dass es AMD derzeit gar nicht nötig hat, bei den CPUs das maximal Mögliche auf den Markt zu bringen. Viel sinnvoller ist es doch, der Kundschaft jede Generation sichtbare, aber nicht übertrieben große Fortschritte zu verkaufen.

Blödsinn.

Zen7 im A16 Prozess wird auch wieder deutlich besser und mit Zen8 wirds auch weiter nach vorne gehen.

Gerade mit Stacking ist heutzutage so viel Potential drin. Wozu auf die Bremse treten? Glaubst du Apple und Qualcomm warten auf die x86 Konkurrenz?

AMD und Intel müssen erstmal aufholen und das fängt eben beim Fertigungsprozess an. Endlich nutzt AMD die neusten Nodes. Wer das anders sieht ist bescheuert.

[Der_Korken]

Bei diesen ganzen 7Ghz-Phantasien wird imho gerne vergessen, dass die max. VCore bei neueren Prozessen sinkt. Ich kann nicht einfach die 5,7Ghz nehmen, die Zen 5 mit 1,4V (?) Brechstange schafft und davon ausgehen, dass N2 auch mit 1,4V und proportional hochgerechneten Takt läuft. Da sind in der Spitze vielleicht 1,2V angesagt und da stehen wir aktuell bei 5,2-5,4Ghz ausgehend von den X3D-Modellen. Abgesehen davon finde ich diesen Brechstangen-Takt sowieso völlig uninteressant. Sorgt nur für absurde Temp-Spikes und unnötiger Stromverschwendung im Teillast-Bereich bei bestenfalls messbarer Mehrleistung. Der halbwegs effiziente Taktbereich wird bei Zen 6 vielleicht so bis 6Ghz gehen.

Die spannendere Frage ist aber, wann das Teil endlich kommt. Ich will wissen, ob ich wegen der AI-Blase noch RAM auf Vorrat kaufen muss, weil der in einem Jahr nochmal das doppelte kostet :freak:.

[Badesalz]

@Der_Korken
Da gäbe es nur die Kleinigkeit, daß Zen6 nicht einfach auf N2 umdesigntes sonst 1:1 Zen5 ist :| TSMC entwickelt keine Takte...

[HOT]

Blödsinn.

Zen7 im A16 Prozess wird auch wieder deutlich besser und mit Zen8 wirds auch weiter nach vorne gehen.

Gerade mit Stacking ist heutzutage so viel Potential drin. Wozu auf die Bremse treten? Glaubst du Apple und Qualcomm warten auf die x86 Konkurrenz?

AMD und Intel müssen erstmal aufholen und das fängt eben beim Fertigungsprozess an. Endlich nutzt AMD die neusten Nodes. Wer das anders sieht ist bescheuert.
Zen7 scheint A14 zu haben, A16 setzt NV bei KI-Chips ein.

[Der_Korken]

@Der_Korken
Da gäbe es nur die Kleinigkeit, daß Zen6 nicht einfach auf N2 umdesigntes sonst 1:1 Zen5 ist :| TSMC entwickelt keine Takte...

Ja und? Meinst du, dass AMD mit Zen 6 ihre Pipeline verlängert um IPC für Takt zu opfern?

[Badesalz]

Ich weiß nicht was sie machen. Man muss das heute aber bestimmt nicht so machen wie Intel mit Pentium 4.

Hoffentlich werden wir das noch erleben können was sie vorhaben.

[HOT]

Bisher weiß man nur, dass er mehr Takt haben soll. Da würde ich einen Zen3 -> Zen4-Moment erwarten, also guter Zuwachs aber nur wenig IPC pro Takt, ich denke, das wäre realistisch. Ein Teil wird auf allgemeine Architekturoptimierung zurückzuführen sein, ein Teil der bessere Prozess + Taktoptimierung der Architektur (N2 HPC), also ähnlich dem, was AMD mit Zen4 gemacht hat.

Und AMD hat ja jetzt Venice für 2026 bestätigt, dann würde ich die Consumervariante kurz davor erwarten. Ich denke, Venice wird wieder im Oktober/November starten, Consumer dann September/Oktober, Vorstellung Comdex oder so. Venice C dürfte dann Anfang 27 folgen, der kommt ziemlich sicher nicht mehr 26.

[latiose88]

Und da kann nur N2 oder N2P in dem Zeitraum kommen. Das heißt die Leistung wird nicht so gut sein wie manche sich das erhofft hatten. Das bedeutet geringe Steigerung des taktes,Stromverbrauch Optimierung leicht und ansonsten geringe IPC Steigerung wenn überhaupt. Der Rest sind 12 Kerne anstatt 8.
Ob AMD 2*12 im Desktop machen wird ,weiß man nicht . Es ist ja nur geraten. Bei 2*12 ist ein geringe Taktsteigerung sicher . Der Rest nicht klar . Es wäre ja schon 2*12 Kerner für einige ein Wahnsinn .
Für die wo nicht so viele Kerne umgehen können ,bedeutet das keine Steigerung der Leistung.
Beim Takt hält sich also AMD zurück . Und auch bei der IPC Steigerung hat AMD nix gesagt oder sowas.
Wir wissen also sicher das nur 12 Kern chiplet. Mehr nicht.

[Lehdro]

Bei diesen ganzen 7Ghz-Phantasien wird imho gerne vergessen, dass die max. VCore bei neueren Prozessen sinkt. Ich kann nicht einfach die 5,7Ghz nehmen, die Zen 5 mit 1,4V (?) Brechstange schafft und davon ausgehen, dass N2 auch mit 1,4V und proportional hochgerechneten Takt läuft.
hm...ist schon lange nicht mehr so. Das einzige was sinkt ist die Vcore unter allcore Load, aber die maximalen Spannungen sind schon seit Jahrzehnten im Bereich 1.4V +/-10%:

Newcastle: 1.5V -> 130nm
Winchester: 1.45V -> 90nm
Windsor: 1.40V -> 90nm
Brisbane: 1.35V -> 65nm
Agena: 1.35V -> 65nm
Deneb: 1.475V -> 45nm
Thuban: 1.475V -> 45nm
Zambezi: 1.45V -> 32nm
Piledriver: 1.45V -> 32nm
Vishera: 1.55V -> 32nm
Zen 1: 1.55V -> 14nm
Zen+: 1.475V -> 12nm
Zen2: 1.50V -> 7nm
Zen3: 1.50V -> 7nm
Zen4: 1.40V -> 5nm
Zen5: 1.375V -> 4nm
Zen6: ????

Aufgelistet jeweils die maximalen Werks VID, die auch automatisch angelegt werden für Singlecore Workloads (Burst/max. Boost).

Da sind in der Spitze vielleicht 1,2V angesagt und da stehen wir aktuell bei 5,2-5,4Ghz ausgehend von den X3D-Modellen.
5.55 GHz ist Fmax für den 9950X3D CCD0 - mit bis zu 1.35V. Non X3D Zen 5 haben nur minimal höhere VIDs im schlimmsten Fall.

[lilgefo~]

Ggf gibt es dann für die 5090 auch eine super Version? Schon seltsam weil es in dem SKU Segment keinen Wettbewerber gibt und die 5080 (auch mit super) weiter genug weg ist von der Performance.

90er kriegen nur ein Update wenn es Konkurrenz gibt, letztes mal mit der Ampere Gen (3090Ti) geschehen.

[Badesalz]

Zen6: ????<1.3V

[CrazyIvan]

Und AMD hat ja jetzt Venice für 2026 bestätigt, dann würde ich die Consumervariante kurz davor erwarten. Ich denke, Venice wird wieder im Oktober/November starten, Consumer dann September/Oktober, Vorstellung Comdex oder so. Venice C dürfte dann Anfang 27 folgen, der kommt ziemlich sicher nicht mehr 26.
Kam nicht Turin-Dense mehr oder weniger zeitgleich mit Classic? Und das, obwohl er in einem neueren Prozess aufgelegt wurde?
Noch dazu ist Venice Dense anscheinend der neue Mainstream, da Classic ja nur noch bis 96c (8*12c) gehen soll.
Spricht für mich alles eher gegen einen späteren Start. Ich würde noch nicht einmal ausschließen wollen, dass Dense sogar zu erst startet und Classic sowie Client später nachfolgen.
Laut Lisa Su haben die ersten CSPs (Cloud Service Provider) bereits Venice für Tests und Integration erhalten - da tippe ich auch eher auf Dense als Classic.
Auch hat man mit MI450 im Tandem mit Venice recht sportliche Timelines kommuniziert - allerdings weiß ich nicht, mit welcher Variante man die vorzugsweise paart.

[amdfanuwe]

Spricht für mich alles eher gegen einen späteren Start.
Denke auch, der 2nm Wafer war Venice Dense.
Ist das Margenstärkere Produkt und erweitert das Portfolio nach oben.
2nm braucht man da eh um die nötwendige Dichte und Effiziens für die 32 Core CCDs zu bekommen.
Nächst wichtiges Produkt wäre der GCD für MI450. Denke, der kommt auch in N2.
Mal sehen, wann dann der 12 Core CCDkommt.

[dildo4u]

Zen6 mit FP16 Int8 Support


https://wccftech.com/amd-zen-6-cpu-core-isa-revealed-avx512-fp16-vnni-int8-more

[HOT]

Jo das klärt ein paar Sachen zusammen mit dem neuesten MLID-Video.

Olympic-Ridge -> 512Bit AVX, 12C pro CCX/D, N2P+N6 IOD+N6 VCache, keine LPE Cores, keine NPU (RDNA2?)


Medusa1 4+4c+2LP
Medusa2 2+4c+2LP
Medusa3(Bumblebee lt. MLID) 2+2c+2LP

[MSABK]

Zen6 mit FP16 Int8 Support


https://wccftech.com/amd-zen-6-cpu-core-isa-revealed-avx512-fp16-vnni-int8-more

Was bedeutet das?

[dildo4u]

Bessere Performance wenn man das Daten Format auf den x86 Kernen nutzt vermutlich Sinnvoll da die Desktop Versionen keine NPU besitzen.

[OgrEGT]

Auf dem AMD FAD hat Mark Papermaster ein Slide gezeigt mit sowohl Zen6 und Zen6c beide 2nm...

[OgrEGT]

Hier die Meldung u.a. dazu und das Slide welches nun auch Zen7 enthält...
https://videocardz.com/newz/amd-presents-new-zen-cpu-roadmap-confirms-zen-7-with-new-matrix-engine
AMD presents new Zen CPU roadmap, confirms Zen 7 with new matrix engine

Siehe auch hier
https://www.3dcenter.org/news/neue-offizielle-roadmaps-zu-zukuenftigen-amd-prozessoren-und-grafikchips

[Adam D.]

Auf dem AMD FAD hat Mark Papermaster ein Slide gezeigt mit sowohl Zen6 und Zen6c beide 2nm...
https://cdn.videocardz.com/1/2025/11/AMD-MEDUSA-GORGON.jpg
Ja, das sieht aber auch danach aus, dass Zen 6 tatsächlich erst 2027 zu kommen scheint.

[dildo4u]

Medusa sind die Laptop Chips die kommen fast immer zur CES im Januar.
Die Zen6 Server sind für 2026 geplant Desktop ist Spekulation.

https://i.ibb.co/27y6K5Jf/AMD-ZEN7-ROADMAP-1200x624.jpg (https://ibb.co/4Z7fNJk5)

[HOT]

https://cdn.videocardz.com/1/2025/11/AMD-MEDUSA-GORGON.jpg
Ja, das sieht aber auch danach aus, dass Zen 6 tatsächlich erst 2027 zu kommen scheint.

Zur CES, jo, genau wie Gorgon CES26.
Der Chart soll mMn nur die NPU-Leistung widergeben, 10TOPs für Phoenix, 16 für HP, 50 für Strix, ~65 für Gorgon und ~100 für Medusa mMn.

[amdfanuwe]

Strix Point wurde (ausnahmsweise) zur Computex am 03.06.2024 vorgestellt zusammen mit Ryzen 9000, Turin und MI300.
Die Folien sind da nicht ganz korrekt. Daher lässt sich aus den Folienauch nicht ablesen, wann es für welche ZEN6 Produkte soweit ist.

[HOT]

Lt. MLID war Strix 1/2 Jahr zu spät.

[rentex]

Ich befürchte ne Verschiebung des ZEN 6 Release, aufgrund der Speicherpreise. 6 Monate?

[dildo4u]

Apple wird nicht aufhören Consumer PC zu verkaufen die x86 um Meilen überlegen sind da kann es sich AMD nicht leisten zumindest Notebook Chips zu liefern.

[HOT]

Dieser bescheuerte Apple-fetisch. Apple ist für PC genau 0 relevant. Der kann noch so schnell sein, er ist trotzdem kein PC. Wenn du Apple toll findest, kauf dir nen Apple und lebe mit den Einschränkungen und dem Abowahn, den die verantalten. Sobald die die Dinger als SoCs für Windows on ARM oder Linux ohne frickelei anbieten, dann werde ich einen Vergleich in Betracht ziehen, vorher ist das reines Fanboytum, es tut mir leid.

Ich befürchte ne Verschiebung des ZEN 6 Release, aufgrund der Speicherpreise. 6 Monate?

Ich weiß nicht, ob du damit auskommst. Tape Out im Februar 2025+5Q wäre Mitte 2026, jetzt sieht es aber eher noch Anfang 27 aus, also Vorstellung CES als allerfrühesten Termin würde ich mal vermuten. Er könnte noch mehr Verspätung haben als Zen4.

[dildo4u]

Das ist nunmal der aktuelle Markt Apple hat mit Abstand den meisten Umsatz und das 5 Jahre noch dem ersten eigenen Laptop Chip.


https://www.accio.com/business/best_selling_laptop_brand_in_the_world

[HOT]

Wie gesagt, keinerlei Substanz. Zeig mir einen Windows PC oder Linux-PC mit Apple-SoC und benchmarke den, dann können wir darüber reden.

[rentex]

Dieser bescheuerte Apple-fetisch. Apple ist für PC genau 0 relevant. Der kann noch so schnell sein, er ist trotzdem kein PC. Wenn du Apple toll findest, kauf dir nen Apple und lebe mit den Einschränkungen und dem Abowahn, den die verantalten. Sobald die die Dinger als SoCs für Windows on ARM oder Linux ohne frickelei anbieten, dann werde ich einen Vergleich in Betracht ziehen, vorher ist das reines Fanboytum, es tut mir leid.



Ich weiß nicht, ob du damit auskommst. Tape Out im Februar 2025+5Q wäre Mitte 2026, jetzt sieht es aber eher noch Anfang 27 aus, also Vorstellung CES als allerfrühesten Termin würde ich mal vermuten. Er könnte noch mehr Verspätung haben als Zen4.

Klingt valide. Schrecklich.

[Daredevil]

Dieser bescheuerte Apple-fetisch. Apple ist für PC genau 0 relevant. Der kann noch so schnell sein, er ist trotzdem kein PC.
Ein "PC" ist ein Computer als Werkzeug, mit dem du Dinge erledigt. Dabei ist es völlig irrelevant, ob der nen AMD/Intel/Apple Prozessor hat, welche GPU dort verbaut ist, wie viel Speicher oder welches Betriebssystem läuft. Wichtig ganz alleinig ist, das man mit diesem Werkzeug das Problem löst, welches vorhanden ist. Dass PCs dies mit verbundenen Vor- als auch Nachteilen erledigt und unterschiedliche Technologien verfolgen, stimmt total. Das jeder eigene Ansprüche an ein System hat ( Offenheit, Effizienz, Datenschutz ), ebenso richtig. Ein Mac allerdings den persönlichen Computer absprechen zu wollen auf Basis des Betriebssystems, ist allerdings realitätsfern.
Ein RasPi ist auch ein Computer, nur halt keiner für jeden.
Wenn du Apple toll findest, kauf dir nen Apple und lebe mit den Einschränkungen und dem Abowahn, den die verantalten.
Was für ein Abowahn? Du kaufst dir die Hardware und benutzt es wie jedes andere Notebook auch. :<

Zeig mir einen Windows PC oder Linux-PC mit Apple-SoC und benchmarke den, dann können wir darüber reden.
Auch wenn dieser Take absolut Schwachsinnig ist, weil Äpfel und Birnen: Selbst emuliert sind manche Windows Anwendungen auf einem Apple Silicon Chip schneller/effizienter als auf einem nativen Notebook Chip. Nicht alle, aber manche, speziell CPU Tasks. Insofern können wir gerne benchen. (:


Der Apple M5 ist in der Variante für das MacBook Pro der Prozessor mit der aktuell höchsten Single-Core-Leistung – vor dem M4 und weit vor AMD und Intel. Die zwei Größen aus dem Windows-Wettbewerb schlägt Apple zudem mit vielfachem Multiplikator in puncto Effizienz. Bei der Leistung pro Watt liefert Apple Silicon schlichtweg eklatant mehr. Der Abstand fällt derart groß aus, dass Apple dieses Jahr einen Teil der Effizienz geopfert hat, um die Single-Core-Krone zu behalten.

Und daher stimme ich dildos Aussage auch zu, AMD ist in Zugzwang. Nicht nur dem technologisch unterlegenerem Intel, sondern auch dem technologisch überlegenerem Apple. Und das einzige, was AMD von abhält, dass Qualcomm sich nicht breit macht sind die Limitierungen bei der Software. Das ist ein enormer Kraftakt, den AMD zu bewältigen hat, Lisa wird aber nen Plan haben, da bin ich mir fast sicher. Bei der CPU Sparte klappt einiges ziemlich gut.

[Nightspider]

Ich befürchte ne Verschiebung des ZEN 6 Release, aufgrund der Speicherpreise. 6 Monate?

Absurd.

Wenn es zu einer Verschiebung kommt dann nur wegen dem N2 Prozess oder weil ein neues Stepping benötigt wird.

[Daredevil]

Naja.... rein vom Marketing her will AMD natürlich auch ein Momentum und einen Hype um die Produkte schaffen. AMD hat mit Zen5 beim Start genau jenes Problem gehabt, dass die restlichen Komponenten zu teuer gewesen sind und deswegen der Sprung auf die neueste Gen sich schlicht nicht gelohnt hat. Dafür konnte Zen5 nichts, in den Köpfen der Nutzer hat sich aber eben kein gutes Bild verfestigt.

Ganz im Gegenteil dazu sei der 9800X3D erwähnt, der genau das Gegenteil erreicht hat. Er war offenbar günstig genug, hat sich verkauft wie warme Semmel und hat einen enormen Hype auf der ganzen Welt ausgelöst. Das hat monatelang die Begierlichkeit dieses Prozessors in den Köpfen der Kunden gefestigt, was ihn nachträglich zu einem sehr guten Ruf verschaffen hat.
Wer redet denn heute oder hat jemals über den 9700X geredet? Quasi niemand.

[Nightspider]

Nein, der Plattformpreis war das Problem bei Zen4 alias Ryzen 7000.
Mainboard und RAM Preise waren vor einem Jahr deutlich günstiger als beim Zen4 Release.

Zen5 mit Ryzen 9700x hat erstmal massiv enttäuscht, weil er in Spielen kaum Mehrleistung bot, trotz aller Ansagen. Deswegen ja der anfängliche Spitzname "Zen5%".

Das das lag und liegt immer noch am Speichercontroller (IOD) weil Zen5 noch stärker durch den RAM ausgebremst wird.

Mit massiv getuntem RAM geht auch der 9700X gut ab.

Wenn Zen6 Richtung DDR5_7200 geht und mit OC 8000 mit 1:1 Teiler schafft, dann wird auch die Non-X3D Variante richtig gut in Spielen performen.

CUDIMM Module gibts ja bis DDR5_9600 aktuell und >10.000 MT/s sind am Horizont.
Mal schauen was Zen6 schaffen wird.
Das Zen5 stark durch RAM gebremst wurde, weiß AMD selber. Die werden da auf jeden Fall mehr Gas geben.

[Daredevil]

Upsala, du hast recht. Bin in einer Zen Generation verrutscht. :D
Genau, den Zen4 Wechsel meinte ich. Super Produkt, das "drumherum" war aber leider zu teuer.
Und wenn das drumherum nun RAM ist, ähnelt sich der Spaß ja.

Wenn nun AM5 Mainboards im Preis fallen und die Produktion deswegen gedrosselt wird, könnte hier auch der Preis wieder langfristig steigen. Wie gesagt, Multifaktorelles Problem, wo es schwer ersichtlich ist, wo der nächste Flaschenhals ist. Sehr bitter, das AMD in so einem Umfeld releasen muss.

[Nightspider]

Es gibt schon echt viele AM5 Plattformen wo die Käufer auf Zen6 upgraden werden.

Dazu kommen die Produkte, die so oder so gekauft werden müssen. Wenn Firmen neue Geräte kaufen müssen, macht es für die Auswahl der CPU keinen Unterschied, wie hoch der RAM Preis ist.

Zen6 macht 2 Node Sprünge. Die Leute/Firmen werden kaufen wollen. Und Zen6 in HPC wird sowieso für AI benötigt.

Die Am5 Plattform ist ~4 Jahre alt wenn Zen6 erscheint. Und ein Zen5% Moment wird das auch niemals werden.

Das wir hier jetzt in jedem Thread den RAM Preis zum Thema machen ist völlig Banane.
Es wurde jetzt 2-3 Monate lang gepredigt, das man sich RAM holen sollte, wenn man in nächste Zeit upgraden will.

Und wenn Samsung, Micron und Co. jetzt auch deutlich mehr RAM produzieren sieht die Situation in 9-12 Monaten vielleicht schon wieder etwas entspannter aus.

Aber ich will jetzt hier echt keine RAM-Preis-Diskussion.

[Oranje7]

Bin da bei Nightspider
Zen6 wäre halt vor allem was für upgrader die eh schon AM5 haben.
Ich als AM4 Benutzer sitze es natürlich aus^

Eine Firma interessiert den RAM-Preis übrigens wenig wenn ein Mitarbeiter einen Rechner zum Arbeiten braucht. Da muss was neues her (ja da wird lieber Intel gekauft)

[aufkrawall]

Auch wenn dieser Take absolut Schwachsinnig ist
Er kann es halt nicht wahrhaben, wie abgehängt x86 bzw. AMD & Intel sind.

[HOT]

Die mögen noch so abgehängt sein, wer keinen MAC will kann sich die Teile einfach ans Knie nageln, vielleicht sinds auch gute Briefbeschwerer, sie sind schlicht irrelevant.
Können auch 10x so schnell sein, das ist völlig wurscht. Ich verstehe die Technikbegeisterung, aber in der Praxis sind die Dinger nicht als PC nutzbar, Ende der Geschichte.

[aufkrawall]

Da würde ich persönlich dir sogar zustimmen. Insbesondere in den USA sehen das aber mittlerweile viele anders.

[HOT]

Gut, ich hab überhaupt nichts dagegen, wenn sich jemand nen Mac kauft. Man muss aber damit leben dann auch. Das ist völlig ok. Aber der Vergleich ist trotzdem einfach Äpfel mit Birnen, Mac und damit dessen Prozessoren ist in einem Zen6-Thread einfach OT, hier gehts um PC-CPUs.

[latiose88]

ich weis was hot meint.Jene so wie wir die Windows Nutzen wollen und keine Frickelleien machen wollen weil schlicht sich nicht auskennt und auch nur Windows Programme,ffür den gibt es nur AMD oder Intel als Opption.Und so sehe ich das auch.Ich kenne mit mit Linux und co nicht aus.
Wenn das nicht Nativ ohne des zutuen des Users geht,ist das halt keine Option.
Aber genug OT.Für mich kommt Zen 6 deutlich zu spät.Ich stehe aktuell vor der Entscheidung und nicht erst 1 Jahr später.Würde ich mich aber für AMD Entscheiden,würde ich als übergang einen 6-8 Kerner nehmen und erst später auf Zen 6 gehen,weil mir die Preise vom 7950x sowie 9950x nicht passen.Sie sind schlicht einfach zu teuer für die Leistung die sie zeigen.
Da bringt mir auch der bessere Preis beim Mainbaord nix.Und was bekommt man für 300€ ja kaum was gutes was Multicore Leistung angeht.Der Plan ist von vorne bis hinten zum scheitern verurteilt.
Und ob Zen 6 überhaupt so geil wird wie angepriesen ist auch noch nicht sicher.Klar wird es sprünge geben,aber ob die richtig genutzt werden,ist eine andere Frage.

[davidzo]

Können auch 10x so schnell sein, das ist völlig wurscht. Ich verstehe die Technikbegeisterung, aber in der Praxis sind die Dinger nicht als PC nutzbar, Ende der Geschichte.

Wie vielen Leuten ist es denn wichtig dass es ein "PC" ist was sie benutzen um ihren täglichen Bedarf an compute zu decken?
Gen Z bevorzugt doch eh schon das Handy vor dem PC als Compute device - und da gibt es gar kein Windows. Für Poweruser Gen-Z dann eben ein tablet, ggf. mit Stifteingabe oder tastatur-cover. Ehemalige PC-Zocker bevorzugen zum Teil Konsolen weil der Lebensmittelpunkt sich verändert hat und die Konsolen Out-of-the-box-experience mehr zu ihrem Zeitmanagement und Umfeld passt. Selbst diehard PC-Game Zocker nutzen nicht selten häufiger ihre Steamdeck als den PC und liebäugeln mit Cachy, SteamOS vor Windows 11.

Der Punkt ist dass es den meisten Leuten egal ist was darunter läuft, hauptsache die Geräte laufen, sind einfach zu bedienen und es ist niedrigschwellig zu wechseln.

Auch Server workloads nutzen zunehmend einen abstrahierten Softwarestack der eh auch auf anderen Plattformen lauffähig ist, weshalb ARM bei den Hyperscalern massiv dazugewinnt - auch ohne Apples Performancevorsprung.

Durch Android und iphones hat jeder Mensch Kontakt mit dem da draußen außerhalb der PC-Bubble. Die Gruppe der Windows-traumatisierten Alten Männer die sich weigern etwas anderes aus zu probieren weil sie unter dem PTBS der Win3.11, 95, 98, ME, XP Erfahrungen leiden ist zunehmen kleiner und wird langsam marginal. Bei besagter GenZ ist es genau umgekehrt - Das Handy ist die vertraute Plattform und der PC fühlt sich seltsam ineffizient, fremd und ungelenk an. Die haben daher keinen Windows-x86-Bias mehr, sondern hätten lieber große Handy - Fernseher Kreuzungen mit Tastatur und anständiger Touchsteuerung wobvei egal ist ob das unter iOS, Android etc. läuft solange die cloudsynchronisation mit dem bevorzugten Amnbieter reibunsglos läuft.

Selbst die meisten konservativen Businessanwendungen und proprietären Geschäftsprozesse sind mittlerweile von einer schwer wartbaren Client-Architektur auf Web-basierte Lösungen umgeschwenkt, was sie praktisch plattformunabhängig macht.

Da du nicht dazu zu bringen bist mal einen Tag macOS auszuprobieren, würde ich dich wenigstens mal darum bitten zu schätzen wieviele Tasks du am Tag erledigst die wirklich komplett auf x86 angewiesen sind. Stell dir einfach vor du würdest ein Qualcomm Windows-Gerät benutzen. Das hat zwar nicht die bessere usability, aber bietet die vertraute awkwardness von windows. Mir fällt außer Spielen momentan wenig ein, was nicht perfekt auch emuliert läuft oder wozu es nicht auch modernere, bessere, plattformunabhängige Alternativen gibt.

[latiose88]

@davkdzo ich habe Anwendungg die mit Linux,Steam OS oder mit mac wohl auch nicht funktionieren wird.Ich verwende X86 Anwendung.Meistens sind es 32 Bit Anwendung.Alte 32 Bit Spiele und vielleicht auch X64 Bit.
Ich würde das niemals ersetzen wollen.Ich habe zudem eine Nas wo ich jeden Tag drauf zugreife.Das Schneid Programm ist auch ein Windows X86 Bit also 32 Bit Programm.Es gibt es nicht für eine andere Plattform.Ich bin also auf solche Programme angewiesen.
Wechseln ist so schwer.Ich mache das Jahre schon so.Und verwende es Aktiv.
Ich gehöre also noch zu den wenigen.Das Programm zum Video Umwandeln geht auch nicht woanderst.Ich bin zu 100% von Windows Abhängig.Verwende noch immer Windows 10.Ich will nicht zu Windows 11 gehen,weil das Scheiße ist.Wenn es nach mir gehen würde,würde ich wohl lieber auf Windows 7 geblieben weil meine Spiele auch auf das besser laufen,aber es gibt auch Spiele zum so runterladen wo Mac und Linux zur Auswahl wären ,aber viele sind das nicht.AUf Anwendungs ebene würde ich also Probleme bekommen und bei Spielen der Kaufbaren wohl auch eher.
ALso ich werde auch weiterhin auf Desktop PPc setzen,sogar Aktiver denn je.

[Daredevil]

Können auch 10x so schnell sein, das ist völlig wurscht. Ich verstehe die Technikbegeisterung, aber in der Praxis sind die Dinger nicht als PC nutzbar, Ende der Geschichte.
Es geht aber nicht um dich hier im Thread, sondern um AMD und dessen Konkurrenz bzw. das Release Timing von Zen6.

Das weiß im übrigen auch AMD, oder vielleicht auch nicht. Weil, die würden sich ja sicherlich nicht mit einem Nicht-PC vergleichen, oder? Weil Apple baut ja keine PCs und damit keine Konkurrenz zu AMD. :D
https://s1.directupload.eu/images/251210/rg9eqvgz.png
Neee jetzt mal ernsthaft. Kein Plan in welcher Welt du lebst, da lebt die Welt aber nicht mit.

[Nightspider]

Auf jeden Fall hatte Apple immer einen Vorsprung bei den Fertigungsverfahren.

Der M5 in N3P ist quasi 1 Node weiter als Zen5.

Mit Zen6 wird dieser Vorteil auf jeden Fall verschwinden. Dann wird man die Architekturen besser vergleichen können.

Nur die APUs werden weiterhin teilweise einen Node hinterherhängen.

[HOT]

Es geht aber nicht um dich hier im Thread, sondern um AMD und dessen Konkurrenz bzw. das Release Timing von Zen6.

Das weiß im übrigen auch AMD, oder vielleicht auch nicht. Weil, die würden sich ja sicherlich nicht mit einem Nicht-PC vergleichen, oder? Weil Apple baut ja keine PCs und damit keine Konkurrenz zu AMD. :D
https://s1.directupload.eu/images/251210/rg9eqvgz.png
Neee jetzt mal ernsthaft. Kein Plan in welcher Welt du lebst, da lebt die Welt aber nicht mit.

Meine Welt beinhaltzet jedenfalls keine totalen Äpfel/Bírnen-Vergleiche. Apple ist hier schlichtweg OT, weil das komplett getrennte Ökosysteme sind. In meinen Augen ist das alles Fanboygehabe, ständig in PC-Threads zu wiederholen, wie geil Apple ist. Das ist keinen Deut besser wie zu PowerPC-Zeiten. Und jetzt mit irgendnem Marketing-Blödsinn von AMD zu kommen ist lächerlich, Marketing nutzt jeden Strohhalm um sich toll darzustellen.

[rentex]

Apple ist hier OT. Back to topic plz.

[Der_Korken]

Ich bin gerade zufällig auf diesen von Kepler verlinkten Tweet gestoßen: https://forums.anandtech.com/threads/zen-6-speculation-thread.2619444/page-322#post-41546781

Es sieht so aus, als würde der in Zen 5 eingeführte Unified Scheduler auf Integer-Seite mit Zen 6 wieder verschwinden und stattdessen durch 6 Scheduler (von 0 bis 5) ersetzt. Dadurch könnte es wieder so wie Zen 3/4 aussehen, nur eben breiter (die haben 4 Scheduler mit je 2 Ports). Wie genau sich die Ports dann bei Zen 6 aufteilen ist natürlich noch nicht bekannt. Zen 5 hat 6 ALUs und 4 AGUs.

Wenn man davon ausgeht, dass AMD die ALUs nicht direkt wieder erhöht, könnte es je eine ALU pro Scheduler geben und die AGUs werden entsprechend verteilt, wie bei Zen 3/4. Dann hätte man zwei Scheduler mit nur einem Port. Mögliche Optionen:
- AMD geht auf 6 AGUs hoch, was aber schon etwas übertrieben wäre
- AMD zieht die Branch-Units wieder aus den ALUs raus und wir hätten 6xALU, 4xAGU und 2xBranch. Dadurch würde der ALU-Durchsatz indirekt steigen, weil Branch-Ops dann keine ALU-Ports mehr belegen.
- Die Anordnung ist völlig anders als bei Zen 3/4, z.B. exklusive AGU- und ALU-Scheduler, die dann zueinander keine "Symmetrie" mehr haben.

Für einen eigentlich kleinen Architekturschritt ist das eine überraschend große Änderung. Ich finde leider auf die Schnelle das Interview nicht mehr, aber ich meine, dass Mike Clark mal gesagt hat, dass sie auf einen Unified Scheduler umgestiegen sind, weil der Ansatz von Zen 3/4 nicht so gut mit mehr ALUs skaliert. Der Grund ist, dass sich in einem Scheduler die Instruktionen stauen, obwohl in einem anderen Ressourcen frei wären, weil man die Instruktionen zu Beginn schlecht einsortiert hat. Je mehr verteilte Scheduler, desto größer die Chance CPU-Zyklen zu verschenken durch ungünstige Verteilung. Dafür ist ein Unified Scheduler extrem komplex und sicherlich weniger effizient bei gleichem theoretischen Durchsatz.

Irgendwas muss AMD an Zen 5 aber nicht gefallen haben, dass die das so schnell wieder umschmeißen. Und es wäre eine Erklärung für einen eventuell (ver)spät(et)en Release von Zen 6.

[latiose88]

hm das würde auch erklären warum sich Zen 5 bei mehr Kernen so schlecht skaliert hat.Es war ungünstig gewesen.Es war echt hinter den Erwartungen .Vielleicht wird Zen 6 ja umso besser werden,wer weis aber leider wird er zu Spät kommen.Bis dahin habe ich schon längst ein neues System.Ist ja noch viele Monate bis dahin hin.

[Der_Korken]

hm das würde auch erklären warum sich Zen 5 bei mehr Kernen so schlecht skaliert hat.Es war ungünstig gewesen.Es war echt hinter den Erwartungen .Vielleicht wird Zen 6 ja umso besser werden,wer weis aber leider wird er zu Spät kommen.Bis dahin habe ich schon längst ein neues System.Ist ja noch viele Monate bis dahin hin.

Alles, was ich beschrieben habe, bezieht sich auf einen Kern. Auf gute oder schlechte Skalierung über mehrere Kerne können sich nur Ressourcen beziehen, die sich mehrere Kerne teilen, z.B. der L3, die IF-Links oder der IOD.

[latiose88]

achso das spielt keine Rolle ob Intel oder AMD,wenn dann sowas wie AVX nicht Leistung bringt sondern kostet,wird es an Limit bei Stromverbrauch,zu wenig L3 Cache oder das von dir beschriebene sein.
Bei Intel ist es AVX 1 & 2 wo Leistung kostet.Bei AMD kostet das nichts sondern bringt Leistung.
Ich frage mich warum es da so viele Abweichungen gibt.Kann man das ebenso Erklären oder nicht?
Und beimm L3 wurde ja bei Zen 5 nichts geändert,aber ja der L2.Wobei der ja pro Kern fest zugeteilt ist und der IOD ist ja der selbe wie bei Zen 4.Also könnte sich wenn dann der IF Link geändert haben bei Zen 5 gegenüber Zen 4.

[x-force]

Meine Welt beinhaltzet jedenfalls keine totalen Äpfel/Bírnen-Vergleiche. Apple ist hier schlichtweg OT, weil das komplett getrennte Ökosysteme sind. In meinen Augen ist das alles Fanboygehabe, ständig in PC-Threads zu wiederholen, wie geil Apple ist. Das ist keinen Deut besser wie zu PowerPC-Zeiten. Und jetzt mit irgendnem Marketing-Blödsinn von AMD zu kommen ist lächerlich, Marketing nutzt jeden Strohhalm um sich toll darzustellen.

einige menschen sehen ihren rollstuhl auch als enablement, weil sie ganz bequem zur fortbewegung die beine nicht mehr bewegen müssen ;)

[robbitop]

Ich bin gerade zufällig auf diesen von Kepler verlinkten Tweet gestoßen: https://forums.anandtech.com/threads/zen-6-speculation-thread.2619444/page-322#post-41546781

Es sieht so aus, als würde der in Zen 5 eingeführte Unified Scheduler auf Integer-Seite mit Zen 6 wieder verschwinden und stattdessen durch 6 Scheduler (von 0 bis 5) ersetzt. Dadurch könnte es wieder so wie Zen 3/4 aussehen, nur eben breiter (die haben 4 Scheduler mit je 2 Ports). Wie genau sich die Ports dann bei Zen 6 aufteilen ist natürlich noch nicht bekannt. Zen 5 hat 6 ALUs und 4 AGUs.

Wenn man davon ausgeht, dass AMD die ALUs nicht direkt wieder erhöht, könnte es je eine ALU pro Scheduler geben und die AGUs werden entsprechend verteilt, wie bei Zen 3/4. Dann hätte man zwei Scheduler mit nur einem Port. Mögliche Optionen:
- AMD geht auf 6 AGUs hoch, was aber schon etwas übertrieben wäre
- AMD zieht die Branch-Units wieder aus den ALUs raus und wir hätten 6xALU, 4xAGU und 2xBranch. Dadurch würde der ALU-Durchsatz indirekt steigen, weil Branch-Ops dann keine ALU-Ports mehr belegen.
- Die Anordnung ist völlig anders als bei Zen 3/4, z.B. exklusive AGU- und ALU-Scheduler, die dann zueinander keine "Symmetrie" mehr haben.

Für einen eigentlich kleinen Architekturschritt ist das eine überraschend große Änderung. Ich finde leider auf die Schnelle das Interview nicht mehr, aber ich meine, dass Mike Clark mal gesagt hat, dass sie auf einen Unified Scheduler umgestiegen sind, weil der Ansatz von Zen 3/4 nicht so gut mit mehr ALUs skaliert. Der Grund ist, dass sich in einem Scheduler die Instruktionen stauen, obwohl in einem anderen Ressourcen frei wären, weil man die Instruktionen zu Beginn schlecht einsortiert hat. Je mehr verteilte Scheduler, desto größer die Chance CPU-Zyklen zu verschenken durch ungünstige Verteilung. Dafür ist ein Unified Scheduler extrem komplex und sicherlich weniger effizient bei gleichem theoretischen Durchsatz.

Irgendwas muss AMD an Zen 5 aber nicht gefallen haben, dass die das so schnell wieder umschmeißen. Und es wäre eine Erklärung für einen eventuell (ver)spät(et)en Release von Zen 6.

Meine Vermutung: es sind nicht notwendigerweise immer technische iterative Gründe. Insbesondere wenn uArchs schnell hinterhereinander kommen. Dann hat man mehrere leapfrogging teams. Angeführt von Menschen. Und wir Menschen sind nicht selten verheiratet mit ihren Ansichten und Ideen und Methoden und Philophien. Selbst wenn es auch mal eine bessere Lösung gibt. Ggf ist es einer dieser Momente wo Team 1 ein fan von unified schedulern ist (bzw der der das zu sagen hatte) und das andere nicht.

Kann natürlich auch völlig anders sein. Aber sowas sehe ich in meinem Berufsumfeld viel viel öfter als es mir lieb ist und ich kann mir sehr gut vorstellen, dass sowas überall der Fall sein kann.

[Der_Korken]

Meine Vermutung: es sind nicht notwendigerweise immer technische iterative Gründe. Insbesondere wenn uArchs schnell hinterhereinander kommen. Dann hat man mehrere leapfrogging teams. Angeführt von Menschen. Und wir Menschen sind nicht selten verheiratet mit ihren Ansichten und Ideen und Methoden und Philophien. Selbst wenn es auch mal eine bessere Lösung gibt. Ggf ist es einer dieser Momente wo Team 1 ein fan von unified schedulern ist (bzw der der das zu sagen hatte) und das andere nicht.

Kann natürlich auch völlig anders sein. Aber sowas sehe ich in meinem Berufsumfeld viel viel öfter als es mir lieb ist und ich kann mir sehr gut vorstellen, dass sowas überall der Fall sein kann.

Bei dem großen zeitlichen Abstand zwischen Zen 5 (der wegen der parallelen Entwicklung auf zwei Nodes eh etwas zäh in der Entwicklung war) und Zen 6 (sofern er erst Ende 26 kommt), wäre das aber schon verwunderlich, wenn man quasi wieder auf einen vier Jahre alten Stand zurückgeht bezüglich Scheduler. Solche Divergenzen will man intern doch sicher nicht haben.

[robbitop]

Naja das sind halt zwei verschiedene Ansätze. Alt gilt nur im Zusammenhang der Historie mit Zen. Intel verbaut iirc seit Jahrzehnten unified scheduler. AMD hat sich aufgrund der Komplexität lange dagegen entschieden. Und die nimmt mit wachsender Breite zu. Beides hat je nach Situation sein für und sein wider. Und wie gesagt: nicht auszuschließen dass es da auch immer mal wieder einen subjektiven bias gibt. :)
Sah man in Intels leapfrogging Entwicklung auch öfter mal was das eine und was das andere Team an Philosophien so favorisierte und Dinge folgen dann augenscheinlich raus (Team 2 brachte die Nachfolge uArch) und kamen dann wieder (Team 1 baut den Nachfolger des Nachfolgers).

[iamthebear]

Ich finde leider auf die Schnelle das Interview nicht mehr, aber ich meine, dass Mike Clark mal gesagt hat, dass sie auf einen Unified Scheduler umgestiegen sind, weil der Ansatz von Zen 3/4 nicht so gut mit mehr ALUs skaliert. Der Grund ist, dass sich in einem Scheduler die Instruktionen stauen, obwohl in einem anderen Ressourcen frei wären, weil man die Instruktionen zu Beginn schlecht einsortiert hat. Je mehr verteilte Scheduler, desto größer die Chance CPU-Zyklen zu verschenken durch ungünstige Verteilung. Dafür ist ein Unified Scheduler extrem komplex und sicherlich weniger effizient bei gleichem theoretischen Durchsatz.

Vielleicht ist AMD aber auch etwas Besseres eingefallen, um das "Stauen" von Befehlen zu vermeiden.

So ganz klar ist mir sowieso nicht was AMD da vor hat:
.) N2 hat ähnliche Kosten/Transistor wie N5
.) Gleichzeitig wird die Kernanzahl um 50% erhöht

Da sehe ich jetzt nicht unbedingt viel Transistorbudget um die Kerne viel weiter aufzublasen nachdem man das schon mit Zen 5 gemacht hat. Vielleicht geht man in einigen Aspekten auch wieder zurück zu Zen 4.

[Badesalz]

Die Idee mit leapfrogging ist, daß sich irgendwann das bessere herauskristalisiert und jemand der drüber steht entscheidet, daß nun nur noch das gemacht wird. Nicht ein jahrzehntelanges Hü und Hott.

Funfact des Tages: Die allerersten Zen9 Gerüchte kommen vor dem Launch von GTA6.

[robbitop]

AMD und Intel nutzen „leapfrogging teams“ genau in demvon mir beschriebenen Kontext iirc. Und das sind native speakers ;)

[Badesalz]

Ähh... ja. Hab vergessen "pro Idee" dabei zu schreiben ;)

@Der_Korken
Der PR-Plot war eher eindeutig, daß Zen5 an vielen Stellen Sachen einführt die schon so ok sind, aber erst bei Zen6 so richtig aufgehen.
Hmm...

[robbitop]

Dann meinten wir unterschiedliche Kontexte :)

[reaperrr]

Die Idee mit leapfrogging ist, daß sich irgendwann das bessere herauskristalisiert und jemand der drüber steht entscheidet, daß nun nur noch das gemacht wird. Nicht ein jahrzehntelanges Hü und Hott.
Falsch, jedenfalls in diesem Fall.

Leapfrogging dient bei AMD einerseits dazu, internen Konkurrenzdruck zu haben, dass sich die Teams gegenseitig zu Höchstleistungen pushen, und andererseits eben nicht immer nur in 2-Jahres-Schritten denken zu müssen, sondern sich für eine neue Gen auch mal 4-5 Jahre Zeit nehmen zu können.

AMD hat jedenfalls 2 Teams:
Nach Fertigstellung von Zen1 hat Team 1 Zen2 gemacht, während Team 2 schonmal mit Zen3 angefangen hat.
Das Zen3-Team hat auch die Iteration Zen4 gemacht, während das Zen2-Team nach Zen2 mit Zen5 angefangen hat und anschließend zu Zen6 übergegangen ist.

Das Team von Zen3/4 arbeitet voraussichtlich hauptsächlich an Zen7, mit Vorbereitungen für Zen8.

Bei dem großen zeitlichen Abstand zwischen Zen 5 (der wegen der parallelen Entwicklung auf zwei Nodes eh etwas zäh in der Entwicklung war) und Zen 6 (sofern er erst Ende 26 kommt), wäre das aber schon verwunderlich, wenn man quasi wieder auf einen vier Jahre alten Stand zurückgeht bezüglich Scheduler. Solche Divergenzen will man intern doch sicher nicht haben.
Es gab das Gerücht, dass Zen5 auch deshalb kein ganz so großer Sprung wie gehofft geworden ist, weil das Team als Startpunkt Zen2 genommen hat, weil sie da besser drinsteckten, und Zen5 deshalb einige der Verbesserungen und Optimierungen, die Zen3/4 schonmal hatten, noch nicht/nicht mehr drin hat.
Kann gut sein, dass sie aus Zeitgründen sich erst nach festzurren von Zen5 einige der Zen3/4-Optimierungen im Zuge der Zen6-Entwicklung nochmal genauer angeschaut, und was sich bewährt hat zum Zen5/6-Zweig portiert haben.

Grundlos werden sie den "Rückschritt" beim Scheduler-Ansatz jedenfalls nicht machen.

Manche Dinge klingen auf dem Papier halt toll und funktionieren vielleicht auch noch ganz gut in Simulationen, nur um sich dann im Endprodukt mit echter Software aus Gründen, die man nicht bedacht oder unterschätzt hatte, in Sachen Perf/W/mm² als nicht besser oder gar schlechter als ein vorheriger, simplerer Ansatz herauszustellen.

Von der Entwicklungszeit auf den Umfang der Änderungen schließen kann man übrigens nicht unbedingt.
Zum Einen, weil die schwindenden Prozess-Fortschritte architekturseitige Takt- und Effizienz-Optimierungen immer wichtiger werden lassen, zum Anderen, weil - ähnlich wie bei Zen4, der gemessen am zeitlichen Abstand zu Zen3 jetzt auch wenig bahnbrechendes brachte - auch die I/O-Dies und die Reife des N2(P)-Prozesses für den Marktstart eine Rolle spielen.

Vielleicht ist AMD aber auch etwas Besseres eingefallen, um das "Stauen" von Befehlen zu vermeiden.

So ganz klar ist mir sowieso nicht was AMD da vor hat:
.) N2 hat ähnliche Kosten/Transistor wie N5
.) Gleichzeitig wird die Kernanzahl um 50% erhöht

Da sehe ich jetzt nicht unbedingt viel Transistorbudget um die Kerne viel weiter aufzublasen nachdem man das schon mit Zen 5 gemacht hat. Vielleicht geht man in einigen Aspekten auch wieder zurück zu Zen 4.
Kosten/Transistor sind nicht ganz so dramatisch, die CPUs haben trotzdem ne viel bessere Marge pro mm² als z.B. Desktop-GPUs.
Ich will gar nicht wissen, wieviel mehr AMD an einem 9800X3D im Vergleich zu einer 9070 verdient.

Aber ansonsten ja, wesentlich fetter als Zen5 wird Zen6 definitiv nicht.
Es wird in erster Linie darum gehen,
- Flaschenhälse im INT-Bereich zu weiten/entfernen,
- eine Reihe kleinerer "low-hanging fruits" zu picken (ROB von 448 auf 512+, einige Optimierungen von Zen4 zurückbringen usw.),
- Taktraten so weit wie möglich hochzuschrauben, ohne groß die Pipeline zu verlängern,
- Rest kommt durch größeren CCD (bis zu 50% mehr L3 für einzelne Threads), Unterstützung für schnelleren Speicher, effizienteren und schnelleren IOD (lässt mehr TDP für Kerne, niedrigere "Strafe" wenn Daten zwischen CCDs ausgetauscht werden)

[Der_Korken]

@reaperrr:

Kurioserweise ist der INT-Scheduler bei Zen 5 ja eine Neuentwicklung und keine Altlast von Zen 2. Letzterer hatte pro ALU-Port einen eigenen Scheduler und einen gemeinsamen Scheduler für alle AGUs (interessanterweise genauso wie Apples Firestorm). Das heißt, das Zen 5 Team ist über die Aufteilung von Zen 3/4 in gewisser Weise hinausgeschossen und rudert jetzt zurück.

[robbitop]

Ggf hat man eingesehen dass die Vorteile die deutlich erhöhte Komplexität nicht aufwiegt. Unified scheduler gibt es ja schon ewig.

[Badesalz]

Falsch, jedenfalls in diesem Fall.Ah? Aber Zen5-Team kann und darf sich die Sachen anschauen wie auch übernehmen, die Team-Zen3/4 gebastelt hat? Na dann hast du meinen Kontext diesbezüglich herausgefunden :wink:
Aber ansonsten ja, wesentlich fetter als Zen5 wird Zen6 definitiv nicht.
Es wird in erster Linie darum gehen, Das ist Binse

[basix]

Bild vom 256C Zen 6 Chip:
https://youtu.be/TvBNWbFK2lY?t=1311

[HPVD]

Bild vom 256C Zen 6 Chip:
https://youtu.be/TvBNWbFK2lY?t=1311

und hier auch ein Artikel zum Package:
https://www.computerbase.de/news/prozessoren/epyc-venice-delidded-nackte-zen-6-cpu-duerfte-auch-die-zukunft-von-ryzen-zeigen.95664/

[HOT]

Hier noch mal ein Venice-Bild. Sind 2 IODs zu erkennen.


https://pics.computerbase.de/1/2/0/7/9/6-ff401fb6493ffe18/3-2160.8ad3c0ea.jpg


Das könnten auch 96 Kerne sein, ich glaube, es gab keine konkrete Aussage dazu, wieviele das sind.

[Der_Korken]

In Relation zu den IODs wären die Dies viel zu groß für nur 12 Kerne. Ich habe auch so das Gefühl, dass Zen 6C diesmal früher als Zen 6 kommt. Dass man 32C zuerst zeigt und nach über einem Jahr nochmal neue Flagschiffe von Zen 5 auflegt, sind für mich deutliche Hinweise.

[Skysnake]

Jetzt wird es spannend. Ich bin mal auf euren Spekulatius gespannt und hole mein Popcorn:D

[Badesalz]

Bezüglich welches Thema genau? :smile: Package?

Komm. Erzähl schon Stückchen was... :wink:

[Skysnake]

Sorry, ich habe keinerlei Überblick was da wann wo wie noch unter NDA steht oder nicht. NN da irgendwelche Dinge zu lenken. Mir ist das zu heiß.

Ich bin aber wie gesagt gespannt was von euch da kommt, weil auch die Hersteller da nicht immer reinen Wein einschenken.

Daher immer selbst die HW mit den eigenen Problemen verproben wenn man wirklich verlässliche Daten haben will. Bei allem anderen läuft man Gefahr bewusst oder unbewusst massiv falsche Daten zu bekommen.

Das ganze Zeug ist heutzutage einfach nur noch abartig komplex und die überwiegende Menge an Entwicklern hat keinen Plan davon. Selbst innerhalb der Hersteller fehlt da in weiten Teilen in meinen Augen ein Problembewusstsein.

Wir rennen da einfach gegen die Wand. Egal wohin man schaut. Ist zumindest mein Eindruck.

[w0mbat]

Was meinst du mit NDA? CES war gerade. Wieso solltest du vor einem NDA Angst haben?

[Der_Korken]

Zu Zen 6 gab es seit Ewigkeiten keine interessanten Leaks mehr bis auf die Sache mit den verteilten INT-Schedulern. Die Anzahl der Kerne (12/32) wurden gefühlt schon vor einem Jahr geleakt, wobei natürlich völlig offen ist, ob es überhaupt stimmt. Dass die CCDs im Desktop nicht mehr per IFOP, sondern InFO-* angebunden werden, kann man nach den gezeigten Venice-Bildern imho als sicher ansehen. Für Idle- und Teillast-Verbrauch wird das ein großer Schritt nach vorne, aber auch für Volllast nimmt man 10-20W weniger Verbrauch durch das Package gerne mit.

Damit sind die interessantesten Punkte imho auch durch. IPC erwarte ich persönlich keinen großen Wurf. Eventuell überrascht uns der Takt durch N2 noch etwas, aber meine Erwartung liegt da irgendwo bei 6,0-6,2Ghz für das Single-CCD-X3D-Modell (was mal eben satte 800-1000Mhz höher als der 9800X3D sind!).

Die spannenste Frage, wo wir imho immer noch völlig im Dunkeln tappen, ist das Release-Datum für den Desktop. Von "Sommer 2026" bis "auf Frühjahr 2027 verschoben" ist alles offen.

[amdfanuwe]

Die Anzahl der Kerne (12/32) wurden gefühlt schon vor einem Jahr geleakt, wobei natürlich völlig offen ist, ob es überhaupt stimmt.
Die 32 c-Kerne sollten nach der Venice Vorstellung als sicher gelten, 256 Kerne bei 8 CCDs.
12 Kern CCD scheint mir auch sicher.
Aber das damit nur 92 Kern Venice erscheinen sollen??
Ich könnte mir vorstellen, dass da 2 CCDs hintereinander oder gestackt auch 192 Kern Venice kommen werden.

Bin mal gespannt, was die 8 kleinen Chips an der Seite bei Venice sind. MCD oder PCIe?

[Der_Korken]

Die 32 c-Kerne sollten nach der Venice Vorstellung als sicher gelten, 256 Kerne bei 8 CCDs.
12 Kern CCD scheint mir auch sicher.
Aber das damit nur 92 Kern Venice erscheinen sollen??
Ich könnte mir vorstellen, dass da 2 CCDs hintereinander oder gestackt auch 192 Kern Venice kommen werden.

Ich würde das so interpretieren, dass die klassischen Kerne zu "Hochtaktmodellen" werden. Von denen gibt es dann in Zukunft "nur" noch 96 Kerne pro Sockel. Eventuell hat sich der aktuelle 128er Epyc schon nicht gut verkauft gegen gleichteure 160er mit Zen 5C, sodass AMD sich sagt: Entweder jemand will max. MT kaufen, dann ist derjenige auch mit mit Zen 6C zufrieden. Oder jemand hat gemischte Workloads und braucht auch zwischendurch viel ST-Leistung, aber diese Kunden brauchen fast nie mehr als 96 Kerne. Auf diese Weise kann AMD 8 IF-Links zu CCDs verbauen und muss in den maximalen Ausbauten jeweils keine IF-Links brach liegen lassen (so wie aktuell mit 192C, die nur 12 der 16 Links nutzen).

[Badesalz]

Sorry, ich habe keinerlei Überblick was da wann wo wie noch unter NDA steht oder nicht.Wenn du dir unsicher bist, dann lass dich lieber nicht ködern :tongue: Alles gut.
Das ganze Zeug ist heutzutage einfach nur noch abartig komplex und die überwiegende Menge an Entwicklern hat keinen Plan davon. Selbst innerhalb der Hersteller fehlt da in weiten Teilen in meinen Augen ein Problembewusstsein.

Wir rennen da einfach gegen die Wand. Egal wohin man schaut. Ist zumindest mein Eindruck.Da möchte ich einmal ansetzen :smile: Du wiederholst das nicht ständig, aber kontinuierlich. Aus welcher Sicht? Des Kernels? Des Treibers? Der Anwendung? Oder geht es dir (wahrscheinlich) einfach eher darum, daß all die Sachen immer dürftiger skalieren? (in Anbetracht der Leistung pro Sockel)

So eine Art insider gag diesbezüglich brachte vor paar Monaten imho Gina Tourassi zu "Discovery", wo sie einerseits erwähnt, daß sie an einem großem Problem jetzt auch schneller rechnen können werden, aber:
"But the second dimension that I find even more exciting, with exascale computing, we are able to pursue multiple problems at the same time."

Ergo, ja, alles skaliert immer schlechter mit weiter steigenden Dimensionen, aber wir können jetzt in kleineren Dimensionen viel mehr parallel laufen lassen :up: Es geht also weniger um die Exascale-Probleme, sondern um die Hunderte Peta-Scale Probleme die jetzt auf einem einzigen Eisen laufen können. An sich wäre Exascale also wohl nur eine Art Konsolidierung für Petascale.
Wie sich das so anhört.

Das insider know-how hast aber nur du hier.

[HOT]

In Relation zu den IODs wären die Dies viel zu groß für nur 12 Kerne. Ich habe auch so das Gefühl, dass Zen 6C diesmal früher als Zen 6 kommt. Dass man 32C zuerst zeigt und nach über einem Jahr nochmal neue Flagschiffe von Zen 5 auflegt, sind für mich deutliche Hinweise.

Mit Sicherheit nicht. Erst wird Consumer kommen, dann Server und die könnte es dann gleichzeitig geben, scheinen ja auch gleichzeitig fertig zu werden für Venice.

[Skysnake]

Allem.

Die Hardware entspricht teilweise nicht mehr dem NUMA Konzept. Das bricht sowohl Kernel, Middle Ware als auch Anwendungen. In den Benchmarks wird das gerne durch die Nutzung aller Kerne mit einer Anwendung überdeckt. Real hat man aber oft die Situation das mehrere Anwendungen parallel auf einem Knoten laufen. Das sehe ich als eines der Hauptprobleme.

Dann gibt es aber auch Bugs in sehr verbreiteter Middleware, was massiv Probleme bereitet und das seit Jahren. Hab dieses Jahr nen Bug identifiziert der wohl seit ca 5 Jahren in ner HPC Middleware steckt die vermutlich >90% benutzen.

Naja und dann gibt es im Kernel auch Probleme mit dem.Spwichermanagwment. Also zumindest unter RH8.

Überhaupt mit RH8 ist es echt zu vielen Problemen gekommen und ich sehe nicht das es mit 9 besser werden wird.

Es gab schon immer Probleme die man so richtig erst at scale gesehen hat. Aber die Häufigkeit wird echt unangenehm...

Auf der einen Seite entwickelt sich Software einfach zu schnell weiter wodurch Sie keine Zeit mehr hat zu reifen und auf der anderen Weite entwickeln sich die Softwarestacks viel zu langsam, weil die Hardware immer schneller voran schreitet.

Das aller größte Problem ist aber in meinen Augen aktuell dass das Speichermodell das Programmierer sehen/kennen nicht mehr zu dem passt was die Hardware wirklich kann/macht. Blöd das selbst die HW Hersteller das teils nicht dokumentieren bzw von der Dokumentation abweichen. Wie soll da bitte Software entstehen die richtig funktioniert?

Das Schlimme ist, das ein Großteil der Entwickler aber nicht mal wissen das Sie auf einem riesigen Problemberg sitzen, weil Sie mir layer on Layer on Layer on Layer on Layer Software arbeiten und gleichzeitig Null Ahnung davon haben die eine CPU oder GPU wirklich funktioniert. Daher wissen Sie aber eben auch nicht was möglich ist und was nicht.

Ich sitze regelmäßig mit Stift und Papier da und rechne aus ob das alles passt und sehe halt oft genug, dass das eben nicht der Fall ist und damit den nächsten PerformanceBug. Das machen aber glaub die wenigsten.

[Nightspider]

Dann gibts ja für die Technologische Singularität viele low hanging fruits. ^^

[Skysnake]

Woher soll ne KI das aber wissen?

Du MUSST gegen 99.9999999999% des aktuell vorhandenen Wissens agieren, das es funktioniert und sie gesagt teils sogar gegen die Dokumentation der Hersteller..

[Badesalz]

Irgendjemand müsste - für das Kernel und Treiber Volk - einen AI-Tracer machen :usweet:

[Nightspider]

Eine AGI füttert man in so einem Fall wohl eher mit den Bauplänen und nicht mit fehlerhaften Dokumentationen.
Eine AGI wäre einem Ingenieur, ob für Software oder Hardware, meilenweit überlegen. Bei numerischen Aufgaben und dem durchsimulieren von vers. Parametern würde so eine AGI in kürzester Zeit uns Menschen hinter sich lassen und sich selbst softwareseitig erstmal extrem weiterentwickeln und den Codemüll Richtung perfektem Assemblercode verschieben, ohne abertausende Overhead-Layer. Da würde auch kein Mensch mehr durchsteigen.

Ist natürlich OT hier.

Aber das Ziel vieler AI Firmen ist ja eine AGI in den nächsten Jahren zu erreichen. Und was eine einzige popelige 5090 schon erzeugen kann ist heftig.

[Badesalz]

Es gibt keine AGIs und keiner hat einen Plan ob und wann es sie geben könnte. Weil sie offensichtlich schonmal nicht auf GPUs entstehen werden.

Warum sollte man beim ASM nicht durchsteigen? Das erste was man ihr fest beibringt ist wie man Kommentare schreibt :D Sie muss sich dann schon selbst dokumentieren.

PS:
Und natürlich auch NASA/Holzmann "The rule of 10" :wink:
http://web.eecs.umich.edu/~imarkov/10rules.pdf

edit:
Und was eine einzige popelige 5090 schon erzeugen kann ist heftig.Das wäre?

[Badesalz]

1. Bisschen PR für Helios
https://www.hpcwire.com/2026/01/07/amd-gives-us-a-peek-at-upcoming-helios-system-mi500-gpus-at-ces/

2. Jemand eine Erklärung was so ein Shic auf der CES verloren hat?

[rentex]

1. Bisschen PR für Helios
https://www.hpcwire.com/2026/01/07/amd-gives-us-a-peek-at-upcoming-helios-system-mi500-gpus-at-ces/

2. Jemand eine Erklärung was so ein Shic auf der CES verloren hat?

Außer KI, hat NV und AMD nichts in der Hand...warum auch, gibt dort die meiste Kohle.

[Badesalz]

Ah guck. Hardwarejesus ist das noch mehr aufgestoßen als mir :biggrin:

Der bingts mal wieder echt auf den Punkt.

[samm]

Außer KI, hat NV und AMD nichts in der Hand...warum auch, gibt dort die meiste Kohle.Sie hätten schon ein paar Produkte im Bereich CONSUMER electronics, die sie konkreter vorstellen könnten (Die X3D(2)-Prozessoren, Mobile Designs), oder eben, passend zum Thread, Zen 6 Vorschau. Stattdessen wird halt im Kreis gew*chst wegen AI, und dann noch mit so unangenehm peinlichen Gästen auf der Bühne.

[ChaosTM]

Sobald effizientere Asics die meisten Anwendungsgebiete der(Brute Force) GPU`s bezüglich AI abdecken können, was definitiv länger dauern wird als bei den Mining Booms, ist alles wieder beim alten..

Same old, aber dauert noch..

[samm]

Chips And Cheese haben ein bisschen was zu Venice und MI400.

Der 256 Core Venice sieht ganz schön komplex aus, mit zusätzlichen Dies und neuem (für Non-Instinct Epyc zumindest) interconnects:

https://chipsandcheese.com/p/ces-2026-taking-the-lids-off-amds

[Nightspider]

Zen2 CCD: 2*4 Core 2*16 MB L3 TSMC N7 ~77 mm2

Zen3 CCD: 8 Core 32MB L3 TSMC N7 ~83 mm2

Zen4 CCD : 8 Core 32MB L3 TSMC N5 ~72 mm2

Zen5 CCD : 8 Core 32MB L3 TSMC N4 ~71 mm2

Zen6 CCD : 12 Core 48MB L3 TSMC N2 ~76 mm2

https://x.com/9550pro/status/2017245821738316188



Regular Zen6 should be September/October

X3D probably at CES 2027

[horn 12]

Dann günstig auf 9800 X3D aufrüsten und Sommerloch 2027 den Zen 6 X3D Nachschieben!

[Semmel]

Das dauert noch ganz schön lange.
Der Non-X3D wird zwar sicher auch einen guten Sprung machen, aber gegenüber einem Zen5 X3D trotzdem kein Fortschritt sein. (aus reiner Gaming-Sicht)

[Nightspider]

Wenn Zen6 viel schnelleren RAM unterstützt wird man in etlichen Spielen auch vor Zen5X3D liegen.

Aber die Diskussion hatten wir hier schon mind. 2 mal. Hängt von vielen Variablen ab.

[Daredevil]

Perplexity Research sagt zu den Kosten foljendes:
Zen2 (N7): $0,12-0,14/mm²
Zen3 (N7): $0,12-0,14/mm²
Zen4 (N5): $0,19-0,21/mm²
Zen5 (N4): $0,22-0,25/mm²
Zen6 (N2): $0,37-0,42/mm²
Somit also statt bislang 28-32$ deftige 53-60$ aufgrund von Waferkosten, Mitbewerber und Yield.

Wer also denkt, dass wird nen "easy" buy, der wird spätestens bei der Preisgestaltung ziemlich überrascht werden, zumal sich die halbe Welt um N2 streitet und manche sich dem auch abkehren, nicht weil es sehr gut ist, sondern eben extrem teuer. Ich denke aber auch, dass dies seit langem mal wieder ein enormer Sprung für AMD wird. Mehr Cache, sicherlich schnellerer Speicher, neue Architektur und der neue Aufbau wird das schon seine Kohle wert sein. Die Zeiten der neuen 200€ Gaming Prozessoren ist damit aber vorerst auch vorbei, den Markt muss AMD aber auch nicht unbedingt mit Zen6 bedienen, weil sie den schon mit Zen4/Zen5 bedienen, quasi Konkurrenzlos. Freue mich sehr drauf und bin gespannt, wie AMD performed, wenn sie wie Apple nicht aufs Geld schauen und wirklich mal rausklotzen. :)

[Semmel]

Wenn Zen6 viel schnelleren RAM unterstützt wird man in etlichen Spielen auch vor Zen5X3D liegen.

Aber die Diskussion hatten wir hier schon mind. 2 mal. Hängt von vielen Variablen ab.

Ja, es gibt eine gewisse Schwankungsbreite. Sagen wir mal -5 % bis +5 % zum Zen5X3D. Das ist nichts, was einen Wechsel rechtfertigt. Dafür braucht es schon einen Zen6X3D.

Und meistens hat AMD übrigens die Erwartungen enttäuscht. ;)

[Daredevil]

Das ist nichts, was einen Wechsel rechtfertigt.
Hättest du nen 5800X3D/7800X3D gehabt, wären hier die Wechsel auch schwer zu rechtfertigen gewesen auf Zen5X3D, sofern du keine 1000-2000€*GPU im Rechner hast. ( oder nen dicken Deal gemacht hättest, was nicht der Norm entspricht )
Viele betreiben ihre CPU halt auch einfach dauerhaft in Teillast, weil sie denken sie müssten den heißen scheiß haben. Ein 9800X3D ist doch schon mit einer 5090 meistens unterfordert in 720p, je höher die Auflösung desto kleiner wird der Unterschied. So eine CPU heute gekauft reicht locker 1-2 GPU Generationen aus, weil sie durch KI perspektivisch eben auch nicht mehr so erforderlich sind.

Ich habe gestern mal FG ausgeschaltet auf meinem 5700X in 2077 und fahre mit knapp 80-90fps durch die Stadt, eigentlich müsste man von einem 9800X3D herabblickend eigentlich davon ausgehen, dass ich mit 25fps spiele. :D Es wird natürlich auch noch Szenen geben, wo es unter 60fps geht, deswegen habe ich ja FG. CPU Power wird manchmal aber einfach zu sehr überschätzt, gerade beim Gen2Gen wechsel. Duch die multifaktorellen Verbesserungen habe ich so ein Gefühl, das Zen6 hier besser oder gleichschnell sein wird, aber es wird einem natürlich nicht mit +50% vom Hocker hauen.

[Nightspider]

Ja, es gibt eine gewisse Schwankungsbreite. Sagen wir mal -5 % bis +5 % zum Zen5X3D. Das ist nichts, was einen Wechsel rechtfertigt. Dafür braucht es schon einen Zen6X3D.

Und meistens hat AMD übrigens die Erwartungen enttäuscht. ;)

Wie schon gesagt, da gibts noch viel zu viel Variablen, so das diese +-5% für die Tonne sind.

Bei Spielen die fast gar nicht auf X3D reagieren könnte Zen6 mal eben 30-40% vorne liegen. Erstmal müssen wir IPC und Taktraten abwarten.

Und die 50% mehr Kerne ohne Latency Tradeoff können in anspruchsvollen Spielen auch nochmal etwas ausmachen.

Das ein Counterstrike mit 12 Kernen jetzt nicht schneller laufen wird ist ja klar. Ich denke da auch eher an Star Citizen und Squadron42.

[Semmel]

Die Zeiten der neuen 200€ Gaming Prozessoren ist damit aber vorerst auch vorbei, den Markt muss AMD aber auch nicht unbedingt mit Zen6 bedienen, weil sie den schon mit Zen4/Zen5 bedienen, quasi Konkurrenzlos. Freue mich sehr drauf und bin gespannt, wie AMD performed, wenn sie wie Apple nicht aufs Geld schauen und wirklich mal rausklotzen. :)

Das sehe ich auch so.
Man merkt es ja jetzt schon an AMDs Modell- und Preispolitik.
Es gibt keine billigen Zen5X3Ds. Der 9800X3D ist das "billigste" Modell.
Nach unten wird nur mit Zen4X3D differenziert, sonst hätte man keinen 7500X3D gebracht und auf den 9600X3D offensichtlich verzichtet.

Mit Zen 6 könnte sich diese Entwicklung verstärken. Zen 6 für High End, Zen 5 für Midrange, Zen 4 für die Einsteiger und Zen 3 für den Pöbel. :D

Hättest du nen 5800X3D/7800X3D gehabt,

Äh, ich hatte doch einen 5800X3D. ;)
Den konnte ich dank der "Speicherkrise" kostenneutral in einen 9800X3D tauschen, sonst hätte ich das nicht gemacht. Mein Plan A war immer direkt auf Zen 6 zu warten. Aber eine gute Gelegenheit muss man nutzen, wenn man sie sieht. ;)

Hwären hier die Wechsel auch schwer zu rechtfertigen gewesen auf Zen5X3D, sofern du keine 1000-2000€*GPU im Rechner hast. ( oder nen dicken Deal gemacht hättest, was nicht der Norm entspricht )

Ich spiele zu 90 % Spiele, die fast nur im CPU-Limit sind. (Anno, Civ und so Zeug)
Da kann ich jede Mehrleistung durchaus sinnvoll nutzen. :)

[rentex]

Ich tendiere dazu, das ZEN6 Desktop, aufgrund der Marktlage später erscheint.
Release zur CES 2027 und X3D später.

[Nightspider]

Den Käse hast du letzten Monat auch schon geschrieben.

[reunion]

Perplexity Research sagt zu den Kosten foljendes:

Somit also statt bislang 28-32$ deftige 53-60$ aufgrund von Waferkosten, Mitbewerber und Yield.


Eine Metrik auf Basis von Preis/mm² ist unzureichend. Eine der wichtigsten Kriterien in der modernen Chipproduktion ist die Die-Size, sie beeinflusst Yield-rate, Verschnitt und Waferausnutzung.

Und die 50% mehr Kerne ohne Latency Tradeoff können in anspruchsvollen Spielen auch nochmal etwas ausmachen.


Mehr Kerne am Ringbus bedeuten allerdings auch generell mehr durchschnittliche Latenz für jeden Kern. Von daher ist die Aussage nur halb richtig.

[basix]

Mehr Kerne am Ringbus bedeuten allerdings auch generell mehr durchschnittliche Latenz für jeden Kern. Von daher ist die Aussage nur halb richtig.

Ob es Latenzsteigerungen innerhalb des CCX gibt wissen wir nicht. Zen 3/4/5 haben eine geringere Core-to-Core Latenz verglichen mit Zen 1/2, obwohl das CCX doppelt so viele Kerne hat. Die L3$ Latenz ist zwischen 1800X und 9950X taktnormiert auch ziemlich nahe beieinander (Zen 5 hat 46 cycles und 1800X hat 40 cycles), obwohl 4x Cache-Kapazität und 2x Cores pro CCX.

Der Vorteil bei N2 ist, dass man das Zeugs nahe zusammen packen kann. Und wenn die physischen Distanzen in etwa gleich bleiben (das CCD soll mit ~76mm2 ja in etwa gleich gross sein wie bei den Vorgängern), dann kann man von sehr ähnlichen Latenzen ausgehen.

[Daredevil]

Eine Metrik auf Basis von Preis/mm² ist unzureichend. Eine der wichtigsten Kriterien in der modernen Chipproduktion ist die Die-Size, sie beeinflusst Yield-rate, Verschnitt und Waferausnutzung.

Neuere Fertigung wird selten günstiger und das Gerücht sagt, der DIE wird größer. Insofern passt Preis pro Fläche doch insofern, weil der Preis pro Wafer sicher steigt und die große, falls das Gerücht stimmt, sicher steigt, was im gesamten einen deutlichen Preissprung bedeuten müsste. ( Muss nichts mit dem Endprodukt zutun haben, geht jetzt nur vom Sand zum DIE )
Oder übersehe ich was? ^^

Und das sehe ich auch allgemein nicht als negativ ein, nicht falsch verstehen.
Wenn das Ding leistet, soll es auch kosten. Apple verbaut ihren Kram auch teilweise enorm teuer, dafür haben sie eben halt auch the latest an greatest.

[rentex]

Den Käse hast du letzten Monat auch schon geschrieben.

Es wäre ja durchaus möglich...

[robbitop]

Ob es Latenzsteigerungen innerhalb des CCX gibt wissen wir nicht. Zen 3/4/5 haben eine geringere Core-to-Core Latenz verglichen mit Zen 1/2, obwohl das CCX doppelt so viele Kerne hat. Die L3$ Latenz ist zwischen 1800X und 9950X taktnormiert auch ziemlich nahe beieinander (Zen 5 hat 46 cycles und 1800X hat 40 cycles), obwohl 4x Cache-Kapazität und 2x Cores pro CCX.

Wobei das auch mit dem Reifeprozess zu tun haben könnte. Bei Zen war ja vieles neu. Und gerade am Anfang war ja vieles noch sehr unreif und hat große Sprünge gemacht. Ob ein Teil der Vernesserungen dann latenznormiert in größere CCX geflossen sind? Kann zumindest sein. Normalerweise ist der Mechanismus so dass je mehr Teilnehmer an einer fabric / mehr hops desto höher die Latenz. Einzelne Gegenbeispiele, die aber separate Gründe haben können, gibt es fast immer / bei jeder Regel. :)

IIRC wurde bei Zen 3 im CCX auf einen bidirektionalen ringbus umgestellt. Ob das damit ggf zu tun hatte? :)

[basix]

Der reine Fakt, dass man mehr Cores verwendet heisst nicht automatisch mehr Latenz. Natürlich muss man weitere Optimierungen vornehmen, damit bei mehr Teilnehmern die Latenz nicht steigt. Oder man ändert die CCX Netzwerk-Topologie. Aber ich denke das sollte klar sein und dürfte auch ganz klar eines von AMDs Zielen bei jeder neuen Zen Generation sein.

[robbitop]

Naja mir ging es darum dass sich bei deinem Beispiel wahrscheinlich mehrere Mechanismen überlagert haben.
Aber klar kann man das Ziel haben, die Latenz nicht weiter zu erhöhen auch von heute aus. Das braucht dann aber wieder eine diametralen Mechanismus der den Nachteil des besagten Mechanismus ausgleicht. Und hier ein wenig der Zweifel ob da so viel Potential übrig ist nachdem man bei Topologien jetzt schon wahrscheinlich weiter auf der Kurve des sinkenden Grenzertrags ist als noch in den frühen Tagen von Zen. Aber ich mag mich hier sehr gerne irren. :)

[Nightspider]

Der Ringbus wird ja auch mit jeder Generation leistungsfähiger (mehr Bandbreite, höherer Takt) was sicherlich einiges kompensiert, da kann man auch einen gewissen Sprung erwarten bei 2 Node Sprüngen. Und wenn die Cores, trotz höherer Anzahl, die kleiche Fläche belegen und damit näher beieinanderliegen werden zwischen manchen Kernen die Latenzen sogar geringer, wenn ich mich nicht irre. Je nachdem welche Cores gerade miteinander kommunizieren müssen. Denn der Abstand zu den nächsten 2-3 Kernen in jede Ring-Richtung sinkt ja erstmal.

Schlimmer als mit 2 CCDs, die über den IOD kommunizieren, kann es nicht werden. :D

Ich bin da eher mal auf die Cache-Dichte gespannt. Wenn AMD den L3 nicht auch wieder dichter packen würde, wären die 76mm² eigentlich nicht möglich.

Das V-Cache Stacking wird sicherlich auch verfeinert, mit wieder dichter gepackteren TSVs, was wieder Fläche beim Cache spart, nehme ich mal an.

PS:

Wäre übrigens interessant zu wissen wie groß die Silicon Bridge wird um ob jedes CCD seine eigene Silicon Bridge bekommt oder eine etwas größere Bridge mittig liegt und eventuell sogar ein paar Datenleitungen direkt zwischen den CCDs ermöglichen würde.
Viel Platz benötigt man sicherlich nicht um paar dutzene CCD to CCD Leitungen dazuzupacken.

[robbitop]

Naja Bandbreite ist nicht Latenz. Und vergleiche mal die Memorylatency von 4 Core cpus aus den 2010ern mit modernen Intel cpus. Skalierung an cores ist nunmal diametral mit latenz und zaubern kann da auch keiner.
Mein 4790K hat eine Memorylatency von 42 ns laut aida64 erreicht (mit tuning). Moderne CPUs liegen da grob Bei Faktor 2. Haben aber auch viel mehr cores. Und klar gabs da auch Innovation - aber das hat alles seine Grenzen. Deshalb führte AMD ja die CCX ein um ein Kompromiss zu machen. Im CCX eine kleine sehr schnelle fabric und außerhalb dann die IF. Mit wachsenden L3 Caches ging die Strategie dann auf (weil die durchschnittliche also hitrate inkludierte memorylatency sank).
Jetzt macht man den ccx aber auch größer und steht dann wieder vor dem gleichen Mechanismus.

Auf mich wirkte es so, dass man mit dem bisherigen Cache und ccx Setup sehr sehr gut balanciert hat. Mich würde es tatsächlich nicht wundern wenn mit Zen 6 im 12 ccx die intra ccx latenz (zB L3) etwas steigt. Aber den Effekt federt man dafür mit einem größeren L3 Cache ab (höhere hitrate). Und wer weiss ggf wächst auch der L2 mittelfristig um da auch zu helfen.

Bei „wir machen einfach den ccx größer und es gibt keine einbußen“ werde ich zumindest skeptisch. Auch wenn das mit Zen 3 schonmal geklappt hat. :)
Aber wer weiss - ggf gab es ja doch noch irgendeine tolle Innovation die diesen Mechanismus ausgleicht. :)
Ich läge hier liebend gern falsch :)

So oder so erwarte ich von Zen 6 X3D einiges. Der ist wahrscheinlich der richtige upgrade Kandidat vom 5800x3d ausgesehen. (der immer noch super läuft)

[Nightspider]

Schon klar aber höherer Takt gleicht es eben auch teilweise aus, wenn ein paar Cycles mehr benötigt werden.

Und höhere Bandbreite reduziert ja theoretisch auch die gesamte Wartezeit, sofern die Bandbreite zuvor mal limitiert haben sollte. Wenn bei Zen5 jetzt aber die Bandbreite zwischen den Cores nie limitierend war, dann erübrigt sich dieser Faktore natürlich.

Aber gerade zum Cache hat AMD die Bandbreite ja auch immer wieder massiv aufgebohrt.


Bei „wir machen einfach den ccx größer und es gibt keine einbußen“ werde ich zumindest skeptisch.

Ist ja auch nichts falsch daran Dinge zu hinterfragen. *Bulldozer hust*

Aber in den letzten 6-8 Jahren hat AMDs CPU Team eigentlich nie enttäuscht, auch wenn Zen5% durch den alten IOD ausgebremst wurde.

Bin da zuversichtlich. AMD scheint ja jetzt ernst zu machen.

[robbitop]

Ja aber der Takt schiebt ja alles gleichzeitig hoch - also auch wieder mehr Rechenleistung die dann wieder relativ gesehen länger „warten muss“. Entsprechend würde das (isoliert betrachtet) die Performance senken. Entsprechend macht es schon Sinn was zu machen um den Malus auszugleichen. Und das passiert ja auch mit der Vergrößerung des L3 Cache. Vermutlich bleibt netto sogar was über so dass man taktnormiert mehr Leistung hat. (bzw hoffentlich)

Zum Punkt: xyz hat nie enttäuscht sage ich immer: die Vergangenheit ist kein zuverlässiger Indikator für die Zukunft. Intel hat auch lange nicht enttäuscht und dann greifen sie plötzlich ins Klo. X-D
(und Zen 5% hat sich jetzt auch nicht gerade mit Ruhm bekleckert. Zum Glück für AMD hat Intel gefailt mit Arrowlake und zum Glück hat der neue VCache mehr Takt ermöglicht - aber die uArch ist für die ganzen Verbesserungen erstaunlich wenig schneller als Zen 4)

Allerdings war es auch nicht so gemeint dass der größere CCX zu einem schlechten Produkt führt. Das ist ja nur eines von ganz vielen Stellschrauben die dann in einer Gesamtkonstellation zu einem Ergebnis führen. :)

[bbott]

... auch wenn Zen5% durch den alten IOD ausgebremst wurde.

Gibt es dafür Belege? Ich habe dazu noch nichts gehört. Außer das Mem Support und Idle durch das IOD leiden (und weniger TDP für CPU vrohanden sind), aber soviel dürft das insbesondere beim X3D nicht ausmachen.

[robbitop]

Es wird ja immer gern X3D angeführt (der wird ja weniger durch Memorylatency gebremst). Weil der ja schneller war. Aber taktnormiert in Spielen sind es auch nicht so viel mehr als 5% ggü Zen 4X3D. Klar gibt es auch Ausreißer aber im breiten Index ist das nicht der Renner.

[bbott]

Der Zen5 X3D war von anfang an nur durch lösen der Takt bremse bei den X3D so viel schneller als der Zen 4 X3D ist seit den Leaks und Reviews bekannt. Das die IPC vergleichbar, aber die IPS viel besser ist, ist doch nichts neues?!
Zen 4 X3D konnte sich auch durch weniger Takt Verluste vom Zen 3 X3D absetzen... nur nicht ganz so deutlich, da kam mehr über IPC.

[latiose88]

hm eine frage wie warscheinlich ist es das z.b ein Zen 6 12 Kerner die selbe Leistung erreichen kann wie ein 16 Kern Zen 5,wenn sagen wir mal alle 16 Kerne wirklich gut ausgelastet bzw fast ganz ausgelastet wird.Oder wenn die Anazal an Kerne eine Rolle spielen,das 12 Kerner nicht gleich schnell sein könnten,was meint ihr dazu?

[Nightspider]

Gibt es dafür Belege?

Zeigt sich schon daran, das der Unterschied zwischen Zen5 und Zen5X3D größer ist, als zwischen Zen4 und Zen4X3D.

Zen5 skaliert auch besser mit schnellem RAM.

Ist ja auch irgendwo logisch wenn ein IOD verwendet wird, was schon paar Jahre alt ist und schon zum Release keine Bäume ausgerissen hat, was die Speicheranbindung betrifft.
Dafür war es für AMD spottbillig den IOD für Zen5 wiederzuverwenden.

[robbitop]

Taktnormiert liegt Zen 5x3d nach wie vor iirc nur grob 5% vor zen4x3d in einem breiten Gaming Index.

[latiose88]

das gleiche gillt wohl auch bei reiner Anwendung ohne Spiele also ausgeklammert von Spielen
der 7950x zu 9950x.
Sind da wohl auch so um die 5% Taktnormoniert.Wenn man dann maximalen Takt dazu nimmt,sieht es bestimmt noch besser für Zen 5 aus.

[Nightspider]

Teile gerne mal den Link aber bei CPU Tests vertrau ich tendenziell eher auf Tests wo anspruchsvolle Titel getestet werden ohne Counterstrike und Co.

Und der Takt spielt natürlich auch eine Rolle, weil die schnellere CPU durch den gleichen Speicher natürlich mehr ausgebremst wird.

Konnte jedenfalls bei einigen Tests sehen das der Abstand zum X3D bei Zen5 größer ist.

[latiose88]

ja aber nur wenn Bandbreite eine Rolle spielt,ansonsten ja nicht oder?

[robbitop]

Gamingindex im 2026er Parcours bei PCGH:
9700x vs 7700x 112%
9800x3d vs 7800x3d 121%
https://www.pcgameshardware.de/CPU-CPU-154106/Tests/Rangliste-Bestenliste-1143392/2/

9700x 5340 MHz avg 97,7 % vom 7700x
7700x 5465 MHz avg
7800x3d 4901 MHz avg
9800x3d 5200 MHz avg 106,1% vom 7800x3d
Quellen für Taktraten siehe unten

Zen 5 vs Zen 4 = 112 % : 97,7 % = 114%
Zen 5x3d vs Zen 4x3d = 121% : 106,1% =114%

Taktnormiert gleicher Abstand zwischen Zen5 und Zen4. Egal ob X3D oder nicht. Denke nicht dass der IOD da viel bremst.

https://www.computerbase.de/artikel/prozessoren/ryzen-5-9600x-ryzen-7-9700x-gaming-benchmark-test.89073/seite-5
https://www.computerbase.de/artikel/prozessoren/amd-ryzen-7-9800x3d-test.90151/seite-4

Was man aber unabhängig davon sagen muss - die ganzen Updates scheinen mittlerweile doch einiges gebracht zu haben. Aus den 5% sind mittlerweile fast die von AMD ursprünglich kolportierten 15% geworden.

[mczak]

hm eine frage wie warscheinlich ist es das z.b ein Zen 6 12 Kerner die selbe Leistung erreichen kann wie ein 16 Kern Zen 5,wenn sagen wir mal alle 16 Kerne wirklich gut ausgelastet bzw fast ganz ausgelastet wird.
Naja also zumindest von Zen-Zen4 war es eigentlich immer so dass der neue 6-Kerner MT ungefähr die Performance des 8-Kerners der Vorgängergeneration erreicht hat - natürlich mit Abweichungen gegen oben und unten weil ja nicht alle Anwendungen gleich stark von der neuen Architektur profitiert haben (und auch zu beachten allällige TDP-Unterschiede). Zen5 hat das aber nicht erreicht. Wenn man also davon ausgeht dass Zen6 wieder mehr Verbesserung bringt könnte das schon etwa hinkommen. Ist natürlich nicht ganz dasselbe mit 12 vs 16 Kernen weil man da auch noch nur 1 statt 2 CCD hat, aber könnte imho trotzdem ein ziemlich enges Rennen werden.

[robbitop]

Auch nochmal der PCGH 2026 CPU Test. Ohne X3D wäre AMD ziemlich am Arsch (das war mir gar nicht so klar). Der 285K ist 11% schneller im Gaming als der 9700X und der 14900K sogar 16%. Trotz all der neuen Updates, die die Zens deutlich nach vorn brachten.
Also rein von der uArch ist AMD offenbar nie an Intel vorbeigezogen.
Sollte Intel mit NVL wirklich einen großen LLC liefern (und da kommen ja auch nochmal neue Kerne) muss AMD aber wirklich richtig fettig nachlegen ansonsten liegt man wieder hinten.

[dildo4u]

Bei PCGH passt es doch 9600x hat 245k und der 9700X 265k Gameing Performance, alles da drüber hat nichts mit dem Massenmarkt zu tun.

[robbitop]

Darum geht es nicht sondern wie viel jede uArch pro Takt rausholt und was das bedeutet für zukünftige SKUs - vor allem wenn Intel auch einen großen LLC bringt.
AMD dominiert nur durch den LLC. Ansonsten liegt der P Core von Arrowlake anscheinend etwas vorn.

[Badesalz]

Auch nochmal der PCGH 2026 CPU Test. Ohne X3D wäre AMD ziemlich am Arsch (das war mir gar nicht so klar).Mag gut sein. Warum sagt aber keiner, wenn sie jetzt 30% vorn sind, Intel ist am Arsch?
(und zwar nicht wegen den Ausgaben für die Fabs)

Es gibt wohl ein Martrialsches Gesetz, nach welchem nur 2 Sachen martialisch sind. Intels Siege und AMDs Niederlagen :rolleyes:

Und nochmal. AMD hat IF. Was Latenz ist was V-Cache wohl abfängt. Wieviel LLC Intel bringt weiß man draußen noch garnicht oder? Was man weiß ist, daß sie keine IF haben.

IF ist für mich weniger µArch als eher Modul-Arch (oder CPU-Arch). µArch ist imho eher, wenn man Epycs ohne V-Cache mit Xeon 6 vergleicht...

[robbitop]

Mag gut sein. Warum sagt aber keiner, wenn sie jetzt 30% vorn sind, Intel ist am Arsch?
(und zwar nicht wegen den Ausgaben für die Fabs)

Es gibt wohl ein Martrialsches Gesetz, nach welchem nur 2 Sachen martialisch sind. Intels Siege und AMDs Niederlagen :rolleyes:

Und nochmal. AMD hat IF. Was Latenz ist was V-Cache wohl abfängt. Wieviel LLC Intel bringt weiß man draußen noch garnicht oder? Was man weiß ist, daß sie keine IF haben.

IF ist für mich weniger µArch als eher Modul-Arch (oder CPU-Arch). µArch ist imho eher, wenn man Epycs ohne V-Cache mit Xeon 6 vergleicht...

Hä? Es sagen alle, dass AMD vorn ist (reviews, user). Das ist ja gerade der status quo. Eben wegen X3D. Wie kommt du darauf dass das keiner sagt?
IF ist auch nur eine Markenbezeichnung für eine Verbindungstopologie. Ich sehe nicht warum Intels Äquivalent da schlechter sein sollte. Und es hat auch keiner gesagt dass der IF Teil der uArch ist. Wie kommst du darauf?
Allerdings ist die Latenz des LLCs trotzdem die Frage. Bei AMD ist der LLC ja im CCX. Also außerhalb der langsamen IF. Muss man mal schauen wie Intel es umsetzt. Also ob es auch Teil des L3 ist oder ob es ein langsamerer L4 ist. Bei vergleichbarer Latenz und Größe gibt es aber keinen plausiblen Grund ein großer LLC würde weniger bringen. (und jetzt bitte nicht den 2 MiB L2 Cache bringen - das Delta ist winzig im Vergleich zu dem Delta mit X3D und darüber hinaus hat die Verdopplung des L2 bei Zen4 gerade mal 3% gebracht)

edit: hier ein guter Grund warum ein bLLC bei Intel viel bringen kann. Arrowlake hat in Gaming massiv Performance trotz neuerem Core verloren durch die höhere memorylatency durch die chiplets. So sehr dass Arrowlake ggü den alten RTL Cores hier hinten liegt. Und es gab ja schon mehrere Artikel die gezeigt haben wie krass Arrowlake auf Memorytuning anspringt. Was ja wegen der schlechten Memorytatency nicht verwundert. Erinnert sehr an Zen der ja mit X3D auch durch die Decke ging und bis zu X3D sehr von Memorytuning profitierte. Hier der link - insgesamt holte (inkl oc die pcgh 43 % mehrleistung aus dem 265er) https://www.pcgameshardware.de/Core-Ultra-7-265K-CPU-280895/Specials/Test-Gaming-Benchmark-vs-9800X3D-1471332/

Und was nun „martialisch“ ist oder wie man was ausdrückt spiel mE überhaupt keine Rolle. Das ist nur Semantik. Vergeudete Zeit über Semantik zu diskutieren IMO.

Der Kernpunkt ist: AMD hat keinen Vorsprung bei der uArch der Cores in Punkto performance. Und bei den Nodes auch nicht mehr weil Intel da wo es ankommt auch TSMC nutzt. Mit dem bLLC fällt dann ggf in 1 Jahr der letzte Vorteil. Will sagen: AMD gibt besser Gas wenn sie kein Momentum verlieren wollen.


——————-
Hab mir gerade mal die Marktanteile von Server, Mobile und Desktop angeschaut. Auch wenn AMD historisch gesehen gut da steht - der Marktführer (der Federn lassen musste) scheint immernoch Intel zu sein. Wirklich überraschend für mich. Und das nachdem sie in einigen Bereichen ja nun seit Jahren deutlich hinten in Performance und Preis lagen.

[davidzo]

Auch nochmal der PCGH 2026 CPU Test.
Habe mir den Test eben mal angeschaut, kann aber nicht erkennen was du meinst.
9950X und 285K sind praktisch gleich schnell, wie zum Launchzeitpunkt auch schon. Die intel CPU führt 6% bei Games, was zwar mehr ist als üblich, aber auch nicht viel. Das kann auch an der game-Auswahl liegen. Bei Anwendungen liegt dagegen der 9950X 5% vorne.

9700X und 245K liegen ebenfalls gleichauf, wobei Intel hier durch die Rabatte erheblich günstiger ist. Das ist aber kein Architekturproblem sondern ein pricing Problem. Solange AMD weiter alle hochpreisigen Zen5 CPUs aus der Hand gezogen werden wird man wohl keine vernünftigen Preise für SingleCCD midrange / entry level CPUs sehen.

Intel gewinnt zwar nicht im highend, wird ihre CPUs aber durch die sehr gute preislage im Midrange sehr gut los.
Dafür verkaufen sie allersdings auch deutlich mehr Silizium pro CPU als AMD. AMD dürfte eine erheblich größere Marge haben.
Außerdem verbrauchen die Intel CPUs trotz einem fullnode Vorsprung biszu 50% mehr unter Vollast. unter Games, Teillast ist Intel aber mehr als Konkurrenzfähig.

Von Architekturüberlegenheit würde ich hier trotzdem nicht sprechen. Die IPC ist sehr ähnlich bis einstellig besser, aber die performance per Area und performance per Watt zu schlecht trotz einem full node Vorsprung.


Wenn Olympic Ridge in 2nm kommt sind das zwei Nodesprünge für AMD. Da kann man also große Sprünge erwarten was Effizienz und Taktraten nach oben gehen dürften.

Ob der Switch von N3B zu N2 oder 18A für Intel nennenswerte Taktgewinne mit sich bringt wissen wir nicht. zumindest 18A war ja nur ein Sidegrade mit etwas besserer Effizienz aber stagnierenden Taktraten.

Genau wir bei Pantherlake kann man bei der CPU µArch von Novalake keine nennenswerten IPC Sprünge erwarten sondern eher eine Konsolidierung. Wenn das nicht wäre würden die bereits großen Dies von Arrowlake bei Novalake nochmal explodieren bei den versprochenen hohen Core-counts und N2 ist ja schweineteuer.

Die letzten IPC Sprünge bei Intel lagen eher unter 10%. Das dürfte Zen6 den Gerüchten nach alleine an Taktsprung hinlegen. Die IPC Gewinne durch ein Fabric mit besseren latenzen und dem lösen der low hanging fruit handbremsen von Zen5 zu Zen6 kommen da nochmal oben drauf.

Zen6 wird zudem AMDs Idle- und Teillastverbrauchsproblem beheben da das serielle Infinity Fabric on Package mit einem massiv parallelen interposer basiertem sea of wires Interconnect ersetzt wird.



Allerdings ist die Latenz des LLCs trotzdem die Frage. Bei AMD ist der LLC ja im CCX. Also außerhalb der langsamen IF. Muss man mal schauen wie Intel es umsetzt. Also ob es auch Teil des L3 ist oder ob es ein langsamerer L4 ist. Bei vergleichbarer Latenz und Größe gibt es aber keinen plausiblen Grund ein großer LLC würde weniger bringen.

Intels L3 ist nicht besonders konkurrenzfähig. Der verbraucht mehr Die-Area und ist erheblich langsamer als AMDs L3. Arrowlake hat mit 36MB vergleichbar viel kapazität wie AMDs 32MB aber mit 80cycles eine fast doppelt so hohe Latenz wie AMDs CCX Cache. Selbst der Bestcase von Intels L3 - Lunarlake - schafft es trotz nur 12MB kapazität nicht an AMDs L3 latenzen anzuknüpfen.

Gleichzeitig hat Intel wohl intern genug Zeit gehabt einen L4 BLLC zu testen. Arrowlake Halo hatte diesen Cache anscheinend genau wie die gecancelten Shores GPUs, aber man hat sich dagegen entschieden diese CPUs zu launchen. Vermutlich hatte der Cache durch noch höhere Latenzen als der L3 kaum einen positiven performance-impact.

Novalakes Cache-System scheint ja unter dem Eindruck dieser Erfahrungen mit Meteorlake und Arrowlake neu designt worden zu sein. Die Gerüchte sprechen von on Die Cache, was gegen den L4 spricht, denn der war in den Halo CPUs ja gestackt.

Also bohrt man vermutlich den L3 auf. Das hat weniger Effekt als bei AMD, weil
1. der riesige L2 schon eine höhere Hitrate pro Core hat und
2. die Latenz des L3 viel schlechter ist als bei AMDs X3D Cache.

Im besten Fall hat Intel den ganzen L3 und den dadurch gehenden Ringbus neu designt und dadurch die Latenzen verbessert.

[robbitop]

Habe mir den Test eben mal angeschaut, kann aber nicht erkennen was du meinst.
9950X und 285K sind praktisch gleich schnell, wie zum Launchzeitpunkt auch schon. Die intel CPU führt 6% bei Games, was zwar mehr ist als üblich, aber auch nicht viel. Das kann auch an der game-Auswahl liegen. Bei Anwendungen liegt dagegen der 9950X 5% vorne.

9700X und 245K liegen ebenfalls gleichauf, wobei Intel hier durch die Rabatte erheblich günstiger ist. Das ist aber kein Architekturproblem sondern ein pricing Problem. Solange AMD weiter alle hochpreisigen Zen5 CPUs aus der Hand gezogen werden wird man wohl keine vernünftigen Preise für SingleCCD midrange / entry level CPUs sehen.

Intel gewinnt zwar nicht im highend, wird ihre CPUs aber durch die sehr gute preislage im Midrange sehr gut los.
Dafür verkaufen sie allersdings auch deutlich mehr Silizium pro CPU als AMD. AMD dürfte eine erheblich größere Marge haben.
Außerdem verbrauchen die Intel CPUs trotz einem fullnode Vorsprung biszu 50% mehr unter Vollast. unter Games, Teillast ist Intel aber mehr als Konkurrenzfähig.

Von Architekturüberlegenheit würde ich hier trotzdem nicht sprechen. Die IPC ist sehr ähnlich bis einstellig besser, aber die performance per Area und performance per Watt zu schlecht trotz einem full node Vorsprung.


Wenn Olympic Ridge in 2nm kommt sind das zwei Nodesprünge für AMD. Da kann man also große Sprünge erwarten was Effizienz und Taktraten nach oben gehen dürften.

Ob der Switch von N3B zu N2 oder 18A für Intel nennenswerte Taktgewinne mit sich bringt wissen wir nicht. zumindest 18A war ja nur ein Sidegrade mit etwas besserer Effizienz aber stagnierenden Taktraten.

Genau wir bei Pantherlake kann man bei der CPU µArch von Novalake keine nennenswerten IPC Sprünge erwarten sondern eher eine Konsolidierung. Wenn das nicht wäre würden die bereits großen Dies von Arrowlake bei Novalake nochmal explodieren bei den versprochenen hohen Core-counts und N2 ist ja schweineteuer.

Die letzten IPC Sprünge bei Intel lagen eher unter 10%. Das dürfte Zen6 den Gerüchten nach alleine an Taktsprung hinlegen. Die IPC Gewinne durch ein Fabric mit besseren latenzen und dem lösen der low hanging fruit handbremsen von Zen5 zu Zen6 kommen da nochmal oben drauf.

Zen6 wird zudem AMDs Idle- und Teillastverbrauchsproblem beheben da das serielle Infinity Fabric on Package mit einem massiv parallelen interposer basiertem sea of wires Interconnect ersetzt wird.




Intels L3 ist nicht besonders konkurrenzfähig. Der verbraucht mehr Die-Area und ist erheblich langsamer als AMDs L3. Arrowlake hat mit 36MB vergleichbar viel kapazität wie AMDs 32MB aber mit 80cycles eine fast doppelt so hohe Latenz wie AMDs CCX Cache. Selbst der Bestcase von Intels L3 - Lunarlake - schafft es trotz nur 12MB kapazität nicht an AMDs L3 latenzen anzuknüpfen.

Gleichzeitig hat Intel wohl intern genug Zeit gehabt einen L4 BLLC zu testen. Arrowlake Halo hatte diesen Cache anscheinend genau wie die gecancelten Shores GPUs, aber man hat sich dagegen entschieden diese CPUs zu launchen. Vermutlich hatte der Cache durch noch höhere Latenzen als der L3 kaum einen positiven performance-impact.

Novalakes Cache-System scheint ja unter dem Eindruck dieser Erfahrungen mit Meteorlake und Arrowlake neu designt worden zu sein. Die Gerüchte sprechen von on Die Cache, was gegen den L4 spricht, denn der war in den Halo CPUs ja gestackt.

Also bohrt man vermutlich den L3 auf. Das hat weniger Effekt als bei AMD, weil
1. der riesige L2 schon eine höhere Hitrate pro Core hat und
2. die Latenz des L3 viel schlechter ist als bei AMDs X3D Cache.

Im besten Fall hat Intel den ganzen L3 und den dadurch gehenden Ringbus neu designt und dadurch die Latenzen verbessert.

Ich habe 9700X mit 285K verglichen. Ok der 9950X ist ein bisschen schneller in Games - hatte ich gar nicht auf dem Schirm. Wichtig: unter „erweitert“ die Balken für Gamebenchmarks angucken - nicht „overall“.
Games:
9700X 100% (also auf den 9700X normiert)
9950X 105%
285K 111%
14900K 116%

Also grundsätzlich ändert das nicht viel an der Aussage, dass Intels P Cores keine Performancenachteile haben pro Takt und absolut.

https://www.pcgameshardware.de/CPU-CPU-154106/Tests/Rangliste-Bestenliste-1143392/2/

Zum LLC: sehr interessant. Kann also gut sein, dass zumindest ein halber Vorteil bei AMD erhalten bleiben wird. Allerdings wird der LLC vermutlich trotzdem massiv helfen wenn man sich den PCGH Artikel zum Tuning des Memorys beim 265er anschaut der allein dadurch iirc >20% schneller wurde. Und getunter Memory ist deutlich langsamer als ein langsamer LLC. Auch der 5775c hatte einen relativ langsamen LLC mit dem eDRAM. Der lag IIRC zwischen 30-40 ns. X3D liegt bei 10-12 ns. Und doch boostete ihn das fast vergleichbar wie X3D auch Zen boostete.

Zum Node: ist N2 eigentlich gesichert? Ich hab da vage was im Hinterkopf dass die leaker da von zurück gerudert waren zT und es N3P oder sowas wurde. Wie NVL? edit: gemini3prp sagt N2P.

edit:Was IPC Sprünge bei Intel angeht. Die waren wahrscheinlich aber (zumindest RTL -> ARL) massiv überdeckt von der deutlich schlechteren latency. Wird interessant zu sehen was latencynormiert passiert (also der reine effekt der uArch). Würde mich nicht wundern wenn ARL da gut vor RTL läge. Man müsste da den Takt gleich setzen und für RTL iterativ die Timings verschlechtern und bei ARL diese tunen bis die Memorylatency etwa gleich liegt. Hat wahrscheinlich nie jemand getestet. Aber der Uplift beim Memorytuning von ARL spricht bereits ein Stück weit dafür :)

edit: ich hatte für NVL auch gestackten Cache (auf dem base tile) im Hinterkopf (gemini3pro sagt es auch). 144 MB dann insgesamt pro Compute die. Das ist etwas viel für on die. Stacking muss L3 aber nicht unbedingt ausschliessen wenn sie es wie AMD machen. Ich tippe aber nicht darauf dass die bLLCs wegen Performance gecanclet worden sind sondern eher aus ökonomischen Gründen. Ich hab vage im Hinterkopf dass MLID mal angeseutet hat, dass da von den Bohnenzählern (BWLern) einiges geaxt wurde. Aus nicht technischen Gründen. Zu teuer - Intel im Survive Mode. Schlechte Führung usw.

[Neurosphere]

Da hängt auch viel am Ram, hier fehlen leider angaben. Es gibt auch benches in denen der 9950x im einstelligen Prozentbereich vor dem 285K liegt. Allerdings immernoch mit deutlich geringerem Stromverbrauch zum Vorteil AMD.

[robbitop]

Naja PCGH testet meist schon die fiesesten Stellen in Spielen. Aber unabhängig davon spielt 5% +/- keine Rolle sondern es geht darum das grundsätzlich kein echter uArch Vorteil in Bezug auf Performance existiert.

[reunion]

Naja PCGH testet meist schon die fiesesten Stellen in Spielen. Aber unabhängig davon spielt 5% +/- keine Rolle sondern es geht darum das grundsätzlich kein echter uArch Vorteil in Bezug auf Performance existiert.

Naja, was ist ein "echter µArch-Vorteil"? Die µArch wurde eben für das 3D-Stacking des L3 entwickelt. Ohne diesen hat AMD einen deutlichen Cache-Nachteil pro Kern. Was ist also der faire Vergleich?

PCGH scheint auf jeden Fall Szenen zu benchen wo mehr Kerne etwas bringen, deshalb ist der Vergleich 285K gegen 9700X nicht wirklich fair. Zumal der 9700X auch niedriger taktet als der 9950X.

[robbitop]

Naja, was ist ein "echter µArch-Vorteil"? Die µArch wurde eben für das 3D-Stacking des L3 entwickelt. Ohne diesen hat AMD einen deutlichen Cache-Nachteil pro Kern. Was ist also der faire Vergleich?

PCGH scheint auf jeden Fall Szenen zu benchen wo mehr Kerne etwas bringen, deshalb ist der Vergleich 285K gegen 9700X nicht wirklich fair. Zumal der 9700X auch niedriger taktet als der 9950X.

Die Implementierung des LLCs wurde dafür gebaut aber IMO nicht die uArch. Siehe oben Zen 5 vs 4 mit oder ohne vcache ist taktnormiert exakt der gleiche Unterschied. Das wäre nicht zu erwarten bei einer uArch die extra dafür gemacht wurde.
X3D ist eine tolle Ingenieursleistung den LLC schnell und groß werden zu lassen. Aber die eigentlichen Cores zeigen IMO keine Indizien dass sie extra dafür gemacht worden sind - dann hätten die non X3D Varianten taktnormiert einen größeren Nachteil was sie nicht haben. Und das wäre auch fragwürdig weil die nonX3D Varianten von Zen sicherlich 1-2 Größenordnungen mehr Verkaufszahlen in allen Segmenten haben. Ein großer Cache bringt einfach immer was weil man nicht auf den langsamen RAM warten muss.

Das mit den Cores habe ich ja eingeräumt und die Prozentzahlen korrigiert. Änderte aber an der Aussage nichts wesentliches. Mehr Kerne sind im Zeitalter von RT mit erhöhter BVH Last langsam sukzessive sinnvoll. Kommt also wahrscheinlich durch immer mehr RT in den Indizes.

[reunion]

Die Implementierung des LLCs wurde dafür gebaut aber IMO nicht die uArch. Siehe oben Zen 5 vs 4 mit oder ohne vcache ist taktnormiert exakt der gleiche Unterschied. Das wäre nicht zu erwarten bei einer uArch die extra dafür gemacht wurde.
X3D ist eine tolle Ingenieursleistung den LLC schnell und groß werden zu lassen. Aber die eigentlichen Cores zeigen IMO keine Indizien dass sie extra dafür gemacht worden sind - dann hätten die non X3D Varianten taktnormiert einen größeren Nachteil was sie nicht haben. Und das wäre auch fragwürdig weil die nonX3D Varianten von Zen sicherlich 1-2 Größenordnungen mehr Verkaufszahlen in allen Segmenten haben.


Die Argumentation kann ich nicht nachvollziehen. Die X3D-Variante holt taktnormiert ~50% Mehrleistung, das ist ein Quantensprung im CPU-Bereich. Was hat die Skalierung mit oder ohne 3D-Cache vs. dem Vorgänger damit zu tun (zumal der auch schon für den 3D-Cache designed wurde)?


Ein großer Cache bringt einfach immer was weil man nicht auf den langsamen RAM warten muss.


Wie viel es bringt hängt wesentlich vom Cache-Design und der µArch selbst ab und ist keine Selbstverständlichkeit.

[reunion]

Intels L3 ist nicht besonders konkurrenzfähig. Der verbraucht mehr Die-Area und ist erheblich langsamer als AMDs L3. Arrowlake hat mit 36MB vergleichbar viel kapazität wie AMDs 32MB aber mit 80cycles eine fast doppelt so hohe Latenz wie AMDs CCX Cache. Selbst der Bestcase von Intels L3 - Lunarlake - schafft es trotz nur 12MB kapazität nicht an AMDs L3 latenzen anzuknüpfen.

Gleichzeitig hat Intel wohl intern genug Zeit gehabt einen L4 BLLC zu testen. Arrowlake Halo hatte diesen Cache anscheinend genau wie die gecancelten Shores GPUs, aber man hat sich dagegen entschieden diese CPUs zu launchen. Vermutlich hatte der Cache durch noch höhere Latenzen als der L3 kaum einen positiven performance-impact.

Novalakes Cache-System scheint ja unter dem Eindruck dieser Erfahrungen mit Meteorlake und Arrowlake neu designt worden zu sein. Die Gerüchte sprechen von on Die Cache, was gegen den L4 spricht, denn der war in den Halo CPUs ja gestackt.

Also bohrt man vermutlich den L3 auf. Das hat weniger Effekt als bei AMD, weil
1. der riesige L2 schon eine höhere Hitrate pro Core hat und
2. die Latenz des L3 viel schlechter ist als bei AMDs X3D Cache.

Im besten Fall hat Intel den ganzen L3 und den dadurch gehenden Ringbus neu designt und dadurch die Latenzen verbessert.

Jup, alles richtig. Die Möglichkeit den L3-Cache zu stacken ist mindestens seit Zen2 vorhanden, der Mitte 2019 gelauncht wurde. Man sieht ja schon wie lange Intel gebraucht hat um jetzt vermutlich Ende 2026 etwas vergleichbares zu bringen, dass da eben sehr viel mehr dran hängt als nur einfach mehr Cache zu verbauen.

Umgekehrt muss man natürlich auch sagen, wenn Intel nach über 7 Jahren endlich etwas ähnlichen bringt, wird man höchstwahrscheinlich auch die µArch und das Cache-design entsprechend überarbeitet haben, damit man eben auch entsprechende Vorteile daraus zieht. Ich rechne also schon mit einer deutlichen Überarbeitung.

[robbitop]

Die Argumentation kann ich nicht nachvollziehen. Die X3D-Variante holt taktnormiert ~50% Mehrleistung, das ist ein Quantensprung im CPU-Bereich. Was hat die Skalierung mit oder ohne 3D-Cache vs. dem Vorgänger damit zu tun (zumal der auch schon für den 3D-Cache designed wurde)?

In dem 2026er CPU Test von PCGH ist der 9800x3d 38% schneller als der 9700X. Taktnormiert sind es 40%.

Das ist nicht verwunderlich da gerade Spiele oft latenzgetriebener Workload sind. Und wenn so extrem viel Cache auch noch so schnell ist 96 MiB mit 11 ns sind crazy, ist das nicht verwunderlich. Schau dir mal an wie cpus in den 80ern und 90ern mit Cache an vs aus skalierten in Spielen. Das war noch brachialer.
Man spart bei einem Cache hit halt gut 50-60 ns. Während also die CPU die warten muss kann die andere 250 cycles lang arbeiten. Bei 3x L3 cache ist die Differenz in der Hitrate schon ordentlich.

Und inwiefern man jetzt absichtlich eine uArch so designt dass sie extra für x3d gemacht ist, wüsste ich gern. Und wenn das so wäre, dürften die Vorsprünge der non X3D Varianten nicht gleich ggü einander sein wie die X3D Varianten weil die Aussage einen nicht gerade kleine bottleneck impliziert (man kann nicht einen großen Vorteil wollen ohne dass wenn man etwas dafür entwickelt dass dann ohne das feature kein bottleneck entsteht, der dann eben jegliche Fortschritte der uArchs nicht auch zu einem gewissen Teil auch mitausbremst). Die Performancecharakteristik als delta wäre dann anders und kleiner. Und weiterhin ist es fraglich ob man eine uArch der cores selbst extra für sowas baut wenn 90…99% der verkauften Produkte nonX3D sind. Eher profitieren Zen und Co besonders davon weil durch die skalierbaren fabrics die als Nachteil eine hohe memorylatency haben. (die liegt grob >40 ns höher als sie zu 4 core Zeiten mal war).

Den reinen Vorsprung als Argument dafür zu betrachten, dass ganz speziell die uArch der Cores dafür gemacht wurde und ein Vergleich ohne eben nicht fair ist, ist IMO etwas zu dünn.
Wie gesagt sieht man bei allen CPUs die lahme latency haben massive Vorteile durch Speichertuning. Und ARL holt damit im PCGH Artikel nur durch Speichertuning >20% raus. Was wohl mit einem 3x so großen L3 Cache passieren würde der nur 11 ns Latenz hat? Ganz ohne dass der core (angeblich) extra dafür gemacht wurde? Sehr wahrscheinlich auch 40% … ish.

[Badesalz]

Hä? Es sagen alle, dass AMD vorn ist Das war nicht die gemeinte Wortwahl. Ja, vergeudete Zeit. Man nutzt es trotzdem. Soviel Zeit muss wohl sein :wink:

[robbitop]

Jup, alles richtig. Die Möglichkeit den L3-Cache zu stacken ist mindestens seit Zen2 vorhanden, der Mitte 2019 gelauncht wurde.


Gibt es dafür eine Quelle? Die KI spuckt aus „ Ian Cutress und andere Analysten (z.B. von Fritzchens Fritz via Die-Shots) haben bestätigt, dass auf den Zen 2-Dies (CCD) die physischen Kontaktpunkte für die vertikale Verbindung fehlten“. Ich frage aus Interesse weil ich nämlich auch irgenswie Zen 2 im Hinterkopf dazu hatte. Zumindest für Prototypen.

Im Interview mit Ian sagte Mike Clark auch Zen 3 und es wurde gesagt zum Glück hat sich keiner beim 5800X (der ja deutlich vor der x3d Version kam) den die allzugenau mit dem Mikroskop angeschaut sonst wäre das schon deutlich eher geleakt worden.

[Badesalz]

Wie gesagt sieht man bei allen CPUs die lahme latency haben massive Vorteile durch Speichertuning.Sachen die ich in unserem 9700 Thread gesehen habe (war woanders nicht anders) und über die ich grad nachgedacht habe wie sie zu dem Thema der letzten 2 Seiten hier passen. Ich glaub da brauch ich Hilfe was Kontext angeht :ucoffee: Das waren:
- In Spieleauflösungen sind und bleiben die P/L überall sehr dünn

- Frametimes_stabi ist mit Zen5 gigantisch besser geworden und liegt noch paar (ab da unwichtigen) Neuancen über den 13e/14er. Das ist quasi brettflach geworden und das ist beim Zen4 keineswegs so.

- Memtuning beim X3D wo es bei 6000 nur noch um Timings geht, ist im Schnitt +15% in den meisten 1%minFPS Fällen.

hmm...

[basix]

Auch nochmal der PCGH 2026 CPU Test. Ohne X3D wäre AMD ziemlich am Arsch (das war mir gar nicht so klar). Der 285K ist 11% schneller im Gaming als der 9700X und der 14900K sogar 16%. Trotz all der neuen Updates, die die Zens deutlich nach vorn brachten.
Also rein von der uArch ist AMD offenbar nie an Intel vorbeigezogen.
Sollte Intel mit NVL wirklich einen großen LLC liefern (und da kommen ja auch nochmal neue Kerne) muss AMD aber wirklich richtig fettig nachlegen ansonsten liegt man wieder hinten.

Arrow Lake ist beim Core ein anderes Biest als Zen 5:
- 64kB L1i$ (vs. 32kB)
- Grösserer ROB (576 vs. 448)
- Grösseres INT Reg-File (~290 vs. 240)
- Grössere INT Scheduler (~97 vs. 88)
- 192kB L1.5$ (n.a. auf Zen 5)
- 3 MB L2$ (vs. 1 MB)

Lion Cove ist da an vielen Orten deutlich fetter als Zen 5. Lion Cove hat zudem eine höhere Branch Prediciton Genauigkeit in Games (laut chipsandcheese: https://chipsandcheese.com/p/running-gaming-workloads-through).
Zen 5 ist bei Gaming oft Frontend latenzlimtiert. Zweit häufigster Grund sind Backend Memory Sachen (ROB, INT Register File). Bringt Zen 6 einen verdoppelten L1i und bohrt ROB sowie INT-Ressourcen auf, dürfte das bei Gaming gut durchschlagen. Dito wenn dazu obendrauf noch die DRAM Latenz sinkt und Cache Misses abschwächt.

[robbitop]

Arrow Lake ist beim Core ein anderes Biest als Zen 5:
- 64kB L1i$ (vs. 32kB)
- Grösserer ROB (576 vs. 448)
- Grösseres INT Reg-File (~290 vs. 240)
- Grössere INT Scheduler (~97 vs. 88)
- 192kB L1.5$ (n.a. auf Zen 5)
- 3 MB L2$ (vs. 1 MB)

Lion Cove ist da an vielen Orten deutlich fetter als Zen 5. Lion Cove hat zudem eine höhere Branch Prediciton Genauigkeit in Games (laut chipsandcheese: https://chipsandcheese.com/p/running-gaming-workloads-through).
Zen 5 ist bei Gaming oft Frontend latenzlimtiert. Zweit häufigster Grund sind Backend Memory Sachen (ROB, INT Register File). Bringt Zen 6 einen verdoppelten L1i und bohrt ROB sowie INT-Ressourcen auf, dürfte das bei Gaming gut durchschlagen. Dito wenn dazu obendrauf noch die DRAM Latenz sinkt und Cache Misses abschwächt.

Ja. Die P Cores erkaufen sich ihre Performance durch viele Transistoren. Insofern bleibt bei Zen ein ökonomischer Vorteil und wahrscheinlich einer der Gründe warum Intel die P Cores angeblich enden lassen wird und die E cores zu mehr ausbalancierten Cores entwickelt wie Zen welche sind. Ja die P Cores sind schon irgendwie Brechstange.

IMO ist die Cache Architektur bei Zen aktuell wesentlich besser balanciert. Die großen Caches pro Core scheinen weniger zu bringen als ein wirklich großer und wirklich schneller L3.
Zen 4s L2 Verdopplung von 512kib auf 1MiB hat laut AMD gerade mal 3% gebracht. Da hitrate eine Wurzelfunktion hat, spricht das Bände über was 2 mib vs 1 mib bringen. Wahrscheinlich braucht es 3 MiB vs 1 MiB um nochmal 3% zu holen. :)

Aber worauf ich hinauswollte - AMD sollte jetzt nicht complacent werden. NVL wird mit dem bLLC wieder seit einer Weile wieder ein würdiger Konkurrent werden und ich tippe darauf dass Intel dann nachlegen wird. Bedeutet, dass man selbst dran bleiben muss. :)
2003-2005 lag man mit K8 ja auch ordentlich vorn. Und auch der K7 stand 1999-2003 ziemlich gut da. Aber irgendwie hat man dann den Fokus verloren und Intel zog mit Core 2 davon und hat den CPU Markt dann für 1 Jahrzehnt durch Salamitaktik kaputt gemacht.
AMD ist nicht mehr das AMD von 2005 - ein Glück. Aber zB im APU Segment sind sie schon ein wenig complacent geworden und Zen 5 war jetzt auch nicht so doll wie erhofft.
Man kann jetzt wieder mehr Konkurrenz erwarten - auch wenn es zwischenzeitlich so aussah als wenn Intel komplett abrutscht.
Und wie immer gilt: wir brauchen Wettbewerb. Ein schwaches AMD oder Intel nutzt niemandem :)

[Nightspider]

Gamingindex im 2026er Parcours bei PCGH:
9700x vs 7700x 112%
9800x3d vs 7800x3d 121%
https://www.pcgameshardware.de/CPU-CPU-154106/Tests/Rangliste-Bestenliste-1143392/2/

9700x 5340 MHz avg 97,7 % vom 7700x
7700x 5465 MHz avg
7800x3d 4901 MHz avg
9800x3d 5200 MHz avg 106,1% vom 7800x3d
Quellen für Taktraten siehe unten

Zen 5 vs Zen 4 = 112 % : 97,7 % = 114%
Zen 5x3d vs Zen 4x3d = 121% : 106,1% =114%

Taktnormiert gleicher Abstand zwischen Zen5 und Zen4. Egal ob X3D oder nicht. Denke nicht dass der IOD da viel bremst.

https://www.computerbase.de/artikel/prozessoren/ryzen-5-9600x-ryzen-7-9700x-gaming-benchmark-test.89073/seite-5
https://www.computerbase.de/artikel/prozessoren/amd-ryzen-7-9800x3d-test.90151/seite-4

Was man aber unabhängig davon sagen muss - die ganzen Updates scheinen mittlerweile doch einiges gebracht zu haben. Aus den 5% sind mittlerweile fast die von AMD ursprünglich kolportierten 15% geworden.

Hmm, interessant.
Vielleicht bencht die PCGH etwas genauer als CB und Co aber es ist schon bissl traurig das die bei der PCGH nicht mal eine Liste der Spiele und die Rahmenbedingungen dazuschreiben können.

Bei CB gibt's schon einige Titel wie BG3 oder Cities:Skylines2, wo Zen5X3D deutlich mehr abgeht als Zen4X3D.
Keine Ahnung ob die da alte Benchmarks mit neuen Benchmarks zusammenwerfen.

[robbitop]

Hmm, interessant.
Vielleicht bencht die PCGH etwas genauer als CB und Co aber es ist schon bissl traurig das die bei der PCGH nicht mal eine Liste der Spiele und die Rahmenbedingungen dazuschreiben können.

Bei CB gibt's schon einige Titel wie BG3 oder Cities:Skylines2, wo Zen5X3D deutlich mehr abgeht als Zen4X3D.
Keine Ahnung ob die da alte Benchmarks mit neuen Benchmarks zusammenwerfen.

Ausreisser gibt es ja immer - ich denke es bezweifelt niemand dass big llc auch mal deutlich mehr bringen kann und auch manchmal deutlich weniger. :) Deshalb denke ich dass ein möglichst breiter Index besser / aussagekräftiger ist. Ausreisser haben da weniger Bedeutung und löschen sich zT aus (gibt ja welche nach oben und nach unten).

[Badesalz]

(wegen #1679)
Man muss aber auch sagen, daß sie trotz schwachem Intel die großen Mühen auf sich nahmen den Cache drunter zu packen. Erstmal eigentlich ohne Not, was eben auch bedeutet, daß sie sehr wohl nach vorn zur Seite schielen...

Zwar erreicht man irgendwann die Reife um sich zugestehen, daß trotz Blasengelaber markttechnisch Kronen nicht relevant sind, aber sich verhauen lassen werden sie wohl nicht mehr. Das kann nur noch passieren, wenn IntelFab TSMC verhaut.
Ausschweifen werden sie nicht, weil das Geld für die nicht im Desktop liegt, aber die Budgets sind mittlerweile groß genug, damit Intel mindestens nicht mehr wegläuft.

[davidzo]

Ich habe 9700X mit 285K verglichen.

Welche Relevanz hat das?

Das eine ist eine midrange CPU mit 8 Kernen 16Threads und das andere eine golden sample highend CPU mit 24 Kernen die das doppelte kostet.

AMD bietet in dieser Generation keine highend CPU mit 1x CCD ohne Vcache an. Aber deswegen für IPC vergleiche eine midrange CPU mit highend zu vergleichen ist falsch.
Auch der Vergleich zu Dual CCDs hinkt ein wenig wenn man an der Core IPC interessiert ist denn wir wissen dass single CCD cpus wie der 9800x3d schneller sind in games als dual CCD selbst wenn letztere bessere bins sind und höher takten.

Man müsste schon einen 9950x nehmen und ein CCD deaktivieren wenn man Aussagen zur Gaming performance von Zen5 vs Lion Cove ableiten will.


9950X 105%
285K 111%

Sagte ich ja schon, 6%. Es gibt aber auch Tests wo es anders herum ausgeht, das hängt auch an der Benchmarkauswahl und dem jeweiligen CPU Sample.


Also grundsätzlich ändert das nicht viel an der Aussage, dass Intels P Cores keine Performancenachteile haben pro Takt und absolut.

Jetzt verschiebst du aber gewaltig die Torpfosten.

Vorher ging es noch im einen IPC Vorsprung und jetzt reicht plötzlich ähnlich schnell.

Ähnlich schnell ist halt nicht sehr glohreich wenn du dafür mehr Fläche brauchst, erheblich mehr Energie und einen full Node Vorsprung beim Fertigungsprozess.

Dass sich an den L3 Latenzen massiv etwas ändern wird wage ich zu bezweifeln, weil gleichzeitig die Kapazität ja massiv ansteigen soll. Arrowlake hat auch schon den L3 auf dem compute Die, hier sehe ich also kein Verbesserungspotential. Novalake wird zudem den Memory controller im Soc Tile haben, genau wie bei Arrowlake, wieso sollte also Arrowlakes Bleifuß beim Dram verschwinden? Arrowlake ist bereits ein low latency redesign von Meteorlake. Wenn da noch low hanging fruits wären hätten die Intel ingenieure sie schon entdeckt.

Das beste was man hoffen kann sind L3 Latenzen näher dran an Lunarlake und Pantherlake, mit massiv höherer Kapazität und Bandbreite aber eher mit Arrowlake vergleichbarer Speicherlatenz. Damit wird man AMDs L3 Cache-design weiterhin hinterher rennen, aber das ist auch okay so denn schließlich hat man dafür die größere L2 Hitrate.

Ob der BLLC aber reicht um den erwarteten Taktsprung von Zen6 und die dort womöglich ebenfalls verbesserten Latenzen zu kontern, das wage ich zu bezweifeln.


Lip Bu tan selbst glaubt jedenfalls selbst nicht ernsthaft daran dass sie deutlich gewinnen können mit Nova lake.


Along with our next generation Nova Lake, coming at the end of 2026, we now have a client roadmap that combines best-in-class performance with cost optimized solutions, giving me confidence that we are on a path to fortify market share and profitability, in both notebooks and desktops, over the next several years.
- Intel CEO Lip-Bu Tan


Wenn man den marketing talk interpretiert steht da im, Grunde folgendes:
- Man rechnet nicht damit die Performance Führung zu übernehmen, aber wenigstens preislich kompetitiv zu sein.
- Man rechnet nicht mit steigendem Marktanteil, aber sieht sich auf dem Weg dazu weniger schnell Marktanteil zu verlieren als bisher.
- Man hofft die Verluste zu stoppen nicht nur im notebookmarkt, sondern auch im Desktop.
- Das beides (Profit, Marktanteile) passiert allerdings eher nicht noch dieses Jahr mit NVL und PTL sondern eventuell erst mit den Nachfolgegenerationen.

Viel tiefer kann man nicht stapeln. Man achte auf die mehrfach verschachtelten Konjunktive in Bezug auf die Marktanteile.

Best in class performance sagt man immer wenn man schon weiß dass man nicht "best performance" schreiben kann. Man schafft sich halt eine Kategorie in die alle schnelleren Konkurrenzprodukte nicht reinpassen.
Beispiel: "Wir haben die schnellste Multithread Performance in der Klasse der BLLC/X3D CPUs mit nur einem compute Chiplet."

Best in class hat Intel immer geclaimt in der Vergangenheit, selbst bei rocket lake oder meteor lake.

[Badesalz]

Best in class performance sagt man immer wenn man schon weiß dass man nicht "best performance" schreiben kann. Oder dann sagen kann, ist doch bei Notebooks auch so. Dann kann man auch noch sagen, "with cost optimized solutions" gehört mit zu dem ersten Teil des Satzes. Andersrum also, für die optimierten Kosten ist die Leistung best in class. usw. usf.

Aber ja. Daß sie mal was bringen was man sich wenigstens mal anschauen kann wäre wahrlich an der Zeit. Wann kommt eigentlich Xeon 7? Da sieht es eigentlich schlechter aus als auf dem Desktop...

[robbitop]

Welche Relevanz hat das?

Das eine ist eine midrange CPU mit 8 Kernen 16Threads und das andere eine golden sample highend CPU mit 24 Kernen die das doppelte kostet.

AMD bietet in dieser Generation keine highend CPU mit 1x CCD ohne Vcache an. Aber deswegen für IPC vergleiche eine midrange CPU mit highend zu vergleichen ist falsch.
Auch der Vergleich zu Dual CCDs hinkt ein wenig wenn man an der Core IPC interessiert ist denn wir wissen dass single CCD cpus wie der 9800x3d schneller sind in games als dual CCD selbst wenn letztere bessere bins sind und höher takten.

Man müsste schon einen 9950x nehmen und ein CCD deaktivieren wenn man Aussagen zur Gaming performance von Zen5 vs Lion Cove ableiten will.

Verstehe nicht warum du dich daran aufhängst. Habe das doch längst eingeräumt und dann im Folgeposting die Zahlen angepasst? :)




Sagte ich ja schon, 6%. Es gibt aber auch Tests wo es anders herum ausgeht, das hängt auch an der Benchmarkauswahl und dem jeweiligen CPU Sample.


Aber auch 10% zu Raptorlake. :)
Aber ja dass es +/- ein paar Prozent sind ist je nach Index der Fall. Auch das habe ich schon geschrieben. Wozu also das nochmal durchkauen? :)


Jetzt verschiebst du aber gewaltig die Torpfosten.
Ich schrieb in #1661 „ Also rein von der uArch ist AMD offenbar nie an Intel vorbeigezogen“.
Kannst du die Stelle bitte zitieren wo ich von einem „IPC Vorsprung“ spreche? Ich hab eben mal kurz drüber geschaut und es nicht gefunden. :)

Ggf/potenziell habe ich mich auch nicht ideal ausgedrückt. Was die Intention war: Zen 5 als core hat keinen Performancevorteil. Und mich hat das einfach überrascht anhand der Stellung die AMD sich erarbeitet hat trotz der Intel fails und was das fur Implikationen haben kann wenn mit dem big LLC auch der letzte Trumpf nicht mehr explizit ist.

Und zumindest in dem PCGH Index liegt auch ein leichter Vorsprung für Lion Cove vor und ein etwas größerer (wahrscheinlich wegen der memorylatency) von RTL. Spannend wäre es alle drei uArchs memorylatency normiert zu betrachen. Ich vermute dann liegt lion cove vor RTL und auch ein bisschen weiter vor Zen 5. Von bremsender lahmer Fabric in Spielen können alle IHVs wahrscheinlich ein Liedchen singen. :)



Vorher ging es noch im einen IPC Vorsprung und jetzt reicht plötzlich ähnlich schnell.

Siehe oben.



Ähnlich schnell ist halt nicht sehr glohreich wenn du dafür mehr Fläche brauchst, erheblich mehr Energie und einen full Node Vorsprung beim Fertigungsprozess.

(1) es ging mir explizit rein isoliert um die performance.
(2) obiges habe ich mindestens 1x schon vor diesem Posting auch geschrieben. Aber darum ging es mir nicht initial. Die Frage ist wie viel mm2 das wirklich mehr ausmacht am Ende vom ganzen SoC und was das wirklich für Kostennachteile bedeutet? Insbesondere wenn man gar nicht so viele P cores braucht und für MT workloads ja auch mit den E Cores performance holen kann, die widerum pro Core weniger mm2 verbrauchen. Aber ja zur rein akademischen Bewertung der Cores: jap deutlich wenig beeindruckend und deshalb werden vermutlich uA die P Cores ge-axt. Was ich auch schon geschrieben habe ^^ (hast du eigentlich alle Postings gelesen bevor du diesen verfasst hast? :))



Dass sich an den L3 Latenzen massiv etwas ändern wird wage ich zu bezweifeln, weil gleichzeitig die Kapazität ja massiv ansteigen soll. Arrowlake hat auch schon den L3 auf dem compute Die, hier sehe ich also kein Verbesserungspotential. Novalake wird zudem den Memory controller im Soc Tile haben, genau wie bei Arrowlake, wieso sollte also Arrowlakes Bleifuß beim Dram verschwinden? Arrowlake ist bereits ein low latency redesign von Meteorlake. Wenn da noch low hanging fruits wären hätten die Intel ingenieure sie schon entdeckt.

Ich denke hier sind wir alle skeptisch. Die L3 Latenz wird höchstwahrscheinlich nicht besser aber der LLC wird deutlich größer was die hitrate verbessert was widerum bedeutet dass man seltener auf die sehr langsame memorylatency warten muss. Wenn auch in einem hitfall die latenz schlechter als beim vcache sein kann.
Allerdings sollen es 144 MiB werden, was ggf ein wenig helfen kann. Zen 6x3d bekommt allerdings auch 144 MiB.
Also ja ein Teilvorteil bleibt wahrscheinlich. Außer Intel überrascht uns doch mit einem neuen LLC der ähnlich wie X3D gebaut ist. Aber unwahrscheinlich.



Ob der BLLC aber reicht um den erwarteten Taktsprung von Zen6 und die dort womöglich ebenfalls verbesserten Latenzen zu kontern, das wage ich zu bezweifeln.
Ist ein guter Punkt. Wobei die Frage ist wie überhypt der Taktsprubg am Ende ist. MLID ist auch schon halb zurückgerudert und begründete es damit dass es ganz überraschend jetzt noch nur N2P statt N2x sein wird.
Und man muss sehen wie viel mehr Performance Intel aus ihren neuen Cores holt. Immerhin sind das IIRC keine refreshcores wie bei PTL sondern wieder neue.



Lip Bu tan selbst glaubt jedenfalls selbst nicht ernsthaft daran dass sie deutlich gewinnen können mit Nova lake.



Wenn man den marketing talk interpretiert steht da im, Grunde folgendes:
- Man rechnet nicht damit die Performance Führung zu übernehmen, aber wenigstens preislich kompetitiv zu sein.
- Man rechnet nicht mit steigendem Marktanteil, aber sieht sich auf dem Weg dazu weniger schnell Marktanteil zu verlieren als bisher.
- Man hofft die Verluste zu stoppen nicht nur im notebookmarkt, sondern auch im Desktop.
- Das beides (Profit, Marktanteile) passiert allerdings eher nicht noch dieses Jahr mit NVL und PTL sondern eventuell erst mit den Nachfolgegenerationen..

Viel tiefer kann man nicht stapeln. Man achte auf die mehrfach verschachtelten Konjunktive in Bezug auf die Marktanteile.

Best in class performance sagt man immer wenn man schon weiß dass man nicht "best performance" schreiben kann. Man schafft sich halt eine Kategorie in die alle schnelleren Konkurrenzprodukte nicht reinpassen.
Beispiel: "Wir haben die schnellste Multithread Performance in der Klasse der BLLC/X3D CPUs mit nur einem compute Chiplet."

Best in class hat Intel immer geclaimt in der Vergangenheit, selbst bei rocket lake oder meteor lake.

Ist das so? Puh ich muss zugeben Marketingsprech ist nicht mein Kerngebiet X-D


Am Ende will ich nur sagen: AMD sollte nicht complacent werden. Intel macht auch ihre Hausaufgaben wie man zuletzt mit PTL gesehen haben und wenn sie noch einen bLLC bringen sind zumindest die Zeiten der „humiliation“ vorbei.

[Nightspider]

Angeblich soll Zen7 ja wieder schneller auf Zen6 folgen und nutzt ja dann TSMCs A14 mit Backside Power Delivery und soll nochmal einen großen Leistungssprung bieten... bleibt abzuwarten ob Intel mit dieser Kadenz mithalten kann oder weiter unter die Räder gerät.
Über Intels A18 wird ja auch verschiedenes bzgl der Yields erzählt...

Wahrscheinlich ist Zen 6 ja schon in Verspätung durch die N2 Prozesse.

Ich nehme mal an das die Zen 7 Architektur dann direkt zum A14 Start fertig und bereit ist. Das wird noch hart für Intel.

[robbitop]

Abwarten. :) bisher werden iirc die release Zeiträume von gen zu gen eher länger und iirc wurde schon öfter gemunkelt dass next next gen dafür aber schneller kommt. ^^

[y33H@]

best-in-class könnte auch das beste Produkt in der Gaming-Klasse bedeuten und cost-optimized könnte sich auf die Marge beziehen ... ich wäre da vorsichtig mit Interpretationen.

[davidzo]

Wahrscheinlich ist Zen 6 ja schon in Verspätung durch die N2 Prozesse.

Das glaube ich nicht. Bisher sind die Gerüchte alle smooth Sailing für venice und olympic ridge.

Das Pferd springt nur noch so hoch wie es muss und solange Zen5 reicht gibt es eben auch nur Zen5.

Seit AMD performance-leader ist hat man ein ganz anderes paradigma zur Produkteinführung als früher noch. Ähnlich wie Intel in den Zeiten der Marktführwerschaft drückt man auf die bremse bzw. verbringt dann die extra Entwicklungezeit mit Optimierungen.

Die Zen1 Markteinführung war gerusht, der dram support sehr schlecht qualifiziert.
Zen2/3000 war das Boost clock Fiasko und diverse Agesa revisionen notwendig.

Seit Zen4 geht man das ruhiger an, zumindest Hardware, Silicon, yield und Taktseitig sind die Produkte sehr ausgefeilt. Bei Zen5 reicht AMD man sogar eine nicht mehr cutting edge Fertigung zur Margenoptimierung. Es gab in letzter Zeit auch keine andauernden Lieferschwierigkeiten mehr wie bei Zen1, Ryzen2000 und Ryzen 3000. Auch wenn Zen5 nicht ganz gefeit von Startschwierigkeiten war (war aber eher ne Microsoft Sache) nimmt sich AMD doch jetzt wesentlich mehr Zeit die Produkte zu polieren.

Das ist ein bisschen wie die Nvidia Strategie der letzten Jahre. Man designt die Hardware so großzügig dass man den Maximalausbau und die Maximaltaktraten noch genau an die Kokurrenz anpassen kann, aber auch bloß nicht zu viel liefert. Man muss Intel nur ganz knapp schlagen, bei niedrigerer TDP und Fertigungskosten, das reicht schon.

Ich denke die polieren Zen6 so lange wie Intel keinen Gegner am Start hat. Sobald sie konkreteres über Novalakes tatsächliche Taktraten und performance wissen, dann teilen sie ihre SKUs und Bins ein und legen das pricing fest.



best-in-class könnte auch das beste Produkt in der Gaming-Klasse bedeuten und cost-optimized könnte sich auf die Marge beziehen ... ich wäre da vorsichtig mit Interpretationen.

Seit wann muss man Intel marketing Aussagen nicht immer auf der Goldwaage sezieren um sie auf den kleinsten gemeinsamen Nenner zu bringen?
Deine Verwendung von Klasse wäre auch ungewöhnlich, weil Gaming eine vertikale Sparte ist und Klassen in der Regel horizontale Zusammenhänge beschreiben. Sozusagen Spalten vs Zeilen in einer Tabelle: Innerhalb gaming gibt es mehrere Klassen.

Ich stimme dir aber zu dass cost optimized nicht dasselbe ist wie cost effective. Das eine kann auch eine gute Marge für Intel bedeuten, was zu Lip bu Tans anderen Aussagen besser passen würde, letzteres steht für eine gute Preis Leistung für den Endkunden. Ich denke er hat bewusst nicht 'cost effective' gesagt.

[Nightspider]

Ja, kommt drauf an wie man in dem Fall Verspätung definiert.

September/Oktober wären 26-27 Monate nach Zen5.
Ich denke die Architektur war schon eher fertig als der Prozess.

[y33H@]

Deine Verwendung von Klasse wäre auch ungewöhnlich, weil Gaming eine vertikale Sparte ist und Klassen in der Regel horizontale Zusammenhänge beschreiben. Sozusagen Spalten vs Zeilen in einer Tabelle: Innerhalb gaming gibt es mehrere Klassen.Auch Gaming-Klassen lassen sich ja lustig definieren, etwa "Enthusiast" (für bLCC vs X3D) oder "sub $500" oder wie auch immer :freak:

[bbott]

...muss AMD aber wirklich richtig fettig nachlegen ansonsten liegt man wieder hinten.
Kann sein, aber bisher haben Intels L2 und L3 Cache Vergrößerrungen wenig bis nichts gebracht (12 gen bis 14 gen). Auch haben die teils doch schon den shared Cache mit der iGPU?!
Intel hat es meist mit höher Latenz wieder zu nichte gemacht. Zen scheint überdurchschnittlich von Cache zu profitieren.
Aber wir werden es in ca. 12 Monaten sehen :-D

[robbitop]

Wenn du die 16 MiB bei PTL meinst dann nein - das ist GPU L2 Cache.
Lokaler Cache (L0-L2 aktuell) scheint nicht so viel zu bringen un die gesamthitrate zu erhöhen. Und ja durch die Chiplets seit MTL haben sie sich die Memorylatency ziemlich erhöht was ARL sichtbar zurückhält. Entsprechend wird auch ein großer LLC was bringen bei NVL.

[mczak]

Auch haben die teils doch schon den shared Cache mit der iGPU?!
intel hat da ziemlich viel ausprobiert. Zumindest bis Raptor Lake hatten die intel cpus alle cpu Kerne (bzw. die E-Cluster) und den IGP direkt am Ringbus mit dem L3.
Bei Lunar Lake sind die E-Cores ja nicht am Ringbus mit dem L3 beteiligt, der Chip hat aber 8 MB SLC (oder Memory Side Cache wie das intel nennt), der kann auch von NPU, IGP etc. genutzt werden. Für die P-Core Performance bringt der wohl eher wenig.
Bei Panther Lake sind die E-Cores wieder am L3-Ring, die LP-E Kerne aber nicht, wiederum sollte da der 8MB SLC helfen.
Arrow Lake hat aber keinen SLC, aber alle (mit Ausnahme der LP-E) Kerne sind eben wiederum am Ringbus, eigentlich müsste der deutlich schlechtere Latenzen zwischen CPU und IGP haben als so ziemlich alle intel Chips der letzten 10 Jahre, weil der so ziemlich der einzige intel Chip ist der keine gesharte Cache Ebene zwischen CPU und IGP hat (so tragisch ist das nicht - hat AMD mit Ausnahme von Strix Halo auch nicht).
Keine Ahnung wie das genau bei Nova Lake aussieht - aber ich denke prinzipiell lässt sich sagen dass ein SLC für die CPU-Performance nicht wirklich was bringt wenn alle CPU-Kerne sowieso einen gemeinsamen L3 haben. Und der bLLC (2D H-Cache?) ist ja sicher zwischen allen Kernen geshart, für die CPU-Performance ist das am Ende ziemlich egal ob da noch weitere Dinge dranhängen (nicht aber natürlich für die Komplexität).

[davidzo]

Wenn du die 16 MiB bei PTL meinst dann nein - das ist GPU L2 Cache.
Lokaler Cache (L0-L2 aktuell) scheint nicht so viel zu bringen un die gesamthitrate zu erhöhen. Und ja durch die Chiplets seit MTL haben sie sich die Memorylatency ziemlich erhöht was ARL sichtbar zurückhält. Entsprechend wird auch ein großer LLC was bringen bei NVL.

Ich denke er meint schon den L2.

Skylake - 256kb 12 Zyklen
Rocketlake - 512kb 13 Zyklen
Alderlake - 1280kb 15 Zyklen
Raptorlake - 2048kb 16 Zyklen
Lunarlake - 2560kb ? Zyklen
Arrowlake - 3072kb 17 Zyklen + 192kb L1.5 cache

Das fühlt sich aber alles nach diminishing returns an weil nach Rockelake trotz immer größerer Zuwächse kaum noch mehr IPC heraus gekommen ist, sehr wohl aber mehr Energieeffizienz und Taktraten. Jedenfalls wenn man Chester Lam und George Cozma glauben schenkt hat schon Alderlakes Ausbau nicht wirklich effizient: https://chipsandcheese.com/p/going-armchair-quarterback-on-golden-coves-caches

[two_smoking_barrels]

Arrow Lake ist beim Core ein anderes Biest als Zen 5:
- 64kB L1i$ (vs. 32kB)
- Grösserer ROB (576 vs. 448)
- Grösseres INT Reg-File (~290 vs. 240)
- Grössere INT Scheduler (~97 vs. 88)
- 192kB L1.5$ (n.a. auf Zen 5)
- 3 MB L2$ (vs. 1 MB)

Lion Cove ist da an vielen Orten deutlich fetter als Zen 5.

IHMO werden die Vergrößerung von Kernresourcen überschätzt. Hier (https://arxiv.org/pdf/1906.08170) ein Intelpaper diesbezüglich:

- eine ver-32-facher aller Kernresourcen von Skylake mit gleichbleibenden Skylake-Branchpredictor (TAGE-SC-L 8KB) führt nur zu ~75% mehr IPC
- eine ver-32-facher aller Kernresourcen von Skylake mit stark aufgebohrten Skylake-Branchpredictor (TAGE-SC-L 64KB) führt nur zu ~80% mehr IPC
- eine ver-32-facher aller Kernresourcen von Skylake mit perfekten Branchpredictor (Perfect BP) führt nur zu ~180% mehr IPC

(Taktkeule rausholen höhrt sich doch plötzlich Vernüftig an?)
----

Bezüglich Intel Caches. Was sehr wichtig ist zu beachgten, dass Intel richtig gute Algorithmen für ihre Caches haben. Hier habe ich ein Diagramm von David Huang zusammengeschnitten (Quelle (https://blog.hjc.im/zen-5-more-details-2.html)) und angehangen.

24 MB L3 von Meteor Lake gewinnen ziemlich eindeutig gegen 32 mb L3 von Zen 4

[mboeller]

Das Pferd springt nur noch so hoch wie es muss und solange Zen5 reicht gibt es eben auch nur Zen5.


das glaube ich nicht. Warum sonst sollte AMD der erste Kunde mit 2nm Tape-out bei TSMC sein wenn nicht der Wunsch ganz vorne dabei zu sein.


.......
Seit Zen4 geht man das ruhiger an, zumindest Hardware, Silicon, yield und Taktseitig sind die Produkte sehr ausgefeilt.


du findest es also schlecht, dass die Produkte nicht mehr beim Kunden reifen? Oder lese ich da was falsches?

[basix]

Angeblich soll Zen7 ja wieder schneller auf Zen6 folgen und nutzt ja dann TSMCs A14 mit Backside Power Delivery und soll nochmal einen großen Leistungssprung bieten...

TSMC Zeitplan:
- A14 = 2028
- A14 mit SPR = 2029

Zen 7 kann schneller kommen, aber bestenfalls mit A14 ;)

Bezüglich Intel Caches. Was sehr wichtig ist zu beachgten, dass Intel richtig gute Algorithmen für ihre Caches haben. Hier habe ich ein Diagramm von David Huang zusammengeschnitten (Quelle (https://blog.hjc.im/zen-5-more-details-2.html)) und angehangen.

24 MB L3 von Meteor Lake gewinnen ziemlich eindeutig gegen 32 mb L3 von Zen 4
Intel hat ein grösseres OoO Window (Meteor Lake > Zen 4), wodurch man Prefetches besser planen kann und damit werden dann Cache-Misses reduziert. Der doppelt so grosse L1i$ hilft allenfalls auch noch was. Schade ist bei dem Vergleich Desktop Zen 5 nicht dabei.

Unter dem Strich ist es in etwa so:
Intel und AMD bewegen sich hinsichtlich BPU und Cache-Utilization auf Augenhöhe. AMD hat allerdings niedrigere Latenzen und benötigt weniger Fläche.

[robbitop]

Bei Lunar Lake sind die E-Cores ja nicht am Ringbus mit dem L3 beteiligt, der Chip hat aber 8 MB SLC (oder Memory Side Cache wie das intel nennt), der kann auch von NPU, IGP etc. genutzt werden..
Kleiner Hinweis: IIRC hatte Intel zu LL in einem der Interviews gesagt der SLC wird nicht durch die GPU für 3DRendering genutzt. In der Hinsicht eher für Video/Multimedia um besonders stromsparend zu sein.

[davidzo]

du findest es also schlecht, dass die Produkte nicht mehr beim Kunden reifen? Oder lese ich da was falsches?
Ich habe das nicht bewertet.
Ich beobachte nur das AMD weniger Risiken eingeht und die Fortschritte allgemein langsamer werden. Das ist meistens so so wenn ein Duopol nicht vollständig im Gleichgewicht ist. Früher war Intel der Leader der auf die Bremse trat, heute ist es AMD.



Bezüglich Intel Caches. Was sehr wichtig ist zu beachgten, dass Intel richtig gute Algorithmen für ihre Caches haben.

Die Trefferquote ist nicht die entscheidende Metrik, sondern die durschnittliche Antwortzeit (AMAT).
Wenn du dir nur die Misses anguckst aber nicht die Antwortzeit, dann blendest du die Latenz ja vollständig aus. Was du willst ist wie schnell im Schnitt geliefert wird. Ein Miss verschlechtert dann je nach penalty massiv die durchschnittliche Antwortzeit, insofern spielt die MPKI hier trotzdem eine wichtige Rolle. Kein wunder dass Intels langsamere aber große Caches aber gut dastehen, wenn nur die Hitrate und nicht die Latenz Strafe keine Rolle spielt.

AMAT = Hit Time + (Miss Rate × Miss Penalty).


Im Übrigen ist die Überschrift 32 vs 24 vs 16MB in dem Diagramm irreführend, denn es geht um mehr als nur den L3.
Der niedrige L3 MPKI in David Huangs Tests ist auch ein Zeichen wie hoch die Hitrate bereits in den großen private core Caches ist und der L3 eben gar nicht so groß sein muss um deren Misses noch aufzunehmen.


TSMC Zeitplan:

Intel hat ein grösseres OoO Window (Meteor Lake > Zen 4), wodurch man Prefetches besser planen kann und damit werden dann Cache-Misses reduziert. Der doppelt so grosse L1i$ hilft allenfalls auch noch was.

Nicht zu vergessen der L1.5 mit 192kb.
Intel P-Cores sind schon an private Cores und OoO ressourcen so fett dass die L3 Cache Größe eine kleinere Rolle spielt. In Anwendungen gelingt es Arrowlake daher auch sehr gut die Latenzen zu verstecken.

Das bedeutet aber auch dass sie weniger von einem riesigen BLLC gewinnen können, aber auch weniger von Latenzverbesserungen des L3. Jedenfalls im Umfeld normaler Anwendungen. Spiele können hier wirklich nochmal anders reagieren als die SPEC Tests von David Huang.

[Badesalz]

Das ist meistens so so wenn ein Duopol nicht vollständig im Gleichgewicht ist. Früher war Intel der Leader der auf die Bremse trat, heute ist es AMD.Das ist allgemein das einzige warum die bei mir so durch sind. Als ich gecheckt habe, daß sie mich/uns ewig verarscht haben.
Das war vom Übergang von Broadwell auf Haswell, wo mir das Licht langsam aufging und sich das mit Skylake in Gewissheit wandelte. Und das haben sie auch nicht gehalten. Es wurde auch noch schlimmer.

Die haben das auch großflächig gemacht. AMD ballert wenigstens mit Epycs, macht da die Kohle, verhaut sie gerechterweise und lässt halt mit Ryzen was abtropfen. Intel hat bis dato einfach alle und jeden verarscht. Mit CPUs.

Netzwerk von denen hab ich geliebt. Bis der Malignom auch auf jene übersprang...

[mczak]

Kleiner Hinweis: IIRC hatte Intel zu LL in einem der Interviews gesagt der SLC wird nicht durch die GPU für 3DRendering genutzt. In der Hinsicht eher für Video/Multimedia um besonders stromsparend zu sein.
So wie ich das verstanden habe ist das aber reine Cache-Policy, d.h. die IGP ist durchaus daran angebunden und die Cache-Kohärenz wird sichergestellt, aber Schreibzugriffe der IGP in den Speicher werden nicht gecacht.
Also ähnlich wie bei Strix Halo der MALL, der wird von den CPU-Kernen auch nicht aktiv genutzt und trotzdem garantiert der MALL Cache-Kohärenz zwischen CPU und GPU.
Wobei bei AMD wurde das so in einem Interview bestätigt, bei intel bin ich mir da nicht wirklich sicher. Wäre aber IMHO schon sinnvoll.

[Badesalz]

Das ist grad etwas besonderes. Mal so nebenbei...

In einer aktuell halbwegs befriedeten Umgebung läuft grad das Thema AMD in einem Intelthread und das Thema Intel in einem AMD-Thread. Welch eine besondere Zeit :usweet:

[robbitop]

Ich denke er meint schon den L2.

Skylake - 256kb 12 Zyklen
Rocketlake - 512kb 13 Zyklen
Alderlake - 1280kb 15 Zyklen
Raptorlake - 2048kb 16 Zyklen
Lunarlake - 2560kb ? Zyklen
Arrowlake - 3072kb 17 Zyklen + 192kb L1.5 cache

Das fühlt sich aber alles nach diminishing returns an weil nach Rockelake trotz immer größerer Zuwächse kaum noch mehr IPC heraus gekommen ist, sehr wohl aber mehr Energieeffizienz und Taktraten. Jedenfalls wenn man Chester Lam und George Cozma glauben schenkt hat schon Alderlakes Ausbau nicht wirklich effizient: https://chipsandcheese.com/p/going-armchair-quarterback-on-golden-coves-caches
Ja. Intel hat sich mit der Balance bei den P Cores etwas verrannt. Wahrscheinlich mottet man die deswegen mittelfristig ein. (was dauert wenn man so eine Entscheidung trifft weil die aktive Pipeline der Entwicklung offenbar 3-4 Generationen lang ist)
Schade, dass man das Royal Core Projekt getötet hat. Wer weiß, wie gut das geworden wäre.

[robbitop]

IHMO werden die Vergrößerung von Kernresourcen überschätzt. Hier (https://arxiv.org/pdf/1906.08170) ein Intelpaper diesbezüglich:

- eine ver-32-facher aller Kernresourcen von Skylake mit gleichbleibenden Skylake-Branchpredictor (TAGE-SC-L 8KB) führt nur zu ~75% mehr IPC
- eine ver-32-facher aller Kernresourcen von Skylake mit stark aufgebohrten Skylake-Branchpredictor (TAGE-SC-L 64KB) führt nur zu ~80% mehr IPC
- eine ver-32-facher aller Kernresourcen von Skylake mit perfekten Branchpredictor (Perfect BP) führt nur zu ~180% mehr IPC

(Taktkeule rausholen höhrt sich doch plötzlich Vernüftig an?)
----

Ja da hat Intel mit den P Cores ja mächtig alles Kernressourcen aufgebohrt in den letzten Jahren. Mit vergleichsweise wenig Steigerung der IPC. Man scheint da aus irgendwelchen Gründen (deminishing returns? limitierung im decoding bei x86 isa? oder aber P core spezifische Probleme?) gegen eine asymptotische Wand zu laufen


Bezüglich Intel Caches. Was sehr wichtig ist zu beachgten, dass Intel richtig gute Algorithmen für ihre Caches haben. Hier habe ich ein Diagramm von David Huang zusammengeschnitten (Quelle (https://blog.hjc.im/zen-5-more-details-2.html)) und angehangen.

24 MB L3 von Meteor Lake gewinnen ziemlich eindeutig gegen 32 mb L3 von Zen 4

Sind das die Missrates in Prozent? Inkludieren die ggf auch den Einfluss vom L2? Denn da hat MTL im Redwood Cove ja 2x so viel wie Zen4/5. Das reduziert natürlich auch den "Druck" auf den L3.


Nicht zu vergessen der L1.5 mit 192kb.
Intel P-Cores sind schon an private Cores und OoO ressourcen so fett dass die L3 Cache Größe eine kleinere Rolle spielt. In Anwendungen gelingt es Arrowlake daher auch sehr gut die Latenzen zu verstecken.

Das bedeutet aber auch dass sie weniger von einem riesigen BLLC gewinnen können, aber auch weniger von Latenzverbesserungen des L3. Jedenfalls im Umfeld normaler Anwendungen. Spiele können hier wirklich nochmal anders reagieren als die SPEC Tests von David Huang.
Der gezeigte missrate Test ist allerdings mit Meteorlake (Redwood Cove). Da gibt es noch keinen L1.5. Aber falls du dich eher auf die zukünftige Aussicht des bLLCs beziehst -> nevermind :)

So wie ich das verstanden habe ist das aber reine Cache-Policy, d.h. die IGP ist durchaus daran angebunden und die Cache-Kohärenz wird sichergestellt, aber Schreibzugriffe der IGP in den Speicher werden nicht gecacht.
Also ähnlich wie bei Strix Halo der MALL, der wird von den CPU-Kernen auch nicht aktiv genutzt und trotzdem garantiert der MALL Cache-Kohärenz zwischen CPU und GPU.
Wobei bei AMD wurde das so in einem Interview bestätigt, bei intel bin ich mir da nicht wirklich sicher. Wäre aber IMHO schon sinnvoll.
Wollte damit nur sagen - bringt halt nichts beim 3D Rendering / Gaming um die GPU schneller zu machen. :)

[davidzo]

Ja. Intel hat sich mit der Balance bei den P Cores etwas verrannt. Wahrscheinlich mottet man die deswegen mittelfristig ein. (was dauert wenn man so eine Entscheidung trifft weil die aktive Pipeline der Entwicklung offenbar 3-4 Generationen lang ist)
Schade, dass man das Royal Core Projekt getötet hat. Wer weiß, wie gut das geworden wäre.

Ja, aus unserer Sicht aktuell würde das Sinn machen. Darkmont ist bei der IPC zumindest im Integer Bereich auf zen5 niveau und kaum hinter Panther Cove. Zudem taktet panther Cove auch nicht mehr exzeptionell hoch so dass die Unterschiede schrumpfen. Mit einer breiteren FPU und mehr Taktoptimierungen dürfte das den P-Cores und Zen Gegenstücken schon sehr nahe kommen.

Aber es sind ja auch noch P-Core CPUs mit SMT geplant die sicher noch kommen werden: Die Lip Bu Tan perf/Area optimierten P-Cores.

Außerdem gab es vor nem Jahr oder so mal das Gerücht dass die P-core und E-core teams um die unified Core Leitung kämpften und das P-Core team gewonnen hat. Keine Ahnung ob da was dran war denn aus heutiger Sicht wäre das dumm. Aber wer weiß wie die nächsten Generationen aussehen, vielleicht rennt auch die E-Core Entwicklung nächste Runde gegen eine Wand und aus interner Sicht wäre es dumm nur auf E-Cores zu setzen.

Ich wundere mich jedenfalls sehr wieso Jim Keller damals so von Intels Schubladenprojekten so geschwärmt hat wenn man davon doch heute kaum etwas sieht.

Ich meine mich zu erinnern das man ihm damals im Interview zum Apple M1 befragt hat bzw. das damit offensichtliche Intel IPC Defizit. Er sagte dazu dass ihn das nicht beeindruckt und Intel auch jede menge breitere Core Designs in petto mit massiv effektiveren Cache Setups hätte.
Das interview war als er gerade erst angefangen hat und eine Art Bestandsaufnahme der Engineering teams gemacht hat. Er meinte dann noch es gäbe super viele talentierte Leute bei Intel und dadurch schon sehr viele erfolgversprechende Projekte die man nur noch umsetzen müsse.

Wenn ich mir aber angucke was Intel dann bisher geliefert hat, dann werde ich den Gedanken nicht los dass man Keller mit optimistischen Pitch-Präsentationen oder geschönten Daten gefüttert hat wie wir das auch aus den Folien bei Intel Produktlaunches gewohnt sind.

Man denke nur an die pre Lunarlake Folien die uns weismachen wollten dass die SMT-losen P-Cores 30% mehr Perf/Power/Area bringen. Sowas sind ja nicht nur Marketingaussagen sondern irgendein engineer muss dafür auch Daten vorbereitet und das intern so gepitcht haben.
Sicher gibt es irgendeinen edgecase wo SMT säuft wie ein Loch und mit genug confirmation Bias kann an auch solche Folien erstellen.

Das Gegenteil war am Ende der Fall: Die MT-Leistung ging ohne SMT zurück, weshalb die Cores höher takten müssen um mehr performance zu erreichen, was sie vermutlich ineffizienter in MT macht als niedriger taktende Cores mit SMT die in MT aber immer noch schneller sind. Das konnte man leider nur bei Meteor vs Raptorlake testen weil es kein Gegenstück zu Raptorlake gab. Trotz besserem Node und Idleverbrauch ist der 155H MT und ST nicht effizienter als ein 13700H und sogar ST etwas langsamer.

[robbitop]

Sehr informativer Post :up:
Ich hatte allerdings vor einem Jahr eher verstanden, dass das E Core Team den lead bekommt. Komisch.

[Undertaker]

Das Gegenteil war am Ende der Fall: Die MT-Leistung ging ohne SMT zurück, weshalb die Cores höher takten müssen um mehr performance zu erreichen, was sie vermutlich ineffizienter in MT macht als niedriger taktende Cores mit SMT die in MT aber immer noch schneller sind. Das konnte man leider nur bei Meteor vs Raptorlake testen weil es kein Gegenstück zu Raptorlake gab. Trotz besserem Node und Idleverbrauch ist der 155H MT und ST nicht effizienter als ein 13700H und sogar ST etwas langsamer.

Unabhängig davon, ob die selbstgesteckten Ziele hier erreicht wurden oder nicht, greifen mir diese Schlussfolgerungen zu kurz:

1) Ein um SMT beschnittenes Design kannst du nicht Kernzahl-normiert mit seinem Vorgänger vergleichen, sondern müsstest dies Flächen-normiert tun (praktisch schwierig in diesem Fall). Ohne SMT wollte man schließlich auch Fläche sparen, die somit in mehr Kerne reinvestiert werden könnte. Bei gleicher Kernzahl muss das SMT-lose Design höher takten und ist damit zwangsläufig massiv im Nachteil.
2) Bzgl. Maximaltakt und damit ST-Leistung war Intel 4 zum damaligen Zeitpunkt eben kein Vorteil ggü. Intel 7. Letztlich hat man durch den Prozesswechsel zu diesem Zeitpunkt nur Effizienz gewonnen und Fläche eingespart.

[basix]

Ich hatte allerdings vor einem Jahr eher verstanden, dass das E Core Team den lead bekommt. Komisch.

Auch in FP ist Darkmont nahe an Cougar Cove dran:
https://youtu.be/jrygnUnBRNI?t=492

Bei selbem Takt ist Darkmont in etwa so schnell wie Lion Cove (Arrow Lake). Cougar Cove hat also nur +10% IPC in Spec 2017. Skymont war aber auch bereits ähnlich nah dran an Lion Cove wie jetzt Darkmont an Cougar Cove.

[robbitop]

Bei SMT hörte man eigentlich immer, dass das einen Hauch von nichts an Transistoren kostet und deshalb ein no brainer ist. Ob Intel da mit den neusten P Cores wirklich so viel Fläche gespart hat? Ich habe den Eindruck, dass sie zurückrudern und das einfach nur wegen der langen Entwicklungspipeline dauert. Und bis dahin erzählen sie halt, dass es Nachteile hat. Macht ja auch Sinn.
Ich denke AMD ist ziemlich froh, dass sie SMT drin gelassen haben und würden das auch nicht wieder entfernen wollen.

[Badesalz]

SMT war für Intel ein viel größeres security issue als für AMD. Entsprechend kompliziert war das Gefrickel das zuzunageln. Das war der Grund warum sie es erstmal komplett entfernt haben.
Sie dachten, sie können das mit E-Cores aufwiegen, aber da wo das Geld lag, im Server, ist niemand auf mixed Cores reingefallen. Keiner wollte sich damit in Serversystemen beschäftigen. Weder Linux noch Microslop noch BSD (BSD eh nicht).

Das ist noch komplizierter als SMT zunageln, also haben die Kernelheinis mit AMD SMT zugenagelt, und behalten. Fertig. Jetzt wo die Jobs gelaufen sind macht Intel ein vorgetäuscht langsames Umdenken (Salami is my life) und bringt das in Ankündigungen wieder zurück. Bis es 1x wieder da ist. Das hatte sonst keine technischen Gründe. Egal was sie erzählen.

IBM fährt 4fach wie 8fach SMT und kam noch nie auf die Idee das auch nur gerüchteweise abzuschaffen.

[davidzo]

1) Ein um SMT beschnittenes Design kannst du nicht Kernzahl-normiert mit seinem Vorgänger vergleichen, sondern müsstest dies Flächen-normiert tun (praktisch schwierig in diesem Fall). Ohne SMT wollte man schließlich auch Fläche sparen, die somit in mehr Kerne reinvestiert werden könnte. Bei gleicher Kernzahl muss das SMT-lose Design höher takten und ist damit zwangsläufig massiv im Nachteil.

Sag das nicht mir sondern Intel. Die kamen doch mit den Folien herum wo plötzlich von perf/watt/area die rede war. Ich verstehe immer noch nicht wie das gemeint war, denn es passt einfach zu nichts was an Daten letzendlich heraus kam.
Im übrigen glaube ich nicht dass es Transistoren gespart hat. Sieht man ja schon daran dass Meteorlake weniger Kerne im Maximalausbau hatte als Raptorlake. Die wenigen Einsparungen haben sie dann an anderer Stelle in den P-Cores wieder verbraucht.

Im mobile haben beide H-Modelle aber sogar den gleichen Kernausbau aus 8+16 (die LPE kerne zähle ich bei meteor lake mal nicht dazu). Es sollte also gemäß Intels Folien dazu sehr vergleichbar sein.
Bzw. gibt es afaik zwei sets an Folien, die einen sprechen von 15% performance/watt/area vorsprung der SMTlosen version und die anderen von sogar 30%. Ein set Folien (welches weiß ich nicht mehr genau?) wurde afaik noch vor MTL releast.


2) Bzgl. Maximaltakt und damit ST-Leistung war Intel 4 zum damaligen Zeitpunkt eben kein Vorteil ggü. Intel 7. Letztlich hat man durch den Prozesswechsel zu diesem Zeitpunkt nur Effizienz gewonnen und Fläche eingespart.

Naja deswegen habe ich ja den 13700H genommen. Mit 5,0Ghz taktet der gleichviel wie der 165H und 200mhz mehr als der 155h bzw. 100mhz niedriger als das MTL topmodell. Fakt ist dass von den angeblichen Singlethread bzw "per Thread"-Vorteilen durch den Wegfall von SMT in der Praxis nichts zu sehen war.

Im MT fährt MTL wesentlich höhere taktraten als ein Raptorlake, kommt aber auch nicht am 13700H dran vorbei, bzw. hat der 155H bei CB sogar probleme am 1360P vorbei zu ziehen obwohl der nur 4P 8E hat.

MTL war einfach ein griff ins Klo für Intel und das Streichen von SMT war eine der Ursachen aber lange nicht der einzige Grund.

[latiose88]

Jap kann ich nur bestätigen das sich 14700k und 265k sich nix nehmen . Also nur sparsamer wurde die CPU . Nun ja Mal sehen wie es bei AMD weiter gehen wird.

[ryan]

Ja, aus unserer Sicht aktuell würde das Sinn machen. Darkmont ist bei der IPC zumindest im Integer Bereich auf zen5 niveau und kaum hinter Panther Cove. Zudem taktet panther Cove auch nicht mehr exzeptionell hoch so dass die Unterschiede schrumpfen. Mit einer breiteren FPU und mehr Taktoptimierungen dürfte das den P-Cores und Zen Gegenstücken schon sehr nahe kommen.

Aber es sind ja auch noch P-Core CPUs mit SMT geplant die sicher noch kommen werden: Die Lip Bu Tan perf/Area optimierten P-Cores.



Das ist mir neu, welche P-Kerne meinst du für welche Generation mit SMT? Hinter Coral Rapids wird der neue unified Kern spekuliert. Der geplante launch Zeitraum lag bei H2 2028.

[reaperrr]

Naja deswegen habe ich ja den 13700H genommen. Mit 5,0Ghz taktet der gleichviel wie der 165H und 200mhz mehr als der 155h bzw. 100mhz niedriger als das MTL topmodell. Fakt ist dass von den angeblichen Singlethread bzw "per Thread"-Vorteilen durch den Wegfall von SMT in der Praxis nichts zu sehen war.

Im MT fährt MTL wesentlich höhere taktraten als ein Raptorlake, kommt aber auch nicht am 13700H dran vorbei, bzw. hat der 155H bei CB sogar probleme am 1360P vorbei zu ziehen obwohl der nur 4P 8E hat.

MTL war einfach ein griff ins Klo für Intel und das Streichen von SMT war eine der Ursachen aber lange nicht der einzige Grund.
Emmmm.... MTL hatte noch SMT (und ja, auch aktiviert beim 155H), nur so zur Info... ;)

Vergleich hier mal Thread-Zahl mit Kernzahl:
https://www.intel.com/content/www/us/en/products/sku/236847/intel-core-ultra-7-processor-155h-24m-cache-up-to-4-80-ghz/specifications.html

Dass MTL so lahm war, hatte andere Ursachen (first-gen Chiplets, Intel 4/3 nicht viel besser als der ausoptimierte Intel 7, kaum uArch-Verbesserungen usw.).

[Badesalz]

Dass MTL so lahm war, hatte andere Ursachen (first-gen Chiplets, Intel 4/3 nicht viel besser als der ausoptimierte Intel 7, kaum uArch-Verbesserungen usw.).Bezüglich SMT schrieb er, daß es eine der Ursachen war.
Ja Intel 4 war kaum besser als Intel 7 :usweet: und ja, "I love Salami" verbesserte die µArch auch kaum. Weil ähhh... "Salami is my life" und so.

[two_smoking_barrels]

Die Trefferquote ist nicht die entscheidende Metrik, sondern die durschnittliche Antwortzeit (AMAT).

Die bessere Hitrate der Intels-Cache meinte ich im Kontext von Intels höheren Cache-Latenzen. War uneindeutig von mir geschrieben.


Im Übrigen ist die Überschrift 32 vs 24 vs 16MB in dem Diagramm irreführend, denn es geht um mehr als nur den L3.
Sind das die Missrates in Prozent? Inkludieren die ggf auch den Einfluss vom L2? Denn da hat MTL im Redwood Cove ja 2x so viel wie Zen4/5. Das reduziert natürlich auch den "Druck" auf den L3.


Nein. MPKI = missed Prediction per Kilo Instruction. Also wieviel DRAM-Zugriffe man pro 1000 ausgeführte Instruktionen brauch. DRAM-Zugriffe sind hier die missed Prediction, da nach dem L3 nur der RAM kommt. Bei ausgeführte Instruktionen geht es um Retired Instruction.

Das bedeutet: Ob der L3-Cache eine sehr gute Hitrate hat, weil die vorherigen Cache-Stufen schlecht sind (daher der L3 Cache kann sehr einfach eine gute Hitrate erzielen) oder der L3-Cache eine sehr schlechte Hitrate hat, weil vorherige Cache-Stufen sehr gut sind (eine weitere Verbessrung der Hitrate für Speicherzugriffe sehr schwierig) ist egal, ein 1MPKI bedeutet immer das Gleiche: Alle 1000 Instruktionen muss man einen sehr teueren Speicherzugriff (potentiel >500 Takte) auf den RAM machen.
Um auf Davidzo Kritik an meiner Darstellung/Interpretation eingeht, könnte man natürlich sagen, dass in den L2-Caches andere Daten sind als im L3-Cache. Daher der L2 dient anderen SPeicherzugriffe als der L3.
Das heißt bei AMD (32 MB L3) + (1MB L2) = 33MB SRAM und bei Intel (24MB L3) + (2MB L2) = 26MB SRAM (bei ST). Und Natürlich ist es einfacher einen guten L3 zu konstruieren, der sich pur auf die Verringerung der RAM-Zugriffe konzentriert, wenn man sich nicht parallel um einen zu kleine L2's kümmern muss.


Intel hat ein grösseres OoO Window (Meteor Lake > Zen 4), wodurch man Prefetches besser planen kann und damit werden dann Cache-Misses reduziert.
Ich weis nicht, wie Prefetching bei der SPEC2017-Suite gelöst wurde. Allgemein denke ich, dass größere OoO-Windows nur sehr minimal bis gar nicht bei Prefetching helfen. Bspw. bietet es sich bei x86 an die Prefetch-Loads über ein "Helper Thread" zu machen, statt die Prefetch-Loads im Hauptprogramm zu haben. Dann kontrolliert man wie weit die Prefetch-Loads vorausgehen über Thread-Synchronisation (sowas wie futex (https://man7.org/linux/man-pages/man2/futex.2.html)), die ROB-Größe ist hierbei irrelevant.

Ansonsten wenn der Compiler die Prefetch-Loads im Code einfügt, hat man das Problem oder zumindest ist das mein Verständnis, das Compiler in sowas sehr schlecht sind.

Aber angenommen, die Spec-Leute haben manuel die Prefetch-hints im Code platziert, so gilt dann immer noch, was ich bereits verlinkt habe, dass die Skalierung der Pipeline-Ressourcen sehr schlecht mit IPC skalieren. Daher würde ich Intels bessere Cache-Hitrate vorallem auf bessere Cache-Algorithmen schieben.

[two_smoking_barrels]

Außerdem gab es vor nem Jahr oder so mal das Gerücht dass die P-core und E-core teams um die unified Core Leitung kämpften und das P-Core team gewonnen hat. Keine Ahnung ob da was dran war denn aus heutiger Sicht wäre das dumm.

Ich verständnis war, Lip Bu Tan hat bei seinen großen Sparmaßnahmen entschieden, dass die Israelis weggesparrt werden. Also das P-Core Team in Haifa noch ~2 Generation rausbringt (was halt in der Pipeline ist) und dann freiwilig gegangen werden. Die alten E-Cores werden dann zu den neuen P-Cores und werden unter dem bisherigen E-Core-Team in Austin weiterentwickelt . Die neuen E-Cores werden dann E-Cores a la AMD. Daher "Unified Core". Also natürlich ist das nur mein Verständnis von der Gerüchteküche.

[two_smoking_barrels]

Ja da hat Intel mit den P Cores ja mächtig alles Kernressourcen aufgebohrt in den letzten Jahren. Mit vergleichsweise wenig Steigerung der IPC. Man scheint da aus irgendwelchen Gründen

Ich würde vermuten, das schlechte skalieren der Kernressourcen mit IPC intrinsisch für Sequentiellen Code ist. Daher, je weiter man in die Zukunft durch größere OoO-Window schaut, destso schwieriger wird das finden weiterer Parallelität.

Natürlich kann man diese schlechte Skalierung (stark) verbessern. Das Beispiel vom Intel-Paper war der bessere Branch-Predictor.
Andere Beispiel: Load-Store-Adress Speculation. Daher man spekuliert ob man Loads, die in der Zukunft liegen eher ausführen kann. Oder sein lassen sollte, weil noch ein Store auf diesselbe Adresse kommt.
Oder die Kerne erzeugen aus einem Spekulativen Load ein Prefetch-Load, sodass die Speicheradresse schon mal im Cache liegt.
Oder die Kerne erzeugen aus einem zukünftigen Store, wo die Adresse bekannt ist, aber noch nicht bekannt ist, was geschrieben wird, ein Prefetch-Load. Daher die benötigte Adresse für den Store liegt schonmal im Cache und andere Caches wissen Bescheid, dass man die Exklusivität über die Cacheline hält.
Etc. die heutigen Kerne werden sicherlich einige dieser Methoden umgesetzt haben, aber Skylake wahrscheinlich nicht.

Aber trotzdem wird weiterhin gelten, dass je weiter man in die Zukunft durch größere OoO-Window schaut, destso schwieriger wird das finden weiterer Parallelität. Ich mein es hat sein Grund, warum bei David Huang ein leicht übertackteter Zen5X3D ganz knapp gegen ein M4P gewinnt. Klar ist das ein unfairer Vergleich, aber der M4P hat ein massiv größeres ReOrderWindow.

448 Entries (Zen5) vs. 361 Entries beim M4P. Nur passen bei Zen eine Micro-Op in eine Entry und bei Apple bis zu sieben(!) Micro-Ops. (Also die Zahl 7 kommt vom M1 explainer. Könnten beim M4 auch mehr sein)

[robbitop]

Pro Takt scheinen die neusten ARM Cores allerdings noch ein Stück vorn zu liegen. M5, Oryo 3, C1 Ultra.
Klar kann man auch sagen, dass taktbarkwit auch potenziell reine IPC kostet. Allerdings schmilzt dieser Grund immer mehr. Die neusten ARM Cores takten bis zu 5 GHz (Oryo 3). Die anderen liegen bei 4,5 GHz. Es fehlen an Taktbarkeit gerade mal 10-15% an der Spitze der SKUs.
Irgendwer meinte mal dass bei der ARM ISA man einfacher die decoder breiter machen kann als bei x86. Und iirc sind die dicken ARM CPUs bei den decodern ja auch besonders breit aufgestellt.

[Badesalz]

Irgendwer meinte mal dass bei der ARM ISA man einfacher die decoder breiter machen kann als bei x86. Und iirc sind die dicken ARM CPUs bei den decodern ja auch besonders breit aufgestellt.CHECK.

[reunion]

Bei SMT hörte man eigentlich immer, dass das einen Hauch von nichts an Transistoren kostet und deshalb ein no brainer ist. Ob Intel da mit den neusten P Cores wirklich so viel Fläche gespart hat? Ich habe den Eindruck, dass sie zurückrudern und das einfach nur wegen der langen Entwicklungspipeline dauert. Und bis dahin erzählen sie halt, dass es Nachteile hat. Macht ja auch Sinn.
Ich denke AMD ist ziemlich froh, dass sie SMT drin gelassen haben und würden das auch nicht wieder entfernen wollen.

Das ist sehr viel mehr als nur ein Eindruck. Der neue Intel CEO sagten beim letzten Conference Call bezogen aufs Data Center Segment, dass das entfernen von SMT ein Fehler war, dass man ohne SMT nicht mehr konkurrenzfähig ist, und das alle zukünftigen Intel-CPUs wieder SMT haben werden. Das kann allerdings eine Zeit dauern, bis es beim Endkunden ankommt. Auch bleibt die Frage, ob die Aussage auch fürs Client-Segment gilt. Vermutlich schon, da man zumindest aktuell die selben Cores verbaut.

Die spannende Frage ist wie man so dumm sein konnte das zu entfernen, wer das entschieden hat und welche Konsequenzen das intern zur Folge hatte, damit sowas hoffentlich in der Zukunft nicht mehr passiert. Das zeugt nämlich davon, dass an entscheidenden Stellen bei Intel Leute sitzen mit maximaler Inkompetenz.

[Badesalz]

Die spannende Frage ist wie man so dumm sein konnte das zu entfernen Das hatten wir schon mehrmals.

Hab ich schon gefragt warum die letzten Seiten nichts mit Zen6 zu tun haben? Oder überhaupt mit AMD? Ok, ich find die Intel-Threads irgendwie auch immer spürbar weniger gemütlich, aber das ist schon eine neue Quali :wink:

Dann löst euch einfach davon, wenn es nicht mehr passt :up:

[HOT]

Sieht ja schwer so aus als würde "RDNA 3.5" für Medusa eher ein RDNA4 lite sein (GFX1170) und RDNA4m heißen. Man versteht die Gerüchte, dass das bei Medusa immer noch ne Variante von RDNA3 sein soll. Es ist ein RDNA3.5/RDNA4-Hybrid.
https://www.pcgameshardware.de/Grafikkarten-Grafikkarte-97980/News/AMD-Radeon-mit-RDNA-4m-im-Linux-Patch-1495982/

[Nightspider]

Vielleicht FSR4 Support?

Interessant wären aber die Gründe, weshalb man nicht RDNA4 verwendet und in welcher Metrik RDNA3 da wirklich noch von Vorteil ist.

[basix]

gfx1170 bekommt FP8 Instruktionen. Die gleichen wie RDNA4. Im besten Fall bekommt Medusa RDNA4 Matrix Cores. Im schlechtesten Fall RDNA3 mässiges WMMA und somit relativ gesehen nur 1/4 des FP8 Durchsatzes wie RDNA4.

[robbitop]

Bei the phawx wurde gezeigt dass in Proton FP8 Befehle per Emulation gebaut worden sind falls das zusammenhängt . https://youtu.be/dzAGvnRxmrA?si=sm-L-GvVdtMMPW1E ca bei 7 min


Aber: in der heutigen Zeit für kleine Low cost APUs - wer erwartet da einen echten Umbau einer legacy uArch von AMD? Das wäre IMO ein First. Bis dato hat man wenn dann ja immer nur Kleinigkeiten geändert. Ich tippe auf Emulation. Oder aber ein Umbau der ALUs für FP8 Support. Aber volle Matrixcores?
1170 ist dann für alles unterhalb von Medusa Halo Mini (umgebrandeter Nachfolger von Strix Point IMO) mit AT4. Also kleine IOD und kleine monolithische APUs.

[Badesalz]

und in welcher Metrik RDNA3 da wirklich noch von Vorteil ist.Angeblich weiterhin die Enerige bei der Datenbewegung.

@all
RDNA 3.8 :rolleyes:

[robbitop]

Das ist sehr viel mehr als nur ein Eindruck. Der neue Intel CEO sagten beim letzten Conference Call bezogen aufs Data Center Segment, dass das entfernen von SMT ein Fehler war, dass man ohne SMT nicht mehr konkurrenzfähig ist, und das alle zukünftigen Intel-CPUs wieder SMT haben werden. Das kann allerdings eine Zeit dauern, bis es beim Endkunden ankommt. Auch bleibt die Frage, ob die Aussage auch fürs Client-Segment gilt. Vermutlich schon, da man zumindest aktuell die selben Cores verbaut.

Die spannende Frage ist wie man so dumm sein konnte das zu entfernen, wer das entschieden hat und welche Konsequenzen das intern zur Folge hatte, damit sowas hoffentlich in der Zukunft nicht mehr passiert. Das zeugt nämlich davon, dass an entscheidenden Stellen bei Intel Leute sitzen mit maximaler Inkompetenz.
Bestimmt die ganz tollen MBAs. Denen spricht man in Amerika ja immer ganz tolle Fähigkeiten zum Senior Leadership zu. Ich habe bis dato nur Idioten getroffen, die nur darin gut waren bullshit fancy klingen zu lassen und deren "Fachwissen" ist trivialste Mathematik getarnt mit anderen tollen Bullshitvokabeln. Ich bin mir sicher die boardrooms sind voll mit solchen Deppen. Wenn ein Unternehmen plötzlich komische Entscheidungen trifft, dann ist wahrscheinlich ein MBA in eine Führungsrolle gekommen. X-D

[robbitop]

Vielleicht FSR4 Support?

Interessant wären aber die Gründe, weshalb man nicht RDNA4 verwendet und in welcher Metrik RDNA3 da wirklich noch von Vorteil ist.
RDNA3 in den APUs (wahrscheinlich hat man da die CUs von N33 genommen) braucht pro CU und wahrscheinlich auch pro fps deutlich weniger Transistoren als RDNA4. Gerade in kleineren APUs wird wahrscheinlich ohnehin nicht geraytract. Dann macht es Sinn nicht so viele Transistoren zu verballern. Kosten.
Das ist ja nicht gerade unüblich dass neue uArchs zwar besser sind aber mehr Transistoren verbrauchen als sie Leistung bringen.

[Badesalz]

Bestimmt die ganz tollen MBAs. [...]Diesjahr schonmal einer der besten Fachbeiträge zu einem Thema :up:

[Skysnake]

Bestimmt die ganz tollen MBAs. Denen spricht man in Amerika ja immer ganz tolle Fähigkeiten zum Senior Leadership zu. Ich habe bis dato nur Idioten getroffen, die nur darin gut waren bullshit fancy klingen zu lassen und deren "Fachwissen" ist trivialste Mathematik getarnt mit anderen tollen Bullshitvokabeln. Ich bin mir sicher die boardrooms sind voll mit solchen Deppen. Wenn ein Unternehmen plötzlich komische Entscheidungen trifft, dann ist wahrscheinlich ein MBA in eine Führungsrolle gekommen. X-D
Naja smt zu entfernen kann schon ok sein für die Cloud wenn sie es eh entfernen. Der Punkt ist aber, das man damit in vielen anderen Bereichen halt blöd aussieht.

Sprich man kann das schon gut begründen warum es die richtige Entscheidung war. Man muss es aber auch können!


Ansonsten Inkompetenz gibt es auf allen Ebenen. Ich habe selbst unter Entwicklern oft genug Leute getroffen die mega in ihrer Nische sitzen und keine 2 Meter weit nach links und rechts blicken können...

Inzwischen habe ich eigentlich nur noch Bock mich mit Fellows und Lead/Principal Engineers zu unterhalten. Da bringt das dann auch was.

Aber an die Leute kommst du gar nicht so einfach ran....

[robbitop]

Naja anstatt SMT zu entfernen aus der HW kann man es doch sicherlich ausknipsen (uefi oder im microcode für bestimmte skus).

[Skysnake]

Es kostet aber etwas Platz und macht Dinge kompliziert. Wenn di eh davon ausgeht es nicht zu brauchen kannst du es schon weglassen.

Aber ist halt ne bewusste Entscheidung die auch Nachteile hat. Muss man halt akzeptieren.

[Nightspider]

Venice sollte eigentlich zwischen 2. und 3. Quartal bei ersten HPC Kunden aufschlagen oder?

Obs da bald paar hübsche Leaks geben wird?

[Platos]

Wieso kann kein SMT bei Cloud sinnvoll sein? Gute Kernauslastung ist doch immer sinnvoll ?

[robbitop]

Es kostet aber etwas Platz und macht Dinge kompliziert. Wenn di eh davon ausgeht es nicht zu brauchen kannst du es schon weglassen.

Aber ist halt ne bewusste Entscheidung die auch Nachteile hat. Muss man halt akzeptieren.
Naja aber es hat ja überall deutliche Nachteile gebracht und man bereut es jetzt. Und es war damals schon super duper offesichtlich dass das ein Fehler war (kann mir gut vorstellen dass die technischen Leute bei Intel das damals auch schon so gesehen haben aber ein irgend ein senior executive MBA Idiot das Sagen hatte ^^). Deshalb: für die wenigen Anwendungen wo SMT ein Problem ist -> deaktivieren und für alle anderen anlassen.

[robbitop]

Wieso kann kein SMT bei Cloud sinnvoll sein? Gute Kernauslastung ist doch immer sinnvoll ?

afaik: Angeblich gab es security issues.

[Badesalz]

Oh... Wir sind wieder bei Intel :up: ANGEBLICH? :|

Es hat sie zu E-Cores gezwungen. Was im Server zwar keine Sau akzeptierte - weil Linuxkernel Leute sagten, daß ist benagelter Wahnsinn sowas so zu managen, daß der Bigeisen Admin das auch akzeptiert - aber es zwang sie auch daran immer weiter zu arbeiten. Woraus unified core entstehen wird.

Das tut dem Ganzen im Allgemeinen vielleicht nicht schlecht. Vor allem wenn man wirklich den Mut aufbringt zurückzublicken und ehrlich vor sich selbst zugibt, was das alles für ein Müll war, allerspätestens nach Haswell/Broadwell.

Das aht sich AMD erst mit Zen5 geleistet :rolleyes: aber 9800X3D wenigstens wurde gut und erst Zen6 SOLL wirklich abliefern. Wir werden sehen :wink:

[y33H@]

Security und Performance Predictability sind die zwei Hauptgründe.

[Badesalz]

Performance Predictability :rolleyes: Stabile Story, Bro -> Microtransaktions laufen auf IBM Mainframes die SMT4 und SMT8 fahren :rolleyes:

Es ging rein um Sicherheit. Bei dem Haufen Probleme war es wirtschaftlicher (auf den ersten Blick) das zu entfernen als dran weiter rumzumurksen.
Einfach nur glücklicherweise, war AMDs herangehensweise bei SMT einfacher zu fixen. Daher haben sie das belassen.

Daß POWER & Co. damit Probleme hatten, hab ich seinerzeit nicht mitbekommen. Wahrscheinlich ist das auch kein Sicherheitsfaktor, wenn man es vom Anfang an vernünftig macht.
Auch wenn Theo davor immer gewarnt hat. Aber auch meist nur auf x86 blickend.

[y33H@]

Du kennst allerhöchstwahrscheinlich weder die Interna von AMD noch von Intel was wie wo wann für/gegen SMT entschieden wurde, von daher wäre ich an deiner Stelle zurückhaltender mit solch absoluten Aussagen ... das was IBM mit SMT4/SMT8 macht, ist nicht (direkt) vergleichbar mit dem Cloud-Zeug was bei AWS und Konsorten laufen haben.

[robbitop]

Die Implementierungen sind auch sehr vendorspezifisch. Zusammen mit den jeweiligen Charakteristiken und Quirks. Aber wie gesagt muss man nicht eine ganze uArch SMT berauben nur weil ein Anwendungszweck da nicht ideal ist es für alle anderen SKUs aber sinnvoll wäre. SMT ausschalten (per fuse, per microcode oder im uefi). Naja aber anscheinend hat man es ja jetzt eingesehen.

[latiose88]

naja gut vielleicht geht Intel ja den selben Weg wie AMD,wer weis.
Und auch spannend wie breit Zen 6 werden wird und was sich sonst so verändern wird..
Ich glaube nicht wirklich an einer Taktsteigerung.Vielleicht ja auch 5 ghz bei 2x12 Kernen.Bei den temperaturen wird es spannend werden und Preis mit sicherheit ganz schön hoch.
Vielleicht werden ja die aktuellen also vorgänger dadurch ja preiswerter im Preis,wer weis.

[Badesalz]

Du kennst allerhöchstwahrscheinlich weder die Interna von AMD noch von Intel was wie wo wann für/gegen SMT entschieden wurde, von daher wäre ich an deiner Stelle zurückhaltender mit solch absoluten Aussagen ... Es gibt tatsächlich Leute die massiv mehr darüber wissen als ich, aber die sind sehr zurückhaltend mit ihren Aussagen...

Kleine Fachfrage diesbezüglich: Weißt du warum Intel Bedenken/Probleme mit der Predictability der Performance (und SMT) hatte, AMD aber nicht? Bzw. hatte AMD vielleicht auch, erzählte es nur keinem, weil das die Kundschaft weder störte noch interessierte?

Es ist ja nicht so, daß ihre Kunden deswegen mit Vorsicht an die Epycs herangehen...

[Tesseract]

bei intel liegt es wohl eher am heterogenen design. die E-cores sind so kompakt mit so wenigen ressourcen dass SMT wahrscheinlich eher unrentabel ist und die P bekommen dann kein SMT damit das verhalten den kleinen gleicht. wenn ein virtueller server einen kleinen core hat ist der immer gleich schnell, wenn er einen virtuelllen großen hat kann der schneller oder langsamer sein, je nach dem was am anderen virtuellen core läuft. security kommt dann noch dazu. wenn zwei clients einen core nutzen könnte das theoretisch sidechannel attacken ermöglichen wo das verhalten des cores rückschlüsse darauf gibt was der andere client macht. das trifft prinzipiell auf AMD auch zu, aber bei nur einem grundlegenden coredesign ist im zweifel deaktivieren wohl sinnvoller als wegdesignen und das feature für gaming usw. verlieren. intel ist das momentan halt eher egal weil starkes MT eh von E-cores erschlagen wird.

Microtransaktions laufen auf IBM Mainframes die SMT4 und SMT8 fahren :rolleyes:

das was da läuft ist throughputoptimiert, die werden vom bereiber selbst mit transactions zugesammt und da ist viel SMT = viel durchsatz. bei cloud services hast du viele clients die oft idle sind, dynamisch was brauchen und sich ressourcen teilen.

[Badesalz]

intel ist das momentan halt eher egal weil starkes MT eh von E-cores erschlagen wird.Hybride Xeons gibt es eh nicht.

Hier mal ein Test gegen Zen4. Geht so...
https://www.hardwareluxx.de/index.php/artikel/hardware/prozessoren/64422-intel-xeon-6700e-serie-144-efficiency-kerne-im-test.html?start=2

Es fehlt nur noch Lolman... :up:

[Pirx]

Security und Performance Predictability sind die zwei Hauptgründe.

eher in-security bei Intel, oder? Gipsel hatte das mal sehr gut erklärt

[Tesseract]

Hybride Xeons gibt es eh nicht.

um xeons geht es heute auch nicht. die P-cores sind in erster line für single- oder einige wenige kritische threads für consumer da. wenn die CPU 20+ threads braucht bevor überhaupt der erste thread keinen eigenen core mehr bekommen würde ist SMT viel weniger wichtig als bei den üblichen 6-8 kernern die schon nach 6-8 threads SMT nutzen können/müssen. für ganz breite designs gibt es E-cores oder überhaupt sowas wie ARM also fällt dieser anwendungszweck für P-core SMT weg und im consumerbereich wird es zumindest momentan einfach mit vielen cores erschlagen bei intel.

mein punkt ist, dass die entscheidung gegen SMT bei intel nicht unbedingt damit zu tun hat ob der core mit oder ohne SMT besser ist sondern dass SMT in intels produktlineup (und das kann man durchaus kritisch hinterfragen) kaum nutzbar ist.

und früher gab es durchaus mischbestückungen auch in datacentern, teilweise sogar mit zweckentfremdeten consumerchips.

[latiose88]

Naja ich habe schon gemerkt wie wichtig smt bzw HT so ist. Der 265k unterliegt dem 14700k und das obwohl die erste CPU mehr IPC hat. Dafür ist die CPU sparsamer. Hat alles so seine vor und Nachteile. Und freilich kostet hypertrading Strom . Umsonst kriegt man die Leistung nicht. Dennoch hätte ich das gewusst ,hätte ich lieber auf AMD gewartet bis ich mir das leisten kann. AMD ist da dann doch besser. Und von hypertrading profitiere ich ebenso. Das habe ich gelernt. Dachte bei 20 Threads könnte ich auf HT schon verzichten.
Es ist erst bei 22-24 Kernen der Fall. Darum wird ein 16 Kerner um ein viel Daches schlechter bei Leistung und so.
Ich hoffe das der 270 was bewegen wird. Ansonsten habe ich ja noch immer die Option auf einen ryzen zu setzen ,wie auch immer. Man braucht ja immer ein Plan b .