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

[y33H@]

Bei CB liegt der 265K in CB24 sogar vor dem 14900K, und das ist ein Parade Benchmark für SMT.

[latiose88]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[reunion]

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

Richtig. Das auch würde ich sogar streichen.

[Badesalz]

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@]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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@]

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]

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]

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.

[dildo4u]

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.

Das soll der Fahrplan bis 2028 sein.

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

[Platos]

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]

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]

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]

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]

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]

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@]

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]

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]

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]

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]

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.

[robbitop]

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]

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

[Complicated]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[Badesalz]

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]

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

[Nightspider]

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]

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]

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]

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]

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]

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]

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]

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

[ChaosTM]

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

Die CPU selbst kommt wohl mit deutlich weniger aus..

[Nightspider]

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]

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. Bleibt dann also wahrscheinlich hauptsächlich dabei dass große Zahlen sich toll anfühlen und man sich auf synthies einen runterholen kann. X-D

[Badesalz]

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]

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.

[Badesalz]

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]

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]

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]

@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]

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]

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]

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]

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.

[Badesalz]

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]

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]

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

[Nightspider]

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]

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]

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

[OgrEGT]

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]

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]

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]

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]

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]

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]

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

[mboeller]

@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]

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]

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]

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

[robbitop]

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]

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]

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]

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

[mczak]

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.

[robbitop]

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]

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]

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]

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]

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.

[Nightspider]

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]

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. ;)

[mczak]

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]

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]

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?

Mit guter Chance geht das alles in Richtung "Ryzen AI".

[Badesalz]

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

[Complicated]

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]

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]

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. ;)

Das neue I/O-Die wird wohl eine NPU bekommen und damit werden die Dinger vermutlich als Ryzen AI 500 kommen. AMD verkauft ja die kommende Strix Point Desktop Version auch als Ryzen AI 400.

[reunion]

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]

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

Wird wohl später...

[Dural]

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]

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

[robbitop]

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]

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

[robbitop]

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]

Ahh sind wir wieder beim Thema Esoterik angekommen?

[robbitop]

Scheint so.

[OgrEGT]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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@]

Epyc mit N2 und Ryzen mit N2P?

[Badesalz]

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

[HOT]

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

[y33H@]

Node ≠ Stepping

[HOT]

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

[Nightspider]

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]

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

[iamthebear]

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]

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

[w0mbat]

Fujitsu Monaka?

[Badesalz]

@wombat
Teils :tongue:

[Nightspider]

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]

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]

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]

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]

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

[amdfanuwe]

Oh, gibt es schon einen Termin dazu?

[Nightspider]

Nein