AMD - Zen 6 (Olympic Ridge, Medusa Point/Halo & Venice, Morpheus-Kerne, 2/3 nm, 2026) [Archiv] - Seite 8

latiose88

2026-02-08, 22:42:46

ok krass,dann leigt es daran das ich da was verwende wo die IPC keine so starke steigerungg gegegben hatte.Diese liegen alle 9950x,9950x3d ,14900k und 14700k mindestens 5-10 % vor dem 265k.
Jedoch wenn ich den 14900k mit nur Luft betreibe oder 9950x mit limiterung auf 80 Grad dann sieht es anderst aus.
Meiner ist bei 90 Grad,5,2 Ghz P Kerne und 4,6 ghz e Kerne bei 215 Watt.
Intel 14900k schaffft das nicht.Und der 9950x wenn man ihn so eingeschrankt betreibt ist er bei 200 Watt.
Ich selbst habe ein Gedämmtes gehäuse names bequiet pure Base 600 und ein bequiet pure Rock pro 3.
Ich würde das spannend finden was da so alles unter diesen bedingung der 9950x sich da so halten kann.Ob dann 80 Grad dazu führt das er dann bei 4,8 oder 4,9 ghz am Ende dabei raus kommen wird oder ob er 5 ghz packen wird.
Und naja 90 Grad ist wirklich wild.
Anderst als bei AMD droht bei 90 Grad bei Intel noch keine drossel,auch wenn das auch schon nicht ohne ist und ich eigentlich kein gutes Gefühl dabei habe.
Aber der 14900k wäre noch härter.Denke mal das der sehr stark gedrosselt werden müsste.
Dann wäre der 14900k am ende echt schlechter.Und um den 14900ks brauchen wir erst garnicht drüber schreiben.
Zum Glück steht in solchen sachen AMD besser da.
Ist die Frage wie sich Zen 6 dabei verhalten wird.Ich werde ja wohl das ganze behalten.Hoffe das man da was draus machen kann.
Ich selbst habe nicht vor auf Wasserkühlung zu setzen.Erwarte dennoch Ordentliche Leistung von solchen CPUS.
Wie hoch Takt und so am Ende mit harten Limits sein wird,hier wird die Fertigung hoffentlich was bewegen können.Denn ich will ganz sicher nicht bei unter 5 ghz dran kleben.
Denn Takt ist bei meiner Anwendung Trumpf.Also alles steht und Fällt mit dem Allcore Takt.
Diese 10 % will ich nämlich auch noch ereichen.
Wenn dann hole ich mir 270 und hoffe das da noch was geht.Die CPU 265k ist jedenfalls am Ende.
Ich habe jeden Kern auf 100 %,takt geht nicht höher dank B860m also kann ich nur noch auf mehr Kerne gehen.
Das gute ist,Stromverbrauch und Temperatur wird bei P Kernen 5,2 ghz nicht sehr hoch gehen.
Unter Cinchebench oder Prime haut der 265k eben mal 250 Watt rein.
Das zeigt nur das meine Anwendung die ich so nutze sehr sparsam unterwegs ist.
Na da bin ich ja beruhigt.
Das ganze macht zwischen maximal und bei meiner Nutzung ganze 14 Grad unterschied aus.
Und dabei taktet der 265k eigentlich nicht höher.Aber Prime Nutzt halt jede Einheit zu 100 % aus.

Nun ja bin jedenfalls sehr Überrascht das der 14700k 5 % schneller ist ,wohl dank HT.
IPC vs HT. Nen interessantes Duell.
Und so viel zu die e Kerne zerreisen nix.
Der 285k ist jedenfalls so schnell wie der 14700k obwohl dieser HT hat.
Warum der 14900k dennoch nicht schneller ist,er wird durch die Hitze und dem sehr hohen Stromverbrauch limitiert.
Nur der 14900ks schafft es durch sehr starkes binning noch was zu bewegen,aber auch dieser Verliert je länger die Last anhält an Leistung.
Wie es wohl bei Zen 5 so aussieht wenn länger Last ansteht.
Die Tests sind mit rund 2 Minuten wohl zu wenig.Ich müsste um realistische Werte zu bekommen 5 Stunden dauerlast erzeugen.Dann sieht es klar aus ,wer Temperatur Limitiert ist und wer sich richtig Entfalten kann.

Hier hat Zen 6 ja die Chance was zu bewegen.Ich hoffe doch bei dem Thema Temperatur geht ordentlich was nach vorne.

Daredevil

2026-02-09, 00:54:04

Wenn SMT die Lösung für alles wäre, hätten Smartphones den Spaß heute auch, mh? Es kommt doch wirklich immer auf den Fokus des Kerns an, welches Problem damit primär gelöst werden soll.

latiose88

2026-02-09, 01:20:32

dann gab es wenigstens ja bei mir eine kleine Steigerung.Zumindest wenn man nur maximal 20 Kerne also Threads hat mag das ja stimmen.Bei 24 Threads sieht es jedoch bestimmt anderst aus.Nun ja ,wie sich der 270 auf einem B860m verhalten wird kann ich jedoch nicht sagen,das sehe ich schon.
Bei AMD wird es schwierig zu vergleichen weil B850 bei AMD ja höher Wertiger ist.Erst ab A620 ist der Chipsatz schlechter als bei Intel.
Drum wird es ja spannend. Und wirkt sich das bei AMD genauso aus wie bei Intel?
Habe da nun 5,1 ghz bei den P kernen und 4,5 ghz bei den E Kernen gesetzt.Temperatur sank von 94 Grad auf 84 Grad und 180 Watt statt 215 Watt.

Wie sieht es da beim 9950x aus,etwa genauso vom Verhalten?
Wobei das ja bei Zen 6 bestimmt wieder anderst sein wird als unter zen 5.

Badesalz

2026-02-09, 06:47:54

Ich schätze keiner soll merken, daß sich hier wer (y33h weniger, da recht karg ;)) um Kopf und Kragen redet. Für Nichts.
Am wichtigsten ist es erstmal komplett auszublenden, daß unified kommt und SMT wieder zurückkommt. Weil... das wirft nur blöde Fragen auf oder?

Und dann entsprechend auch, daß AMD SMT nicht aufgab und mit Epycs am flexen ist. Ja nach hinten rutschen lassen.

Aber hej, heute geht es nicht um Xeons... Kann ich verstehen. Der Zug ist für Intel grad auch am abfahren. Erstmal wird es auch morgen nicht um Xeons gehen. Meistens geht es um... ähh... Cinebench.
Ja Intel arbeitet ENG mit Maxon bei der Entwicklung und Optimierung dieses Benchmarks, aber bitte lieber nicht allzu oft erwähnen.

PS:
Gipsel for the President ;)

Wenn SMT die Lösung für alles wäre, hätten Smartphones den Spaß heute auch, mh?Warum bist du so schwach? Wo taucht denn die These auf, SMT wäre die Lösung FÜR ALLES?

mboeller

2026-02-09, 07:28:05

Und dann entsprechend auch, daß AMD SMT nicht aufgab und mit Epycs am flexen ist.

warum hätte AMD SMT aufgeben sollen? ZEN ist 2017 auf den Markt gekommen. Das SMT funktioniert besser als bei Intel (Performance Uplift) und ist aufgrund des neueren Kerns auch nahezu sicher. AMD musste nur geringe BIOS-Anpassungen vornehmen und mit geringen Performance-Problemen leben um die Sicherheit wiederherzustellen. Siehe Thread unten.

Bei Intel scheint das SMT schon min. 10 Jahre älter zu sein und wenn ich nur an diesen netten Thread erinnern darf Meltdown & Spectre: Sicherheitsrisiken durch Spekulation bei aktuellen Prozessoren (https://www.forum-3dcenter.org/vbulletin/showthread.php?t=585993); ist das SMT so verbugged gewesen, das Intel nur übrig blieb es abzuschalten und komplett neu zu entwickeln. Deshalb braucht es halt so lange bis es wieder implementiert werden kann und (hoffentlich) sicher ist.

Badesalz

2026-02-09, 07:45:53

warum hätte AMD SMT aufgeben sollen?Wie warum? Aus den gleichen sehr guten Gründen die hier aufgeführt wurden warum Intel abseits der Sicherheit sinnvollerweise SMT aufgab :D

[...]
Ja. Davon sprach ich. Es war aber nicht einfach verbuggt. So fair sollte man sein. Es tauchten allgemeine Sicherheitsprobleme betreffend Prozessisolation auf und auf die Art wie AMD es macht war es erstmal eine größere Baustelle und auf die Art wie Intel es machte war es eine gigantische Baustelle. Pech. Keiner dran gedacht davor, AMD dabei aber halt mehr Glück gehabt. AMD konnte das retten, Intel hat das lieber erstmal gleich ganz abgeschafft.

performance prediction und der Plot, ist doch eh besser gewesen und nun guckt euch unsere Hybriden an wie toll das geworden ist, ist anschließende PR für Laien, damit es nicht alleine nur an security issues hängen bleibt..
Imho natürlich. Imho :wink:

Tesseract

2026-02-09, 10:26:47

ich habe nie behaupuptet intels weg wäre sinnvoll, ich finde den weg seit jahren unsinnig. genauso wie das abschalten von AVX512. ich spekuliere nur über intels gründe für die entscheidung.

reunion

2026-02-09, 10:57:08

die E-cores sind so kompakt mit so wenigen ressourcen dass SMT wahrscheinlich eher unrentabel ist

Es ist ein Trugschluss zu glauben, dass ein Core besonders breit sein muss, um von SMT zu profitieren. Der wesentliche UseCase von SMT ist nicht, dass ein Core so super breit ist, dass er zwei Threads parallel ausführen kann. Das ist schon alleine deshalb nicht möglich, weil die meisten Datenpfade nur einmal vorhanden sind. Der wesentliche UseCase ist, dass ein Thread gerade gestalled ist, weil er zB auf den Speicher warten muss oder auf die Synchronisation mit einem anderen Thread auf einem anderen Core und währenddessen kann der zweiten SMT-Thread ausgeführt werden anstatt dass der ganze Core stalled. Die Zen-Architektur war zB bis einschließlich Zen4 sehr schmal und der SMT-Uplift war trotzdem höher als auf Intels P-Cores.

robbitop

2026-02-09, 11:00:25

So schmal sind die e cores auch nicht mehr. Und erinnert sich noch jemand an die Atom cores? Die waren super schmal und hatten smt. Allerdings auch schwach ausgelastet wegen in order execution

reunion

2026-02-09, 11:19:14

ich habe nie behaupuptet intels weg wäre sinnvoll, ich finde den weg seit jahren unsinnig. genauso wie das abschalten von AVX512. ich spekuliere nur über intels gründe für die entscheidung.

Es zeigt einfach, dass intern kein langfristiger, durchdachter Plan vorhanden ist, der auch durchhaltbar ist, sondern man offensichtlich ständig improvisieren muss.

Das big.LITTLE-Konzept hat man kurzfristig eingeführt, weil man bei der Perf/Watt überrollt wurde. Der Tradeoff war AVX512 zu deaktivieren und zu Beginn massive Scheduling-Probleme.
SMT musste man offenbar abschalten weil die Implementierung eklatante Security-Schwächen hatte und eine neue hatte man kurzfristig nicht parat. Dazu hat man dann auch noch die Fehlentscheidung getroffen zu glauben, dass man es eh nicht braucht.
Auch das ganze Chiplet-Design bei Intel wirkt wie aus der Not geboren und wenig durchdacht. AMD verwendet die selben Chiplets immer wieder über unterschiedliche Produkte und Produktkategorien hinweg. Das senkt die Kosten und spart Ressourcen. Bei Intel besteht jeder Chip aus eine Vielzahl an unterschiedlichen Chiplets in unterschiedlichen Nodes und von unterschiedlichen Foundries. Aber es gibt null Synergien.

Die Liste könnte man noch lange fortführen. zB auch mit den dGPUs, die man zuerst einführt und dann wieder cancelt etc. Oder die Unzähligen Versuche eine brauchbare DataCenter-GPU zu liefern.

Badesalz

2026-02-09, 11:24:35

genauso wie das abschalten von AVX512Ich vermute, da hatten sie eine Art TDP-Problem... um auf die Leistung zu kommen die AMD damals mit dem nachoptimierten 2x256 hatte, was selbst der Typ der y-cruncher schreibt in klaren Worten ausdrücklich gelobt hat :usweet: (im Gegensatz zu AMDs ersten solchen Versuchen) und sind so dem direkten Vergleich entkommen.

Es zeigt einfach, dass intern kein langfristiger, durchdachter Plan vorhanden ist, der auch durchhaltbar ist, sondern man offensichtlich ständig improvisieren muss.Klingt tatsächlich plausibel, aber sie haben auch extrem gesäubert. Die Pipelines sind halt schon vorgefüllt, aber wenn sie an den richtigen Stellen gesäubert haben, sollte sich das auch irgendwann zeigen. Unified und SMT-back würde darauf hindeuten.

Irgendwer versucht das wieder zurückzudrehen. Vielleicht haben sie auch paar Leuten die bisher unten nur gearbeitet und nicht geschwätzt haben, wichtigere Positionen gegeben...

robbitop

2026-02-09, 11:37:21

Macht das Abschalten von avx512 aus tdp Gründen wirklich Sinn? TDP limitierten -> CPU muss halt runtertakten. Aber pro W sollte man ja trotzdem schneller sein - also mehr Durchsatz pro W trotz weniger Takt.

basix

2026-02-09, 11:45:26

Es war auch ein Instruction-Set Problem bei big.Little.

reunion

2026-02-09, 11:48:36

Es war auch ein Instruction-Set Problem bei big.Little.

Richtig. Das auch würde ich sogar streichen.

Badesalz

2026-02-09, 11:57:09

Es war auch ein Instruction-Set Problem bei big.Little.Ja doch. Da war tatsächlich was. Jedenfalls in der Kommunikation... Das ist ebenfalls ein Teil des Irrsinns was man dabei an Aufwand für Scheduling treiben muss (müsste).

@robbitop
Ja, wenn du gegen dich selbst vergleicht. Wenn du aber gegen andere vergleichst, die dabei spürbar weniger Theater mit dem Energiehaushalt haben, dann ist es ggf. besser du kommst erst garnicht nzu Schiesserei, statt da mit einem Messer aufzutauchen.
E-Cores hätten wie AMD erst 2x256 machen können. P-Cores 1x512. Wäre halt nur Glückssache wo es durchläuft, insgesamt aber trotzdem ein Win. Naja. Alles sehr schwierig zu machen...

Sei es drum. Das ist eh nicht deren primäres Problem.

y33H@

2026-02-09, 17:21:18

Es zeigt einfach, dass intern kein langfristiger, durchdachter Plan vorhanden ist, der auch durchhaltbar ist, sondern man offensichtlich ständig improvisieren muss.

Das big.LITTLE-Konzept hat man kurzfristig eingeführt, weil man bei der Perf/Watt überrollt wurde. Der Tradeoff war AVX512 zu deaktivieren und zu Beginn massive Scheduling-Probleme.
SMT musste man offenbar abschalten weil die Implementierung eklatante Security-Schwächen hatte und eine neue hatte man kurzfristig nicht parat. Dazu hat man dann auch noch die Fehlentscheidung getroffen zu glauben, dass man es eh nicht braucht.
Auch das ganze Chiplet-Design bei Intel wirkt wie aus der Not geboren und wenig durchdacht. AMD verwendet die selben Chiplets immer wieder über unterschiedliche Produkte und Produktkategorien hinweg. Das senkt die Kosten und spart Ressourcen. Bei Intel besteht jeder Chip aus eine Vielzahl an unterschiedlichen Chiplets in unterschiedlichen Nodes und von unterschiedlichen Foundries. Aber es gibt null Synergien.

big.little war lange in Planung, immerhin kam Lakefield schon Sommer 2020 raus
wieso weshalb SMT zwischenzeitlich rausflog, ist Speku - klar ist nur, Intel bringt es mittelfristig zurück und mehr will ich dazu nicht sagen
das ist falsch - im Client wie im Server Segment werden Tiles innerhalb einer Generation ebenfalls wiederverwendet ... paar Beispiele:

Granite Rapids, Sierra Forest, Clearwater Forest nutzen allen das gleiche I/O Die aber unterschiedliche Compute Dies
Meteor, Arrow Lake, Panther Lake nutzen CPU, iGPU, I/O Dies um die Performance je nach Design rauf/runter zu skalieren für Desktop bzw Notebook

AMD wiederum hat diverse Dies, vor allem monolitische wie Krackan oder Strix, die freilich nicht anderweitig in SoC-Designs verwendet werden können ... aber auch Chiplets wie die CCDs und das I/O Die von Strix Halo, was es einzig dort gibt - die Ryzen 9000 nutzen andere CCDs und natürlich iGPU-bedingt auch andere I/O Dies.

reunion

2026-02-09, 18:22:46

big.little war lange in Planung, immerhin kam Lakefield schon Sommer 2020 raus

Der Satz ergibt keinen Sinn. Du nennst ein Datum wann es raus kam - was hat das damit zu tun, wie lange es in Planung war? Wenn man dafür ein Instruction set opfern muss, war es jedenfalls schlecht geplant.

wieso weshalb SMT zwischenzeitlich rausflog, ist Speku - klar ist nur, Intel bringt es mittelfristig zurück und mehr will ich dazu nicht sagen

Selbst die öffentliche Kommunikation dazu war dilettantisch. Never ever war diese doppelte Kehrwende von Intel ein langfristiger Plan.

das ist falsch - im Client wie im Server Segment werden Tiles innerhalb einer Generation ebenfalls wiederverwendet ... paar Beispiele:
Granite Rapids, Sierra Forest, Clearwater Forest nutzen allen das gleiche I/O Die aber unterschiedliche Compute Dies
Meteor, Arrow Lake, Panther Lake nutzen CPU, iGPU, I/O Dies um die Performance je nach Design rauf/runter zu skalieren für Desktop bzw Notebook

Okay, das wusste ich tatsächlich nicht. Da gibt es aber durchaus noch Potential wenn man sich ansieht wie viele Dies da vorhanden sind. Und innerhalb einer Generation sind deine Aufzählungen nicht?!

AMD wiederum hat diverse Dies, vor allem monolitische wie Krackan oder Strix, die freilich nicht anderweitig in SoC-Designs verwendet werden können ... aber auch Chiplets wie die CCDs und das I/O Die von Strix Halo, was es einzig dort gibt - die Ryzen 9000 nutzen andere CCDs und natürlich iGPU-bedingt auch andere I/O Dies.

Um AMD ging es mir jetzt eigentlich nicht. Aber Base-Die, viele Tapeouts und Packaging kosten Geld - man kann durchaus hinterfragen ob ein Single-Die bei kleinen SoCs nicht billiger ist als das was Intel macht. Zumindest laut AMD ist das der Fall IIRC.

Complicated

2026-02-09, 18:30:38

aber auch Chiplets wie die CCDs und das I/O Die von Strix Halo, was es einzig dort gibt - die Ryzen 9000 nutzen andere CCDs und natürlich iGPU-bedingt auch andere I/O Dies.
Zudem ein schlechtes Beispiel: Strix Halo nutzt die nächste Stufe beim Packaging und eliminiert SerDes für die Verbindung der Chiplets. Die nächsten Ryzen werden ebenfalls dieses Packaging nutzten und bauen eben auf diesem verbesserten Interconnect auf. Die CCDs können da kaum gleich sein mit der 9000-Serie, das liegt in der Natur der Sache dieses Pipecleaners.

mczak

2026-02-09, 18:43:59

Ich fand ja den Verzicht auf SMT von intel auch eher seltsam, eine gewisse Logik dahinter kann ich aber schon sehen wenn man 2 verschiedene Kerne hat.
Intel erwähnt ja selbst im Optimization Guide (glaube das bezog sich auf Meteor Lake) dass es schneller ist wenn man 2 Threads hat wenn die in verschiedenen E-Kernen laufen als im selben P-Kern. Und wegen der relativen Ineffizienz der P-Kerne kann man wohl davon ausgehen dass so auch der Stromverbrauch tiefer ist.
Dann würde es eben durchaus Sinn ergeben dass man SMT streicht und stattdessen mehr E-Kerne verbaut, das ist dann sowohl schneller als auch (bezügl. Stromverbrauch) effizienter. Bezüglich Fläche dürfte sich das aber nicht auszahlen (intel sprach ja von 10% kleineren P-kernen durch SMT-Verzicht bei Lunar Lake, wobei ich davon ausgehe das bezog sich auf Kern zumindest ohne L3). Lunar Lake ist dafür natürlich ein schlechtes Beispiel weil der ja nicht wirklich eine Kompensation durch mehr E-Kerne für den SMT-Verzicht hat, das Resultat ist dann halt im Wesentlichen einfach tiefere MT-Performance. Ausserdem braucht man natürlich auch mehr Fabric um alles zu verbinden wenn man da einfach mehr E-Cluster verbaut.
Wären die P-Kerne im Vergleich zu den E-Kernen aber nicht so ineffizient würde das so keinen Sinn ergeben. Und hat man bloss eine Sorte Kern natürlich auch nicht. Und ja man könnte natürlich auch argumentieren wenn man MT Performance eben durch E-Kerne erreichen will statt P Kernen mit SMT, dann würde es wohl Sinn machen wenn die E-Kerne SMT unterstützen würden...

Badesalz

2026-02-09, 18:46:15

Selbst die öffentliche Kommunikation dazu war dilettantisch. Never ever war diese doppelte Kehrwende von Intel ein langfristiger Plan.Lass ihm auch mal bisschen Luft zum Atmen... Eigentlich wird nicht irgendeine der Thesen vehement verneint. Für mich war das tatsächlich ein guter, sachlicher Post seinerseits (wenn man bisschen geübt ist zu lesen...)

@mczak
Bitte.. Hähne? Ei?

iamthebear

2026-02-09, 19:46:17

Das big.LITTLE-Konzept hat man kurzfristig eingeführt, weil man bei der Perf/Watt überrollt wurde. Der Tradeoff war AVX512 zu deaktivieren und zu Beginn massive Scheduling-Probleme.

Das Problem war, dass der Ringbus nur bis 8 Stops vernünftig skaliert. Zur Not kommt man noch auf 10 oder 12 hoch aber dann ist definitiv Schluss.
AMD hat das Problem umgangen indem sie auf 2 CCDs gesetzt haben, was aber wieder andere Probleme verursacht.
Intel hat das Ganze gelöst, indem sich 4 E Cores einen Ring Stop teilen.

Grundsätzlich war der E Core Ansatz von Intel ja gut und schedulerseitig immer noch sauberer zu lösen als AMDs Frickellösung mit der Game Bar.
Das Problem war nur, dass das E Core Design einfach Schrott war. Gracemont war bei ST extrem lahm aber trotzdem bei Performance/mm² kaum besser.

SMT musste man offenbar abschalten weil die Implementierung eklatante Security-Schwächen hatte und eine neue hatte man kurzfristig nicht parat. Dazu hat man dann auch noch die Fehlentscheidung getroffen zu glauben, dass man es eh nicht braucht.

Laut Gerüchten hat es bei Intel 2 parallele Entwicklungen gegeben:
a) Ein SMT Design (vermutlich noch größere Kerne) mit 4 Threads pro Kern
b) Ein Design mit etwas kleineren Kernen ohne SMT, wo sich jedoch die 2 Kerne den L2 teilen

In internen Simulationen hat das SMT Design deutlich schlechter abgeschnitten, weshalb man sich für die Variante ohne SMT entschieden hat.

Im Clientbereich ist der Nutzen von SMT seit Skymont sowieso fraglich. Bei ARL würde SMT nicht viel bringen, da es sinnvoller ist zuerst die E Cores zu nutzen und dann erst den 2. Thread der P Cores und so viele Threads nutzt nur ein kleiner Teil der Software. Im Zweifelsfall kann man mit der gesparten Fläche/TDP noch mehr E Cores verbauen.
Und im klassischen Serverbereich ist SMT aus Sicherheitsgründen sowieso oft aus wenn mehrere Kunden auf demselben physischen Server gehostet werden und nach CPU Stunde abgerechnet werden.

Für KI Anwendungen ist das Fehlen von SMT aber ziemlich dämlich. Da spielt das Sicherheitsrisiko meistens keine Rolle und man verschenkt MT Performance.

Auch das ganze Chiplet-Design bei Intel wirkt wie aus der Not geboren und wenig durchdacht. AMD verwendet die selben Chiplets immer wieder über unterschiedliche Produkte und Produktkategorien hinweg. Das senkt die Kosten und spart Ressourcen. Bei Intel besteht jeder Chip aus eine Vielzahl an unterschiedlichen Chiplets in unterschiedlichen Nodes und von unterschiedlichen Foundries. Aber es gibt null Synergien.

AMD hat früher einfach wesentlich weniger Marktanteil und Entwicklerressourcen gehabt. Das mussten diese sparen. Von Vorteil für das Produkt ist das mit Sicherheit nicht, genauso wenig für die Fertigungskosten wenn man ständig Dinge mitschleppen muss, die beim aktuellen Produkt gar nicht benötigt werden siehe die ganzen TSVs bei non VCache CPUs.

Die Liste könnte man noch lange fortführen. zB auch mit den dGPUs, die man zuerst einführt und dann wieder cancelt etc. Oder die Unzähligen Versuche eine brauchbare DataCenter-GPU zu liefern.

Die dGPUs bei Intel haben nur den Sinn, dass man Erfahrung mit Treibern in einer etwas höheren Performanceklasse sammeln kann um z.B. so Dinge wie CPU Overhead in den Griff zu bekommen. Das eigentliche Geschäft macht Intel mit iGPUs.
Bei AMD läuft es doch nicht viel anders. Hätte man keinen APU/Konsolenmarkt wäre die dGPU Sparte schon lange eingestampft worden denn bei dem aktuellen Marktanteil rechnet sich die Entwicklung nicht.

Ich vermute, da hatten sie eine Art TDP-Problem... um auf die Leistung zu kommen die AMD damals mit dem nachoptimierten 2x256 hatte, was selbst der Typ der y-cruncher schreibt in klaren Worten ausdrücklich gelobt hat :usweet: (im Gegensatz zu AMDs ersten solchen Versuchen) und sind so dem direkten Vergleich entkommen.

Eine vollständige AVX512 Implementierung kostet eben einiges an Transistoren, die man bei den E Cores anscheinend nicht opfern wollte, denn bei denen geht es doch primär um Performance/mm² und der Anteil an Anwendungen die AVX512 nutzen ist überschaubar.

Macht das Abschalten von avx512 aus tdp Gründen wirklich Sinn? TDP limitierten -> CPU muss halt runtertakten. Aber pro W sollte man ja trotzdem schneller sein - also mehr Durchsatz pro W trotz weniger Takt.

Die Dauerlast könnte PL1/2 gut abfangen. Aber PL4 würde eventuell deutlich höher liegen falls die Kerne gerade mit sehr leichter Last im max Turbo laufen und auf einmal eine schwere AVX512 Last daher kommt. Das gibt dann einen kräftigen Spike bis die Telemetrie greift und den Takt zurückfährt.

Badesalz

2026-02-09, 20:39:07

Im Clientbereich ist der Nutzen von SMT seit Skymont sowieso fraglich.Wow... Du hast bis hierhin echt wirklich viel mitbekommen oder? :|

Hast du da erzählt, Intel wird SMT nur wegen KI zurückbringen? (weil alles andere hast du irgendwie ausgeschlossen)

Was war nochmal deine These, daß auch Hybride wieder verschwinden werden? Das hab ich irgendwie nicht mitbekommen.

iamthebear

2026-02-10, 00:12:54

Ohne SMT muss Intel im aktuell sehr lukrativen Datacenterbereich um ca. 30-40% mehr Kerne bringen um mit AMD mithalten zu können. AMD bringt 192 Zen 6 Kerne, Intel braucht 288 Kerne um mithalten zu können da eben SMT fehlt.

10% mehr Transistoren opfern für 30-40% mehr MT Performance wäre es wert

Im Clientbereich ist das anders:
a) MT Performance ist eher zweitrangig. Hier ist der niedrigere Energiebedarf im ST Modus wichtiger (laut Intel 15%)
b) Man hat mit Skymont einen zweiten Kerntyp mit doppelter Performance/mm². Mit E Cores kann man die MT Performance mit 10% Transistoreinsatz auch schon um 20% steigern braucht aber weniger Threads dafür.

Klar Arrow Lake ist beim Gaming eine Niete aber das liegt an zu kleinem L3, zu hohen Speicherlatenzen und lahmen Ring. Da würde SMT auch nichts daran ändern.

Der einzige Vorteil von SMT beim Gaming ist, dass man so 2 Threads auf einen Ring Stop bekommt. Das schafft aber Nova Lake ohne SMT auch mit 2 echten Kernen.

Skysnake

2026-02-10, 04:05:31

Wie willst du denn bitte beurteilen wie gut oder schlecht die Diamond Rapids ohne SMT sind, wenn Sie noch nicht verfügbar sind?

Und zu glauben mit SMT wäre alles gut ist ziemlich naiv.

Soll ich dir mal sagen, was Intel mit Diamond Rapids bei mir liefern muss um mit den aktuellen EPYC gleich zu ziehen?

Wenn ich mich recht erinnere ca Faktor 1.2 mehr Cores und Memory Bandbreite weil Sie so ineffizient sind....

Und das mit SMT. Wird aber eh ausgeschaltet, das es überwiegend nichts bringt.

Es gibt durchaus Gründe warum die aktuellen Intels so abstinken und es kann durchaus Gründe geben warum Diamond Rapids abstinkt. Ich gehe aber eher weniger davon aus das es an fehlendem SMT liegen wird.

Badesalz

2026-02-10, 07:09:46

Der einzige Vorteil von SMT beim Gaming ist, Das war grad 2 Seiten lang kein Thema. Der Post an sich hatte aber eh nichts mit meinem davor zu tun oder? (mit welchem dann, übrigens?)

@Skysnake
Danke. Hat meinen Geduldsfaden gerettet.

y33H@

2026-02-10, 08:00:53

Und innerhalb einer Generation sind deine Aufzählungen nicht?!Für Client innerhalb der MTL/ARL/PTL-Generationen und bei Datacenter ebenfalls, beispielsweise Granite Rapids für diverse Ableger (GRN-D HCC sowie GNR-D XCC und GNR-AP UCC sowie GNR-SP XCC verwenden alle das gleiche 44C Die).
Der Satz ergibt keinen Sinn. Du nennst ein Datum wann es raus kam - was hat das damit zu tun, wie lange es in Planung war? Wenn man dafür ein Instruction set opfern muss, war es jedenfalls schlecht geplant. Weil du vom Release grob 3-4 Jahre abziehen kannst, solange dauert es eine CPU zu planen und zu entwickeln. Und nein, AVX-512 für Laptops zu "opfern" ist nun wahrlich nicht das Problem.

Platos

2026-02-10, 08:16:49

Bei Intel Blicke ich momentan sowieso nicht so ganz durch. Kommt jetzt SMT zurück oder nicht, kommen wieder nur ganze Kerne oder bleibts bei big.little oder kommen "rentable untis". Bei GPUs: Kommen noch neue dGPUs (Grafikkarten) Generarionen oder ist das eher Geschichte?

Bei Titan Lake war ja glaube ich mal von 98 Kernen die Rede oder so, weiss aber nicht mehr, ob das ein "Gerücht" war oder eine eigene Hypothese vom Verbreiter der Info. Falls es wirklich Rentable Untis gäbe, könnte es ja sein, dass man entweder 1 grossen Kern hat oder jeweils 4 kleine und dann würde es mit 96 Kernen ja 24 grosse oder eben 96 kleine geben, was sich irgendwie realistisch anhört. Aber ist achon lange her.

Und bei AMD: Gibts hier eig. irgendwelche Infos dazu, mal was an der ineffizienten Bauweise was zu verbessern, welche bei Niedriglast (nicht idle) direkt den Stromverbrauch in die Höhe schnellen lässt? Das hat mich bisher immer von AMD abgeschreckt. Das Problem gibts ja nur bei ihren Chiplet-CPUs und von daher dürfte es daran liegen. Also gibts da irgendwie mal neue Generationen von Interconnects oder sowas? Ist da was bekannt in der Gerüchteküche? AMD ist/wäre mir sowieso lieber mit ihren nur grossen Kernen und besserer sonstiger Effizienz usw.

robbitop

2026-02-10, 08:21:56

dildo4u

2026-02-10, 08:24:19

Platos

2026-02-10, 08:47:54

IIRC waren die Gerüchte von MLID so:
- Royal Cores mit Rentable Units wurden gecanclet. MBA-Profi hat wahrscheinlich entschieden ^^
- P Cores sterben (kein Wunder, denn Wahnsinn was die für Handstände (in Bezug auf Transistoren und Leistungsaufnahme und Breite und Caches usw) machen mussten um auf ihre IPC zu kommen relativ zu Zen)
- E Cores werden zu den neuen All-around cores. Ggf. balancierter ähnlich wie die Zen Cores.

Naja, ok, man entwickelt basierend von den E-Cores weiter, aber es gab ja auch schon Ideen, dass es dann trotzdem weiterhin abgespeckte Kerne geben könnte analog zu Zen C-Kernen. Also nur weil man nicht mehr 2 Architekturen hat, heisst das ja noch nicht, dass man kein big.little mehr fahren will/kann.

Aber mir stellt sich schon die Frage, wie man die Singlecore-Leistung eines P-Cores mit einem zukünftigen "E-Core" erreichen will bzw. übertrumpfen will. Denn das muss man. Man kann nicht einfach mit Titan Lake Jahre später gleiche Perfomance bringen oder sollte es nicht wollen zumindest.

Vlt. peilt ja aber Intel auch eher Server an und der Desktop ist ihnen mehr oder weniger egal und bei Mobile ist extreme spitzen Singlecore Leistung jetzt auch nicht sooo relevant.

Das soll der Fahrplan bis 2028 sein.

https://www.3dcenter.org/news/geruechtekueche-intels-titan-lake-soll-ab-2028-wieder-einheitliche-cpu-kerne-bringen

Genau, das ist/war alles sehr vage. Ja, unified, aber eben: Unified heisst nicht kein big.little, es heisst nur, dass es keine 2 parallele Architekturen mehr gibt.

Für mich klingt das alles noch sehr ungewiss.

Badesalz

2026-02-10, 08:49:24

Und bei AMD: Gibts hier eig. irgendwelche Infosdazu, mal was an der ineffizienten Bauweise was zu verbessern, welche bei Niedriglast (nicht idle) direkt den Stromverbrauch in die Höhe schnellen lässt?Ja. Die Baustelle soll mit Zen6 anfangen bearbeitet zu werden.

PS:
Es könnte sein, daß die Strategien längerfristig eh nur noch APUs und HEDT für Desktop planen. Nichts mehr dazwischen. Könnte auch bei AMD so sein. Die APUs werden so langsam schnell genug, Fakeframes salonfähiger, die Auflösungen treiben nicht mehr wirklich an. Der Edelzocker kann dann APU + dGPU fahren.
Es ist ja keine technische Unmöglichkeit Sockel für APUs zu machen. Und je nach Einsatz APUs mit viel schwächeren iGPUs zu bringen, wenn man eh dGPU will. Die dann nur wirklich was vom Netzteil zieht, wenn sie auch genutzt wird. Intel wie AMD, wie gesagt.

Desktop läuft dann generell auf der iGPU. Man muss sich nicht mehr im BIOS entscheiden. Die Umschaltung passiert automatisch. Jedwede Desktopsoft die davon profitiert kann dann einen Lauf auf der dGPU anfordern (nicht nur Spiele).

Platos

2026-02-10, 08:51:35

Ja. Die Baustelle soll mit Zen6 anfangen bearbeitet zu werden.

Das wäre ja schon "bald". Da bin ich mal gespannt.

Edit: Habs gefunden, denke ich. Vermutlich das: https://www.techpowerup.com/341445/amd-d2d-interconnect-in-zen-6-gets-sea-of-wires-upgrade

robbitop

2026-02-10, 09:21:43

Naja, ok, man entwickelt basierend von den E-Cores weiter, aber es gab ja auch schon Ideen, dass es dann trotzdem weiterhin abgespeckte Kerne geben könnte analog zu Zen C-Kernen. Also nur weil man nicht mehr 2 Architekturen hat, heisst das ja noch nicht, dass man kein big.little mehr fahren will/kann.

Aber mir stellt sich schon die Frage, wie man die Singlecore-Leistung eines P-Cores mit einem zukünftigen "E-Core" erreichen will bzw. übertrumpfen will. Denn das muss man. Man kann nicht einfach mit Titan Lake Jahre später gleiche Perfomance bringen oder sollte es nicht wollen zumindest.

Naja schaue dir mal die Entwicklung der E Cores an. Die sind von der IPC mittlerweile sehr nah an den P Core und der Takt ging ja auch ordentlich nach oben.
Ich vermute bei den P Cores hat man sich verrannt und braucht jetzt mal einen reboot.

Ob es weiterhin 2 cores geben wird -> da habe ich nichts von MLID in Erinnerung. Mein Eindruck ist, dass man sich gegenseitig nachmacht wenn einer von beiden erfolgreich ist. Aber mit dem typischen lag von 3-5 Jahren (Entwicklungspipeline).
Und dank den 3-5 Jahren hängt sowas ggf manchmal in einer Resonanz. (Hochtaktdesigns, SMT, 2 uArchs vs balanced uArch usw)

reunion

2026-02-10, 09:40:15

Beim anderen kann ich im Großen und Ganzen mitgehen, aber da nicht:

Im Clientbereich ist der Nutzen von SMT seit Skymont sowieso fraglich. Bei ARL würde SMT nicht viel bringen, da es sinnvoller ist zuerst die E Cores zu nutzen und dann erst den 2. Thread der P Cores und so viele Threads nutzt nur ein kleiner Teil der Software. Im Zweifelsfall kann man mit der gesparten Fläche/TDP noch mehr E Cores verbauen.

Auch im Client-Bereich würde SMT einiges bringen. Man bekommt ~30% mehr MT-Performance und eine höhere Perf/Watt für <5% Siziliumkosten. Das ist eigentlich ein no-brainer.

Heute muss Intel einen 18A Panther Lake mit 16 Kernen bei der MT-Performance gegen einen 4nm Strix Point mit 12 Kernen stellen um gerade so einen Gleichstand zu schaffen. Das ist hochgradig ineffizient.

reunion

2026-02-10, 09:46:38

Weil du vom Release grob 3-4 Jahre abziehen kannst, solange dauert es eine CPU zu planen und zu entwickeln.

Das war nicht der Punkt. Der Punkt war, dass man da wohl kurzfristig was umwerfen musste, sonst führt man nicht zuerst AVX512 ein um es dann kurze Zeit später wegen dieses Designs wieder canceln zu müssen.

Und nein, AVX-512 für Laptops zu "opfern" ist nun wahrlich nicht das Problem.

Wenn ich ein neues Instruction set einführe, dann schaffe ich das nicht mehr ab. Es werden heute noch Instruction sets unterstützt die Jahrzehnte alt sind - ganz einfach weil es Software gibt, welche diese verwendet und teils auch benötigen um zu funktionieren. Ich kenne ein Beispiel aus dem Universitätsbereich die mächtig angepisst waren, dass Intel AVX-512 wieder abgeschafft hat. Ist auch logisch, man schreibt lange und aufwändig Software um die Performance zu steigern und dann sagt der CPU-Hersteller einfach Pech gehabt gibts nicht mehr.

y33H@

2026-02-10, 09:55:18

Es gibt ja weiterhin AVX-512 bei den Xeons und mit AVX10 kommt auch ein neues AXV für die E-Cores: https://cdrdv2.intel.com/v1/dl/getContent/784343

Aber das ist mittlerweile hart off-topic.

Complicated

2026-02-10, 10:01:49

Und bei AMD: Gibts hier eig. irgendwelche Infos dazu, mal was an der ineffizienten Bauweise was zu verbessern, welche bei Niedriglast (nicht idle) direkt den Stromverbrauch in die Höhe schnellen lässt? Das hat mich bisher immer von AMD abgeschreckt. Das Problem gibts ja nur bei ihren Chiplet-CPUs und von daher dürfte es daran liegen. Also gibts da irgendwie mal neue Generationen von Interconnects oder sowas? Ist da was bekannt in der Gerüchteküche? AMD ist/wäre mir sowieso lieber mit ihren nur grossen Kernen und besserer sonstiger Effizienz usw.
Ja, Strix Halo ist schon mit diesem verbesserten Interconnect (Fanout-Packaging) als erstes (APU/CPU)-Produkt im Markt. Details zu den Unterschieden bei Latenz und Stromverbrauch (10X geringer für den Interconnect) durch das weglassen der SerDes auf dem Chip:
0:00 Intro
0:44 Strix Halo
2:21 Strix Halo Chip Deep-Dive
5:37 Next-gen ZEN 6 interconnect?
6:34 Strix Halo vs Granit Ridge
7:48 SerDes & Infinity Fabric on Package
11:14 GMI-wide & GMI-narrow
13:48 Next-gen Fan-out die-2-die / TSMC InFO-oS
21:11 Next-gen 3D V-Cache
22:05 From ZEN 2 to ZEN 6

maH6KZ0YkXU

Platos

2026-02-10, 13:53:34

Sehr, sehr gutes Video. Die Verbindung (Interconnect) ist also quasi wie bei den Multi-DIE-GPUs, also so ähnlich.

Allgemein sehr gut erklärt. Damit dürfte dann (hoffentlich) dieses Problem von AMD endlich entschwinden. Da bin ich mal gespannt und hoffe, dass dann die Niedriglasteffizienz gut getestet wird. Vermutlich wieder nicht und einzelne Nutzer machen es wieder. Wenn das gut wird, könnte Zen7 was werden für mich (wegen noch mehr Kernen).

Der Kanal ist übrigens auch super. Kaum ein video, was nicht extrem gut ist (also ich seh grad keins). Das ist auch selten auf Youtube.

Complicated

2026-02-10, 14:56:32

Sehr, sehr gutes Video. Die Verbindung (Interconnect) ist also quasi wie bei den Multi-DIE-GPUs, also so ähnlich.
Es ist exakt was Navi31 genutzt hatte als erstes Produkt.
https://www.techpowerup.com/301071/amd-explains-the-economics-behind-chiplets-for-gpus
https://www.techpowerup.com/img/R2zcqt2Ocnjrk9Td.jpg

HOT

2026-02-10, 15:06:32

robbitop

2026-02-10, 15:57:58

Korreliert das nicht beides? Wenn es elektrisch energieeffizient ist kommt potenziell (wenn es das Protokoll bzw die fabric es nicht verkackt) auch was latenzarmes dabei heraus.

KarlKastor

2026-02-10, 16:18:55

Du kannst den ja trotzdem unterschiedlich hoch takten. Hoher Takt ist für Latenz optimiert, niedriger Takt ist für Effizienz optimiert.

Complicated

2026-02-10, 16:53:12

Tom von MLID sagte aber schon vor längerer Zeit (vielmehr seine Quellen), dass der neue Connect nichts mit Halo zu tun hat und nicht energieoptimiert ist sondern latenzoptimiert. Ich würde auch mal davon ausgehen, dass die CCDs, die für Desktop/Server verwendet werden wieder etwas anders sind, als diejenigen, die mobil verwendet werden, wie bei Zen5 ja auch schon.Es ist eher so, dass Server und Mobile Fanout-Packaging nutzen werden, da dort Energieeffizienz des Datentransfers den größten Impact hat. Ob es Desktop-SKUs wegen den noch fehlenden Packaging-Kapazitäten geben wird ist unklar. Die Marge und die Konkurrenz werden da wohl wichtige Faktoren sein. "Good enogh" könnte da den Desktop schon treffen, da dort das Powerbudget auch weniger Bedeutung hat. Es könnte aber den SKUs mit 2 CCD-Chiplets bei den Latenzen möglicherweise einen entscheidenden Sprung geben.

horn 12

2026-02-10, 23:17:16

Release von Zen 6 dann wann laut Neuestens Infos, Herbst 2026 und Zen 3D Modelle Vorstellung CES 2027 und Verfügbarkeit 2027 Februar - März also in knapp einem Jahr ?

Ist dies noch etwa korrekt ?

aceCrasher

2026-02-11, 00:17:07

Release von Zen 6 dann wann laut Neuestens Infos, Herbst 2026 und Zen 3D Modelle Vorstellung CES 2027 und Verfügbarkeit 2027 Februar - März also in knapp einem Jahr ?

Ist dies noch etwa korrekt ?
Ich kann mir nicht vorstellen dass die X3Ds so viel später kommen wenn Nova Lake mit bLLC noch dieses Jahr kommt. Man will die Gaming-Krone sicherlich nicht abgeben.

Badesalz

2026-02-11, 06:38:24

Ich kann mir nicht vorstellen dass die X3Ds so viel später kommen wenn Nova Lake mit bLLC noch dieses Jahr kommt. Man will die Gaming-Krone sicherlich nicht abgeben.Dafür hat man schon den 9850X3D hingestellt. Oder was meinst du was das für ein Wunder sein wird, der Nova Lake? :| Der erste Zen X3D ist von 2022...

Hast du mitbekommen, daß Intel sich um die PS6 beworben hat? Jetzt wo wir wissen, es wird ein X3D Zen, hat Intel doch bestimmt auch was mit bLLC vorgestellt...

Neurosphere

2026-02-11, 09:15:36

Problem dürfte bei Intel wohl nach wie vor der Stromverbrauch sein, das ist auch sehr wichtig bei einer Konsole, nicht nur die reine Performance. Es kann schon sein das Core 400 mit Cache Zen 5 X3D schlägt, auch wenn man nicht in die PS6 kommt.

Badesalz

2026-02-11, 09:28:28

Falls das mit PowerVia und RibbonFET wieder nur mit Watt-Overaggregation geht, dann können sie auch das behalten :crazy2:

Krone hin oder her :hammer:

HOT

2026-02-11, 10:06:45

Es ist eher so, dass Server und Mobile Fanout-Packaging nutzen werden, da dort Energieeffizienz des Datentransfers den größten Impact hat. Ob es Desktop-SKUs wegen den noch fehlenden Packaging-Kapazitäten geben wird ist unklar. Die Marge und die Konkurrenz werden da wohl wichtige Faktoren sein. "Good enogh" könnte da den Desktop schon treffen, da dort das Powerbudget auch weniger Bedeutung hat. Es könnte aber den SKUs mit 2 CCD-Chiplets bei den Latenzen möglicherweise einen entscheidenden Sprung geben.

Nope für Server dürfte auch die Latenzoptimierung deutlich wichtiger sein als die 1-2W, die man so einsparen würde pro CCD.

basix

2026-02-11, 12:50:52

Nope für Server dürfte auch die Latenzoptimierung deutlich wichtiger sein als die 1-2W, die man so einsparen würde pro CCD.

Bei 16x CCDs sind das aber schon 16-32W, die man anderweitig zur Verfügung hat. Das rechnet sich also schon auch.

HOT

2026-02-11, 13:08:46

Bei 16x CCDs sind das aber schon 16-32W, die man anderweitig zur Verfügung hat. Das rechnet sich also schon auch.

Das wird die Server kaum stören. Latenz ist viel wichtiger. Damit lässt sich viel mehr Verbrauch sparen als mit nem Mobilinterface.

Complicated

2026-02-11, 13:21:37

Nope für Server dürfte auch die Latenzoptimierung deutlich wichtiger sein als die 1-2W, die man so einsparen würde pro CCD.Das ist doch kein entweder oder, deine Unterscheidung gibt es nicht - Fanout-Packaging hat beides und KI-Serversysteme wissen jetzt schon nicht wo der Strom her kommen soll.

1-2W? Eine Reduzierung der Interconnect-Stromkosten um 80% bei jedem Datentransfer onChip hat in einem Helios Rack ganz sicher eine andere Größenordnung.
Die Latenzverbesserung kommt ja durch das weglassen der SerDes, die ein Stromfresser sind. Im Video ist das eigentlich ausführlich erklärt.
Systemanteil des Verbrauchs: Obwohl spezifische Wattzahlen für den Interconnect nicht veröffentlicht werden, ist die Infinity Fabric Teil des I/O-Die, der zusammen mit der Speichercontroller-Einheit einen signifikanten Teil des TDP (Thermal Design Power) ausmacht. Mit dem 5th Gen EPYC (9005/9004) wurde das Energiemanagement durch direkt beobachtete thermische Daten (Directly Observed Thermals) verbessert, um den Verbrauch dynamisch anzupassen.

rentex

2026-02-13, 09:24:25

Wie ist eigentlich der Stand, für die max.supportet RAM Speed (ohne EXPO) bei ZEN6?

Badesalz

2026-02-13, 09:30:51

Angeblich ist 6400 quasi gesichert. Bisschen ähh... vager ist, daß es auch 1DPC (1 Slot belegt) optimiert ist und da bis 8000 ziehen soll.

Ich würde das beim X3D mit 2 guten 6000/30 selbst bei StarCitizen aber eher entspannt sehen.

rentex

2026-02-13, 09:44:10

6400 ist schon ein guter Sprung. Aber um so bessser.
1 DPC soll mir recht sein.

Nightspider

2026-02-14, 16:25:38

Ich hoffe da geht noch mehr.

Der IOD von Turin (Zen5 Server IOD) schafft ja angeblich schon 6400.

AMD EPYC “Turin” is still a 12-channel DDR5 design. DDR5 speeds are up to DDR5-6000, but AMD said it will qualify up to DDR5-6400 for certain customer platforms

kA obs auch wirklich Platinen gibt die 6400 bei Turin unterstützen.

Semmel

2026-02-14, 16:33:41

Zen 4 kann offiziell nur 5200 und der Sweetspot ist trotzdem bei 6000.

So gesehen sind 6400 schon ein ordentlicher Sprung. Der Sweetspot könnte bei 7200 liegen und mit der Keule könnten 8000 drin sein.

Badesalz

2026-02-14, 16:53:02

Du meinst es wird 1:1 7200 können? hmm... Was ist der Sweetspot beim Zen5? Dachte auch 6000? :wink:

Der V-Cache soll beim Zen6 größer sein.

basix

2026-02-16, 15:41:32

Gut wäre ja 1:1:1 für FCLK / UCLK / MCLK. Das wäre 3.2 GHz bei DDR-6400. FCLK läuft bei Zen 5 typischerweise bei 2.0 GHz.

mczak

2026-02-16, 16:25:45

Gut wäre ja 1:1:1 für FCLK / UCLK / MCLK. Das wäre 3.2 GHz bei DDR-6400. FCLK läuft bei Zen 5 typischerweise bei 2.0 GHz.
Wir wissen doch noch gar nicht ob das überhaupt prinizipiell genau gleich funktioniert mit dem MC und den verschiedenen Taktraten? Falls ja wäre aber ddr5-6400 wohl schon ein vernünftiger Sweetspot. Wobei ja auch CU-DIMMs unterstützt werden sollen, da wäre es dann auch hilfreich wenn deutlich höhere Taktraten vernünftige Teiler hätten (wobei CU-DIMMs nach dem anfänglichen Hype irgendwie auch schon wieder aus der Mode gekommen sind...).

basix

2026-02-16, 17:12:22

Nein, wissen wir nicht ob das gleich funktioniert. Vielleicht kann man auch keine krummen Multiplikatoren zwischen FCLK und UCLK fahren, nur noch 1:1:1. Und dann noch 1:1:2 bei schnellem DRAM.

Den selben Takt für Infinity Fabric und Memory Controller zu fahren würde vermutlich einige Sachen simpler gestalten. Sobald man beginnt zu teilen, muss man Buffer einbauen (z.B. bei 1:2:2). N3P anstatt N6 dürfte da hoffentlich schon gut was freischaufeln bei der Taktbarkeit.

Nightspider

2026-02-16, 18:18:28

6400 wäre trotzdem lächerlich, wenn die CCDs 2 fette Node Sprünge machen und den neuesten 2nm Node nutzen und +50% Cores bieten, sowie deutlich mehr Takt.

Wäre bescheuert wenn AMD beim IOD nicht auch etwas auf das Gaspedal drücken würde.

Veraltete IODs hatten wir jetzt genug Jahre. Bei Intel wird schon gefühlt 5 Jahre lang 7200-8000 via OC ermöglicht.

Eventuell will man ja auch Zen7 mit dem gleichen IOD befeuern, welcher 16 Kerne pro CCD und noch mehr IPC bringen soll. 6400 können sie behalten.

CU-DIMM Module gibts seit 1-1,5 Jahren mit DDR5_9600.

rentex

2026-02-16, 18:38:41

Weil RAM Speed bei einem X3D, auch soo entscheidend ist...

ChaosTM

2026-02-16, 18:44:46

APU`s brauchen den schnellstmöglichen Speicher um die Grafikeinheit zu befeuern.

Die CPU selbst kommt wohl mit deutlich weniger aus..

Nightspider

2026-02-16, 18:48:16

Weil RAM Speed bei einem X3D, auch soo entscheidend ist...

[ ] Die Welt besteht nur aus Games

[ ] Alle Games profitieren gleichermaßen von X3D

[ ] Du hast verstanden worum es geht

[x] Keiner zwingt dich teuren RAM zu verbauen

robbitop

2026-02-16, 18:54:00

Badesalz

2026-02-16, 18:57:07

Keiner zwingt dich teuren RAM zu verbauenKeiner zwingt AMD dazu den Blödsinn, der Intel überhaupt noch am Leben hält, zu unterstützen. JEDEC Timings sind Vollgrütze.

Nightspider

2026-02-16, 18:59:00

Badesalz

2026-02-16, 19:05:58

6000/30 ist imho noch nicht so ganz ein starkes RAM-Tuning.

Hier kann ja jeder bei 6000er RAM bleiben, wenn er will aber die Option zu haben, mehr zu bekommen hätten einige schon gerne.Ich denke am Ende wird das auch Stückchen mehr :wink:

Nightspider

2026-02-16, 19:09:22

6000/30 ist imho noch nicht so ganz ein starkes RAM-Tuning.

Hat auch keiner gesagt. Ist mir auch buggy bei welchem RAM Takt hier jeder in Zukunft verweilen will.

Und wenn sich hier welche einen X3D an 4800er China RAM löten ist mir das auch wumpe.

robbitop

2026-02-16, 19:19:34

Lieber zu viel als zu wenig.

Auch ein 9800X3D profitiert noch fühlbar von starkem RAM Tuning.

Und wenn Zen6 so viel Speed zulegt, werden die 50% mehr L3 bei 50% mehr Kernen auch nicht die Rettung sein. Es wird helfen aber sehr schneller RAM wird trotzdem noch Vorteile bringen. Garantiert.

Hier kann ja jeder bei 6000er RAM bleiben, wenn er will aber die Option zu haben, mehr zu bekommen hätten einige schon gerne.
Wobei aber der Vergleich fehlt 6000 MHz mit maximalem timing tuning vs höberer Takt (gleiche Module!) und timingtuning (die timings mit höherem Takt werden dann schlechter durch den höhereren Takt.
Ich vermute, dass die Unterschiede dann nahe null sein werden. Einfach weil die meisten Anwendungen/Spiele latenzgetrieben sind.

rentex

2026-02-16, 20:00:33

@Nightspider

[x] Ich scheisse auf die Arbeit von AMD, eine effiziente CPU entwickelt zu haben...getreu dem Motto: Ich will Gas, Ich will Spaß.

mczak

2026-02-16, 21:34:22

Aha und welchen realworld Applikationen bringt es denn sonst was in signifikanter Form? Insbesondere vor dem Hintergrund dass der L3 bei Zen6 x3d auf 144 MiB wächst.
Wenn man dann noch die timings/subtimings tunt, wird wahrscheinlich fast nirgends bei noch höheren Ramtaktraten realworld signifikant was bei rumkommen vermute ich.
Also ich weiss nicht man darf ja nicht vergessen dass da bis zu 24 Kerne möglich sind. Bei bloss einem CCD gebe ich dir recht da wird höherer Speichertakt wohl nicht allzuviel bringen. Gab ja aber auch schon Gerüchte dass dual-compute NVL durch Bandbreite limitiert ist, das könnte imho durchaus auch ein Thema sein bei Zen6, Cache hin oder her (aber natürlich längst nicht in allen Applikationen).

Badesalz

2026-02-17, 06:25:57

Hat auch keiner gesagt. Ist mir auch buggy Ja. Wie jedes Mal. Erstmal kommt das Hammärken wo kein Nagel ist und dann ist es eh Wurst. Schon ok :rolleyes:

robbitop

2026-02-17, 09:45:37

Also ich weiss nicht man darf ja nicht vergessen dass da bis zu 24 Kerne möglich sind. Bei bloss einem CCD gebe ich dir recht da wird höherer Speichertakt wohl nicht allzuviel bringen. Gab ja aber auch schon Gerüchte dass dual-compute NVL durch Bandbreite limitiert ist, das könnte imho durchaus auch ein Thema sein bei Zen6, Cache hin oder her (aber natürlich längst nicht in allen Applikationen).

Ja ok. Aber welche realworld Consumer Applikationen fahren das aus? 24C/48T? Und dann hat man ja immernoch den riesen Cache der den Druck auf das SI reduziert.
Ich denke das ist zum überwiegenden Großteil eine eher theoretische Betrachtung, dass die Bandbreite nicht ausreichen könnte.

davidzo

2026-02-17, 10:49:16

Badesalz

2026-02-17, 11:12:44

Das sind Fälle die entweder HEDT fährt oder ein Server. NVL ist auch mit 256 cores kein HEDT. Xeon 600 ist HEDT/Workstation. Das ist Granite Rapids. Bandbreite passt hier übrigens.

Die CPU bleibt sinnlos. Es gibt dafür nichts sinnvolles in consumer real world. Die 10 Typen pro 1Mio. potenzieller Käufer die ständig Handbrake am laufen haben sind kein Markt. Wie viele Leute kennt ihr die überhaupt irgendeinen Zen4/Zen5 Threadripper haben?
Auch abseits der Bandbreite, weil wie es aussieht kommen die 2-Tile nur mit dem dicken Cache (um eben etwas von der Bandbreite zu retten).

PS:
Intel hat in den Xeon 600 Folien nur die Vorgänger erwähnt. AMD erstmal nicht...

robbitop

2026-02-17, 15:13:11

Naja, bei langen Vektoren sind die Desktop CPUs schon Bandbreitenlimitiert. Da gibts den schönen Cheese and chips Artikel vom Epyc 9355P der über GMI Wide verfügt (64+64b vs 32+16 im Desktop).
- Viele Videocodecs haben AVX512 Codepfade die wahrscheinlich gut mit Bandbreite skalieren.
- Simulationen wie FE Analyse, Stream, Triad (ich weiß, eher workstation workload) sind auch massiv Bandbreitenabhängig.
- Kompressionsalgorithmen sind weitestgehend Bandbreitenlimitiert
- Kleine KI workloads die auf der CPU laufen sind Bandbretenlimitiert. Schlussendlich ist auch die NPU selber bandbreitenlimitiert
- Vektordatenbanken und Suchen sind bandbreitenlimitiert. Das betrifft zwar nicht die normale Dateisuche, aber fast alle Ähnlichkeitssuchen, wie nach Bildern oder Audio sind Bandbreitenlimitiert.
- RAG Datenbanken für lokale LLMs um den Kontext für den lokal laufenden Chatbot nachzuladen sind etwa CPU tasks die Bandbreitenlimitiert sind. Windows Recall sehr wahrscheinlich auch.
- Kryptografie wie AES-GCM oder Scrypt ist auch häufig Bandbreitenlimitiert und skaliert daher schlechter mit mehr Cores.

In diesen Workloads sehe ich auch nicht dass Novalake sich da mit mehr Cores groß absetzen könnte, hängen doch beide an einem ähnlichen 128bit DDR5 SI.
Sind aber alles keine Consumerworkloads. Ryzen ist ja eine Consumer CPU.
Klar die gehen als Ryzen PRO auch in Workstations aber dort treffen sie dann eben auch auch "nur" auf Core Ultra die auch nicht mehr Bandbreite haben. Wer bei den Workloads mehr Power will, nimmt dann ohnehin Epyc (in der Workstation oder halt im Rechencluster).
Bei großen Firmen ist einiges von den Beispielen nicht mehr auf der workstation sondern tatsächlich auf clustern im Firmenrechenzentren.

Also ich denke der overlap zwischen Anwendungen, die wirklich trotz riesem L3 noch Bandbreitenlimitiert sind (und auf der CPU und nicht auf der GPU oder anderen spezialisierten PUs laufen) und der tatsächlichen Anwendung von Consumer CPUs ist ziemlich klein. Das meiste rennt auf Epycs/Xeons oder auf GPUs/T/NPUs.

---------------------------------------

Ich persönlich denke aber auch, dass mit 12C CCDs außerhalb von Synthie-Oranierorgien mehr als genug MT Leistung für 99,99% der consumer vorhanden ist. 24C braucht noch kaum jemand bzw profitiert kaum jemand im Consumerbereich. Und bei den 12C CCDs reicht die Bandbreite dann noch dicker als dick ^^

Badesalz

2026-02-17, 16:49:06

@robbi
Vielleicht wird Zen7 wieder bisschen monolythischer? ;) Daheim braucht das alles so langsam nicht mehr.

Nightspider

2026-02-17, 17:02:47

Auf keinen Fall. Es geht ja gerade darum die Teile vom teuren Prozess wegzubekommen, die kaum noch skalieren, wie IO Krams und Cache.

14A, Backside Power Delivery usw werden die Waferpreise weiter stark steigen lassen.

Und durch Stacking erreicht man eben noch weitere Vorteile, wie bessere Latenzen, größere Caches usw.

Bei Nova Lake liegt der Big LLC ja neben den Cores, da werden die Latenzen kräftig steigen.

mczak

2026-02-17, 17:21:19

Auf keinen Fall. Es geht ja gerade darum die Teile vom teuren Prozess wegzubekommen, die kaum noch skalieren, wie IO Krams und Cache.

Ja ich denke das kann man ausschliessen, nicht-monolithisch wird bleiben. Nicht ohne Grund hat man neue Packaging-Techniken entwickelt. Fragt sich höchstens wieviele verschiedene Dies man kombiniert.

Bei Nova Lake liegt der Big LLC ja neben den Cores, da werden die Latenzen kräftig steigen.
Naja also wirklich stark brauchen die wegen dem bLLC nicht unbedingt zu steigen, etwas aber schon. Und vielleicht gelingt es intel ja die L3 Latenzen ansonsten etwas zu senken so dass es im Endeffekt nicht wirklich gross langsamer ist.

Badesalz

2026-02-17, 19:58:57

Bisschen monolythischer... Scheint wohl sehr schwerer technischer Begriff... :rolleyes:

OgrEGT

2026-02-17, 21:11:50

Bisschen monolythischer... Scheint wohl sehr schwerer technischer Begriff... :rolleyes:
Meinst du mit "bisschen" bspw ein Zen7 CCD+IO monolithisches Die mit 16C welches für das meiste reicht an das aber weitere 16C CCD-only Dies angeschlossen werden können?

basix

2026-02-17, 23:09:24

Weil RAM Speed bei einem X3D, auch soo entscheidend ist...

Auch einem X3D hilft schneller RAM in Games. Und ausserdem gibt es auch CPUs ohne X3D ;)

Und wie schon andere angetönt haben gibt es auch noch anderes als Spiele, welche neben Latenz auch Bandbreite gerne haben. Man darf sich ja wohl schlicht das bestmögliche Produkt in allen Lebenslagen wünschen ;)

Badesalz

2026-02-18, 06:20:55

Meinst du mit "bisschen" bspw ein Zen7 CCD+IO monolithisches Die mit 16C welches für das meiste reicht an das aber weitere 16C CCD-only Dies angeschlossen werden können?Grob derartiges. Ja.

OgrEGT

2026-02-18, 07:07:00

Grob derartiges. Ja.

Wäre nicht ganz abwegig... Bei den Medusa APUs wird ja ähnliches spekuliert...
Die Frage wäre wie man das kosteneffizient hinbekommt... das CCD-only und das CCD+IOD Die müssten dann fast in unterschiedlichen Nodes gefertigt werden? Da sonst wertvolle Waferfläche für das CCD+IOD "verschwendet" würde... X3D wird dann auf den unterschiedlichen Dies auch komplizierter... sofern das auf >16C Sinn macht... es sei denn man würde den X3D Cache in ein universelles Base Die verbauen auf das dann wahlweise die unterschiedlichen CCD Dies gestacked werden...

Badesalz

2026-02-18, 08:16:30

Wäre nicht ganz abwegig... Bei den Medusa APUs wird ja ähnliches spekuliert...
Die Frage wäre wie man das kosteneffizient hinbekommt... das CCD-only und das CCD+IOD Die müssten dann fast in unterschiedlichen Nodes gefertigt werden?Ich will keineswegs drauf rumreiten :freak: War halt ein "vielleicht" und "teils".
Aber brauchen, brauchen wir das nicht mehr zwingend im gewöhnlichen Desktop (Gamer, private Workstation).
Davor war das noch sehr wohl der Fall. Das war ja auch der Coup. Ausschließlich Vorteile hat es aber nicht. Davor war das aber eben so. Das war der einzige wirtschaftlich sinnvolle Weg solche Sachen überhaupt realisieren zu können.
Nodes, Stacking/Packaging sind mittlerweile aber paar Level weiter.

Für sehr wahrscheinlich halte ich das aber auch nicht. Noch nicht. Wäre für Zen7 vielleicht auch noch zu früh.

Nightspider

2026-02-18, 10:09:25

Mobile APUs sind im IO Bereich aber auch deutlich abgespeckter als bei Desktop CPUs oder?
Könnte jetzt nur keine Zahl nennen, ob es 30% sind oder 50% oder nur 20%.

Badesalz

2026-02-18, 10:34:09

Ja. Für den Desktop muss das nicht. Da drückt ein Noctua auf den Deckel.

mboeller

2026-02-18, 11:38:19

@robbi
Vielleicht wird Zen7 wieder bisschen monolythischer? ;) Daheim braucht das alles so langsam nicht mehr.

Eigentlich hatte ich von den ganzen XBOX-Videos her (MLID) den Eindruck das es eher in die andere Richtung geht.

APU's:

CPU-Die // Northbridge // GPU (AT 2/3/4) incl. LPDDR5/6 Interface

Ob die Northbridge jetzt wirklich zw. CPU und GPU sitzt oder seitlich angeflanscht wird und entweder die CPU oder die GPU dafür ein Interface bekommt, da bin ich mir nicht sicher. Aber wahrscheinlich ist es wie bei der XBox die GPU. Bei der XBox ist CPU+Northbridge halt ein Die und nicht 2.

reunion

2026-02-19, 09:52:58

RDNA4m in Medusa hat die RDNA4 Matrix-ISAs, dürfte als FSR4 können:
https://videocardz.com/newz/amd-ryzen-500-medusa-rdna-4m-igpu-shows-rdna-4-matrix-isa-support-fsr-4-support-looks-likely

robbitop

2026-02-19, 13:47:07

Sehr gute Entscheidung. Damit steht dann auch neueren AI Features nichts im Weg. Die höhere RT Performance aus RDNA4 wird wahrscheinlich niemand gebrauchen können auf kleinen low end APUs und dann nimmt man eher die höhere raster perf pro transistor von RDNA3 mit (die CUs vei RDNA4 sind zwar schneller aber auch überproportional teurer). Entsprechend hat man transistornormiert für das Zielclientel wahrscheinlich die beste Lösung. :up:
Überraschungen gibt es ja immer wieder - hätte ich nicht gedacht, dass AMD da nochmal Matrixcores in eine alte uArch einbaut.

MSABK

2026-02-19, 13:55:33

Hmm, könnte vlt auch interessant für Valve sein.

robbitop

2026-02-19, 14:20:52

Das sehe ich ehrlich gesagt weniger. Die einzige HW die neue nicht bereits veröffentlichte Chips bekommt in halbwegs absehbarer Zukunft ist das Steam Deck 2. Und was dort die Erwartungshaltung für den Chip ist da war Valve sehr sehr klar. Sie erwarten wenn sie ein Deck 2 machen nicht weniger als einen „generational leap“ und zwar bei 15W. Perf/Transistor ist da auch wichtig klar - aber um erstmal in Frage zu kommen braucht es einen gewaltigen Sprung in Bezug auf Perf/W. Und da ist RDNA3 nicht so toll. Daran ändern die Matrixunits auch nichts.
Ich würde dort eher auf einen ARM Chip tippen den man von der Stange nehmen kann. Von Samsung (dann kann man den RADV Treiber weiternutzen dank der AMD exclipse gpu) oder von Qualcomm. AMD hat für obere Anforderung nichts in der Pipeline was geleakt wäre und wirklich custom bei der relativ kleinen Anzahl der Verkaufszahlen des Decks (5 mio sind für einen handheld PC super aber sind viel zu wenig für custom silicon). Wenn es was customartiges von AMD wird dann IMO etwas was jemand anderes fallen gelassen hat (VG APU aus dem Deck 1 ist bspw ursprünglich für MS für ein surface laptop entwickelt worden und MS hat es dann doch nicht gewollt) oder man es sich teilt. Hier käme der angeblich für den xbox handheld entwickelte und letztes Jahr gecancelte SoC ggf auch in Frage.
IMO: wenn es eine APU von AMD werden soll dann wird es rdna5 haben.

MSABK

2026-02-19, 14:59:50

Vlt kommt alles ganz anders und es wird ein Aufguss ala 6xZen6 und 8CU RDNA4m geben in N2.

Wer weiß. Aktuell 0 einschätzbar, mit der aktuellen Krise rechne ich eh nocht vor 2028 mit was neuen.

robbitop

2026-02-19, 15:01:07

Das würde aber nicht sen generational leap bringen. Halte ich für unwahrscheinlich. Aber ja die Speicherkrise wirft sowieso alle / viele HW Pläne von allen möglichen Firmen durcheinander.

Sonyfreak

2026-02-19, 15:47:58

mczak

2026-02-19, 15:52:24

robbitop

2026-02-19, 16:14:07

Ich hoffe sehr darauf, dass Valve nicht plötzlich auf eine andere CPU-Architektur setzt und dadurch alle Fortschritte, die in den letzten Jahren hinsichtlich der Spielekompatibilität zu Linux gemacht worden sind, in Gefahr bringt. ;(

mfg.

Sonyfreak
Was Kompatibilität angeht ist die CPU ISA soweit ich das sehe kaum ein Problem. ARM-> x86/x86-64 Emulation ist nichts neues und funktioniert grundsätzlich (außerhalb von Kernellevel Treibern). Valve selbst arbeitet (bzw zahlt Entwickler dafür) seit 7 Jahren am open source Emulator FEX. Die Frage ist, auf wie wenig overhead man das gedrückt bekommt. Bis dato sind diese Emulationen (Microsoft Prism und Apple Rosetta2) schon nennenswert vom Overhead. Dieser ist auch sehr sehr variabel - an manchen Stellen sehr gering und an manchen sehr hoch. ~20...40% würde ich sagen ist die Größenordnung.

Kurz/mittelfristig kritischer sind die GPU Treiber. Wenn man AMD GPU IP nutzt, kann man den RADV Treiber nutzen (den Valve jahrelang ähnlich unterstützt hat wie FEX). Der ist mit großem Abstand der beste 3D Gaming Treiber unter Linux. Gerade Qualcomm hätte da noch viel Arbeit vor sich.
Aber nichts was sich nicht durch andere IHVs, wenn der Wille und das Budget da ist, auch über mehrere Jahre aufholen lassen würde.

RDNA4m (wenn's denn tatsächlich RDNA 3.5 mit Matrix Cores ist) taugt doch eh nicht wirklich für Next-Gen Handhelds. RDNA4 soll ja deutlich bandbreiteneffizienter sein, das halte ich für zwingend für den angestrebten Generational Leap (wenn man da nicht irgendwelche komischen Dinge punkto Speicher macht). Klar mehr Cache ist ebenfalls zwingend aber ich würde meinen man braucht beides.

:up: sehe ich auch so

reunion

2026-02-19, 16:16:11

RDNA4m (wenn's denn tatsächlich RDNA 3.5 mit Matrix Cores ist) taugt doch eh nicht wirklich für Next-Gen Handhelds. RDNA4 soll ja deutlich bandbreiteneffizienter sein, das halte ich für zwingend für den angestrebten Generational Leap (wenn man da nicht irgendwelche komischen Dinge punkto Speicher macht). Klar mehr Cache ist ebenfalls zwingend aber ich würde meinen man braucht beides.

Ich denke auch es braucht zwingend RDNA4 oder neuer. Man braucht sich ja nur die Ergebnisse des Xclipse 960 mit RDNA4 im neuen Exynos 2600 ansehen. Trotz unterlegenen Samsung Prozess macht das Ding selbst eine Adreno 840 GPU im Qualcomm Snapdragon 8 Elite Gen 5 nass und übertrifft in OpenCL-Benchmarks (z.B. Geekbench 6) teilweise sogar ARM-basierte Laptop-Chips. Die Xclipse 950 mit RDNA 3 bricht dagegen speziell bei Dauerlast völlig weg und ist eigentlich chancenlos. Die out-of-order-memory-execution ist ein erheblicher Vorteil gerade im ultra-mobilen Bereich, dagegen ist jede in-order-execution einfach nur brute-force die man mit deutlich mehr Bandbreite kompensieren muss. Und das kostet auch Leistungsaufnahme.

reunion

2026-02-19, 16:27:09

Ich hoffe sehr darauf, dass Valve nicht plötzlich auf eine andere CPU-Architektur setzt und dadurch alle Fortschritte, die in den letzten Jahren hinsichtlich der Spielekompatibilität zu Linux gemacht worden sind, in Gefahr bringt. ;(

mfg.

Sonyfreak

Naja, Zen6 ist halt eigentlich schon eine reinrassige HPC-Architektur. Da steckt mittlerweile eine enorm potente FPU drinnen und viel anderes Zeug das man eigentlich für Spiele nicht benötigt. Und AMD macht keine Anstalten eine zweite x86-Architektur zu entwickeln. Von daher könnte ein ARM-Core schon eine bessere Wahl sein für ein Handheld. Wenn ich tippen müsste würde ich am ehesten auf ARM-Cores mit AMD-GPU-Architektur in einem AMD custom Chip tippen. Die jahrelange Treiberarbeit wird man IMO nicht wegwerfen.

mczak

2026-02-19, 17:22:12

Naja, Zen6 ist halt eigentlich schon eine reinrassige HPC-Architektur. Da steckt mittlerweile eine enorm potente FPU drinnen und viel anderes Zeug das man eigentlich für Spiele nicht benötigt. Und AMD macht keine Anstalten eine zweite x86-Architektur zu entwickeln.
Wobei die Zen APUs ja leicht abgespeckte FPUs haben, allerdings durchaus immer noch ziemlich potent. Kann aber schon sein dass ein kommuner ARM-Core da prinzipiell etwas besser geeignet wäre.

robbitop

2026-02-19, 18:13:32

Nightspider

2026-02-19, 18:44:25

Zen6 Desktop CPU Varianten:

6 8 10 12
8+8 10+10 12+12

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

Eigentlich keine News wert, weil obvious aber egal. ^^

Semmel

2026-02-19, 18:56:45

mczak

2026-02-19, 19:21:31

Zen6 Desktop CPU Varianten:

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

Eigentlich keine News wert, weil obvious aber egal. ^^
Naja also komplett offensichtlich ist das nicht, aber war schon sehr wahrscheinlich. Wobei das ist eine ganze Menge SKUs - bisher gab es (ohne X3D) eigentlich bloss 4 (6/8/12/16 Kerne), auch wenn da noch ein paar weitere existieren (verschiedene TDP, ohne IGP...), neu wären das dann 7.
Dass der 6 Kerner weiterhin existiert könnte wohl ein Hinweis darauf sein dass AMD gerne den "Preis pro Kern" ähnlich halten möchte und es einfach teurere Modelle gibt? Ich kann mir jedenfalls nicht vorstellen dass man den aus Gründen der Resteverwertung braucht.

Der_Korken

2026-02-19, 22:29:52

Ist zwar eher unwichtig, aber mich würde das Namensschema für Zen6 interessieren, nachdem man dort an zwei Grenzen stößt.

Das vierstellige Schema ist mit der 9 vorne dran am Ende.
Macht man einfach fünfstellig weiter, also Ryzen 10000?

Und wie macht man die Modellbezeichnungen innerhalb der Serie?
Nach bisherigem Schema:
10600 = 6-Core
10700/10800 = 8-Core
10900 = 12-Core
10950 = 16-Core

Die werden wohl kaum einen 10999 als 24-Core bringen. ;)

Bei so einer Spannweite wird AMD wohl nicht schon wieder zwei Hunderter für die gleiche Kernzahl "verschwenden". Wenn es eine 10K-Serie wird, würde ich vermuten, dass der 12-Kerner die 800 am Ende bekommt, weil das dann jeweils die größte Config mit einem CCD über alle Serien gewesen wäre. Nach unten dann 10C = 700, 8C = 600, 6C = 500. Nach oben hin wird es trotzdem eng und man müsste in 50er Schritten gehen (16C = 850, 20C = 900, 24C = 950). Die Preisen würden aber trotz gleichem Namen ordentlich steigen, d.h. einen 10800X3D würde ich z.B. irgendwo bei 599$ bis 699$ sehen. Die 2-CCD-Modelle bewegen sich da schon zwischen Desktop und Workstation und werden nach oben hin vierstellig werden.

Kann aber auch sein, dass AMD die CPUs in ihr mobiles Namensschema eingliedert und den 12C als Ryzen 7 AI 570X3D verkauft (der 370HX hat ja schon 12 Kerne (wenn auch nicht alles große)). Dann wären 580, 590 und 595 frei für 16C, 20C, 24C.

Leonidas

2026-02-20, 05:53:28

Badesalz

2026-02-20, 08:50:29

@Leo
Das nützt nichts. Man muss auch jeweils die Modellreihe benennen.

Complicated

2026-02-20, 09:30:31

Meistens gings dann wieder dreistellig los, siehe auch Intel.
Um dann nicht veraltet zu wirken steigt man mit der Generation bei den Zahlen wie bei der Konkurrenz ein - hier hatte Intel bisher immer die Vorgaben gemacht und AMD folgt nach. Ist halt der Marktführer in einem Duopol.

HOT

2026-02-20, 09:30:50

Ist zwar eher unwichtig, aber mich würde das Namensschema für Zen6 interessieren, nachdem man dort an zwei Grenzen stößt.

Das vierstellige Schema ist mit der 9 vorne dran am Ende.
Macht man einfach fünfstellig weiter, also Ryzen 10000?

Und wie macht man die Modellbezeichnungen innerhalb der Serie?
Nach bisherigem Schema:
10600 = 6-Core
10700/10800 = 8-Core
10900 = 12-Core
10950 = 16-Core

Die werden wohl kaum einen 10999 als 24-Core bringen. ;)

5-stellig wird die Nummer auf keinen Fall. Man wird sich an den neuen Generationsnummern orientieren. Statt RyzenAI könnte die CPU auch RyzenAI heißen.

RyzenX R5 550 6c, RyzenX R5 560 8c, RyzenX R7 570 10c, RyzenX R7 580 (X3D) 12c, RyzenX R9 590 (X3D) 16c, RyzenX R9 595 (X3D) 24c.

Ich sehe nicht, waurm man einen 20c ins Lineup einbauen sollte. Die Käuferschicht ist bei 16c schon derart dünn, dass sich das einfach nicht lohnen wird und auch der Leistungsabstand wäre auch so gering zum Topprocdukt im Softwarteschnitt, dass es mMn idiotisch wäre.

reunion

2026-02-20, 09:40:26

reunion

2026-02-20, 09:42:24

Ab Zen6 gibt es auch LP Varianten die schon auch architektonisch anders sein sollen. In etwa so wie die Oryo Cores eine L und eine M Variante haben. Tenstorrent hat das für ihre CPUs auch auf der roadmap. Dann wird es gleich als Familie geplant und man braucht nicht notwendigerweise 2 getrennte Entwicklungen.

Ich bin gespannt. Vielleicht macht man wirklich eine Art modulare CPU-Architektur. Mit Zen5 wo man die FPU auch auf Silizium-Ebene defacto einfach abschneiden kann und dann statt einer 512bit FPU eine 256bit FPU bekommt ist der erste Schritt schon getan das stimmt. Und auch die X3D-Variante geht im Grunde in diese Richtung, man kann den 3D-Cache verbauen oder auch nicht.

rentex

2026-02-20, 14:06:49

https://wccftech.com/amd-olympic-ridge-zen-6-ryzen-desktop-cpus-launching-2027/

Wird wohl später...

Dural

2026-02-20, 15:30:36

Eh egal, wird ziemlich sicher Intel.

Die letzten Jahr genug AMD gehabt, zudem ich mir nach wie vor einbilde das Intel System sauberer und runder laufen als die von AMD.

Sehe es jeden Tag beim 13900K / 9950X Vergleich.

rentex

2026-02-20, 15:53:41

Hatte vor ZEN3, ebenfalls, lange Intel Systeme genutzt...hatte den selben Eindruck, das Intel Systeme, "sauberer" liefen.

robbitop

2026-02-20, 16:51:20

Kann ich so gar nicht nachvollziehen - zumindest auf AM4. Seit 2017 ein B350 Board mit Ryzen 1700 als Unraid Server der 24/7 rennt (wurde 2023 auf 5950X upgegradet). Keine Ausfälle oder Abstürze. Und am Gamingdesktop ein 5800X3D mit CO -30 - tagsüber als homeoffice System und Abends/WE Gaming. Keine Probleme.

Ich frage mich bei solchen Instabilitäts Angaben oft, wie viel mit anderen Komponenten, Softwarekonfiguration oder OC zusammenhängt. Und es sind ja oft subjektive - also nicht quanititative "Datenpunkte". "ich habe das "Gefühl" es läuft "sauberer"" X-D

Unabhängig davon kann ich AM5 nicht beurteilen - ggf. gab es da initial mehr Kinderkrankheiten mit UEFIs/AGESA. Gab es IIRC bei Intel aber auch immer mal dass es Anfangs Kinderkrankheiten mit Treibern/BIOS gab bei neuen Plattformen. Manchmal sogar Chipsets die neue Revisionen brauchten. Und je nach dem in welcher Zeitperiode man schaut, ist mal der eine oder mal der andere vorn oder hinten. Das würde ich aber nicht generalisieren. Oder wenn -> dann nur mit quantitativen Daten. Idealerweise jeweils gemessen wenn die Plattform etwas gereift ist.

Sind AM5 Systeme ohne OC denn heutzutage problematisch?

https://wccftech.com/amd-olympic-ridge-zen-6-ryzen-desktop-cpus-launching-2027/

Wird wohl später...
Die Zyklen dauern immer länger von Zen zu Zen. AMD muss aufpassen. Intel gibt wieder Gas.

Interessant beim wccf Artikel dass sie Zen 6 nur 64 mb bllc zuordnen und dem max L3 96 Mib - mit einem Fragezeichen. Obwohl eigentlich bekannt ist, dass es 50% mehr werden. Also 144 MiB.

Bei Novalake - ist der bLLC denn ein L4? Denn wenn es einfach nur ein großer L3 ist, dann sind es auch nur 144 MiB maximal. Und das doppelte Zählen vom Cache über 2 compute dice bei NVL macht keinen Sinn. Aus gleichen Gründen wie bei AMD. Die compute dice werden keinen sinnvoll schnellen Zugriff auf den bLLC des jeweils anderen haben. Also bleibt es pro Kern bei maximal 144 MiB.

rentex

2026-02-20, 17:05:25

Es geht nicht um Abstürze, sondern darum, wie fluffig das System reagiert. Mit AM4, hatte ich Damals, einige Probleme mit USB.

robbitop

2026-02-20, 18:19:34

Vielleicht waren das noch early days? Das Problem habe ich gar nicht gehabt.

Ich finde diese Bewertung jedenfalls sehr wackelig aus oben benannten Gründen.

Twodee

2026-02-20, 20:20:10

Ahh sind wir wieder beim Thema Esoterik angekommen?

robbitop

2026-02-20, 20:58:02

Scheint so.

OgrEGT

2026-02-21, 05:19:00

Aus den eigenen begrenzten Erfahrungen auf die Gesamtheit zu schließen war noch nie sinnvoll... keine Ahnung was Intel-Gefühle hier im Zen6 Thread suchen...

rentex

2026-02-21, 08:36:41

Kommt mal runter. Wer das Thema befeuert hat, wart ihr doch. Daher weiter im Text.

Intel verschiebt nun ebenfalls...

https://www.techpowerup.com/346613/intel-nova-lake-s-coming-in-2027-ces-launch-alongside-amd-olympic-ridge-likely

Leonidas

2026-02-21, 09:50:51

https://wccftech.com/amd-olympic-ridge-zen-6-ryzen-desktop-cpus-launching-2027/
Wird wohl später...

Unsicher. Das Originalposting erwähnt das nur beiläufig, mitnichten als "Verschiebung". Dies sehe ich als andere "Meinung" zum Zen6-Releasetermin, nicht als ernstzunehmende Meldung über eine tatsächliche Verspätung.

reunion

2026-02-21, 10:10:57

Die Zyklen dauern immer länger von Zen zu Zen.

Naja liegt primär daran dass man EPYC und Ryzen geswitched hat. EPYC Zen5 kam erst Ende 2024, EPYC Zen 6 soll schon Mitte 2026 kommen, das sind nur 18 Monate. Dafür ist es bei der Desktop-Version deutlich mehr, da diese jetzt offenbar weniger Prio hat als die Server-Version. Mobile ist noch ein Fragezeichen, könnte allerdings auch noch früher kommen als die Desktop-Version.

Badesalz

2026-02-21, 10:26:45

Man launcht, wenn eh fertig, nicht nach Prioritäten, sondern nach Sinn... Klingt am Ende wie ein Synonym, aber Priorität klingt irgendwie verkehrt (für mich).

rentex

2026-02-21, 10:35:09

Unsicher. Das Originalposting erwähnt das nur beiläufig, mitnichten als "Verschiebung". Dies sehe ich als andere "Meinung" zum Zen6-Releasetermin, nicht als ernstzunehmende Meldung über eine tatsächliche Verspätung.

Das war auch nicht als "Verspätung" im eigentlichen Sinn, zu verstehen.

dildo4u

2026-02-21, 11:11:16

Man launcht, wenn eh fertig, nicht nach Prioritäten, sondern nach Sinn... Klingt am Ende wie ein Synonym, aber Priorität klingt irgendwie verkehrt (für mich).
Die Situation ist aber neu du launchst natürlich nur Epyc in großen Stückzahlen da dort der Ram Landet.

OgrEGT

2026-02-21, 12:08:01

Kommt mal runter. Wer das Thema befeuert hat, wart ihr doch. Daher weiter im Text.

Äh... wo denn und wer sind "ihr"?
Aber ja gerne weiter im Text...

Nightspider

2026-02-22, 17:52:30

Die Situation ist aber neu du launchst natürlich nur Epyc in großen Stückzahlen da dort der Ram Landet.

Das wurde nicht erst in den letzten 4 Monaten entschieden...

Vielleicht launcht AMD im Desktop auch zuerst die teuersten 10 und 12C Ryzens und erst mit deutliczhem Versatz dann 8C und 6C und das wird falsch interpretiert.

dildo4u

2026-02-22, 17:57:46

Natürlich nicht aber AMD selber hat für 2026 Zuwächse nur im Server Bereich vorraus gesagt.
Desktop / Laptop soll hingegen zurück gehen wegen RAM Preisen dementsprechend wird ausgeliefert.

Nightspider

2026-02-22, 18:08:15

Ist ja auch logisch.

Zumal Zen 6 Desktop für 2026 sowieso nur eine geringe Rolle spielen würde, wenn der Launch erst spät im Jahr erfolgt.

Und das die Desktop Verkäufe drastisch einbrechen werden, war ja schon letztes Jahr für jeden klar.

Aber wenn Zen6 zuerst für EPYC kommt, dann wurde das schon vor langer Zeit entschieden.
Und falls Zen6 Desktop den etwas neueren Prozess (N2P) bekommt, dann haben wir den Beweis dafür.

Da Zen6 Desktop ja viel kleinere Dice nutzt, lassen sich Yieldverluste mit einem brandneuen Prozess noch besser kompensieren.
Aber auf die Venice Yields bin ich auch mal gespannt, falls wir welche bekommen.

Badesalz

2026-02-24, 20:37:12

Wenn Zen 6 ordentlich werden sollte, wird er als Ryzen soetwas sein wie die 50er Nvidias. Das kommt CES 2027 (dafür kein paperlaunch) und dann erst wird eine längere Pause eingelegt.

Kann ich mir grad gut denken -> Keine Prophezeihung.

y33H@

2026-02-24, 20:50:53

Epyc mit N2 und Ryzen mit N2P?

Badesalz

2026-02-25, 06:59:22

Vielleicht verzögern auch weder Intel noch AMD, sondern TSMC... ;)

HOT

2026-02-25, 10:13:34

Epyc wird wieder ein anderes Stepping sein, wie immer bisher.

y33H@

2026-02-25, 10:19:02

Node ≠ Stepping

HOT

2026-02-25, 22:33:55

Hä? Zen3 war B0, Epyc B1 und optimiert Desktop B2 beispielsweise. Alle N7.

Nightspider

2026-02-25, 22:58:57

Venice kommt aber erst mit den 32C Zen6c CCDs, wenn ich nicht falsch informiert bin.

Das "normale" Zen6 CCD mit 12C kommt danach. Aber es gibt glaube keine Infos darüber wie groß dieser Versatz ist.

HOT

2026-02-26, 09:36:30

Die kommen offenbar gleichzeitig, war bei Zen5 auch so. Erst Desktop, dann Server (normal ein Stepping weiter) und gleichzeitig damit das dense-Die.

iamthebear

2026-02-26, 20:02:34

Epyc mit N2 und Ryzen mit N2P?

Gab es nicht mal das Gerücht, dass Zen 6 für N2 designed wird, vor Release jedoch auf N2P hochportiert wird?

HOT

2026-02-27, 10:30:34

Natürlich sind die alle N2P. Ich bin mir nicht mal sicher, ob es überhaupt ein kommerzielles N2-Produkt gibt.

w0mbat

2026-02-27, 12:09:29

Fujitsu Monaka?

Badesalz

2026-02-27, 12:11:38

@wombat
Teils :tongue:

Nightspider

2026-03-01, 13:38:04

Ich habe MLID nochmal gefragt welcher Node für das IOD genutzt wird für Zen6 und Zen7 und seiner Antwort war:

"I know they have designed multiple - with one being 6nm. So, it's entirely plausible they have 6, 4, and 3nm designs for whichever product they want."

iamthebear

2026-03-01, 13:49:13

Ich könnte mir gut vorstellen:
.) Desktop Zen 6 bekommt weiterhin ein 6nm IOD, denn hier bringt ein kleinerer Node nur wenig.
.) Laptops werden ein N4 IOD bekommen da hier die Energieeffizienz wichtiger ist
.) Die APUs, die grösere Mengen an WGPs haben dürften N3 bekommen, da dies besser skaliert. Hier gibt es dann womöglich auch die monolithischen Varianten mit CCD/IOD in einem.

basix

2026-03-02, 09:02:59

Laut Gerüchten ist es ein N3P IOD mit RDNA 4m und NPU ;)

Würde aus meiner Sicht Sinn machen:
- IP Re-Use zwischen Desktop und Mobile (Mobile nutzt unisono N3P)
- NPU und GPU (inkl. VCN, DCN) werden gut mit N3-Logikdichte skalieren
- 4 Jahre lang eine neue iGPU zu haben, welche FSR4+ unterstützt (RDNA 4m = RDNA 3.5 + FP8 WMMA)

Alle Laptop IOD / SoC sind definitiv N3P. Monolithische Versionen wie Medusa Point nutzen RDNA 4m. Die grossen Medusa Halo bekommen AT3 / AT4 und somit RDNA5. RDNA5 ist ebenfalls N3P.

Nightspider

2026-03-04, 15:06:30

Nachfrage nach Venice ist laut Lisa Su riesig:

https://www.computerbase.de/news/prozessoren/riesige-cpu-nachfrage-amd-ceo-lisa-su-jeder-will-venice.96398/

War ja nicht anders zu erwarten. Den Preis kann AMD sicherlich hoch ansetzen, sowohl bei HPC als auch Client.

rentex

2026-03-04, 15:41:03

Ich sehe schon die Desktop CPUs, sich richtig verspäten.

amdfanuwe

2026-03-04, 17:30:41

Oh, gibt es schon einen Termin dazu?

Nightspider

2026-03-04, 17:52:39

Nein

HOT

2026-03-16, 16:49:23

4+4+2 Medusa hat doppelt soviel L3$ wie sein Vorgänger Kraken: https://videocardz.com/newz/amd-zen6-medusa-point-10-core-cpu-leak-confirms-32mb-l3-cache

MSABK

2026-03-16, 17:13:52

Hmm, hoffentlich RDNA4.

robbitop

2026-03-16, 18:07:28

RDNA3.7 wohl (rdna3 plus matrix cores für fsr ml). Die Halo/mini SKUs hingegen haben wohl rdna5.
Die 32 MiB L3 sind großzügig - hoffentlich in einem ccx. (strix point hatte iirc 16+8)
RDNA3.7 gibts nur weil in den kleineren APUs der Käufer dicke GPUs nicht belohnt und RDNA4 kostet pro CU überproportional viele Transistoren und RT wird in dem Performancelevel ohnehin kaum benutzt.

mczak

2026-03-16, 18:45:28

Die 32 MiB L3 sind großzügig - hoffentlich in einem ccx. (strix point hatte iirc 16+8)
Ist doch wohl anzunehmen, Strix hat doch bloss 2 CCX weil ein "Standard Zen5 CCX" nur maximal 8 Kerne haben kann. Ausserdem ist eine allfällige Stromersparnis bei tiefer Last (also Abschalten des Hochtakt-Clusters) (wobei ich eh nicht wirklich überzeugt bin dass da 2 CCX insgesamt bei Strix von Vorteil waren) eh nicht relevant weil man ja die LP-Kerne hat.

robbitop

2026-03-16, 18:51:46

Ja das sehe ich auch so. Ich finde 32 MiB aber für eine 0815 APU ungewöhnlich großzügig.

mczak

2026-03-16, 20:01:20

Ja das hat schon was, 32MB wären da ziemlich grosszügig, Medusa Point als günstigster Chip ist ja eigentlich eher ein Kracken als Strix Nachfolger.

amdfanuwe

2026-03-17, 02:55:04

Hat lediglich 2LP Cores zusätzlich und mehr Cache. Das ist der Kraken Nachfolger.
Vielleicht ist doch was dran, das der noch mit einem CCD gekoppelt wird. Gäbe mit 4MB/Core weniger Probleme ( nehme mal an, dass die LP Cores nur bei Video und Standby aktiv sind, ansonsten deaktiviert werden).
Mit X3D CCD und NVidia mGPU könnte das ein gutes Gaming Notebook abgeben.

mboeller

2026-03-17, 06:32:54

Ja das sehe ich auch so. Ich finde 32 MiB aber für eine 0815 APU ungewöhnlich großzügig.

da hat wohl ein Panther AMD ein wenig Beine gemacht ;)

Selbst die kleinen Panther-Lake GPU performen nicht so schlecht.

robbitop

2026-03-17, 07:02:16

Das wäre IMO etwas kurzfristig im Kontext einer Chipentwicklung. Die Konfiguration steht IMO deutlich langfristiger als dass PTL etwas damit zu tun hat. :)

latiose88

2026-03-17, 07:21:33

Sind das etwa die Vorzeichen von Zen 6. Na also doch keine 2*12 sondern mit extra Mini Kerne. Schade aber gut kann man nix machen.

robbitop

2026-03-17, 08:16:51

Es ist schon länger bekannt, dass es ab Zen 6 auch LP Kerne geben soll. Zusätzlich zu den c Cores.
Die Intention der LP Cores ist das Stromsparen. Die Idee ist, dass die im IOD sitzen (bzw bei monolithischen Chips außerhalb des ccx) damit man den ganzen CCX/CCD inkl Infinityfabric Link bei kleiner Last ausknipsen kann. Das erhöht die Akkulaufzeit von mobile Geräten. Macht Intel seit MTL iirc.

mczak

2026-03-17, 08:18:47

Sind das etwa die Vorzeichen von Zen 6. Na also doch keine 2*12 sondern mit extra Mini Kerne. Schade aber gut kann man nix machen.
Davon war bei Medusa Point nie die Rede, man soll den Chip aber ja mit einem Standard 12-Kerne Zen 6 CCD kombinieren können.
Wobei ich mal behaupten würde nur fürs Gaming braucht man das Zusatz-CCD eigentlich nicht, wenn denn die Gerüchte so stimmen, bloss eine dGPU (weil die iGPU von Medusa Point wohl bloss knapp Strix Niveau erreicht).
Das wäre dann schon keine schlechte Strategie, weil man dann mit einem Chip (die Zen 6 12 Kern CCDs fertigt man ja sowieso) fast alle Notebook-Klassen bedienen kann (insbesondere weil ja Medusa Halo / Halo min erst später kommen sollen), vom Feld-Wald-Wiesen Notebook (weder dGPU noch CCD) bis mobile Workstation (mit beidem). Nur dass man da halt eine dGPU für vernünftige Grafikleistung braucht (die dann wohl von Nvidia ist) ist suboptimal.

rentex

2026-03-28, 07:26:10

Mich beschäftigt gerade die aktuelle Lage am Golf (+ KI) und die möglichen Auswirkungen auf HW in den nächsten Monaten.
So wie es aussieht, kann ich mir nicht vorstellen, das wir hier keinerlei Verschiebungen sehen werden.

MSABK

2026-03-28, 08:45:54

Natürlich wird es verschiebungen geben. Es kommen ja auch news dass die KI-Firmen jetzt auch Cpus aufkaufen wollen und der Markt gibt da dann nicht viel her für consumer.

Neue Hardware halte ich bis Mitte/Ende 2027 für unrealistisch. Der Speichermarkt z.B ist tot für Consumer.

horn 12

2026-03-28, 09:11:25

Laut Igor kommen Neuvorstellungen in nächster Zeit keine Einzigen!

Skysnake

2026-03-28, 14:32:51

Das beschränkt sich nicht nur auf Consumer. Mein neues Spielzeug hat es nicht geschafft. Ist einfach zu teuer geworden.

Aktuelle Planung sieht jetzt 2027 vor. Da gibt es dann vielleicht auch nochmals mehr Geld, weil man ja ein Jahr länger das alte Zeug benutzt hat.

Aber ob das reicht???

Und vor allem wird es ja irgendwann ziemlich fragwürdig. Für 20% Mehrleistung x00% mehr bezahlen ist halt naja. Dann vielleicht doch nochmals ein Jahr in die Wartungsverläbgerung gehen und vielleicht die Nutzingspeaks über die Cloud abfangen.

Vielleicht wird es ja 2028 wieder normal was die Preise anbelangt. Ewig kann man den Austausch auch nicht hinauszögern. Die Fehlerraten gehen mit der Zeit hoch und die Hersteller wollen irgendwann auch keine Supportverlängerung mehr liefern. 5 Jahre reichen in meinen Augen. No need Systeme 7 oder 8 Jahre zu betreiben. Das macht dann irgendwann auch keinen Spaß mehr.

rentex

2026-03-28, 18:06:54

5 Jahre sind eine ordentliche Zeit.
Musste mich in letzter Zeit bremsen, irgendwelche Panikkäufe zu tätigen.

bbott

2026-03-29, 17:13:18

Ja das sehe ich auch so. Ich finde 32 MiB aber für eine 0815 APU ungewöhnlich großzügig.
Ich denke eine APU würde deutlich mehr von Cache für die iGPU profitieren. Ein Shared L3/IF Cache wäre dringend notwendiger, als der CPU 32MB statt 16BM zu spendieren.
Aber ich habe dies bezüglich noch nichts gelesen.

amdfanuwe

2026-03-29, 17:28:50

Bei 8CU wohl nicht wirklich.

robbitop

2026-03-29, 18:29:01

Ich denke eine APU würde deutlich mehr von Cache für die iGPU profitieren. Ein Shared L3/IF Cache wäre dringend notwendiger, als der CPU 32MB statt 16BM zu spendieren.
Aber ich habe dies bezüglich noch nichts gelesen.

Ohne Frage ist das so. Ich meinte es eher im historischen und ökonomischen Kontext (Präzedenz).

basix

2026-03-30, 09:17:45

Medusa 1, 2, 3 werden wohl keinen Zusatzcache mitbringen. Da tippe ich neben ein paar WMMA Features von RDNA4 (vermutlich aber keine Matrix Cores, nur FP8-Support) eher auf schnelleren LPDDR5X und interne Bandbreitenoptimierungen von RDNA4 (out-of-order memory access, dynamic register allocation, central compression/decompression).

Was wohl fehlt bei RDNA4m sind irgendwelche anderen Anpassungen auf SIMD-Seite, wie erwähnt die Matrix-Cores sowie die stärkeren RT-Cores.

robbitop

2026-03-30, 10:31:15

Ich bin überrascht, dass sie das überhaupt machen. Aber ich denke auch sie werden nur das Nötigste machen, was viel pro Transistor bringt und möglichst wenige davon frisst und/oder wenig Aufwand macht.
Da es GFX11 ist, wird sicher das meiste bleiben wie es ist. FP8 Support (inkl speedup - zumindest dann Faktor 4 ggü FP32 bzw Faktor 2 ggü FP16; wer weiß ggf sind die Matrix Units ja billig dann gibts die doch). Das mit dem out of order memory access -> selbst da bin ich skeptisch. Die RDNA3,7 SKUs scheinen ja nicht besonders viele CUs zu haben. Medusa Point laut Gerüchten nur 8 CUs - da sollte die Bandbreite wohl reichen. Halo Mini wird IMO der richtige Strix Point Nachfolger und der sollte dann hoffentlich RDNA5 bekommen mit etwas mehr L2 Cache wenigstens ^^

basix

2026-03-30, 11:58:26

Faktisch "gratis" ist das compression/decompression Zeugs, da das transparent abläuft.

Alles rund ums Memory-Access re-ordering und dynamic registers sehe ich wie du als weniger wahrscheinlich an (da mehr Aufwand). Wäre aber vermutlich auch relativ günstig hinsichtlich Chipfläche und würde Bandbreiten- und Energieeffizienz steigern.

mczak

2026-03-30, 12:14:39

Ich würde auch meinen Memory-Access Re-ordering ist doch quasi das Key-Feature von RDNA4 das die Architektur an sich wirklich schneller macht. Dürfte imho deutlich mehr kosten in der Implementierung als sowas wie ein paar Datenformate mehr zu unterstützen oder verdoppelte Ray-Box Tests. Wenn da derart tiefgreifende Aenderungen bei RDNA 3 vornimmt um das zu implementieren könnte man es wohl auch gleich sein lassen und einfach RDNA 4 verwenden.
Von daher halte ich das für weitgehend ausgeschlossen. Und wie schon erwähnt, bei bloss 8 CUs auch nicht wirklich nötig. Man hat mit 8 CUs auch gar nicht den Anspruch da irgendwie mit den schnellsten (mit "normalem" 128 bit SI) IGPs zu konkurrieren, das sollte einfach eine "gut genug" IGP für Feld-Wald-Wiesen Notebooks sein, reicht ja auch locker aus um z.B die 4 Kern Xe3 zu schlagen oder auch die 860M von Kracken. Ist dann halt im Allgemeinen höchstens Strix Point Niveau, macht aber nichts weil es eben neu Halo mini gibt als High-End IGP für "normale" NBs mit 128 bit SI.

davidzo

2026-03-30, 12:59:13

Naja, was sie bei einer APU eigentlich brauchen ist MXFP4 Support und das hat auch RDNA4 nicht. Das halbiert einfach mal den Speicherbedarf für lokale AI. Dann kannst du mit 32GB schon brauchbare Modelle für den Alltag lokal betreiben (30B Modell wie zB. nemotron oder Qwen3 coder) so wie das die M4pro M4max user schon seit Jahren machen.

Die Idee das man den edge AI Case mit einer fixed function NPU abdeckt ist ziemlich tot. AMDs NPUs sind einfach zu unflexibel und liegen softwaretechnisch größtenteils brach. Je früher wir NPUs begraben desto besser, denn dann kann man sich Dinge konzentrieren die sowohl bei Gaming auch AI helfen: Bandbreite und Speichermenge.

Nvidia liegt da seit über einem Jahr schon mit Blackwell und nativer NVFP4 Verarbeitung vorne. Glück für AMD dass man in dem Preisbereich bisher meist nur Meteor-/Arrowlake + Ampere und Lovelace als Konkurrenz hat. Das hat sich aber mit Pantherlage und Xe3 bereits für den Gamingmarkt geändert und mit N1X und N1 kann nvidia die Daumenschrauben im mobile Workstationbereich anziehen.
Vs Pantherlake fehlt ein größerer LLC cache und Bandbreiteneffizienz, vs GB10 fehlt die Halo Version und MXFP4 support.

Da hat AMD imo dringend Nachholbedarf, insbesondere wenn man bedenkt dass Medusa en gros erst in 2027 shipped und auch 2028 AMDs wichtigstes Angebot sein soll.

robbitop

2026-03-30, 13:09:47

Mein Reden mit der NPU. Verschwendete Fläche -> besser über die Tensor Cores laufen lassen. (wobei ich vermute, dass das bei Medusa Point noch erhalten bleibt)
Ich würde aber aufgrund der IP Nummer (GFX1170) nicht so viel erwarten und es ist auch nur eine kleine APU (8CUs spricht eher für einen Krackan Nachfolger). Da braucht es vieles nicht besonders üppig. FP8 support mit speedup.

Der_Korken

2026-03-30, 13:24:42

reunion

2026-03-30, 13:26:14

Die Idee das man den edge AI Case mit einer fixed function NPU abdeckt ist ziemlich tot.

Wie kommt man zu einer solchen Schlussfolgerung? Die Idee, dass Apple, Google, Qualcomm, AMD, Intel, etc. große Siliziumflächen in kosten-sensiblen Bereichen für NPUs opfern, wenn diese Technologie nicht deutlich überlegen ist, ist schon ziemlich absurd. Die Vorteile der NPUs sind evident: Energieeffizienz, Niedrige Latenz, wesentlich mehr Performance pro TOPS und pro Fläche bei Inference. GPUs sind vor allem für Training geeignet. Klar muss man die NPUs softwareseitig nutzen, aber das ist nur eine Frage der Zeit. Ohne Hardware gibt es eben keine Software.

basix

2026-03-30, 15:31:30

Naja, was sie bei einer APU eigentlich brauchen ist MXFP4 Support und das hat auch RDNA4 nicht. Das halbiert einfach mal den Speicherbedarf für lokale AI. Dann kannst du mit 32GB schon brauchbare Modelle für den Alltag lokal betreiben (30B Modell wie zB. nemotron oder Qwen3 coder) so wie das die M4pro M4max user schon seit Jahren machen

XDNA2 kann bereits FP8 und dazu noch MXFP6 mit doppeltem Durchsatz wie FP8. MXFP4 wird mit MXFP9 emuliert, kann man also schon nutzen (einfach "nur" FP8 / MXFP9 Durchsatz). XDNA3 wird da definitiv natives MXFP4 nachrüsten.
https://docs.amd.com/r/en-US/am027-versal-aie-ml-v2/AIE-ML-v2-Architecture

Wird bei sowas auch Speicherplatz (und somit auch Bandbreite) verschwendet? Könnte man das nicht einfach trotzdem in FP8 berechnen und wieder auf FP4 runtercasten? Oder kostet das Casten von nicht-nativ unterstützten Formaten dann soviele Operationen, dass es eh völlig sinnlos wäre?
Jo, kann man emulieren (siehe meine Antwort oben)

davidzo

2026-03-30, 16:02:31

Wird bei sowas auch Speicherplatz (und somit auch Bandbreite) verschwendet? Könnte man das nicht einfach trotzdem in FP8 berechnen und wieder auf FP4 runtercasten? Oder kostet das Casten von nicht-nativ unterstützten Formaten dann soviele Operationen, dass es eh völlig sinnlos wäre?
Das wird ja auch gemacht, kostet aber Leistung, da du quantisieren und dequantisieren musst sowohl für die Aktivierungen als auch Gewichte selbst. Das geht auf die Registerbandbreite und Akkumulationslogik und kann die Gewinne durch den geringeren Bandbreitenbedarf auffressen sodass FP8 auf solcher Hardware sogar schneller ist solange der Ram reicht.

Int4 ist sogar noch etwas kleiner im Speicher als MXFP4, taugt aber weniger, weil das Vorzeichen fehlt bzw. Exponent und Mantisse nicht so flexibel verteilt werden können.

Aber der Punkt von MXFP4 und NVFP4 ja nicht einfach weniger Genauigkeit, sondern fast die gleiche Genauigkeit bei leicht komplexerem scheduling und leichtem Overhead zu erreichen wie FP8 bzw. FP16 oder 32.

Schon bei Int8 hat man die Gewichte vorsortiert und mit einem zusätzlichen E8M0 Skalierungsfaktor pro Block versehen, womit man im Prinzip INT32 Dynamik und 16bit Genauigkeit erreicht. Schlecht ist halt wenn du dann einen Outlier hast der dir die ganze Abtastung für den ganzen Block verreißt (in der Regel 128 weights).

Stell dir das ungefähr so vor wie Color Banding / clipping beim 3D Rendering. Wenn du z.B. HDR dynamisch mit rechnerisch nur 8bit Farben pro Kanal umsetzen willst, dann kommt es zu Colorbanding sobald du extreme hell/dunkel kontraste hast.

Microscaling und Floating point ist deswegen besser weil einerseits die Blöcke mit gleichem Skalierungsfaktor nur noch 32 Werte umfassen und andererseits mit E5m2 und E4m3 auch zwei verschiedene Formarte für unterschiedlichen Dynamikbereich zur Verfügung stehen. Das Color clipping wäre hier also nur sehr lokal in einzelnen Texturen/Effekten und nicht im ganzen Bild.

Allerdings ist sowohl Block scaling als auch Microscaling aufwändig auf Software- / Compilerebene und eben nur so gut wie die Umsetzung.

MI350X hat OCP Microscaling für 32er Blocks mit MXFP8/4 in Hardware. Das heißt die Umrechnung kostet keinen Overhead und sie können mit kleineren Blöcken arbeiten was die Auslastung erhöht. RDNA4 ist afaik nicht auf demselben Niveau wie CDNA4 weil man WMMA ALUs von Navi anders verschaltet sind.

Blackwell geht aber noch einen Schritt weiter weil man mit NVFP4 16er Blocks unterstützt und der Skalierungsfakotr nicht Integer sein muss (E8M0) sondern auch FP8 sein kann (E5m3). Zudem gibt es noch einen dritten hierachischen Skalierungsfaktor der global angewendet werden kann. Praktisch bekommst du also mit 4bit eine Dynamik und Genauigkeit die nah genug an 32bit ist, aber mit der 7 bis 8 fachen Performance.

Der_Korken

2026-03-30, 16:36:30

Danke für die Erklärungen. Ich hatte mich mit diesen Mini-Datentypen noch nie näher beschäftigt, vor allem dass da noch blockweise Skalierungsfaktoren und solche Späße benutzt werden. Ich dachte einfach, dass die Größe und Struktur des NN einfach so viel mehr bringt als präzisere Aktivierungen, dass dort mit so absurd kleinen Formaten gerechnet wird. Dass die "Emulierung" von kleineren Datentypen keine Geschwindigkeitsvorteile bringt, sondern eher Performance kostet, das hatte ich schon erwartet. Ich hatte deine Aussage über den Speicherbedarf zuerst so gelesen, als wären Chips, die ein kleines Format nicht unterstützen, gezwungen die größeren Gewichte bereits im Speicher vorzuhalten. Ich hatte neulich erst überlegt, mal lokale Opensource-Modelle zu testen und da ist die Größe des VRAMs der limitierende Faktor. Der Performance-Verlust in den RAM zu gehen ist da natürlich gewaltig. Aber ich merke schon, ich schweife etwas vom Topic hier ab ... :redface:

latiose88

2026-03-30, 18:09:04

So so es gibt im unteren Bereich also fast keine weiter Entwickelung. Naja AMD hat es ja nicht nötig weil sind ja bei. Zen 6 auf die größeren CPUs anvisiert. So gesehen gibt es da fast keine Marge bei so was kleinen. Darum wird es auch wenn nur mini Updates geben.

davidzo

2026-03-30, 19:27:24

Wie kommt man zu einer solchen Schlussfolgerung? Die Idee, dass Apple, Google, Qualcomm, AMD, Intel, etc. große Siliziumflächen in kosten-sensiblen Bereichen für NPUs opfern, wenn diese Technologie nicht deutlich überlegen ist, ist schon ziemlich absurd. Die Vorteile der NPUs sind evident: Energieeffizienz, Niedrige Latenz, wesentlich mehr Performance pro TOPS und pro Fläche bei Inference. GPUs sind vor allem für Training geeignet. Klar muss man die NPUs softwareseitig nutzen, aber das ist nur eine Frage der Zeit. Ohne Hardware gibt es eben keine Software.

Ich bin da ganz bei dir. Das habe ich auch immer geglaubt dass fixed function hardware ideal für inferencing ist.

Aber nach drei Jahren (Ryzen 7040: Januar 2023) und immer noch keinem einzigen Modell dass in LM-Studio, Pytorch, Llama.cpp, Ollama auf einer NPU läuft, verliere ich die Hoffnung dass das überhaupt geht.
Es gibt genug GGUF Modelle, MLX Modelle in jeder erdenklichen Vorquantisierung, aber kaum welche für AMD NPUs?
Intel ist da zwar etwas weiter mit IPEX-LLM, aber viel Hoffnung habe ich auch da nicht, weil halt Intel.

AMD hat zwar ein paar absolute Billo (=mini) LLMs auf Huggingface gestellt die das ONNX Format benutzen und die NPU nutzen sollen, aber so wie ich das verstanden habe macht die NPU da nur den Prefill und die GPU weiter das ganze Decoding.
Scheinbar fehlt es der NPU an den Operatoren die man bräuchte und die GPU ist im Endeffekt doch viel schneller.

Für sowas wie Whisper und Visuelles tracking kann man die NPU nutzen, aber für LLMs sieht es nicht so aus als wenn es jemals der fall sein wird.

mboeller

2026-03-31, 11:57:41

Die Idee das man den edge AI Case mit einer fixed function NPU abdeckt ist ziemlich tot.

das Memo haben wohl nicht alle bekommen:

https://www.notebookcheck.com/HC1-Effizienter-Chip-deklassiert-jede-GPU-bei-lokaler-KI-Beschleunigung.1261928.0.html

zeigt schön die Vor- und Nachteile des Ansatzes (funktioniert nur mit Llama 3.1 8B)

robbitop

2026-03-31, 12:03:03

Der Talaas HC1 ist dabei nicht nur auf die Beschleunigung von KI-Modellen insgesamt beschränkt, sondern sogar auf ein spezielles Modell, konkret Llama 3.1 8B und damit ein tendenziell kleines Modell.
Das scheint der Preis zu sein mit dem das bezahlt wird. Wenn das stimmt, ist das gar kein sinnvoller Vergleich weil es nur für ein spezifisches Modell genutzt werden kann.

davidzo

2026-03-31, 12:20:24

das Memo haben wohl nicht alle bekommen:

https://www.notebookcheck.com/HC1-Effizienter-Chip-deklassiert-jede-GPU-bei-lokaler-KI-Beschleunigung.1261928.0.html

zeigt schön die Vor- und Nachteile des Ansatzes (funktioniert nur mit Llama 3.1 8B)

Sorry, das ist völlig out of context. Die Rede war davon dass AMDs integrierte NPUs bisher Verschwendung von Sand sind. Es wäre imo besser wenn AMD die GPU aufbohrt dass sie Microblockscaling MXFP4 beherrscht.
Dein Link hat nichts mit AMD XDNA zutun.

Im übrigen zeigt auch der Link was die Limits von Asics sind: Ja, du kannst Modelle drauf laufen lassen und damit gigantische Mengen Text auf einem geistig eingeschränkten level heraus hauen. Aber für die interessanten Modelle fehlt der Speicher und die Speicherbandbreite.

Decoding ist schon immer ein Task der weniger an der Rechenleistung hängt sondern vor allem an der Speicherbandbreite. Da helfen einem auch große SRAM Caches nur wenig, da die nur einen Bruchteil der Gewichte rein passen. 192bit Speicherinterfaces wie bei Qualcomm X2 Elite oder gar 256bit wie bei AMD, Apple und Nvidia GB10 sind hier die sinnvollere Lösung für lokale AI.

Sicher haben Asics Vorteile weil sie die Rechenwerke mit mehr Density packen können. Und wenn Cerebras irgendwann mal genug SRAM auf einen cutting edge Wafer packt dass es für ein Modell ausreicht, dann werden die beeindruckend viel schneller und effizienter sein.
Aber solange Speichermenge und Bandbreite das Limit sind sehe ich Vorteile für die GPU weil sie flexibler programmierbar ist und nebenbei eben auch Grafik beschleunigen kann.

reunion

2026-03-31, 12:31:57

davidzo

2026-03-31, 17:16:26

IMO fehlen euch da völlig die Relationen. Es geht nicht um "ein bisschen einen Vorteil". Wir reden hier von einem Bruchteil(!) der Leistungsaufnahme. Die TOPS sind auch nicht vergleichbar, eine NPU liefert pro TOPS wesentlich mehr Performance. Real-Time Tasks kannst du mit einer GPU sowieso vergessen. Und nein das ist nicht theoretisch, Apple-, Google,- oder Qualcomm-Smartphones führen heute bereits lokale KI auf NPUs aus, nicht auf der GPU. Das der Desktop da wie üblich hinten dran ist, ist richtig. Macht aber die Technologie NPU nicht obsolet.

Solche gigantischen Vorteile sind höchstens Edge cases und in der Praxis gar nicht machbar.
Arithmetik ist bei Decoding eben nicht der Hauptverursacher des Power Draw, sondern es ist der Speicher bzw. Speicherzugriff. Bei der "Memory Wall" die AI gerade bremst geht es um die Frage von SRAM vs DRAM. Ob der in einer GPU verbaut ist oder in AISCs ist völlig egal, es geht immer um Joules per Bit beim Speichertransfer und nicht Tops an Arithmetikleistung.

Und natürlich wäre ein Modell rein in einem gigantischen SRAM am effizientesten und auch am schnellsten. Das sieht man ja bei Cerebras WSE3 und Groqs LPUs. Aber eben auch unbezahlbar. Da ist es billiger ein paar Atomkraftwerke neben die Rechenzentren zu stellen und weiterhin Beschleuniger mit DRAM zu verbauen. Entsprechend haben zwar alle großen Hyperscaler ein oder mehrere WSE3s als Spielzeuge und in der Forschung und auch nicht wenige haben einen Stack an LPUs, aber die Cloudservices laufen bei Allen außer Google dann doch auf GPUs.

Oh und btw, Tops sind Integer. Es hat sich aber herausgestellt dass das eher ungeeignet ist für reduced memory footprint AI workloads. Wir müssen also eher die Tflops vergleichen.

Für jetzige LLMs ist die Arithmetikleistung von GPUs völlig ausreichend. Schon mit GDDR7 kann man auch bei den ganz großen Modellen bedeutend schneller Decodieren als ein Mensch mitlesen kann - das ist also für den aktuellen Markt des Token streamings ausreichend und einfach parallelisierbar, bzw. in überschaubarer Zeit auch mit Desktophardware zu erledigen.

Aber das Ziel der AI startups ist ja die AGI, also die Hyperintelligenz die schlauer ist als der Mensch. Dafür muss halt um mehrere Größenordnungen schneller gedacht werden, so dass im gleichen zeitraum die Agenten, Reasoning / COT, Prototyping und Neudenken dekodiert werden können. Eine 100Token Antwort kann da gerne mal mehrere 10.000 Token intern gekostet haben.

Arithmetik wird erst dann wieder ein Bottleneck wenn man einen Weg findet wie zum Beispiel Cache / Speichermanagement mittels Compute optimiert werden kann, so dass du besser mit den paar GB einer cerebras WSE oder den paar hundert MB Cache einer AMD oder nvidia GPU auskommst.

basix

2026-04-01, 09:18:56

Taalas HC1 ist ein interessantes Konzept. HC1 ist aber auch ein 800mm2 Brummer, so klein ist der nicht. Vorteile sind: Kein DRAM und nur TSMC N6. Also insgesamt die Kosten pro Chip.

Bei Llama 8B frage ich mich allerdings wie das genau gebenchmarked wurde. Tokens/User ist nur eine Seit der Medaille. Kann HC1 nur 1x User abdecken oder 100x gleichzeitig? Für die Ökonomie in der Cloud macht das einen grossen Unterschied. Die GPUs werden eine möglichst grosse Batch-Size nutzen. Hat man lokales Inferencing für nur wenige User sind hohe Tokens/User natürlich interessant. Es wäre aber schon nicht schlecht, wenn man immerhin die Weights updaten könnte wenn ein optimiertes Modell um die Ecke käme (Modellgrösse und Architektur müsste natürlich gleich bleiben).

HC2 soll ein "Frontier Model" umsetzen, was auch immer das dann heisst.
https://www.forbes.com/sites/karlfreund/2026/02/19/taalas-launches-hardcore-chip-with-insane-ai-inference-performance/

Wenn man "Weights to Chip" wirklich in 2 Monaten hinkriegt, könnte das auch für Frontier Models wirklich interessant sein:
https://imageio.forbes.com/specials-images/imageserve/699689f5070dd21455f408f8/Taalas-will-deliver-superfast-AI-in-standard-server-chassis-/960x0.jpg?format=jpg&width=1440

Hier noch ein Vergleich zum Throughput und Kosten:
https://imageio.forbes.com/specials-images/imageserve/698e2f299c4682f997ce113a/Taalus-economics-could--over-time--reshape-the-industry-/960x0.jpg?format=jpg&width=1440

reunion

2026-04-01, 10:43:54

22. Juli kommt höchstwahrscheinlich Zen6 EPYC / Instinct 500
https://www.amd.com/en/corporate/events/advancing-ai.html

Der_Korken

2026-04-01, 13:07:40

Ob es auf der Computex wohl Infos zu Consumer Zen 6 geben wird? Wenn im Juli erst das AI-Gedöns kommt, wohl eher nicht ...

rentex

2026-04-01, 17:40:01

Ob es auf der Computex wohl Infos zu Consumer Zen 6 geben wird? Wenn im Juli erst das AI-Gedöns kommt, wohl eher nicht ...

...glaub ich ebenfalls nicht. Der Fokus liegt auf KI.

horn 12

2026-04-01, 18:21:46

und dann wirklich erst CES 2027 mit Launch im Februar, März 2026 für Zen 6 Desktop

rentex

2026-04-01, 20:26:02

März 2027...Herbst 27, wenn das mit dem CPU Bedarf und dem Rohstoffmangel so weitergeht.

reunion

2026-04-05, 10:47:47

IPC: CYC>Zen6
clock: Zen6>CYC

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

Ob das glaubwürdig ist? Ka. Aber der Typ hat keinen so schlechten track record.

Der_Korken

2026-04-05, 11:26:37

Ich lese gelegentlich im Anandtech-Forum mit und dort wird CYC nach aktuellem Stand ein superbreiter Kern mit 12-wide clustered decode. Da Zen 6 nur ein Tick mit vllt. +10% IPC wird, dürfte es für Intel keine Kunst sein sich vor Zen 6 zu setzen. Die Frage ist nur, was Intel dafür alles bezahlt, insbesondere auch beim Verbrauch.

reaperrr

2026-04-05, 17:05:30

Ich lese gelegentlich im Anandtech-Forum mit und dort wird CYC nach aktuellem Stand ein superbreiter Kern mit 12-wide clustered decode.
Das muss nicht zwangsläufig bedeuten, dass die IPC massiv steigt bzw. massiv stärker steigt als bei Zen6.

Zen4 hatte nur einen einzelnen 4-wide Decoder.
Zen5 hatte "clustered" 8-wide (2x4) Decode und 50% mehr INT pipes, trotzdem in manchen Bereichen keine 10% mehr reale IPC.

Weder Zen5, noch Golden/Raptor Cove mit 6-wide Decoder, noch Lion Cove mit 8-wide Decoder hatten wesentlich mehr reale IPC als Zen4.

Zen5 ist im Integer-Bereich z.B. relativ stark durch den relativ schmächtigen 240-entry IntegerPRF ausgebremst.
Wenn AMD den diesmal kräftig aufgebohrt hat (da sie im FPU-Bereich diesmal nicht mehr viel machen mussten, weil Zen5 den FPU-Bereich mit vollem AVX512 und verdoppeltem FP_PRF schon massiv aufgebohrt hat), kann die Integer-IPC-Steigerung von Zen6 in der Praxis recht hoch ausfallen, obwohl sie dafür gar nicht so wahnsinnig viel Transistoren einsetzen müssen.

Ich rechne zwar schon damit, dass NVL/CYC bei der IPC insgesamt ein größerer Schritt wird als Zen6, aber bei Intel wird das seit Ice Lake auch regelmäßig mit starkem Transistor- und Stromverbrauchszuwachs erkauft, also erstmal abwarten, was das für die Taktraten bedeutet.

Und ob der bLLC von den Latenzen mit AMD's X3D mithalten kann, muss man auch erstmal sehen.

Der_Korken

2026-04-05, 17:31:32

Zen 5 hat zwar doppelt so viele Decoder, kann sie im ST-Betrieb aber nicht nutzen. Chips and Cheese hatte mal einen witzigen Test, wo sie es geschafft haben auf Zen 4 und 5 jeweils den µOp-Cache abzuschalten. Mit einem Thread hat Zen 5 dadurch ordentlich Durchsatz verloren, weil die 4 Decoder anscheinend zu schwach sind. Mit zwei Threads auf dem gleichen Kern war der Durchsatz zwischen µOp an und aus dann fast wieder gleich. Zen 4 hatte mit nur vier Decodern auch im ST-Betrieb keine Probleme. Die verdoppelten Decoder scheinen also auch Nachteile gebracht zu haben.

Bei den INT-Pipes sind es auf dem Papier zwar 50% mehr, aber nur wenn man die dedizierte Branch-Pipe weglässt, die es bei Zen 3/4 gab. Wenn das Verhältnis INT:Branch bei maximal 4:1 liegt, können Zen 3/4 also bereits 5 Instruktionen pro Takt. Da sind die 6 von Zen 5 nicht so viel mehr, wobei sie flexibler verteilt werden können. Mit den INT-Registern hast du natürlich vollkommen recht und ich hoffe auch, dass die Wald- und Wiesensoftware diesmal mehr profitiert als die ganzen AVX-Cruncher. Der FP-Register-Block sieht zu den anderen Architekturen eher wie ne GPU als ne CPU aus.

Was hingegen bei Intel schief gelaufen ist, würde ich auch gerne mal wissen. Sunny Cove und Golden Cove haben jeweils schon noch ordentliche Sprünge geschafft. Eventuell ist das so eine Art "Netburst-Problem", wo jede Taktsteigerung durch längere Pipelines erkauft wurde, die zu einem Performance-Verlust geführt hat, die wiederum durch noch mehr Takt ausgeglichen werden musste. Irgendwann steigt die Performance dadurch effektiv nicht mehr. Bei Lion Cove fühlt sich das so ähnlich an, nur dass eben eine breitere Architektur über höhere interne Latenzen erkauft wurden. "Gefühlt" deswegen, weil ich für die höheren Latenzen keine Belege habe.

Eventuell laufen die x86-Architekturen hier auch in ISA-Wände durch das 16-Register-Limit und das Fehlen von conditional instructions, die mit APX kommen sollen. Einen Grund muss es ja haben, dass sowohl Intel als auch AMD sich so lange vor breiteren Architekturen gedrückt haben, während Apple und QC da schon vor Jahren viel weiter waren. In dem Fall wäre Coyote Cove natürlich eine Wette, dass sich APX schnell überall durchsetzt. Zen 6 wird es ziemlich sicher noch nicht haben.

davidzo

2026-04-05, 20:31:34

IPC: CYC>Zen6
clock: Zen6>CYC

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

Ob das glaubwürdig ist?

Dazu braucht man keine Glaskugel.
Das entspricht sowohl dem aktuellen status quo, als auch dem Trend der letzten 5+ Jahre. Außerdem sagen auch die früheren Leaks zu Zen5 und Zen6 dass sich die IPC Steigerungen in Grenzen halten, aber der Takt massiv ansteigt.
Es wirkt nicht so als wenn die Aussage auf basis neuer Informationen getroffen wurde.

Ich lese gelegentlich im Anandtech-Forum mit und dort wird CYC nach aktuellem Stand ein superbreiter Kern mit 12-wide clustered decode. Da Zen 6 nur ein Tick mit vllt. +10% IPC wird, dürfte es für Intel keine Kunst sein sich vor Zen 6 zu setzen. Die Frage ist nur, was Intel dafür alles bezahlt, insbesondere auch beim Verbrauch.

Gibt es zu dem 12wide Quellen oder ist das eigene Spekulation?
- Lion und Cougar sind 8 wide. Ist das nicht ein wenig unrealistisch dass Intel hier so in die Vollen gehen würde und 9, 10wide überspringt?
- Außerdem verdoppelt man eh mal eben die Kerne pro Sockel.
- Gleichzeitig verachtfacht man den LLC bei den Flaggschiff Modellen.
- Mit AVX10.2 und APX Instructions hat man eigentlich schon genug Architekturveränderungen für eine Generation zu bieten
- coyote cove wird der letzte Aufschrei vom Intel haifa team sein bei dem schon seit Langem stellen abgebaut wurden. Dass man hier nochmal fundamental neue building blocks verwendet ist unwahrscheinlich, wird doch in Zukunft der unified core vom Austin Team gemacht auf Basis aufgebohrter E-Kerne. Dass ausgerechnet hier ein extrem komplexer 12-wide x86 decoder debütieren soll finde ich suspekt.

Dabei verbessert sich die Density laut TSMC nur um rund 20% von N3 auf N2.
- Es würde besser zur Strategie passen wenn Intel die P-Cores deshalb entschlackt und nicht noch weiter vergrößert. Die 4MB shared L2 für je 2 Cores anstatt je 3MB privater Cache beim Vorgänger sehen auch eher nach Schonkost aus als nach einem massiv verbreiterten Design. - Der neue gesharte L2 Cache wird auch kaum bessere Latenzen haben wegen Arbitrierung, Kohärenz overhead und in MT die schlechtere Hitrate durch cache contention zwischen den cores. Wieso sollte man also den Core aufbohren wenn man den L2 Cache schlechter macht?

Darkmont hat relativ kompakte 3x3wide Decoder und sogar 3x4 sind im Gespräch für künftige E-Cores. Ich kann mir eher vorstellen dass man den 8-wide decoder von cougar cove also durch ein einfacheres 3x4 Austin Design ersetzt das im Vergleich eher an Diefläche spart.

Die Diefläche spricht gegen gigantisch breite Cores bei Coyote Cove.
Es sei denn man wechselt gleichzeitig von HP Libraries auf HD. Das würde einiges an Takt kosten, aber auch massiv Density bringen. Das wäre aber ein sehr riskanter move und für Intels Desktop Strategie sehr untypisch.

basix

2026-04-05, 20:45:32

12-wide Decode empfinde ich jetzt nicht als so weltbewegend. Skymont und Darkmont sind bereits 9-wide (3x 3 cluster) und dabei deutlich kleiner als Lion/Cougar Cove.

CYC könnte also 3x 4-wide Decoder bringen.

Der_Korken

2026-04-05, 20:50:28

@davidzo

Ich habe mal in deren Nova Lake Thread ein paar Seiten zurückgescrollt und die 12-wide-Spekulation taucht ziemlich aus dem nichts auf. Entweder ist der Leak dafür schon länger als einen Monat her oder ist einfach nur die typische adroc_thurston- aka Bondrewd-Spekulation. Der tut immer so, als würde er schon super viel wissen und deutet dann Dinge an ohne konkret zu werden. Der ist in meinen Augen ziemlich AMD-biased und hat mit RDNA3 und Zen 5 jeweils ordentlich ins Klo gegriffen.

Prinzipiell sehe ich es ähnlich wie du: Intel braucht nicht noch breitere Kerne, sondern muss erstmal das vorhandene Potenzial heben. Genauso passen solche großen und entsprechend durstigen Kerne nicht ins Bild des Dual-Compute-Dies, sofern Intel keinen 500W-Sockel launchen will. Eine Erklärung für den shared L2 könnte aber sein, dass das fehlende SRAM-Scaling sonst zu sehr reinhaut. Für die Peak-ST-Leistung könnte das sogar vorteilhaft sein, weil ein Kern jetzt 4MB L2 nutzen kann.

latiose88

2026-04-05, 22:48:28

hm ok,es mag zwar nur 10 % sein,für mich werden es wenn alles gut geht 25% sein.Warum die Zen 5 mit breiter und AVX 512 hat wirklich keinerlei wirkung gezeigt.Ich selbst durfte einen 9950x testen.Ob nun 4,8 oder durschnitt 5 ghz,das sppielt keine Rolle.Der Vorgänger war ja auch so um die 5 Ghz gewesen.Wenn beim 9950x und 7950x das selbe Ergebnis dabei raus kommmt,bei gleichen Takt,dann weis man ok IPC hat nicht gewirkt.Bei beiden ohne AVX 512.Das scheint wohl die größte Änderung zu sein bei beiden.
Ich hatte gehofft das sich Zen 5 sich von Zen 44 abheben könne.Ich habe scheinbar eine Anwendung erwischt oder die falschen Einstellung um davon zu Profitieren.
Ich hoffe die Bremse wird gelöst das sich diese Entfalten kann.Dadurch werden die 15% dank Zen 5 zu den 10% bei Zen 6 eben zusammen gebracht.

Das Zen 5 garkeine Steigerungg gab,stimmt jedoch nicht.Was es heißt IPC Steigerung sieht man bei mir gut zwischen Ryzen 7 7700x und Ryzen 7 9700x.Da scheint die 15 % richtig rein zu hauen.
Wenn also Zen 5 nur teilweise eine wirkung zeigt bei den 6 und 8 Kerner aber bei den 12 und 16 Kerner nicht,kann es nur eines heißen.Es bremmst die Latenz oder was anderes.
Ich hoffe das damit das Porblem gelöst ist.
Und 25 % mehrleistung + rund 800 mhz mehr Allcore Takt,das haut ganz sicher rein.
Das würde ich schon spüren.Ich kann es ja ganz leicht ausrechnen,wo dann der 12 Kerner ungefähr landen wird.Es wäre beeindruckend wenn es so wäre oder noch beeindruckender bei übertreffen.Das warten wird sich also lohnen.

Skysnake

2026-04-06, 06:58:01

Also die aktuellen AMD Server CPUs wischen mit Intel den Boden. Egal wohin du auch schaust. Bei Peak haben die Intels noch nen Vorteil, aber innerhalb echter Anwendungen verpufft das überwiegend und wird dann ganz oft zu nem Rückstand.

Die AMD Kerne sind verdammt gut das single Core Leistung anbelangt. Insbesondere beim Memory Theoughput. Die sind da Faktor 1.5 bis 2 schneller als die Intel Server CPUs. Das ist echt massiv.

So lange AMD den Abstand behält wird Intel nicht an AMD vorbei kommen.

dildo4u

2026-04-06, 08:00:52

Ist das aktuell nicht fast egal da der KI Ausbau alles aufkauft was produziert wird Intel soll die Letzen Monate angeblich mehrmals die Preise erhöht haben.

https://www.techpowerup.com/347984/intel-reportedly-planning-another-cpu-price-increase-in-may-amid-massive-demand

robbitop

2026-04-06, 08:34:41

Ich bin sehr skeptisch für mehr Breite bei den Decodern und beim Backend bei x86. Das hat in den letzten Jahren asymptotisch kleine Gewinne bei x86 pro Thread gebracht. Und ob man wirklich in signifikanten Anteilen der Zeit mehr als 8 Instructions pro Thread bekommt und das auch noch ein bottleneck sein soll. Das verbrät man potenziell Transistoren für winzige Gewinne.

basix

2026-04-06, 09:48:42

Skymont und Darkmont haben keinen uOp-Cache, deswegen machen dort breitere Decoder schon Sinn.

Wenn Intel hier beim Decoder in die Breite geht und den L1i vergrössert (und allenfalls de uOp-Cache weglässt oder zumindest verkleinert), geht man vom Aufbau her in Richtung ARM.
Was noch fehlt ist ein grosser L1d-Cache. Intel hat hier mit 48kB L1.0 und 192kB L1.5 aber bereits einen "Workaraound" verglichen mit den 128kB bei z.B. Apple M4.
Die 4MB shared L2 sind auch eine Annäherung an ARM (Apple hat hier allerdings 16 MByte).

robbitop

2026-04-06, 09:58:33

Ja aber die dicken P Cores hatten breite decoder und uPp Cache. Hat hinten raus alles super wenig gebracht. Was ja irgendwie auch Sinn macht denn jeder Thread hat eine begrenzte Menge an ILP die man rausquetschen kann. 12 fach wirkt auf mich ziemlich OP wenn man wahrscheinlich im Schnitt bei einem Bruchteil der instructions per cycle pro Thread liegt. Wo liegt man da gerade im Schnitt 2 oder 3? Vor ~20 Jahren war es knapp über 1 ^^

basix

2026-04-06, 10:37:19

Wie gesagt, Intel könnte beim uOp-Cache zurückfahren. Dann sieht das mit den breiten Decodern wieder anders aus. AMD ist auch von einem 4-wide zu 2x 4-wide Decoder hochgefahren. Die machen das nicht nur zum Spass ;)

robbitop

2026-04-06, 10:50:49

Sagt man so. Trotzdem waren die Fortschritte winzig. Resultate > Theorie. ;)

Der_Korken

2026-04-06, 12:01:31

Die AMD Kerne sind verdammt gut das single Core Leistung anbelangt. Insbesondere beim Memory Theoughput. Die sind da Faktor 1.5 bis 2 schneller als die Intel Server CPUs. Das ist echt massiv.

Wie ist das mit der Single-Core-Leistung gemeint? Also wirklich Szenarien, wo die Software viel zu wenig Threads generiert und nur ein Bruchteil der Kerne laufen? Ich hätte gedacht, dass die Effizienz weiterhin der Dealbreaker ist, weil bei Intel der Takt komplett wegbricht bei voller Last. Zumindest war das der Zustand seit Zen 2, wo AMD bei gleichem Verbrauch locker doppelt so viele Kerne gebracht hat, die auch noch deutlich mehr Takt geschafft haben. Da war das im CPU-Limit gerne mal Faktor 3. Allerdings noch TSMC N7 vs Intel 14nm++ bzw. 10nm vanilla.

Skymont und Darkmont haben keinen uOp-Cache, deswegen machen dort breitere Decoder schon Sinn.

Wenn Intel hier beim Decoder in die Breite geht und den L1i vergrössert (und allenfalls de uOp-Cache weglässt oder zumindest verkleinert), geht man vom Aufbau her in Richtung ARM.
Was noch fehlt ist ein grosser L1d-Cache. Intel hat hier mit 48kB L1.0 und 192kB L1.5 aber bereits einen "Workaraound" verglichen mit den 128kB bei z.B. Apple M4.

Das mit dem µOp-Cache ist mir bis heute nicht klar. Er erhöht natürlich den Instruktions-Durchsatz ohne sich an die teuren Decoder ranzutrauen. Aber ich dachte immer, dass er auch die Pipeline verkürzt, weil der Lookup viel schneller geht als einmal durch den L1I und die Decoder zu laufen. Selbst wenn die Decoder genug Durchsatz hätten, hätte ich allein durch die kürzere Recovery bei Branch Mispredictions schon deutlich mehr Performance erwartet. Trotzdem verzichten Intels E-Cores und alle ARM-Cores darauf.

Was den L1D angeht, werden wir erst dann echte Verbesserungen sehen, wenn endlich mal die Pagesize angehoben wird. Das würde nicht nur beim L1D helfen, sondern überall, weil so ein 48MB großer L3, wie Zen 6 ihn haben soll, mittlerweile 12K Seiten groß ist bzw. mit 3D-Cache sogar 36K Seiten. Das ist so viel mehr als ein einzelner Kern in seinem TLB halten kann, dass ich mich schon gefragt habe, ob größere CCXs überhaupt noch was bringen.

Ja aber die dicken P Cores hatten breite decoder und uPp Cache. Hat hinten raus alles super wenig gebracht. Was ja irgendwie auch Sinn macht denn jeder Thread hat eine begrenzte Menge an ILP die man rausquetschen kann. 12 fach wirkt auf mich ziemlich OP wenn man wahrscheinlich im Schnitt bei einem Bruchteil der instructions per cycle pro Thread liegt. Wo liegt man da gerade im Schnitt 2 oder 3? Vor ~20 Jahren war es knapp über 1 ^^

Ich habe bis gestern nicht gewusst, wo der konzeptuelle Unterschied zwischen einem sequenziellen Decoder und einem clustered Decoder liegt. Wenn ich das richtig verstanden habe, dann nutzt man beim clustered decoding den BTB als Pivot, um die einzelnen Decoder-Blöcke an mehreren Stellen parallel anzusetzen. Das geht, weil im BTB immer gültige Sprungziele stehen, d.h. der Anfang einer Instruktion. Eigentlich ganz nett, weil ein sequentieller 8-way Decoder wie der in Lion Cove nicht nur überproportional teurer ist (eventuell sogar teurer als ein 3x4-way Decoder?), sondern auch noch unflexibler bei Branches. Vielleicht macht man den Decoder nicht wegen des Gesamtdurchsatzes so fett, sondern damit man auch bei sehr branchigen Code immer einen guten Mindestdurchsatz hinbekommt und die geteilten Decoder-Blöcke billig genug sind (Skymont hat ja auch 3x3, das hatte ich vorher gar nicht bedacht).

aceCrasher

2026-04-06, 19:31:32

In dem Fall wäre Coyote Cove natürlich eine Wette, dass sich APX schnell überall durchsetzt.
Vielleicht versuchen sie das auch selbst über APO zu forcieren? Würde gut dazu passen dass das Tool jetzt etabliert wird.

Der aktuelle Wissensstand ist dass Zen 6 nicht mit APX und AVX 10.2 kommen wird, oder? Wäre das für euch ein Grund eher Nova Lake zu kaufen? Eigentlich kaufe ich Produkte ungerne auf dem Versprechen späteren Software Supports, daran verbrennt man sich leicht die Finger.

Der_Korken

2026-04-06, 19:58:00

Nur wegen AVX10.2 und APX würde ich das nicht machen. Bis das wirklich ankommt, hat man eh schon wieder aufgerüstet. Grundsätzlich finde ich Nova Lake interessant, wenn es auch bLLC-Versionen mit nur einem Chiplet gibt und das zu gangbaren Preisen.

Prinzipiell sehe ich Zen 6 im Vorteil, weil AMD im Gegensatz zu Intel die 3nm-Karte und die Advanced-Packaing-Karte noch auf der Hand hat. Andererseits kann Zen 6 auch voll auf Server optimiert sein, d.h. noch mehr AVX512 und SMT-Betrieb statt 1T. Die 32kB L1I, die afaik in einem Venice-Leak zu sehen waren, sehen dahingehend eher nach "Zen 6%" plus Takt aus. Wobei ich nicht mit viel mehr als 6 Ghz rechne bei vertretbarem Verbrauch.

aceCrasher

2026-04-06, 20:27:18

Falls Zen 6 für den Desktop, wie du sagst, wieder nur einen geringen IPC Sprung hinlegt und nicht deutlich über 6 GHz kommt, wird es eng gegen Nova Lake mit bLLC im Gaming. Irgendwoher muss die Leistung ja kommen. Ich erhoffe mir ja noch niedrigere Speicherlatenzen durch das neue IOD.

iamthebear

2026-04-06, 21:50:40

latiose88

2026-04-06, 21:51:28

Die mich wird es nur die ein paar Einheiten wo aufgebohrt wird mit mehr allcore Takt ein plus machen .

Ich weiß jetzt schon das ich von Apx noch von ax10 ein Vorteil haben werde ,wie halt auch von Avx 512 ich nicht profitiere noch von dem extra Cache. Ich profitiere nur beim 9950x3d dank der höheren Taktraten die es teilweise erreicht und der besseren Chipgüte.
Ich profitiere nicht vom extra l3 Cache.
Ich bin mit dem 265k eh nur vom einen 9950x3d mit 5,2 GHz nur 17 % entfernt. Es wird also spannend. Was mir Zen 6 da so bieten wird. Die 5,2 GHz sind für eine Luftkühlung ne Herausforderung. Da erhoffe ich mir das zumindest bei gleichen Takt die CPU Kühler bei Luftkühlung sein wird.

Der_Korken

2026-04-06, 22:36:26

Was den Takt angeht: Ich will mal stark hoffen, dass AMD hier zumindest in den mittleren 6GHz Bereich kommt. Das sind schließlich 2 Node Jumps. Selbst 7GHz wären jetzt nicht so abwegig. Apple, Qualcomm und ARM haben bereits von N5P auf N3P schon 30% zugelegt und schlagen mittlerweile alle selbst die Highend Desktopmodelle von Intel und AMD bei der ST Performance.

Ich bin weiterhin pessimistisch. Die meisten nehmen die 5,7Ghz von Zen 5 als Basis und schlagen dann 15-20% drauf. Zen 5 säuft mit 5,7Ghz aber gefühlt doppelt so viel wie mit 5,2Ghz, was man an den hohen Verbräuchen des 9850X3D gesehen hat. Zum einen würde ich meine CPU nicht so auf letzter Rille laufen lassen, zum anderen würde ich anzweifeln, ob das in N2 überhaupt möglich ist. Die ganzen Taktgewinne der Fertigungsprozesse sind afaik ISO-Voltage, d.h. für 5,7Ghz+X% müsste ich diesen dann deutlich kleineren Kern mit 1,4V brutzeln lassen.

Wenn ich mal die realistischeren 1,2V des 9800X3D nehme, dann sind es bis 6,5Ghz schon +25% und bis 7Ghz +35%. Wo sollen die herkommen? AMD muss auf gleicher Fläche und bei gleichem Verbrauch 50% mehr Kerne durchfüttern. Da auch der Cache um 50% wächst, die SRAM-Packdichte aber nur marginal steigt, muss die Logik-Packdichte um deutlich mehr als 50% steigen, d.h. der Großteil der Prozessgewinne geht für Packdichte und Effizienz drauf. Taktgewinne von 20% und mehr sehe ich da nicht. Deswegen würde ich sagen mit moderater Spannung gehen 6,0Ghz und mit der Brechstange vielleicht 6,5Ghz, wobei ich mir da schon vorstellen könnte, dass es wegen Überhitzung der Hotspots zu Throttling kommt und man die 6,5Ghz in der Praxis gar nicht erreicht.

davidzo

2026-04-06, 23:08:18

Ich bin weiterhin pessimistisch. Die meisten nehmen die 5,7Ghz von Zen 5 als Basis und schlagen dann 15-20% drauf.

Sehe ich auch so. Solche generationellen gewinne gab es seit Zen1 nicht mehr.

Ich will nochmal an die alte geleakte Roadmap zu Zen5 Nirvana/Eldora und Zen6 Morpheus/Monarch erinnern. Die Daten zu zen4 und Zen5 haben alle gestimmt, sogar die IPC Angaben. Zen5 hatte da laut Folie 15% mehr IPC, was zwar nicht im Gaming zutrifft aber im Server/Epyc sehr wohl. Zen6 steht da mit 10% drauf.

110% IPC mal 120% Takt wären 32% Performancegewinn. Das ist etwas hoch für eine Generation bei AMD imo, gerade wenn "Zen5%" der größere Sprung sein sollte gegenüber Zen6 der eher im Corecount breiter wird.

Allerdings soll der N2P Prozess sehr wohl gut performen, unter Anderem wegen der neuen Super High Performance Metal-Insulator-Metal (SHPMIM) Kondensatoren. Die haben mehr als die doppelte performance pro Fläche wie frühere Lösungen und stabilisieren Voltage drops/spitzen innerhalb des Dies.
Allerdings geht dadurch imo eher die voltage runter bzw. Effizienz hoch und die MT Taktraten, nicht der ST Turboclock.

Ich denke 6Ghz oder 6.2Ghz im Turbo und 5,5-5,8Ghz allcore wären imo schon ein guter Zuwachs.

latiose88

2026-04-07, 00:42:48

die5,8 ghz allcore sehe ich wenn dann nur bei einem 12 Kerner,nicht jedoch bei 2x12 kerner oder sowas.Da zwei chiplet auch strom brauchen,geht da die Allcore Takt runter.Dann heißt es wenn überhaupt 5,8 ghz bei 12 Kerne vs 5,2 ghz bei 24 Kerne.Sofern das denn stimmt.
Und ja wenn es blöd läuft werden die bremsen doch nicht so gelöst,dann bekommtich niemals die Zen 5 IPC steigerung expliziet auf die 12 und 16 Kerne oben drauf bei Zen 6,wer weis wo die Bremse liegt.Das kann ich nicht sagen,ich tippe auf latenz.

robbitop

2026-04-07, 08:24:33

Die Die Size von Zen6 wird nicht spürbar größer als Zen 5, obwohl da 50% mehr Kerne und Cache verbaut sind. Das das deutet daraum hin, dass das Transistorbudget in etwa gleich ist. Da würde ich jetzt keine großen IPC Verbesserungen erwarten. Ich denke 10% allgemeine IPC in non Gaming Workloads wären hier schon ein Erfolg. Bei Spielen bringt der größere L3 (144 vs. 96MB) vielleicht noch einmal 5% zusätzlich.

Was den Takt angeht: Ich will mal stark hoffen, dass AMD hier zumindest in den mittleren 6GHz Bereich kommt. Das sind schließlich 2 Node Jumps. Selbst 7GHz wären jetzt nicht so abwegig. Apple, Qualcomm und ARM haben bereits von N5P auf N3P schon 30% zugelegt und schlagen mittlerweile alle selbst die Highend Desktopmodelle von Intel und AMD bei der ST Performance.
Nodesprünge allein bringen kaum noch Taktsprünge. Manchmal gibt es sogar Regressionen (Intels 22nm vs 32 nm, Intels 14 nm Nachfolgendes haben ewig gebraucht um an 14 nm vorbeizukommen). 5 GHz haben wir schon mit 65 nm gesehen. Vor fast 20 Jahren mit POWER6. Bulldozer mit 32 nm, Sandy Bridge (allerdings mit regurälen OC). Also als Axiom kann man das jedenfalls nicht mehr sehen.

basix

2026-04-07, 20:39:58

N2P legt ~2x Logikdichte verglichen zu N4P zu und daneben ~1.2x SRAM Dichte. Dazu kommen NanoFlex (FinFlex Nachfolger) Designoptimierungsmöglichkeiten, GAA Vorteile usw. welche in ~1.4x Speed Boost oder >2x Energieeffizienz münden. N2P ist ein riesiger Sprung gegenüber N4P.

7.0 GHz sind sicher sehr hoch gesteckt aber komplett abwegig ist es auch nicht. Vielleicht ist es sogar AMDs Ziel. AMD hat das Ziel aber nie ganz erreicht ;) z.B. bei Zen 5 sollen es 6.0 GHz gewesen sein.

Das einzige was wir wissen ist AMDs Angabe: >1.7x Performance & Efficiency bei 256C vs. 192C. Anhand der >2x was der Prozesssprung ermöglicht, sind 1.7x eine sehr gute Ausnutzung der Möglichkeiten. Vor allem wenn man bedenkt, dass auch die Taktraten steigen müssen, wenn nicht gleich +30% IPC draufgelegt werden. Peak Taktraten bei Desktop kann man sicher nicht direkt daraus ableiten, aber ein erstes Indiz ist es ja schon. Was man aber beachten sollte: 1.7x Performance wird man wohl schon erreichen aber nicht gleichzeitig 1.7x Efficiency. Ich vermute da einen anderen Betriebspunkt der CPU. Venice soll mit bis zu 600...700W TDP antreten und somit +20...40% gegenüber den 500W von Zen 5.

Der_Korken

2026-04-07, 21:42:12

Sind diese ganzen Angaben von TSMC bezüglich +x% Density oder +y% Speed nicht alle als "entweder oder" zu verstehen? Sprich: Wenn du volle 2xDensity nimmst, hast du halt 0% mehr Takt und 0% weniger Verbrauch. Über das Design lässt sich natürlich auch was rausholen, wenn man doppelt so viele Transistoren zur Verfügung hat, aber bei weitem nicht genug, um die angepriesenen Kriterien alle zu erfüllen. Ich habe keinen Zweifel, dass Venice im Datacenter-Bereich gut abgehen wird, aber im Desktop wäre ich deutlich zurückhaltender.

basix

2026-04-07, 22:05:10

Transistor Density kann man schon in etwa so annehmen, dass sich die im angegebenen Rahmen steigert. Siehe die ganzen ARM Chips in N3E vs. N5. Dort sind die Taktraten gleichzeitig auch stark angestiegen. Hier hat man mit FinFlex / NanoFlex ein Instrument zur Hand um Density zu maximieren ohne gross Performance opfern zu müssen. Was nicht gleichzeitig geht sind Speed und Energieeffizienz. Das ist klar ein entweder / oder.

Edit:
Vergleich Apple M4 zu M2 (N3E vs. N5P)
- Transistor Count = 28 vs. 20 Mrd.
- Die Size = 155mm2 vs. 145...155mm2
- Transistor Density = 1.31...1.4x
- CPU Takt = 4.47 GHz vs. 3.44 GHz (1.3x)

TSMC N3E vs. N5 v1.2 (~N5P):
- 1.3x Transistor Density (ganzer Chip) / 1.6x Logic --> Passt ganz gut
- 1.18x Speed --> M4 Cores verbrauchen einiges mehr Energie als M2 Cores, da 1.3x deutlich mehr sind als 1.18x und selbst 1.18x als Idealfall kaum je erreicht wird. Die Transistor Density beeindruckt das aber wenig

davidzo

2026-04-07, 22:26:59

Chips and Cheese hat mal die Diesize der 32C Chiplets abgeschätzt und kommt darauf dass ein Zen6C + L3 Cache slice fast genau so groß ist wie bei Zen5:
https://chipsandcheese.com/p/ces-2026-taking-the-lids-off-amds
Venice has 8 CCDs each of which have 32 cores for a total of up to 256 cores per Venice package. Doing some measuring of each of the dies, you get that each CCD is approximately 165mm2 of N2 silicon. If AMD has stuck to 4MB of L3 per core than each of these CCDs have 32 Zen 6 cores and 128MB of L3 cache along with the die to die interface for the CCD <-> IO die communications. At approximately 165mm2 per CCD, that would make a Zen 6 core plus the 4MB of L3 per core about 5mm2 each which is similar to Zen 5’s approximately 5.34mm2 on N3 when counting both the Zen 5 core and 4MB of L3 cache.

Wir wissen aber dass sich bei Zen6 in der Corearchitektur nicht soviel getan haben dürfte.
Demnach hat sich AMD bei dem Server CCD eher für die highe performance libraries von N2 entschieden, nicht die High Density oder Ultra High density auf die sich der 2x Zuwachs bezieht. Ich rechne stark damit dass das im Desktop auch so ist.

basix

2026-04-07, 22:34:36

Im Endeffekt ist Transistor-Density eine nebensächliche Metrik. Wichtig ist nur PPA und Yield ;) Und für uns Consumer allenfalls noch ST-Taktraten und dazugehörige V/f-Curve.

N2P zu N3E ist bei der Density allerdings kein grosser Sprung. TSMC gibt 1.15x an bei 1.2x Logic Density. Ein paar Transistoren mehr dürfte Zen 6 dennoch bekommen, auch wenn Cores + Cache insgesamt kleiner werden.
+10% IPC wären da ja nichtmal so schlecht, falls nur wenige Transistoren dazukommen ;)

Für uns die etwas bessere Referenz dürfte aus meiner Sicht 8C Zen 5 vs. 12C Zen 6 sein. Da steht es bei 8.32bn Transistoren bei 70.6mm2 zu angeblich 76mm2 bei Zen 6 für 12 Cores. N5P -> N3E -> N2P ist laut TSMC 1.3 * 1.15 = 1.5x Chip Density. Das passt ganz gut: 1.5x Cores und ein paar Transistoren mehr bei den Cores. Da etwas mehr Transistoren, wird der Chip leicht grösser. Zen 5c in N3E zu Zen 6c in N2P, wie es Chipsandcheese analysiert hat, passen da ebenfalls stimmig ins Bild. Interessanterweise fast perfekt (mit 1.15x Chip Density von TSMC kämen bei Chipsandcheese 1.08x Transistoren dazu; 70.6 * 1.08 = 76.2mm2 -> Punktlandung). Falls das stimmt, dass da pro CPU-Core nur im Rahmen 1.1x Transistoren dazu kommen, die IPC um das gleiche oder mehr steigt und gleichzeitig der Takt stark hochgeht (oder die Effizienz stark steigt), sieht das nach einem ganz guten Design aus.

Nightspider

2026-04-07, 23:14:16

Sind diese ganzen Angaben von TSMC bezüglich +x% Density oder +y% Speed nicht alle als "entweder oder" zu verstehen? Sprich: Wenn du volle 2xDensity nimmst, hast du halt 0% mehr Takt und 0% weniger Verbrauch.

Nein, deswegen ist die Dichte ja immer extra aufgeführt.

Nur Speed <> Power korrellieren logischerweise.

So als ob du die alte Schaltung im neuen Node shrinkst und dann diesen Part aus dem Wafer schneidest. Ob du durch die höhere Dichte mehr von diesen Schaltungen auf einen Wafer bekommst interessiert ja erstmal nicht für die Speed <> Power Angabe für den Node.

Und welche Effizienzverbesserungen -oder verschlechterungen durch zusätzliche Transistoren bei selbiger Schaltung resultieren ist ja Wurst für die Speed <> Power Angabe. Sonst könnte man ja gar keinen sinnvollen Wert angeben. Wo sollte man anfangen und wo aufhören?
Das hängt ja dann nur vom Architektur-Team ab, wie intelligent die zusätzlichen Transistoren genutzt werden. Ein Team könnte damit Wunder vollbringen und ein anderes Team könnte damit Scheiße bauen.

Deswegen gehts gar nicht anders als die Dichte als seperate Metrik aufzuführen.

basix

2026-04-07, 23:40:16

Genau.

Was man noch anmerken sollte:
Das Thema Dichte gilt primär für Chips mit ähnlichem Design-Fokus. Also Highspeed-Designs sollte man nur mit Highspeed-Designs vergleichen. Zen 5c ist natürlich kompakter als Zen 5 Classic, aber dafür auch langsamer. Das heisst jetzt noch nicht zwingend, dass die Transistordichte unterschiedlich ist, aber sehr wahrscheinlich ist Zen 5c aufgrund HD-Cells dichter gepackt. Zen 5c wird vermutlich aber auch ein paar Transistoren weglassen, welche bei Zen 5 Classic der Taktbarkeit dienen.

Zen 4c mit 16C hat 9.0bn Transistoren. Zen 4 mit 8C 6.57bn. CCD Grösse ist 73mm2 zu 70mm2. Zen 4c ist somit 1.31x dichter gepackt. Und dabei halbiert Zen 4c noch den L3-Cache pro Core. Cache, wo Transistoren am dichtesten gepackt werden.

Was man also vergleichen kann:
- Zen 5 Classic <-> Zen 6 Classic
- Zen 5c <-> Zen 6c

Hier sollte man die Transistordichte wie in etwa von TSMC angegeben steigern können. Aber das hängt auch vom Design ab. Zen 5 ist deutlich dichter gepackt als Zen 4. Der Unterschied N5 zu N4P gibt das nicht her. Da sind noch andere Designoptimierungen eingeflossen.

reunion

2026-04-08, 09:23:39

basix

2026-04-08, 10:40:38

Zen 6 bekommt ein paar AVX512 Updates (INT8 VNNI und FP16, sowie BMM). Grundsätzlich damit das komplette AVX512 Feature-Set, aber noch kein AVX10.
https://cdn.wccftech.com/wp-content/uploads/2023/07/Intel-AVX10-AVX-512-Support-P-Core-E-Core-CPUs-_1.png

AVX10, APX und ACE (letzteres mit 1/2 Durchsatz) kommen mit Zen 7.

aceCrasher

2026-04-08, 11:30:24

AVX10, APX und ACE (letzteres mit 1/2 Durchsatz) kommen mit Zen 7.Wissen wir das schon, oder ist das Spekulation deinerseits? Ich meine das auch in einem Rumor/Leak gelesen zu haben, der erschien mir aber recht neblig.

basix

2026-04-08, 11:51:28

Ist nicht ein "wissen" oder eine offizielle Bestätigung, mehr eine educated guess basierend auf Informationsschnipsel ;)

Hinweise auf ACE gibt es in geleakten Dokumenten und "New Matrix Engine" wurde für Zen 7 auch angekündigt. Ausserdem bestätigt Mark Papermaster ACE für Zen 7 genau hier: https://youtu.be/yUBzu7oTTDo?t=665

AVX10 und APX waren 2025 auf AMD Folien von Mark Papermaster zu sehen (x86 Konsortium). Damit ist jetzt nicht bestätigt, dass Zen 7 damit kommt aber ich würde das als ungewöhnlich ansehen. Zen 7 soll laut Gerüchten primär auf IPC fokussieren. Da wäre APX ein geeignetes Instrument dafür. APX und AVX10.2 sollen zudem mit Intel Nova Lake und Diamond Rapids (https://www.phoronix.com/news/Linux-KVM-Preps-Intel-APX) kommen. Da würde Zen 7, welcher später erscheint, zeitlich auch passen. APX ist für SIMD Code zudem auch hilfreich (AVX512, ACE --> ML/AI Zeugs).

https://www.techpowerup.com/342829/amd-zen-7-to-implement-avx10-and-ace-instruction-sets
https://x.com/InstLatX64/status/1989348693422858337
https://pbs.twimg.com/media/G5uUXWuXIAIVtsS?format=jpg&name=large

Nightspider

2026-04-08, 12:13:31

Blöde Frage:

Werden die auch so selten Vorteile bringen wie AVX512 ?

basix

2026-04-08, 12:20:22

APX dürfte genereller greifen, da nicht auf Vektor & SIMD Code beschränkt. Benötigt aber eine Neukompilation (aber auch keine Code Änderungen). Vorteile von APX: Höhere IPC (da schneller), Entlastung des Speichersubsystems und geringerer Stromverbrauch. Aus meiner Sicht ist APX deswegen ein no-brainer.
https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html
Intel APX doubles the number of general-purpose registers (GPRs) from 16 to 32. This allows the compiler to keep more values in registers. As a result, code compiled with Intel APX contains 10% fewer loads and more than 20% fewer stores than the same code compiled for an Intel® 64 baseline. Register accesses are not only faster, but they also consume significantly less dynamic power than complex load and store operations.

AVX512/AMX: Kommt auf deine Anwendungen drauf an. AVX2 ist ja relativ weit verbreitet. AVX512 wäre verbreiteter, hätte Intel das nicht aus den Consumer-CPUs entfernt ;) Mit Nova Lake kommt das wieder zurück (AVX10.2). Der neueste Shit für AVX512 und AMX/ACE ist ML/AI (local inferencing), was wohl immer öfters Anwendungen finden wird. Wie lange das dauern wird? Keine Ahnung.

latiose88

2026-04-08, 14:00:18

Hm ich weiß nicht wie stark mein Programm avx2 nutzt aber bestimmt so um die 5% und avx 10.2 muss das Programm erst noch unterstützen. Und das wird eines Tages geschehen mit einer neuen Version aber nicht bei mir. Das heißt es bleibt immer ein Teil der CPU auf der Strecke. Was für die Temperatur bestimmt gut ist.

mczak

2026-04-08, 15:13:58

Im Prinzip sollte Zen 6 ja AVX 10.1 unterstützen - da sind ja keine neuen AVX-512 Features mit dabei, und Zen 6 unterstützt alle "alten" AVX-512 Features, ist also bloss eine Frage des Feature Flags. Sonderlich viel fehlt auch nicht für AVX 10.2, wäre also logisch dass das mit Zen 7 kommt.

Ich schätze mal das könnte schon noch etwas dauern bis man da weite Verbreitung bei "normalen" Desktop-Apps sieht - mal abgesehen davon dass eben Feld-Wald-Wiesen Code nicht unbedingt von Vektoreinheiten profitieren kann. Weil sich das eben für die Entwickler nicht wirklich lohnt wenn fast niemand eine CPU hat die das auch unterstützt.

Aber es gibt ja durchaus auch schon Anwendungen die von AVX-512 durchaus stark profitieren (da schlägt dann auch mal ein Ryzen 9700X locker einen Core Ultra 9 285k, bei dreifacher Effizienz). Solche Anwendungen werden sicher nicht allzu lange brauchen um auch AVX 10.2 zu nutzen - gerade für AI-Kram (wenn's denn nicht über NPU / GPU läuft) sollte AVX 10.2 nochmal einen Vorteil bieten (FP8-Support).

latiose88

2026-04-08, 16:55:08

Hm wird es auch außerhalb von Avx noch Verbesserung geben weil ich was von integer also floing Point Verbesserung gelesen habe. Aber das wird sich ja noch zeigen.

basix

2026-04-08, 20:24:36

Solche Anwendungen werden sicher nicht allzu lange brauchen um auch AVX 10.2 zu nutzen - gerade für AI-Kram (wenn's denn nicht über NPU / GPU läuft) sollte AVX 10.2 nochmal einen Vorteil bieten (FP8-Support).

FP4 Support ist nicht geplant? Oder geht das dann via ACE?

mczak

2026-04-09, 12:18:17

FP4 Support ist nicht geplant?
Ist vielleicht später geplant, keine Ahnung, aber AVX 10.2 hat als neue Formate nur Unterstützung für E5M2 und E4M3.
Wobei "Unterstützung" muss man da vielleicht genauer definieren für alle Formate mit weniger als Single Precision:
- FP16 wird seit F16C Feature unterstützt (pre-AVX-512), aber nur Konversion, keine Arithmetik. Letzeres benötigt AVX512 Feature Flag FP16, das ist relativ neu (kommt bei AMD erst mit Zen6, bei intel theoretisch Alder Lake, aber wir wissen ja was damit passiert ist, sowie bei Server CPUs Sapphire Rapids).
- BF16 geht mit BF16 Feature Flag, aber auch hier nur Konversion ohne Arithmetik, mit Ausnahme eines Befehls (Skalarprodukt). Umfassende Arithmetikunterstützung kommit mit AVX 10.2.
- FP8 in Form von E5M2 (nennt intel auch BF8), E4M3 (nennt intel auch HF8), nur Konversion, kommt mit AVX 10.2. Interessanterweise gibt es keinen Befehl um BF8 in was anderes zu konvertieren, HF8 kann man nach FP16 konvertieren. Die andere Richtung geht mit beiden Formaten, ausserdem auch noch 2 weitere Befehle (Konversion von Int8 aus, mit Bias).

Wenn du es genau wissen willst: https://www.intel.com/content/www/us/en/content-details/828965/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html

Leonidas

2026-04-11, 17:35:55

Sind diese ganzen Angaben von TSMC bezüglich +x% Density oder +y% Speed nicht alle als "entweder oder" zu verstehen?

Nicht korrekt. Die Density gilt immer. Die entweder/oder-Angaben sind die zu Taktrate und Stromverbrauch. Entweder -15% Saft oder +10% Takt.

latiose88

2026-04-11, 18:52:08

Juhu danke dir für diese Info. Ich nehme mal an das AMD sich für die extra 10 % entscheiden wird. Weil nen höherer Takt sich besser verkaufen wird als auf weniger Energie. Hat mAh ja gesehen was passiert wenn man auf weniger Energie setzt,besonders bei Intel. Die Leute wollen mehr Takt sehen als sparsamere Produkte.
Und das dürfte bedeuten das bei den mit ab 12 Kerner mindestens mit 5,2 GHz allcore als Minimum sehe. Werden. Bei den maximalen sind es so 5,6 bis 5,7 GHz allcore Takt. Das wird ausreichen um sogar mit Luftkühlung noch halbwegs kühl zu bekommen. Wer mehr will braucht dann eine viel bessere Kühlung dann. Zen 6 wird echt voll spannend werden. Nicht nur breiter sondern auch schneller. Bei sparsamer geht vielleicht auch was Villeicht dann 4,8-5 GHz bei weniger Spannung. Naja wir werden schon sehen wie es weiter geht.

Ich tippe aber eher darum daß es bei 5,2 GHz bleiben wird und keine höheren Taktraten weil dann kommt wieder der Strom oder Temperatur Hammer und dann drosselt nur unnötig die CPU wieder.

Bei AMD drosselt ja schon vor dem maximalen Watt Limit die CPU. Das wäre im dem Sinne die 230 Watt kann mAh so sagen. Bei dem shrink braucht die CPU weniger Strom dann und der takt klettert dann so oder so endlich höher. Endlich kein drosseln mehr wegen zu hohen stromverbauch.
Ich weiß eigentlich sollte ja bei 200 Watt Schluss sein und alles andere ist nur extra Leistung.
Aber dennoch schade. Bei Intel ist das ja erst bei 250 Watt Schluss. Naja wie auch immer.