Zen 5 (3/4 nm, 2024)

[Zossel]

Wann kommt das bei ARM? Ein X4 oder dessen Nachfolger als auch die Big Cores bei Apple würden sicher davon profitieren.

Frag diejenigen die ARMs bauen.


Zudem ist es evtl. auch energietechnisch interessant, wenn man zwei Threads auf einen starken Core mapt (SMT) und einen zusätzlichen Kern schlafen legen kann. Oder ist das mehr ein Problem auf SW-Seite, dass man SMT dann halt auch beachten muss.

Telefone haben eigentlich schon lange genügend CPU-Rumms für den überwiegenden Anteil der User.

[Zossel]

Die ARM-ISA schließt SMT sicher nicht aus.

Gäbe es überhaupt eine denkbare ISA die solche Implementierungsdetails ausschließt?
Mir fällt da nix ein.

[basix]

Frag diejenigen die ARMs bauen.

War auch eine hypothetische Frage. Hier wird das wohl niemand beantworten können ;)


Telefone haben eigentlich schon lange genügend CPU-Rumms für den überwiegenden Anteil der User.
Logisch. Fortschritt und Energieeffizienz nimmt man aber immer gerne ;)

[Zossel]

Logisch. Fortschritt und Energieeffizienz nimmt man aber immer gerne ;)

Hab gerade mein 4 Jahre altes Telefon gewechselt, bis auf das schnellere rendern von OsmAmd Karten fühlt sich das neue Ding nicht anders an als der alte Klingelkasten.

[Der_Korken]

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

Danke für diese klaren Worte. Das meine ich völlig unironisch, weil ich mein Hardware-Wissen aus Foren, Artikeln und Grundvorlesungen aus dem Studium habe, während ich thematisch woanders zu Hause bin (Algorithms). Ich poste hier gelegentlich mal meine educated guesses, finde es aber gut, wenn man mir hier widerspricht, wenn meine Ideen Quatsch sind.

Ganz prinzipiell benötigt eine OoOE-CPU nur recht geringe Änderungen, um mehrere Threads zu verwalten. Und zwei Instruktionen aus zwei verschiedenen Threads sind nun mal per Definition unabhängig voneinander. Das ist also eine sehr billige Möglichkeit, mehr unabhängige Instruktionen in die Pipeline zu schaufeln (man kann sich quasi die Dependency Checks zwischen den 2 Threads in einem riesigen ROB sparen).


Dass man sich bei der ILP-Extraktion viel Arbeit sparen kann, wenn man sowieso zwei unabhängige Streams hat, ist klar. Vielleicht spricht da aus mir immer noch so ein wenig der neidische Blick rüber auf die Firestorm-Kerne von Apple, die (zumindest wenn man noch mit Zen3+ vergleicht) aus einem Kern mit 1T so viel Perf/W rausgeholt haben wie Zen3+ mit 2T. Um bei der absoluten ST-Leistung mit Firestorm mitzuhalten, muss Zen 3+ dann gegenüber dem MT-Betrieb den Takt massiv erhöhen und verbraucht in ST-Workloads dann schnell mal ein Vielfaches des Firestorm-Kerns.

Dadurch entsteht bei mir der Eindruck, dass AMD und Intel hier im Frontend-Bereich massiv hinterherhinken und den Durchsatz ihrer Kerne (der sehr wohl auf Augenhöhe mit Apple ist) nur auf die Straße kriegen, wenn sie zwei Instruction-Streams haben. Das wiederum würde aber bedeuten, dass gerade hier noch tiefhängende Früchte für z.B. Zen 5 wären, um die ST-Leistung zu erhöhen. Apple hat bisher bewusst auf SMT verzichtet und auch wenn ich absolut bei dir bin, dass ein so breiter Kern (7 INT ALUs afaik) sich dafür doch total anbieten würde, muss Apple irgendeinen guten Grund haben, das nicht zu tun. Im Zweifelsfall sehe ich Apples Kern hier als "moderner" an, weil er neuer ist, genauso wie "Zen" für mich moderner war als Intels Skylake, der eine Evolution darstellt, die bis auf Nehalem zurückgeht und bei der Effizienz immer der Zen-Evolution hinterhinkte.


In typischem Code ist die tatsächlich in der Praxis erreichte IPC (oder ILP, egal) ewig weit von dem weg, was der Kern bei optimalem Code theoretisch erreichen könnte. So ein fettes Frontend und so fette Scheduler-Ressourcen kannst Du da gar nicht sinnvoll dranbasteln, als daß das anders wird.



Irgendwo eine 5. ALU hinzuklatschen hilft eigentlich nur in irgendwelchen Cornercases, wenn die Instruktionen durch suboptimales Scheduling blöde auf die einzelnen (getrennten) Int-Scheduler verteilt sind und das dann von der Implementation billiger wird, als besseres Scheduling zu verbauen. Merke: Mehr ALUs können eventuell die Performance steigern, auch wenn vorher immer welche frei waren (also zu keinem Zeitpunkt alle Arbeit hatten). ;)
[...]
Ein breiteres Backend steigert die single-Thread-Leistung. Im Normalfall weniger, als der Kern breiter geworden ist (ein 25% breiterer Kern erhöht die Performance um weit weniger als 25%).


Hier kann ich dir nicht so ganz folgen. Das erste Zitat kann ich erstmal so hinnehmen. Aber der letzte Satz aus dem zweiten Zitat (inkl. Kontext davor) ist für mich dann erstmal ein Widerspruch, denn wenn die vorhandenen 4 ALU-Ports nicht ausgelastet wurden, dann würde ich daraus schlussfolgern, dass entweder nicht genügend Instruktionen dekodiert werden können (Durchsatz) oder es genug Instruktionen gibt, diese aber voneinander abhängen. In beiden Fällen würde doch eine fünfte ALU nicht helfen?

[latiose88]

Ich frage mich ob man eine Software also ein Programm dazu bringen kann noch mehr Instruktionen zu erstellen bzw zu erschaffen als es eigentlich so Produziert.
Und steigen die Instruktionen bei 2 Baugleichen Anwendung dadurch noch mehr oder weil diese sich so gleich sind erhöht sich die Instruktionen nicht recht viel weiter nach oben?
Ich habe keine Ahnung wie es sich da so Verhält.Ich weis nur das es ja die selben Instruktionen so sind.Und das es dann rund 40% durch das an Leistung kostet.

[davidzo]

Ganz prinzipiell benötigt eine OoOE-CPU nur recht geringe Änderungen, um mehrere Threads zu verwalten. Und zwei Instruktionen aus zwei verschiedenen Threads sind nun mal per Definition unabhängig voneinander. Das ist also eine sehr billige Möglichkeit, mehr unabhängige Instruktionen in die Pipeline zu schaufeln (man kann sich quasi die Dependency Checks zwischen den 2 Threads in einem riesigen ROB sparen).

Ich meine mal gehört zu haben dass ein zweites Registerset vonnöten ist. Und dass register gerade bei x86 einen nicht zu unterschätzenden Platz- und Energiebedarf haben, vergleichbar mit dem L1 oder einem großen ROB einer breiten OoO CPU. Sicherlich steigt auch der Druck auf das Cachesystem wenn du einen zweiten Thread beherbergst. Vielleicht neben 4K pages ein weiterer Grund wieso x86 CPUs vergleichsweise langsame caches mit hohe Assoziativität haben.

Registerfiles könnten durchaus ein Energieverbraucher der sich schlecht power gaten lässt im Gegensatz zu physischen Cores und Cache, gerade was static power angeht. Vielleicht sieht man daher bei mobile (Handy)CPUs eher noch davon ab SMT zu verwenden weil man damit rechnet dass die CPU 99,9% im Idle oder Teillast läuft.

Apples Argumentation gegen SMT ist dass es mehr Energie verbraucht und ich nehme einfach mal an dass da auch was dran ist. Es kommt halt immer auf das Vergleichszenario an. Echte Cores können sicherlich bei gleicher MT Leistung weniger verbrauchen als eine halbierte CPU mit SMT Cores (weil diese einen höheren takt benötigt).

Ein umgekehrtes Testszenario ist das was Anandtech mit dem 5950X gemacht hat: SMT off vs SMT on bei der gleichen kernanzahl. Mit SMT Off taktet die CPU 350mhz höher und der Hotspot wird auch wärmer. Das ist logisch, da 4Ghz vs 4,35ghz eben auch ein erheblicher Taktunterschied sind. Ob mehr Takt oder SMT schließlich besser performt ist abhängig vom spezifischen workload. In diesem Fall war es eindeutig pro SMT: https://www.anandtech.com/show/16261/investigating-performance-of-multithreading-on-zen-3-and-amd-ryzen-5000/4

Ich meine aber dass es bei Intel-Cores zu P4 oder Nehalem Zeiten perf/Watt Vergleiche zwischen SMT OFF und ON bei gleicher Frequenz und dort zwar die performance anstieg, aber nicht in demselben maße wie der Energieverbrauch anstieg. Und selbst das ist noch kein richtiger Vergleich um Apples Aussage zu untermalen weil eine SMT OFF gemessene CPU ja noch den Registerballast mit herum schleppt den eine SMT-lose CPU nicht benötigt.

Bei der performance per Area wird SMT sicherlich sinnvoll sein. Wenn aber performance per energy gefragt ist könnte das schon wieder anders ausfallen. Fragt sich halt wo man die Bedingungen für das Simulationsszenario setzt, bei der Chipgröße oder bei der Threadanzahl. Und der Workloadmix für den Test und Anteil an idle+Teillast spielt sicher auch eine große Rolle.

Ich bin gespannt auf Qualcomms Nuvia-Kerne und ob diese SMT nutzen werden. Nuvias Core soll ja eine Evolution der früheren Apple Cores sein, also viele sehr moderne Konzepte umsetzen. Und ursprünglich hatte Nuvia den Server/ Cloud native Markt im Visier und erst nach dem Kauf durch QC jetzt auch handys und labtops.



Die ARM-ISA schließt SMT sicher nicht aus. Es gibt ja Eigendesigns von Leuten mit einer ARM ISA-Lizenz, die SMT in ihre ARM-Server-CPU-Linie eingebaut haben, beide jeweils mit SMT4 für einen vergleichsweise schmaleren Core als Zen4).

Ich weiß nicht ob das so ein starkes Argument ist jetzt ausgerechnet eine CPU zu zitieren die am Markt ziemlich gefloppt ist und deren Hersteller damals gerade günstig von Marvell übernommen wurde. Als ThunderX2 endlich verfügbar war gab es schon Epyc Rome mit ca. doppelter Leistung und höherer Energieeffizienz. Cavium hatte es ja schon gegen den Skylake Xeon schwer.
Die echten Cloud native CPUs mit nennenswerten Marktanteilen bei den Hyperscalern waren schon eher Ampere Altra (Max) und Amazons Gravitron (2,3), beide ohne SMT und 1-2 Jahre später.


DIe primäre Zielgruppe für diese Dinger sind in erster Linie Hyperscaler, die nehmen die zusätzlichen Threads sicherlich gerne mit.
Ist das so?
Ich dachte denen geht es vor allem darum SLAs zu erfüllen und nicht maximale MT-Leistung zu präsentieren. Und dafür sind vor allem predictable latencies und performance wichtig, was du mit vCPUs auf SMT threads nicht bekommst. Echte Cores lassen außerdem im Gegensatz zu SMT threads zu mehr Guests auf einem Host zu betreiben, ein nicht zu unterschätzender Kostenvorteil.

[Complicated]

Ein 8-Core mit 16 Threads kann 128 vCPUs bereitstellen. Welchen Kostenvorteil haben Hyperscaler wenn sie auf vCPUs verzichten?

Und die Behauptung ohne vCPU mehr Guests auf den 8 Cores zu hosten, müsstest etwas erläutern in diesem Kontext.

[amdfanuwe]

Vielleicht sieht man daher bei mobile (Handy)CPUs eher noch davon ab SMT zu verwenden weil man damit rechnet dass die CPU 99,9% im Idle oder Teillast läuft.


SMT wurde damals eingeführt um die Wartezeit eines Threads bei Festplatten oder I/O Zugriff sinnvoll zu nutzen.
Spielt bei Mobile CPUs weniger eine Rolle. Zudem macht es bei Mobile auch nichts, wenn eine umfangreichere Bearbeitung der Daten mal ne Sekunde länger dauert. Sieht bei HPC halt anders aus, wenn ein Job mehrere Tage läuft.

[Zossel]

SMT wurde damals eingeführt um die Wartezeit eines Threads bei Festplatten oder I/O Zugriff sinnvoll zu nutzen.

Hüstel.

[Zossel]

Ein 8-Core mit 16 Threads kann 128 vCPUs bereitstellen. Welchen Kostenvorteil haben Hyperscaler wenn sie auf vCPUs verzichten?

Und die Behauptung ohne vCPU mehr Guests auf den 8 Cores zu hosten, müsstest etwas erläutern in diesem Kontext.

Definiere vCPU.

Selbst auf auf einer CPU mit einem Thread kann man 100 VMs starten. Ready to run Prozesse landen dann eben auf der RunQueue wenn die CPU was anderes zu tun hat.

[Zossel]

Dadurch entsteht bei mir der Eindruck, dass AMD und Intel hier im Frontend-Bereich massiv hinterherhinken und den Durchsatz ihrer Kerne (der sehr wohl auf Augenhöhe mit Apple ist) nur auf die Straße kriegen, wenn sie zwei Instruction-Streams haben.

Auf vergleichbaren Nodes?

[Zossel]

[QUOTE=davidzo;13323959]
Registerfiles könnten durchaus ein Energieverbraucher der sich schlecht power gaten lässt im Gegensatz zu physischen Cores und Cache, gerade was static power angeht. Vielleicht sieht man daher bei mobile (Handy)CPUs eher noch davon ab SMT zu verwenden weil man damit rechnet dass die CPU 99,9% im Idle oder Teillast läuft.

Sachen die man im voraus berechnet, dann aber verwirft weil sich was geändert hat kosten nun mal Energie.

Apples Argumentation gegen SMT ist dass es mehr Energie verbraucht und ich nehme einfach mal an dass da auch was dran ist. Es kommt halt immer auf das Vergleichszenario an. Echte Cores können sicherlich bei gleicher MT Leistung weniger verbrauchen als eine halbierte CPU mit SMT Cores (weil diese einen höheren takt benötigt).

Wenn ich aus einer Befehlssequenz mehr ILP ziehe kostet das auch Energie, ne ALU rechnet nicht für lau.

[Complicated]

Echte Cores lassen außerdem im Gegensatz zu vCPUs zu mehr Guests auf einem Host zu betreiben, ein nicht zu unterschätzender Kostenvorteil.

Und die Behauptung ohne vCPU mehr Guests auf den 8 Cores zu hosten, müsstest etwas erläutern in diesem Kontext.
Definiere vCPU.
Nicht meine Baustelle zu definieren was gemeint war. Ich bin auch gespannt. ;)

[CrazyIvan]

Was SMT bei Hyperscalern angeht bin ich ganz bei davidzo:
SMT wird dort größtenteils deaktiviert, um das "Noisy Neighbour" Phänomen auszuschließen - sprich, dass die benachbarte VM einem auf dem gleichen physischen Kern Leistung klaut. Und natürlich sind Sidechannel Attacken vor allem in dem Bereich weiterhin ein großes Thema - wer kann schon garantieren, dass bereits sämtliche Angriffsvektoren bekannt und behandelt sind.

[Zossel]

Was SMT bei Hyperscalern angeht bin ich ganz bei davidzo:
SMT wird dort größtenteils deaktiviert, um das "Noisy Neighbour" Phänomen auszuschließen - sprich, dass die benachbarte VM einem auf dem gleichen physischen Kern Leistung klaut. Und natürlich sind Sidechannel Attacken vor allem in dem Bereich weiterhin ein großes Thema - wer kann schon garantieren, dass bereits sämtliche Angriffsvektoren bekannt und behandelt sind.

Als billiger Jakob würde mich das nicht jucken, da will ich verkaufen, und zwar ein Vielfaches von dem was ich eigentlich herumstehen habe.

[davidzo]

Nicht meine Baustelle zu definieren was gemeint war. Ich bin auch gespannt. ;)

War doch schon beschrieben was gemeint war. Ohne SLAs sind VMs nicht ernst zu nehmen und die kann ich eben nur erfüllen wenn ich predictable performance und Latenzen habe. Das heißt in der Praxis 1 Core pro Guest. Ob das nun noch ein virtueller Thread dazu ist, ist relativ egal um ein SLA zu erfüllen. Deswegen auch das ganze gerede über Private L2 und der shared L3 ist hyperscalern halt auch ziemlich egal. Die würden am liebsten alles bifurcaten, SI, PCIe lanes, SSD speed, etc. um halt auch dram und storagelastige SLAs erfüllen zu können.

Alle firmen die ihre Prozesse irgendwo in die cloud outsourcen setzen auf SLAs oder haben das zumindest noch vor. Die billigen Jacobs die den 30% extrathread entdecken sehe ich irgendwie im Business-Umfeld nicht. Das sind doch eher nerds, gamer, filesharer die sich nen kleinen virtual server mieten um irgendwas unkritisches drauf laufen zu lassen. Wobei die sowas auch eher auf ihrem NAS hosten. Da freut man sich natürlich über SMT, wenn der minecraftserver oder der medienserver dadurch schneller läuft.

[latiose88]

Und ja sehe ich auch so.Bei 2 oder mehr Parallel ausgeführte Instanzen bzw Workflow da merkt man sehr deutlich den Boost von SMT. Bei der doppelten Anzahl jedoch also 16 vs 32,sieht es halt dann eher schlecht mit SMT oder bei Intel HT aus,aber nur wenn man die Anzahl der Anwendung nicht mehr steigern kann.

[Zossel]

Alle firmen die ihre Prozesse irgendwo in die cloud outsourcen setzen auf SLAs oder haben das zumindest noch vor. Die billigen Jacobs die den 30% extrathread entdecken sehe ich irgendwie im Business-Umfeld nicht. Das sind doch eher nerds, gamer, filesharer die sich nen kleinen virtual server mieten um irgendwas unkritisches drauf laufen zu lassen. Wobei die sowas auch eher auf ihrem NAS hosten. Da freut man sich natürlich über SMT, wenn der minecraftserver oder der medienserver dadurch schneller läuft.

Bin ich wieder in der Jahrtausendwende gelandet wo IT noch richtig was kosten durfte?

[Complicated]

@Zossel
Habe ich auch gedacht. Mit der Praxis hat das wenig zu tun.

[Gipsel]

Dass man sich bei der ILP-Extraktion viel Arbeit sparen kann, wenn man sowieso zwei unabhängige Streams hat, ist klar. Vielleicht spricht da aus mir immer noch so ein wenig der neidische Blick rüber auf die Firestorm-Kerne von Apple, die (zumindest wenn man noch mit Zen3+ vergleicht) aus einem Kern mit 1T so viel Perf/W rausgeholt haben wie Zen3+ mit 2T. Um bei der absoluten ST-Leistung mit Firestorm mitzuhalten, muss Zen 3+ dann gegenüber dem MT-Betrieb den Takt massiv erhöhen und verbraucht in ST-Workloads dann schnell mal ein Vielfaches des Firestorm-Kerns.Eine gewisse IPC bei etwas über 3GHz hinzubekommen ist eben auch einfacher als bei ~6GHz. Einen ROB mit >600 Einträgen so zu designen, daß der auch noch bei 6GHz funktioniert, erfordert erheblich mehr Aufwand (und eventuell auch einen überproportionalen Mehrverbrauch). Insofern ist auch der Zieltakt eine Abwägung hierbei.
Dadurch entsteht bei mir der Eindruck, dass AMD und Intel hier im Frontend-Bereich massiv hinterherhinken und den Durchsatz ihrer Kerne (der sehr wohl auf Augenhöhe mit Apple ist) nur auf die Straße kriegen, wenn sie zwei Instruction-Streams haben. Das wiederum würde aber bedeuten, dass gerade hier noch tiefhängende Früchte für z.B. Zen 5 wären, um die ST-Leistung zu erhöhen. Apple hat bisher bewusst auf SMT verzichtet und auch wenn ich absolut bei dir bin, dass ein so breiter Kern (7 INT ALUs afaik) sich dafür doch total anbieten würde, muss Apple irgendeinen guten Grund haben, das nicht zu tun. Im Zweifelsfall sehe ich Apples Kern hier als "moderner" an, weil er neuer ist, genauso wie "Zen" für mich moderner war als Intels Skylake, der eine Evolution darstellt, die bis auf Nehalem zurückgeht und bei der Effizienz immer der Zen-Evolution hinterhinkte.Ein möglichen Grund wurde ja schon genannt: Sicherheit. Das dürfte eine strategische Entscheidung gewesen sein, wo nicht nur die Performance eine Rolle spielte (weil dann wäre SMT drin).
PS: ROB/Renamer/Scheduler und so zählen klassischerweise auch zum Backend.
Hier kann ich dir nicht so ganz folgen. Das erste Zitat kann ich erstmal so hinnehmen. Aber der letzte Satz aus dem zweiten Zitat (inkl. Kontext davor) ist für mich dann erstmal ein Widerspruch, denn wenn die vorhandenen 4 ALU-Ports nicht ausgelastet wurden, dann würde ich daraus schlussfolgern, dass entweder nicht genügend Instruktionen dekodiert werden können (Durchsatz) oder es genug Instruktionen gibt, diese aber voneinander abhängen. In beiden Fällen würde doch eine fünfte ALU nicht helfen?In manchen Corner-Cases eben doch. Nimm als Beispiel mal Zen4. Da gibt es im Prinzip 4 Integer-Scheduler, die nur an die jeweils angeschlossenen Einheiten schedulen können (3x ALU+AGU Paar, 1x ALU+Branch). Es kann ganz dumm laufen und einer der Scheduler bekommt die ganzen voneinander unabhängigen µOps, die anderen 3 aber alle die mit Abhängigkeiten und stallen. Dann drehen 3 ALUs/AGUs meistens Däumchen und der Durchsatz wird von dem einen verbleibenden Scheduler bestimmt. Natürlich wird versucht sowas zu vermeiden, aber einfach mehr ALUs dranzuklatschen würde eben auch helfen, obwohl der Durchsatz nirgendwo in der Nähe des Maximums ist. Hier würde also das Backend limitieren, weil es auf verteilte Scheduler setzt, nicht weil es ungenügend Ausführungsresourcen gibt oder das Frontend nicht genügend Instruktionen liefert.

Und falls sich einer fragt, warum man überhaupt verteilte Scheduler benutzt, (statt unified, die eine verbesserte Schedulingeffizienz ermöglichen), ist die Antwort wieder Designaufwand und Taktbarkeit. Auf der FPU-Seite gab es bis Zen2 einen unified Scheduler (mit 4 Ports), aber ab Zen3 gibt es dort zwei Scheduler mit 3 Ports (vermutlich weil der Aufwand für bzw der Stromverbrauch eines einzigen Scheduler mit 6 Ports nicht zu rechtfertigen war oder man Einbußen bei der Taktbarkeit riskiert hätte).

[Gipsel]

Ich meine mal gehört zu haben dass ein zweites Registerset vonnöten ist. Und dass register gerade bei x86 einen nicht zu unterschätzenden Platz- und Energiebedarf haben,Das ist allegemein so, nicht nur bei x86. Die "architectural register" (also die durch die ISA definierten) sind bei x86 (16 Int Register) aber auch klein gegenüber der Größe des physisch vorhandenen Registerfiles (224 bei Zen4, 280 bei GoldenCove, man braucht ja Platz zum Renaming). Das fällt also am Ende nicht wirklich ins Gewicht, weil man einfach die vorhandenen Renameregister nutzen kann. Mehr Rename-Register helfen natürlich der Performance, das gilt aber mehr oder weniger allgemein für ST und MT (hängt vermutlich eher von der Größe des ROBs ab, wieviele Register der Sweetspot wären). Solange man also eine gewisse Mindestgröße des Registerfiles erreicht hat (was bei heutigen Desktop-CPUs sicher der Fall ist), ist das kein Problem.
Sicherlich steigt auch der Druck auf das Cachesystem wenn du einen zweiten Thread beherbergst.Und SMT ist auch ein guter Weg, um Cachelatenzen zu verstecken. ;)
Vielleicht neben 4K pages ein weiterer Grund wieso x86 CPUs vergleichsweise langsame caches mit hohe Assoziativität haben.Langsam im Sinne von Zyklen? Dann kommt eben immer noch der Zieltakt hinzu. Wir hatten ja schon Apples Firestorm als Beispiel. Der hat eine L1-Latenz von 3 bis 4 Zyklen bei 3,2GHz (je nach Art der Adressierung). Zen4 hat 4-5 Takte bei >5.5GHz (sind *meisten* 4 Takte; AMD nutzt dafür eine way prediction, um vorherzusagen, in welcher Cacheline die Adresse zu finden ist, 5 Takte gelten bei mispredict; GoldenCove ist bei 5 Takten [mit +50% Assoziativität und Größe, ist dieser VIPT-Zusammenhang]). Die Zugriffszeiten sind bei AMD und intel also tendentiell etwas kürzer (schneller).

Die Pagegröße spielt aber tatsächlich bei VIPT eine Rolle und gibt quasi eine bestimmte Beziehung zwischen Cachegröße und Assoziativität vor (aber keine Latenz, die Aufgabe dieser Beziehung erfordert allerdings eine latency Penalty).
Registerfiles könnten durchaus ein Energieverbraucher der sich schlecht power gaten lässt im Gegensatz zu physischen Cores und Cache, gerade was static power angeht. Vielleicht sieht man daher bei mobile (Handy)CPUs eher noch davon ab SMT zu verwenden weil man damit rechnet dass die CPU 99,9% im Idle oder Teillast läuft.Auf dem Handy benötigt man selten maximalen Durchsatz, niemand läßt da Blender laufen, das ist wahr. Apple will aber auch Desktops mit ihren CPUs versorgen.
Apples Argumentation gegen SMT ist dass es mehr Energie verbraucht und ich nehme einfach mal an dass da auch was dran ist.Mich würde mal interessieren, wo die das gesagt haben. Wurde das nur reininterpretiert oder ist das nur eine schlechte Schutzbehauptung?
Es kommt halt immer auf das Vergleichszenario an. Echte Cores können sicherlich bei gleicher MT Leistung weniger verbrauchen als eine halbierte CPU mit SMT Cores (weil diese einen höheren takt benötigt).Ein kompletter zweiter Kern verdoppelt natürlich die Ausführungsresourcen, aber zum Preis des doppelten Aufwands in Silizium und Stromverbrauch (für den Kern, also abzüglich des Drumherums). SMT erhöht den Durchsatz in MT-Szenarien um größenordnungsmäßig 20% für und 5% mehr Silizium (und einem oft vernachlässigbaren Mehrverbrauch, wenn gleicher Takt, aber immer mit besserer Performance/Watt [mindestens gleich gut] wenn z.B in einem harten Powerlimit).
Ein umgekehrtes Testszenario ist das was Anandtech mit dem 5950X gemacht hat: SMT off vs SMT on bei der gleichen kernanzahl. Mit SMT Off taktet die CPU 350mhz höher und der Hotspot wird auch wärmer. Das ist logisch, da 4Ghz vs 4,35ghz eben auch ein erheblicher Taktunterschied sind. Ob mehr Takt oder SMT schließlich besser performt ist abhängig vom spezifischen workload. In diesem Fall war es eindeutig pro SMT: https://www.anandtech.com/show/16261/investigating-performance-of-multithreading-on-zen-3-and-amd-ryzen-5000/4Ja, natürlich ist es vom Workload abhängig. Aber egal, wie man das Szenario konstruiert (festgepinnter Takt, hartes Powerlimit), SMT liefert im Schnitt meßbare Performancesteigerungen und eben auch steigende Performance/Watt.
Bei der performance per Area wird SMT sicherlich sinnvoll sein. Wenn aber performance per energy gefragt ist könnte das schon wieder anders ausfallen.Nicht wirklich. Mit Strom versorgte aber ungenutzte Einheiten liefern keinen Beitrag zur Performance, kosten aber Energie. Und die einzelnen Einheiten im Kern werden nur clockgated, nicht powergated, wenn die zumindest ab und zu mal eine Instruktion abbekommen (powergating kostet ziemlich viel Zeit). Also wenn man die Implementation des Kerns nicht verbockt, kann die Performance/W mit SMT eigentlich nie sinken (und steigt im Schnitt). Bestimmte Strukturen müssen auch aktiv sein, wenn nur ein Instruktionsstream aktiv ist. Der Verbrauch steigt also im allgemeinen weniger als der Durchsatz.
Und dann gibt es noch eine Menge sekundärer Effekte. Nur mal als Beispiel: Mit zwei Instruktionsstreams wird im Schnitt weniger tief spekuliert. Man spekuliert also nicht nur weniger oft falsch sondern muß im Fall der Fehhlspekulation zudem noch weniger energiefressende Operationen verwerfen.
Ich weiß nicht ob das so ein starkes Argument ist jetzt ausgerechnet eine CPU zu zitieren die am Markt ziemlich gefloppt ist und deren Hersteller damals gerade günstig von Marvell übernommen wurde. Als ThunderX2 endlich verfügbar war gab es schon Epyc Rome mit ca. doppelter Leistung und höherer Energieeffizienz. Cavium hatte es ja schon gegen den Skylake Xeon schwer.
Die echten Cloud native CPUs mit nennenswerten Marktanteilen bei den Hyperscalern waren schon eher Ampere Altra (Max) und Amazons Gravitron (2,3), beide ohne SMT und 1-2 Jahre später.Das Projekt hat ja auch ein paar Jahre im Limbo verbracht, bevor es auf den Markt kam. Und es ging um ARM und SMT. Zu dem Zeitpunkt waren die schon okay und für das schmale Design hat SMT ordentlich was gebracht. Das war der Punkt.
Ist das so?
Ich dachte denen geht es vor allem darum SLAs zu erfüllen und nicht maximale MT-Leistung zu präsentieren. Und dafür sind vor allem predictable latencies und performance wichtig,Predictable Performance bedeutet nicht unbedingt maximale MT-Leistung. Als Kunde willst Du vielleicht gerne eine vorhersagbare Performance und mußt dafür im Zweifelsfall extra zahlen (genau wie für die zusätzliche Performance wegen SMT).
Den von SMT angebotenen zusätzlichen Durchsatz kann der Anbieter aber nutzen, um seine Ressourcen etwas mehr zu überbuchen (im Zweifelsfall auf Kosten vorhersagbarer Performance für den Kunden).

[Zossel]

Und dass register gerade bei x86 einen nicht zu unterschätzenden Platz- und Energiebedarf haben, vergleichbar mit dem L1 oder einem großen ROB einer breiten OoO CPU.

Condition code register sind ein Ärgernis für OOO-Maschinen, allerdings hat lediglich RISC-V die entsorgt. Allerdings mit Auswirkungen wenn sehr breite Arithmetik gerechnet werden soll, zu dem Thema gibt es jede Menge Diskussionen um sich eine eigene Meinung dazu zu bilden.

[Zossel]

Den von SMT angebotenen zusätzlichen Durchsatz kann der Anbieter aber nutzen, um seine Ressourcen etwas mehr zu überbuchen (im Zweifelsfall auf Kosten vorhersagbarer Performance für den Kunden).

Im Regelfall sind die Applikationen für sowas einfach viel zu schlecht programmiert.

[Platos]

Ist eig. was bekannt über einen infinity fabric-Nachfolger (also Stichwort energieeffizienter, nicht Leistungsfähiger bei der Bandbreite) ?

AMD ist da ja ziemlich im hintertreffen, was Stromverbrauch anbelangt (beim Interconnect). Also gibt es hier Information über einen Nachfolger/Verbesserung ? Also etwas, das CPU bezogen ist.

[amdfanuwe]

IFoP dürfte halt am billigsten sein.
Bei RDNA3 haben sie was neues getestet.
Mal sehen, wie das bei MI300 verbunden ist.

Für Desktop dürfte billig die Priorität haben, da spielen ein paar Watt Mehrverbrauch nicht die Rolle.

[w0mbat]

Ist eig. was bekannt über einen infinity fabric-Nachfolger (also Stichwort energieeffizienter, nicht Leistungsfähiger bei der Bandbreite) ?

AMD ist da ja ziemlich im hintertreffen, was Stromverbrauch anbelangt (beim Interconnect). Also gibt es hier Information über einen Nachfolger/Verbesserung ? Also etwas, das CPU bezogen ist.

Wenn du die chips nicht nahe zusammenrücken oder einen interposer nutzen willst, ist IF ziemlich gut. Ist immer ein trade-off.

[Platos]

Ja, aber gibt es dazu keine Infos?

Mit RDNA 3 haben sie was anderes ja. Das kann ne deutlich höhere Bandbreite handeln.

Aber ist das auch energieeffizienter?

Bei Niedriglastszenarien sieht man halt, wie mies AMD ist und auch, dass es am Chiplet-Design liegt (Gegenbeispiel: 5700G usw).

Aber es geht mir jetzt nicht darum, obs nun gut ist oder nicht. Ich bin mehr daran interessiert, ob es im CPU Bereich da irgendwelche Gerüchte gibt oder obs da gar nichts gibt.

Weiss das jemand ?

[reaperrr]

Aber es geht mir jetzt nicht darum, obs nun gut ist oder nicht. Ich bin mehr daran interessiert, ob es im CPU Bereich da irgendwelche Gerüchte gibt oder obs da gar nichts gibt.

Weiss das jemand ?
Also ich folge den Gerüchteküchen eigentlich recht regelmäßig und hab in der Richtung nichts bahnbrechendes mitbekommen. Neue IF-Revisionen werden natürlich kommen, aber dazu wieviel die bringen hat sich meines Wissens noch keiner geäußert.

Wobei ich zumindest vermuten würde, dass es da schon Verbesserungen geben wird, einfach weil Strix Halo ja auf CPU-Chiplets setzt und sich ein niedrigerer Idle-Verbrauch auch in Gaming-Laptops natürlich positiv auf die OEM-Nachfrage auswirken würde und deshalb in AMDs Interesse liegen sollte.
Andererseits wird StrixHalo wg. der großen IGP generell einen recht hohen Idle-Verbrauch für eine APU haben, dafür wird halt der Verbrauch einer diskreten GPU + deren PCIe-Anbindung eingespart.

[Nightspider]

IF ist gut und wird stetig verbessert.

Mit neueren Packaging Methoden kann man die Effizienz auch deutlich verbessern mit Niedriglastbereich.


Bei Niedriglastszenarien sieht man halt, wie mies AMD ist

Ist das so?

Imo sieht man nur den Chiplet-Tradeoff beim Verbrauch. Oder hast du jetzt von GPUs gesprochen?

RDNA2 war sehr effizient.

[Platos]

Hmm, wenn ich jetzt so ein bisschen Rumforste, finde ich folgendes:

https://www.golem.de/news/universal-chiplet-interconnect-express-chiplet-konsortium-ohne-aws-und-nvidia-2203-163644.html

Da wäre der Energieverbrauch immerhin 3-6x besser. Allerdings habe ich dazu nie mehr was gehört. Ist jetzt zwar nicht Zen5 bezogen, aber was nutzt eig. Intel für die Tiles bei Meteorlake ? EMIB oder eben vlt. genau das oben verlinkte? Denn sie nutzen ja schliesslich auch Fertigungsprozesse von TSMC. Also würde sich so ein Standart ja gerade zu anbieten.

Oder aber man setzt vlt. in Zukunft auf 3D Stacking, wobei das bei Logik halt schon schwierig ist.

Ist dazu was bekannt ? Also jetzt Herstellerunabhängig bezüglich 3D Stacking von Logik (also quasi Chiplets) ?

Gibts eig. hier keinen Thread bezüglich Chip-Connecting (2D und 3D verfahren) ?

IF ist gut und wird stetig verbessert.

Mit neueren Packaging Methoden kann man die Effizienz auch deutlich verbessern mit Niedriglastbereich.



Ist das so?

Imo sieht man nur den Chiplet-Tradeoff beim Verbrauch. Oder hast du jetzt von GPUs gesprochen?

RDNA2 war sehr effizient.

Ich meine schon die CPUs. Was meinst du mit "Chiplet-Tradeoff" ? Woher kommt dieser denn ? Also der erhöte Energiebedarf.

[Nightspider]

Damit die Siliziumchips trotz der großen Distanz vone inigen cm kommunizieren können, müssen die Daten mit etwas mehr Spannung durchs Kupfer geprügelt werden. Du hast größere/stärkere Transistoren für die Off-Chip Kommunikation zwischen den Chips und die Leiterbahnen sind lang und dünn und haben einen Widerstand, der diesen Aufwand erfordert. Da geht einfach Strom in Form von Wärme flöten....

Keine Ahnung wie die reale Taktung aussieht aber bei 3Ghz wären das 3 Milliarden Pulse die durch die Leiterbahnen ""gedrückt"" werden. Da gehen halt 10-20 W für nichts drauf.

Hoffe die Erklärung ist halbwegs korrekt. :D

[Platos]

Damit die Siliziumchips trotz der großen Distanz vone inigen cm kommunizieren können, müssen die Daten mit etwas mehr Spannung durchs Kupfer geprügelt werden. Du hast größere/stärkere Transistoren für die Off-Chip Kommunikation zwischen den Chips und die Leiterbahnen sind lang und dünn und haben einen Widerstand, der diesen Aufwand erfordert. Da geht einfach Strom in Form von Wärme flöten....

Ja aber das gehört doch zum Interconnect mit dazu? Also der verbindet die ja im Endeffekt. Also Chipletverbindung.

Und genau da ist AMD schlecht bezüglich Energieverbrauch (zahlen dazu gibts im Link in meinem letzten Post. Da ist AMD 3x schlechter wie Intel mit EMIB beispielsweise).

Ich finde ja dieser "universelle" Interconnect interessant (auch der obige Link), aber dazu finde ich nichts mehr bezüglich realen Produkten.

Oder halt eben wie gesagt 3D Stacking, aber ich denke, das ist in den nächsten 5-10 Jahren kein Thema für Logik (?)

[Nightspider]

Oder aber man setzt vlt. in Zukunft auf 3D Stacking, wobei das bei Logik halt schon schwierig ist.

Na davon reden wir ja schon seit Jahren.

Schwierig? Was heißt schwierig? Man muss die Wärmeabgabe beachten.

Du musst halt so stapeln das die Teile, die am meisten Abwärme produzieren weit außen liegen.
CPU Kerne auf IO und Cache zu stapeln macht AMD jetzt schon bei MI300.

Also Logik stacken ist kein Problem mehr. Es ist im Moment vor allem eine Frage der Kosten und der Verfügbarkeit.
Denn die Fabriken für Advanced Stacking schießen gerade erst aus dem Boden und die bisherigen Kapazitäten könnte Apple alleine aufsaugen.

Von TSMC wird gerade eine neue Packaging Fab eröffnet und hochgefahren.

Stacking wird zur Normalität und mit den Jahren werden wir immer extremere Formen erleben.

Nicht wenige haben vor 1-2 Jahren schon Stacking bei Zen5 erwartet. Aber das werden wir wohl erst mit Zen6 oder Zen6 erleben.

Ja aber das gehört doch zum Interconnect mit dazu? Also der verbindet die ja im Endeffekt. Also Chipletverbindung.

Und genau da ist AMD schlecht

Zählt EMIB nicht eher zu den Packaging Methoden? Ist doch auch Silizium wenn ich mich nicht irre und Intel verbindet eben Silizium mit Silizizm über Silizium.
Das hat bessere elektrische Eigenschaften und vor allem deutlich kürzere Wege als AMDs bisheriger CPU Chiplet Ansatz.

[memory_stick]

Solange AMD bei Chiplets im CPU Bereich übers Substrat geht wird die Effizienz des Interconnects nicht an Interposer/EMIB/etc. heranreichen, einfach aufgrund der elektrischen Eigenschaften und den Distanzen.
Intel hat bisher EMIB (2.5D) und Foveros (3D) stacking, und über die Kosten davon wissen wir nichts. Äquivalente Verfahren bei AMD stammen von TSMC mit allen InFo Varianten, welche ich immer durcheinander bringe :)

Mei MTL wird intel soweit ich das Verstanden habe auf einen (aktiven?) Base Die als Interposer setzen, die Tiles sind darauf gestackt. Da hat man natürlich kürzere Wege, weniger Materialübergänge und dadurch geringeren Widerstand und Kapazitäten, ähnliche Wärmeausdehnungskoeffizienten, etc. Alles Vorteile um die Interconnect power zu verringern.

Auf Protokollebene bin ich ehrlich gesagt überfragt, a) was genau verwendet wird bezgl. encoding, etc. und b) inwiefern dies eine Auswirkung auf die Link power hat.
Einzelne Links schlafenlegen kann IF ja mind. seit Zen4

[Platos]

Na davon reden wir ja schon seit Jahren.

Schwierig? Was heißt schwierig? Man muss die Wärmeabgabe beachten.

Du musst halt so stapeln das die Teile, die am meisten Abwärme produzieren weit außen liegen.
CPU Kerne auf IO und Cache zu stapeln macht AMD jetzt schon bei MI300.

Also Logik stacken ist kein Problem mehr. Es ist im Moment vor allem eine Frage der Kosten und der Verfügbarkeit.
Denn die Fabriken für Advanced Stacking schießen gerade erst aus dem Boden und die bisherigen Kapazitäten könnte Apple alleine aufsaugen.

Von TSMC wird gerade eine neue Packaging Fab eröffnet und hochgefahren.

Stacking wird zur Normalität und mit den Jahren werden wir immer extremere Formen erleben.

Nicht wenige haben vor 1-2 Jahren schon Stacking bei Zen5 erwartet. Aber das werden wir wohl erst mit Zen6 oder Zen6 erleben.

Hat es denn bei z.B einem 16-Kerner genug Fläche auf dem IO-DIE, um alle Logik-Chiplets darauf zu stapeln?

Ich meinte übrigens mit Logik stapeln, dass man 2 Logikchips übereinander stapelt. Aber ja, jetzt wo du es sagst... Mir viel gerade nicht ein, dass der Logikchip ja oben sein kann und darunter keiner...

Aber wie gesagt: Hätte es denn genug Fläche beim IO Die dafür ? Denn mit dem 3D Cache haben wir ja gesehen, dass das sehr gut geht und vor allem sehr Energieeffizient. Die Wege werden ja eben genau durch solche Methoden verkürzt (also 3D Stacking).



Zählt EMIB nicht eher zu den Packaging Methoden? Ist doch auch Silizium wenn ich mich nicht irre und Intel verbindet eben Silizium mit Silizizm über Silizium.
Das hat bessere elektrische Eigenschaften und vor allem deutlich kürzere Wege als AMDs bisheriger CPU Chiplet Ansatz.

Das sind doch alles Packaging-Methoden ?

[Platos]

Solange AMD bei Chiplets im CPU Bereich übers Substrat geht wird die Effizienz des Interconnects nicht an Interposer/EMIB/etc. heranreichen, einfach aufgrund der elektrischen Eigenschaften und den Distanzen.
Intel hat bisher EMIB (2.5D) und Foveros (3D) stacking, und über die Kosten davon wissen wir nichts. Äquivalente Verfahren bei AMD stammen von TSMC mit allen InFo Varianten, welche ich immer durcheinander bringe :)

Mei MTL wird intel soweit ich das Verstanden habe auf einen (aktiven?) Base Die als Interposer setzen, die Tiles sind darauf gestackt. Da hat man natürlich kürzere Wege, weniger Materialübergänge und dadurch geringeren Widerstand und Kapazitäten, ähnliche Wärmeausdehnungskoeffizienten, etc. Alles Vorteile um die Interconnect power zu verringern.

Auf Protokollebene bin ich ehrlich gesagt überfragt, a) was genau verwendet wird bezgl. encoding, etc. und b) inwiefern dies eine Auswirkung auf die Link power hat.
Einzelne Links schlafenlegen kann IF ja mind. seit Zen4

Ja, genau. Ich frage mich, wenn AMD da eher in eine etwas modernere Richtung wechselt bezüglich Connecting Methoden.

So, wie sie das jetzt handhaben, ist das einfach nicht Energieeffizient.

[amdfanuwe]

Welche mechanische Verbindung für UCIe genutzt wird, ist für das CLX-/PCIe-Protokoll egal, weil der Standard agnostisch sein soll.

UCIe ist also nur ein Protokoll, ähnlich wie AMDs IF.


Hinsichtlich der Effizienz spricht das UCIe-Konsortium von 0,25 bis 0,5 Picojoule pro Bit, je nach Implementierung. AMDs Infinity Fabric soll älteren Daten zufolge mit 1,5 pJ/Bit darüber liegen, Intels EMIB und OCPs Bunch of Wires (BoW) mit 0,5 pj/Bit hingegen in einem ähnlichen Bereich.
Da widerspricht sich der Artikel selbst.
Der Verbrauch ist abhängig von Leitungslänge, -dicke, Kontakt Fläche etc.
Je kleiner die Kontakte und je geringer der Wellenwiderstand umso geringer der Verbrauch.

----
Hab hier ein PDF gefunden, das die Interconnect Problematik beschreibt:

Seizing the Bandwidth Scaling of On-Package Interconnect in a
Post-Moore’s Law World (https://dl.acm.org/doi/pdf/10.1145/3577193.3593702)

[Complicated]

Ist eig. was bekannt über einen infinity fabric-Nachfolger (also Stichwort energieeffizienter, nicht Leistungsfähiger bei der Bandbreite) ?

AMD ist da ja ziemlich im hintertreffen, was Stromverbrauch anbelangt (beim Interconnect).
Ja, genau. Ich frage mich, wenn AMD da eher in eine etwas modernere Richtung wechselt bezüglich Connecting Methoden.

So, wie sie das jetzt handhaben, ist das einfach nicht Energieeffizient.
Da sie die einzigen sind, die einen Interconnect haben der das überhaupt kann (die 4 Iteration schon mittlerweile) ist deine Sicht da wohl etwas verkehrt.

Intel versucht immer noch erfolglos etwas zu finden das skalieren kann mit den Chiplets und andere sind da auch noch nicht angekommen. AMDs Vorsprung würde ich auf ca. 3 Jahre schätzen von der Technik bei MI300 ausgehend verglichen mit Nvidias Grace Hopper und bei Intels Sapphire Rapids sind es wohl eher 5 Jahre.

Wo IF Schwächen hat mit der Energieeffizienz ist bei CPUs mit weniger als 12 Kernen - ab dort ist das Verhältnis uncore zu core Verbrauch schlechter als bei Intel, darüber ist es besser. Nur das wird ebenfalls immer besser mit jeder Iteration. Und doch skaliert IF bis runter zu 4 Kernen von den größten 128-Cores - Nvidias und Intels Server Interconnects sehe ich nirgends in Consumer Produkten. Und sie können auch keine 128 Kerne auf einer SKU unterbringen.

[Platos]

Dein AMD vs Intel Gelaber interessiert mich nicht.

[Complicated]

Dann sag mir mal mit wessen Interconnect du AMDs IF vergleichst mit deinem Unfug?
Du hast nicht den Dunst einer Ahnung und erzählst etwas von schlechter Effizienz. Geh spielen und komm wieder wenn du erwachsen bist.

[Nightspider]

Hat es denn bei z.B einem 16-Kerner genug Fläche auf dem IO-DIE, um alle Logik-Chiplets darauf zu stapeln?

Die Chips müssen nicht die gleiche Größe haben.

Der V-Cache Slice ist auch kleiner als ein CCD.

Aktuell sind 2 CCDs ungefähr 20% größer als der IO Chip.
Aber natürlich kann AMD die Chips auch so designen, das sie die gleiche größe hätten.
Im schlimmsten Fall gibt es etwas totes Silizium beim günstigeren Base-Die.

Ja, genau. Ich frage mich, wann AMD da eher in eine etwas modernere Richtung wechselt

In der großen Massenproduktion für alle Consumer?

Wenn es dafür die Kapazitäten gibt und diese aus Preis/Leistungssicht Sinn ergeben.

Die Kosten müssen schließlich stimmen. Viele Consumer kaufen CPUs im 200 Euro Bereich.

Wenn alle Leute nur 500 Euro CPUs kaufen würden, würde es das jetzt schon geben.

[Zossel]

Die Desktop-Teile fallen einfach bei Servern-Teilen hinten raus.

Ich könnte mit vorstellen das für die Verbindung der Dies eine ähnliche Technik verwendet die beim AWS Graviton3 verwendet wird wenn das günstig und in Stückzahlen verfügbar ist.
Keine Ahnung welchen Namen diese Technik von TSMC hat, ich steige da auch nicht durch.

[Zossel]

Ist eig. was bekannt über einen infinity fabric-Nachfolger (also Stichwort energieeffizienter, nicht Leistungsfähiger bei der Bandbreite) ?

AMD ist da ja ziemlich im hintertreffen, was Stromverbrauch anbelangt (beim Interconnect). Also gibt es hier Information über einen Nachfolger/Verbesserung ? Also etwas, das CPU bezogen ist.

BTW: Hat Intel eigentlich mittlerweile einen Interconnect mit dem sich größere Mengen an CPU-Dies sinnvoll zusammen dengeln lassen? (Mesh oder Ring scheinen mir wenig geeignet)

[Platos]

Die Chips müssen nicht die gleiche Größe haben.

Der V-Cache Slice ist auch kleiner als ein CCD.

Aktuell sind 2 CCDs ungefähr 20% größer als der IO Chip.
Aber natürlich kann AMD die Chips auch so designen, das sie die gleiche größe hätten.
Im schlimmsten Fall gibt es etwas totes Silizium beim günstigeren Base-Die.

Ich meine ja auch nicht die gleiche Grösse, aber der IO DIE muss doch mindestens gleich gross sein, wie alle Chiplets zusammen ?

Ansonsten ragen die Logik-Chiplets ja über den IO DIE.

Und bezüglich totes Silizium: Wie kontaktiert man die Logik-DIEs denn, wenn die "Enden" in totes Silizium ragen. Dann müssten die Kontakte ja mitten im Chip sein?

Edit: Wobei Foveros Omni von Intel soll genau das auch können. Also der Top-DIE muss nicht kleiner sein wie der Base-DIE: https://www.anandtech.com/show/16823/intel-accelerated-offensive-process-roadmap-updates-to-10nm-7nm-4nm-3nm-20a-18a-packaging-foundry-emib-foveros/4

Ich frage mich aber schon, wie das gehen soll. Also ich meine jetzt in Bezug auf mechanische Belastung. Die Kontaktierung muss dann aber wirklich irgendwo mitten im Chip stattfinden und nicht am Rand des Chips.


In der großen Massenproduktion für alle Consumer?

Wenn es dafür die Kapazitäten gibt und diese aus Preis/Leistungssicht Sinn ergeben.

Die Kosten müssen schließlich stimmen. Viele Consumer kaufen CPUs im 200 Euro Bereich.

Wenn alle Leute nur 500 Euro CPUs kaufen würden, würde es das jetzt schon geben.

Das es Wirtschaftlich sein muss, ist klar :)


BTW: Hat Intel eigentlich mittlerweile einen Interconnect mit dem sich größere Mengen an CPU-Dies sinnvoll zusammen dengeln lassen? (Mesh oder Ring scheinen mir wenig geeignet)

Bin mir nicht sicher, aber nutzte man bei Lakefield nicht auch Foveros ? Da hat man zwar keine CPU-DIEs gestapelt, aber bei Meteorlake soll ja die 2. Version von Foveros genutzt werden und später dann Foveros Omni und Foveros Direct. Ich meinte, die erste Version hat man z.B bei lakefield genutzt.

Also kurz gesagt: Eine Nachfolgergeneration von Foveros (die, die in Meteorlake genutzt wird), kann das (offensichtlicherweise, denn Meteorlake kommt ja als Tile-Design).

Die Desktop-Teile fallen einfach bei Servern-Teilen hinten raus.

Ich könnte mit vorstellen das für die Verbindung der Dies eine ähnliche Technik verwendet die beim AWS Graviton3 verwendet wird wenn das günstig und in Stückzahlen verfügbar ist.
Keine Ahnung welchen Namen diese Technik von TSMC hat, ich steige da auch nicht durch.

Keine Ahnung, wie das alles heisst. Aber das finde ich dazu gerade: https://3dfabric.tsmc.com/english/dedicatedFoundry/technology/3DFabric.htm

[Nightspider]

Ich meine ja auch nicht die gleiche Grösse, aber der IO DIE muss doch mindestens gleich gross sein, wie alle Chiplets zusammen ?

Ich wiederhole mich: Nein!

Kannst genaus tote Silizium Dummies (Quader) an die Stellen packen, wo irgendwas irgendwen überragt oder nutzt diese gleich zur Stromübertragung. (Oder irgendwann zur Kühlung)

Wärme fließt ja mit dem Strom. Masse außen über noch breitere Dummies abführen die wieder Kontakt zu einem Kühlkörper (oder direkt zu Wasser :naughty:) haben.

[Platos]

Ich wiederhole mich: Nein!

Kannst genaus tote Silizium Dummies (Quader) an die Stellen packen, wo irgendwas irgendwen überragt oder nutzt diese gleich zur Stromübertragung. (Oder irgendwann zur Kühlung)

Wärme fließt ja mit dem Strom. Masse außen über noch breitere Dummies abführen die wieder Kontakt zu einem Kühlkörper (oder direkt zu Wasser :naughty:) haben.

Und die Kontaktierung zwischen oberem und unterem DIE findet dann somit nicht am Rand sondern irgendwie mitten im DIE statt?

Wenn man das so machen will, ok. Erscheint mir aber irgendwie aufwändiger, wie wenn der Top-DIE kleiner ist.

Habe den oberen Post noch editiert. Intels Foveros Omni benötigt anscheinend auch kein kleineren Top-DIE.

Aber Foveros Omni kommt ja erst noch.

[Nightspider]

Wenn 10-20% der Fläche überhängen dürfte es keine große Rolle spielen, was die Kontaktierungen betrifft. Bei echtem Stacking kannst du eine extrem hohe Kontaktierungsdichte auf kleiner Fläche erreichen.

Abgesehen davon geht die Tendenz dahin, dass die Logic Chips viel kleiner ausfallen als die Base oder Cache Dies.

Der Anteil der reinen Kernlogik bei Zen4 ist winzig klein. Angefangen vom L1 bis zum L3 nimmt alles was zum Cache gehört ca. 70-75% von der gesamten Fläche ein. Und da ist der L0 noch nicht mal mitgezählt weil der lokal bleiben muss. (Keine Ahnung ob man irgendwann auch den L1 auslagern könnte aber das wird wenn dann noch sehr sehr weit in der Zukunft liegen)
Aber L3/L2 und damit der größte Anteil der Fläche wird in den nächsten Jahren ausgelagert, also brauchst du dir keine Sorgen machen das die Logic Chips größer sein werden.

Bei MI300 wurde auch der Infinity Cache unter die Compute Dies ausgelagert.

Wir sind hier aber mittlerweile ziemlich Offtopic.

[Complicated]

@Platos
Das ganze ist sehr wirr, was du schreibst. AMDs Infinity Fabric ist nicht das Äquivalent zu Intels EMIB oder Foverors. Den Vergleich, den du ziehst macht einfach keinen Sinn.
Foveros konkurriert mit TSMCs Packaging-Verfahren und ist da ebenfalls weit entfernt von Gleichstand.
CoWOs, InFO oder SoIC sind hier die TSMC-Technologien von denen du redest.

Das hat vor allem überhaupt nichts mit Zen5 zu tun. Unfundierter Offtopic.
Bitte an einen Mod das aufzuräumen

[Platos]

Wenn 10-20% der Fläche überhängen dürfte es keine große Rolle spielen, was die Kontaktierungen betrifft. Bei echtem Stacking kannst du eine extrem hohe Kontaktierungsdichte auf kleiner Fläche erreichen.

Abgesehen davon geht die Tendenz dahin, dass die Logic Chips viel kleiner ausfallen als die Base oder Cache Dies.

Der Anteil der reinen Kernlogik bei Zen4 ist winzig klein. Angefangen vom L1 bis zum L3 nimmt alles was zum Cache gehört ca. 70-75% von der gesamten Fläche ein. Und da ist der L0 noch nicht mal mitgezählt weil der lokal bleiben muss. (Keine Ahnung ob man irgendwann auch den L1 auslagern könnte aber das wird wenn dann noch sehr sehr weit in der Zukunft liegen)
Aber L3/L2 und damit der größte Anteil der Fläche wird in den nächsten Jahren ausgelagert, also brauchst du dir keine Sorgen machen das die Logic Chips größer sein werden.

Bei MI300 wurde auch der Infinity Cache unter die Compute Dies ausgelagert.

Wir sind hier aber mittlerweile ziemlich Offtopic.


Ja ok. wenn man die jetzigen Cores noch kleiner macht (wegen dem auslagern) und diese dann somit nach unten wandern, könnte das tatsächlich ziemlich klein ausfallen. Also der Logik-DIE.

Muss mir den MI300 mal genauer ansehen.

Und ja, im Chipfertigungsthread wäre die DIskussion wohl besser aufgehoben.

[Orko]

Ich meine ja auch nicht die gleiche Grösse, aber der IO DIE muss doch mindestens gleich gross sein, wie alle Chiplets zusammen ?

Ansonsten ragen die Logik-Chiplets ja über den IO DIE.

Und bezüglich totes Silizium: Wie kontaktiert man die Logik-DIEs denn, wenn die "Enden" in totes Silizium ragen. Dann müssten die Kontakte ja mitten im Chip sein?

Edit: Wobei Foveros Omni von Intel soll genau das auch können. Also der Top-DIE muss nicht kleiner sein wie der Base-DIE: https://www.anandtech.com/show/16823/intel-accelerated-offensive-process-roadmap-updates-to-10nm-7nm-4nm-3nm-20a-18a-packaging-foundry-emib-foveros/4

Ich frage mich aber schon, wie das gehen soll. Also ich meine jetzt in Bezug auf mechanische Belastung. Die Kontaktierung muss dann aber wirklich irgendwo mitten im Chip stattfinden und nicht am Rand des Chips.




Ich wiederhole mich: Nein!

Kannst genaus tote Silizium Dummies (Quader) an die Stellen packen, wo irgendwas irgendwen überragt oder nutzt diese gleich zur Stromübertragung. (Oder irgendwann zur Kühlung)

Wärme fließt ja mit dem Strom. Masse außen über noch breitere Dummies abführen die wieder Kontakt zu einem Kühlkörper (oder direkt zu Wasser :naughty:) haben.


Es macht das Stapeln von Chip natürlich einfacher, wenn kleinere Chips auf grössere (oder zumindest gleichgrosse) Chips gestapelt werden, aber es ist nicht zwingend erforderlich.

hypothetisches Beispiel Zen xy:

Es sollen mehrere CCDs auf ein IOD gestapelt werden, wobei die Fläche der CCDs in Summe grösser ist als die des IODs.

Da die CCDs vermutlich deutlich mehr Wärme als das IOD erzeugen, ist dies thermisch unproblematisch da die CCDs ja oben, also beim Heatspreader sitzen. Es bleibt das mechanische Problem, denn die überragenden CCDs sollten (insbesondere bei der Heatspreader Montage) nicht abbrechen, und unterschiedliche thermische Ausdehnungskoeffizienten (Substrat, Silizium, Heatspreader) sollten nicht zu Chip- bzw Kontaktbrüchen führen.

Optionen:

1) Das IOD wird ähnlich den EMIB Brücken in das Substrat (Leiterplatte) eingelassen. Die CCDs sitzen mit einem Ende / einer Hälfte über dem IOD (Datenverbindung) und mit dem anderen Ende / der anderen Hälfte über dem Substrat (Stromversorgung)

2) Das Substrat wird um den IOD Platz herum mit Metallpfosten erhöht. Dann wird das IOD plaziert. Dann die CCDs. Diese sitzen mit einem Ende / einer Hälfte über dem IOD (Datenverbindung) und mit dem anderen Ende / der anderen Hälfte auf dem Metallpfosten (Stromversorgung). Underfill füllt dann auch den Platz zwischen den Metallpfosten aus. Das überragende Ende jedes CCDs wird durch Metallpfosten und Underfill angestützt.

3) Wie von Nightspider geschrieben werden überragende CCDs durch totes Silizium abgestützt. Hier vorteilhafter Weise "totes Silizium" nicht im Sinne von inertem Silizium sondern im Sinne von Interposer Silizium: ohne Transistoren aber mit wenigen Leiterbahnlagen und Durchkontaktierungen (für die Stromversorgung der CCDs)

Wenn der Nachteil in Kauf genommen wird, dass die Stromversorgung der CCDs über den IOD erfolgt, gibt es noch etliche weitere Möglichkeiten:

4) "etws" überragende CCDs können auch einfach durch ausreichend viel Underfill abgestützt werden. Oder irgendwelchen anderen Prozesse die dort Plastikmaterial o.Ä. einbringen.

5) Überragende CCDs können ggf (hier ist mir kein Praxisbeispiel bekannt; also unsicher ob dies real funktionieren würde) auch mit dem Heatspreader verlötet werden um diese mechanisch zu stabilisieren.

[Orko]

6) In den Heatspreder kommt oben seitlich ein "kleines" Loch. dann wird der komplette Innenraum mit einem flüssigem Material geflutet und dieses dann z.B. thermisch ausgehärtet. Alle Chips sind dann schön in Plastik eingepackt.

7) Nach der Chipmontage werden diese diese per Molding-Prozess in einen Plastikkörper eingepackt (etwa analog zu BGA Chippackages). Entweder wird ein fortschrittlicher Prozess verwendet, welcher die Oberseiten aller oben liegenden Chips frei lässt. Oder diese werden anschliessend freigeschliffen. Dann wird der Heatspreader montiert.

[Platos]

Interessant, danke.

1) und 2) halte ich dann für den wahrscheinlichsten Fall.

[Gipsel]

Und die Kontaktierung zwischen oberem und unterem DIE findet dann somit nicht am Rand sondern irgendwie mitten im DIE statt?Die Zeiten, als ein Die nur am Rande Kontakte hatten, sind seit den Zeiten des Wire-Bondings tot. Flip-Chip-Dies hatten ihre Kontakte schon immer über die komplette Fläche verteilt.
Und die Kontakte an überhängenden Flächen kann man z.B. so machen, wie TSMC das hier zeigt (die unteren Dies sind dort nur kleine Brückenchips, die entsprechend vergossen sind und Kontakte gehen auch durch die Vergußmasse):
https://3dfabric.tsmc.com/site_img/dedicatedFoundry/technology/cowos/CoWoS-L_01.png

Die unteren Lagen sind übrigens meist <50µm dünn. Man baut da also auch nicht ewig weit in die Höhe.

==================================

Und das war es dann hoffentlich mit dem Packaging Off-Topic. Dazu haben wir glaube ich auch einen eigenen Thread. Hier soll es um Zen5 gehen!

[Tarkin]

https://twitter.com/harukaze5719/status/1675365723659718659?s=20

"GRANITE RIDGE 6C 105W A0"

geht los mit ZEN 5 Engineering Samples

[basix]

Nice :)

[Zossel]

https://twitter.com/harukaze5719/status/1675365723659718659?s=20


Was steht da? Twitter ist ja kaputt.

[M4xw0lf]

Was steht da? Twitter ist ja kaputt.
Nicht mehr als das gefettete in Tarkins Post.

[Tarkin]

Was steht da? Twitter ist ja kaputt.

man braucht neuerdings einen Account um Tweets zu sehen (Maßnahme gegen Scraper Bots)

[robbitop]

Ggf kann man auch einfach das Zitat dann hier reinbringen? ;)

[HOT]

https://twitter.com/harukaze5719/status/1675365723659718659?s=20

"GRANITE RIDGE 6C 105W A0"

geht los mit ZEN 5 Engineering Samples

Also ca. 1 Jahr noch bis launch

Man war sich bei AMD ja jetzt nicht mehr sicher, ob man nicht doch mehr Kerne bringen möchte. Aus meiner Sicht geht das nur mit dem 16c N3B-Die für Zen5c, also 8c GR (+X3D) gepaart mit einem N3 16c-Die, ähnlich wie bei Strix Point oder Phoenix 2. Also, 24c mMn incoming etwas später als die normalen Zen5.

[Nightspider]

Also ca. 1 Jahr noch bis launch

Liegt wirklich noch ein ganzes Jahr zwischen einem Engineering Sample und dem Marktstart? War das nicht weniger?

Zen5 in Q3 wäre bisschen spät.

__

Erste Strix Point APUs sind ja auch kürzlich in irgendwelchen (Benchmark?) Datenbanken aufgetaucht.

Dürfte dann genauso noch ein Jahr dauern bis zum Release oder?

Also kann man vom 3. Quartal 2024 ausgehen hinsichtlich eines Strix Points Marktstarts?

Fänd ich für die APU auch bisschen zu spät, zumindest für die kleine APU.


__

Nach den Bergamo Tests stellt sich fast die Frage warum man normale Zen5 Cores anstatt der Dense Cores in den APUs verbauen sollte, vom Release Zeitraum mal abgesehen. (Zen5c wird wohl später fertig als Zen5)

Am Cache hat AMD bei den bisherigen APUs ja sowieso schon gespart und damit Leistung geopfert.

Theoretisch hätte AMD jetzt auch schon Phoenix mit Zen4c neu auflegen können aber dafür mit 12 monolithischen Kernen oder 8 kleinen Zen4c Kernen aber dafür mit Infinity Cache für die integrierte Grafik. Da hätte man viel mehr gewonnen beim 0815 Consumer / Gamer / SteamDeck Markt.

Da frage ich mich auch, ob man sich die Zeit an den APUs mit den normalen Kernen nicht hätte sparen können und direkt mit den Dense Cores in APUs angreifen hätte sollen. Das hätte dann eventuell die Entwicklung letzterer beschleunigt. Phoenix ist ja noch nicht mal wirklich gut verfügbar.
Aber das ist sicherlich auch eine Risikoabwägung gewesen, die Planungen hierfür laufen ja schon seit Jahren.

__

Laut dem letzten Video von RGT kann man wohl bei Strix Halo hohe Taktraten von über 5Ghz bis Richtung 6 Ghz erwarten:

https://youtu.be/FL49Lhhy8D0?t=163

[ryan]

Also kann man vom 3. Quartal 2024 ausgehen hinsichtlich eines Strix Points Marktstarts?

Fänd ich für die APU auch bisschen zu spät, zumindest für die kleine APU.



Phoenix ist jetzt erst rausgekommen, das würde eigentlich gut passen. Im Juni letztes Jahr gab es auch schon Einträge (https://wccftech.com/amd-ryzen-7000-phoenix-point-cpu-spotted-8-zen-4-cores-based-on-a-4nm-process-node-for-laptops/) zu Phoenix.


Wobei man bei AMD zwischen Ankündigung/launch und der echten Verfügbarkeit unterscheiden muss, weil da kann locker ein halbes Jahr dazwischen liegen. Dass AMD Phoenix schon zur CES launcht oder vorstellt, wäre sogar möglich :freak:



Laut dem letzten Video von RGT kann man wohl bei Strix Halo hohe Taktraten von über 5Ghz bis Richtung 6 Ghz erwarten:

https://youtu.be/FL49Lhhy8D0?t=163


Mittlerweile sollte klar geworden sein, dass RTG nur spekuliert und das als Fakt oder Insider Quelle verkauft. Letztens erst mit den Raptor Lake refesh SKUs. Oder letztes Jahr, wo er Phoenix mit 16-24 CUs angegeben hat. Der labert nur Müll.

[nagus]

Also ca. 1 Jahr noch bis launch

Man war sich bei AMD ja jetzt nicht mehr sicher, ob man nicht doch mehr Kerne bringen möchte. Aus meiner Sicht geht das nur mit dem 16c N3B-Die für Zen5c, also 8c GR (+X3D) gepaart mit einem N3 16c-Die, ähnlich wie bei Strix Point oder Phoenix 2. Also, 24c mMn incoming etwas später als die normalen Zen5.

bei zen4 war es aber deutlich unter einem jahr - Jänner 2022 - Ende August 2022 Vorstellung / Verkauf ab 27. September 2022.

also 8 -9 Monate ca. dann wäre eine Vorstellung von zen5 im Q1 2024 möglich (Feb/März). Für einen CES Launch event wäre es vermutlich zu früh.

Btw, die ersten A0 engineering samples von ZEN1 kamen ca. zur selben Jahreszeit (Juli 2016) und Launch/Release war dann Anfang März 2017.

AMD sollte auch halbwegs Zeitnah Intels 14 GEN kontern. Glaube nicht, dass die fast ein Jahr später (q3 2024) erst zur Party kommen ;)

Nachtrag: Bei Zen3 waren es ca. 6 Monate (Mai-November) und bei Zen 2 ca. 8-9 monate.

Q1 2024 sollte demnach ziemlich realistisch sein

[HOT]

Auch Strix Point gibts schon als Sample, das find ich heftig. AMD macht wirklich ernst.

[ryan]

AMD sollte auch halbwegs Zeitnah Intels 14 GEN kontern. Glaube nicht, dass die fast ein Jahr später (q3 2024) erst zur Party kommen ;)

Nachtrag: Bei Zen3 waren es ca. 6 Monate (Mai-November) und bei Zen 2 ca. 8-9 monate.

Q1 2024 sollte demnach ziemlich realistisch sein


Phoenix gibt es erst seit Ende Juni, da wird so schnell nichts Neues kommen. Denkbar wäre höchstens ein früher paper launch mit Exklusivrechten für Asus. Das hat dann nur wenig Relevanz.

[Nightspider]

Wenn AMD mit Phoenix Probleme hatte oder die Kapazitäten lieber für Genoa umverteilt wurden, dann muss das absolut keinen Einfluss auf den Nachfolger haben.
Wir wissen ja auch noch immer nicht, ob es wirklich Probleme bei RDNA3 gab, sowohl bei den diskreten GPUs als auch bei den APUs.

AMD hat auf jeden Fall sehr viele Eisen gleichzeitig im Feuer, wenn es bei einem Produkt Probleme gibt wird man nicht alle Ressourcen für das Problem aufwenden sondern sich weiter auf die nächsten Produkte konzentrieren und das Problem versuchen mit wenig Ressourcen zu lösen.

Vielleicht hat AMD sehr zeitig gemerkt das RDNA3 und Phoenix nicht so toll werden und deswegen die Kapazitäten eher zu HPC und Consumer geschoben, und Derivate einegstampft.
Ich will hier nochmal betonen das RDNA3 quasi keinen deut energieeffizienter ist als RDNA2 trotz eines Fullnode Sprunges. Die Treiber wurden jetzt 9 Monate später halbwegs gefixed was den Idle Verbrauch betrifft.

Wir spekulieren schon über RDNA4 und es ist noch nicht mal eine 7800 Karte auf dem Markt.

Meine Hoffnung ist das AMD sich zeitig genug auf die Nachfolger konzentriert hat und Strix Point und RDNA3.5 und RDNA4 einschlagen und erfolgreich werden.

Genoa und Bergamo sind ein großer Erfolg, Zen4 und Zen4c laufen super und AMD bereitet gerade Zen5 Produkte vor, die vielleicht schon im 1.Q 2024 kommen.
AMD scheint fast nur noch nach vorne zu schauen. Der rasante Erfolg gibt Lisa Su Recht.

[robbitop]

Ich habe den Eindruck das liegt zT auch an den Laptop OEMs. 7940HS Laptops sind seit April kaufbar. 7840 Handhelds seit Mai. Aber die Breite des Angebots ist bei Intel auf einem anderen Level. Angeblich weil Intel bei der Integration stark hilft und AMD diese Ressourcen fehlen. Wobei ich das auch ein wenig für eine Ausrede halte, denn die kleinen China Krauter wie GPD und Aya Neo verbauen zeitnah neuste AMD APUs. Wenn die kleinen Krauter das hinbekommen, müssen Größen wie Lenovo, Asus, MSI und HP doch locker können.

[Mangel76]

Ich habe den Eindruck das liegt zT auch an den Laptop OEMs. 7940HS Laptops sind seit April kaufbar. 7840 Handhelds seit Mai. Aber die Breite des Angebots ist bei Intel auf einem anderen Level. Angeblich weil Intel bei der Integration stark hilft und AMD diese Ressourcen fehlen. Wobei ich das auch ein wenig für eine Ausrede halte, denn die kleinen China Krauter wie GPD und Aya Neo verbauen zeitnah neuste AMD APUs. Wenn die kleinen Krauter das hinbekommen, müssen Größen wie Lenovo, Asus, MSI und HP doch locker können.

Bei denen geht es wahrscheinlich eher um Rabatte als Intel-Exklusivpartner.

[ryan]

Ich habe den Eindruck das liegt zT auch an den Laptop OEMs. 7940HS Laptops sind seit April kaufbar. 7840 Handhelds seit Mai. Aber die Breite des Angebots ist bei Intel auf einem anderen Level. Angeblich weil Intel bei der Integration stark hilft und AMD diese Ressourcen fehlen. Wobei ich das auch ein wenig für eine Ausrede halte, denn die kleinen China Krauter wie GPD und Aya Neo verbauen zeitnah neuste AMD APUs. Wenn die kleinen Krauter das hinbekommen, müssen Größen wie Lenovo, Asus, MSI und HP doch locker können.


Von Asus gab es relativ früh 2 Modelle mit 7940HS. Die müssen da irgendeinen Deal haben. Es gibt relativ früh 1-2 showcase Modelle von einem OEM, also meistens Asus, die anderen ziehen erst Monate später nach. Das lief schon öfter so ab und wiederholt sich immer wieder. Die anderen OEMs sind verärgert, liefern würde sie natürlich gerne. Schau dir die Framework Laptops an. Versionen mit Phoenix sind nur vorbestellbar, es fehlen einzig und allein die Phoenix Chips. Die nächste Lieferung wird erst im Q4 bzw. Q1 erwartet.

Dazugekommen sind in dieser Generation Handheld Hersteller. Irgendeinen Deal muss es da geben oder sie werden irgendwie bevorzugt bei der Lieferung.


Übrigens wird wieder offensichtlich, dass das U lineup bei Phoenix eine untergeordnete Rolle bei AMD spielt, es sind fast ausschließlich HS Modelle gelistet. Der Trend war schon bei Rembrandt zu beobachten und scheint sich mit Phoenix weiter zu verstärken. AMDs neuere Generationen verlagern sich immer weiter in den Premium Bereich, wofür sich HS Modelle besser eignen.

Ich meine ist ja klar, AMD hat nicht umsonst ältere CPU und GPU Generationen parallel am laufen, die vom low end bis zur Mittelklase das Angebot auffüllen.

[amdfanuwe]

Die anderen OEMs sind verärgert, liefern würde sie natürlich gerne.
Sicher? Die dürften erst mal bemüht sein ihre Bestände an i-1100 und i-1200 sowie Ryzen 5000 los zu werden, bevor sie neue CPUs ordern.
Und AMD wird ohne Bestellungen nicht Haufenweise Chips auf Verdacht ins Lager legen.
Aus Geizhals Anzahl der gelisteten Modelle:
https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=84709&stc=1&d=1690070599

Also, kauft erst mal den alten Kram auf, dann gibt es auch wieder neues.

[ryan]

Sicher? Die dürften erst mal bemüht sein ihre Bestände an i-1100 und i-1200 sowie Ryzen 5000 los zu werden, bevor sie neue CPUs ordern.



Schau mal hier (https://www.computerbase.de/forum/threads/intel-meteor-lake-cpu-mit-vpu-einheit-fuer-kuenstliche-intelligenz-im-hands-on.2145851/page-2#post-28253300).


AMDs APUs in 2023 war der schlimmste Paperlaunch seit Jahren. Und das sagen hier vor Ort in Taiwan sogar die Notebookhersteller, die haten ziemlich. Den Phoenix+ Refresh kannst dann eigentlich erst für Ende 2024 einplanen, obwohl er wohl wieder Anfang 2024 angekündigt wird ...


Oder wie erklärst du dir denn, dass das Framework Laptop nicht genügend Chips bekommt? Die verkaufen nichts altes ab, alte Bestände gibt es nicht, es gibt nur RPL-P und Phoenix. Die nächste Lieferung ist erst in Q4 bzw. Q1 möglich. Da muss es einen starken Engpass geben, weswegen AMD rationieren muss oder bestimmte OEMs bevorzugt beliefert.

Übrigens gibt es bis heute keinen Treibersupport für die Phoenix iGPU auf der AMD Seite. Der erste Treiber soll noch diesen Monat kommen, siehe hier (https://wccftech.com/amd-radeon-700m-rdna-3-igpu-driver-for-phoenix-apus-to-release-by-end-of-july/). Krass wie lange das dauert.

[Gipsel]

Übrigens gibt es bis heute keinen Treibersupport für die Phoenix iGPU auf der AMD Seite.Dann beziehst Du den Treiber eben in der Zwischenzeit vom Hersteller Deines Geräts. Oder wie laufen die bereits erhältlichen Geräte?
Kann sich noch jemand daran erinnern, daß das bis vor gar nicht so langer Zeit der Standard war und die Hersteller von Notebooks sich extra auf eine Whitelist setzen mußten, damit der Referenztreiber von der AMD-Webseite auf ihren Geräten überhaupt installierbar war (war bei nV das Gleiche)?

[amdfanuwe]

Oder wie erklärst du dir denn, dass das Framework Laptop nicht genügend Chips bekommt?
Wieviel Millionen haben die denn bestellt?

[basix]

Nach den Bergamo Tests stellt sich fast die Frage warum man normale Zen5 Cores anstatt der Dense Cores in den APUs verbauen sollte, vom Release Zeitraum mal abgesehen. (Zen5c wird wohl später fertig als Zen5)

Am Cache hat AMD bei den bisherigen APUs ja sowieso schon gespart und damit Leistung geopfert.

Theoretisch hätte AMD jetzt auch schon Phoenix mit Zen4c neu auflegen können aber dafür mit 12 monolithischen Kernen oder 8 kleinen Zen4c Kernen aber dafür mit Infinity Cache für die integrierte Grafik. Da hätte man viel mehr gewonnen beim 0815 Consumer / Gamer / SteamDeck Markt.

Da frage ich mich auch, ob man sich die Zeit an den APUs mit den normalen Kernen nicht hätte sparen können und direkt mit den Dense Cores in APUs angreifen hätte sollen. Das hätte dann eventuell die Entwicklung letzterer beschleunigt. Phoenix ist ja noch nicht mal wirklich gut verfügbar.
Aber das ist sicherlich auch eine Risikoabwägung gewesen, die Planungen hierfür laufen ja schon seit Jahren.
Max. ST Performance ist auch bei Mobile ein Kriterium. Evtl. takten die Zen 4c/5c Cores nur bis 4.5 GHz und dann ist Ende Feuer, dann ist die ST-Performance schon nicht so prickelnd.

Was sicher stattfinden wird: Mehr als 8x grosse Cores werden wir wohl bei Mobile nicht sehen (ausser so Sachen wie Dragon Range und Strix Halo, welche 2x der normalen CCDs verwenden). MT-Skalierung bei Mobile wird über mehr "c" Kerne realisiert, ähnlich wie es Intel mit den P- & E-Cores macht.

Übrigens wird wieder offensichtlich, dass das U lineup bei Phoenix eine untergeordnete Rolle bei AMD spielt, es sind fast ausschließlich HS Modelle gelistet. Der Trend war schon bei Rembrandt zu beobachten und scheint sich mit Phoenix weiter zu verstärken. AMDs neuere Generationen verlagern sich immer weiter in den Premium Bereich, wofür sich HS Modelle besser eignen.

Muss man die Stückzahlen rationieren, macht solch ein Vorgehen viel Sinn.

Aber es ist schon ein Trauerspiel: AMD hat gute Mobil-Produkte aber sie zu kaufen ist schwer.

[Zossel]

Dann beziehst Du den Treiber eben in der Zwischenzeit vom Hersteller Deines Geräts. Oder wie laufen die bereits erhältlichen Geräte?
Kann sich noch jemand daran erinnern, daß das bis vor gar nicht so langer Zeit der Standard war und die Hersteller von Notebooks sich extra auf eine Whitelist setzen mußten, damit der Referenztreiber von der AMD-Webseite auf ihren Geräten überhaupt installierbar war (war bei nV das Gleiche)?

Das ist allerdings ein reines Windows-only Thema.

[ryan]

Dann beziehst Du den Treiber eben in der Zwischenzeit vom Hersteller Deines Geräts. Oder wie laufen die bereits erhältlichen Geräte?
Kann sich noch jemand daran erinnern, daß das bis vor gar nicht so langer Zeit der Standard war und die Hersteller von Notebooks sich extra auf eine Whitelist setzen mußten, damit der Referenztreiber von der AMD-Webseite auf ihren Geräten überhaupt installierbar war (war bei nV das Gleiche)?


Ja natürlich, nur bekommt man eben nicht die neuesten Treiber. Hersteller Treiber hinken immer hinterher, werden selten aktualisiert. Bei Intel funktioniert das doch auch.

[Gipsel]

Ja natürlich, nur bekommt man eben nicht die neuesten Treiber. Hersteller Treiber hinken immer hinterher, werden selten aktualisiert.Hast Du nicht selber geschrieben, daß der erste offizielle AMD-Treiber noch diesen Monat kommen soll? Wie relevant ist das Problem also überhaupt (selbst wenn er erst im August kommen sollte)?

[ryan]

Hast Du nicht selber geschrieben, daß der erste offizielle AMD-Treiber noch diesen Monat kommen soll? Wie relevant ist das Problem also überhaupt (selbst wenn er erst im August kommen sollte)?


Wann war der launch von Phoenix? Und wann folgt der erste Treiber? Der Treiber hat am launch Tag verfügbar zu sein und wenn nicht, dann eben eine Woche später. Aber doch nicht ein halbes Jahr später. Ich meine wenn man nach deiner Sichtweise geht, kann AMD gerne bis Ende des Jahres warten, weil dann vielleicht eine Handvoll Geräte verfügbar sein werden und es dann relevant wäre. Das ist dann in Ordnung, nur nicht AMD kritisieren, ja nicht zu viel verlangen hier.

Intel könnte sich das nicht erlauben, nach einer Woche würden alle Seiten darüber berichten und Intel zur Veröffentlichung nötigen. Das ist damals bei Rocketlake-S passiert, der Treiber kam 4 Tage später....nachdem es erste Jammer News (https://videocardz.com/newz/intel-awkwardly-forgot-to-release-graphics-drivers-for-rocket-lake) gab.



The company has failed to publish a public graphics driver, even though the series were officially introduced 3 days ago.


Aber irgendwo zeigt es auch, dass die iGPU nicht mehr den großen Stellenwert genießt bei AMD. Große Desktop Versionen gab es seit Jahren nicht mehr und bei den Notebooks gibt es alle 3 Generationen mal ein größeres Performance Update. Gefühlt erst dann wenn sie müssen, wenn Intel zu nah rankommt mit ihren iGPUs. Dazwischen wird nur das Nötigste getan.

[Gipsel]

Wann war der launch von Phoenix?Seit wann sind Geräte erhältlich? Und es gab Treiber (halt nur nicht direkt von AMD). Bei dem zitierten Intel-Beispiel gab es keine (war halt Desktop und keine nicht separat erhältliche Mobil-CPU/APU wo man die vom Notebook-/Handheld Anbieter bekommen kann).

[vinacis_vivids]

Zen5 Spekulation
sQuzgvJ-dPc

Cinebench 23 pts (Zen5 - Engineering Sample)
16C = 49.000
12C = 36.000
8C = 23.000
6C = 17.000

Vergleich:
7950X 16C = 38.000
12900K = 27.000

Das wäre ein Boost von mind. +28% ggü. dem Zen4 7950X 16C. :eek:

[ChaosTM]

Diese "destroys everything" oder "changes everything" Videos nehme ich schon aus Prinzip nicht wirklich ernst.

[robbitop]

Das wären 28%. 16c vs 16 c. Das wäre (bei gleicher Kernanzahl) in der Tat ein sehr hoher Sprung.

[Der_Korken]

Cinebench 23 pts (Zen5 - Engineering Sample)
16C = 49.000
12C = 36.000
8C = 23.000
6C = 17.000

Fragt sich, warum der 16C auf die doppelte 8C-Performance nochmal 6,5% drauflegt. Normales Verhalten wäre eher, dass es knapp weniger als 1:1 mit Kernen skaliert, selbst wenn bei festem Takt (dynamisch würde der 8C sogar höher takten, weil mehr PPT pro Kern).

Ansonsten wäre alles >20% in MT bei gleicher Kernzahl sehr gut imho. Zen 4 hat in MT gerade erst einen massiven Sprung gemacht, weil durch den geringen Verbrauch von N5 der Takt in MT viel stärker gestiegen ist als in ST.

Edit: Damit sich das nicht jeder angucken muss: ST-Socres "mid to high 2K", d.h. ST steigt ähnlich stark wie MT. Hätte ja auch sein können, dass AMD das Backend so absurd breit macht, dass die Kerne nur mit 2T pro Core schneller werden :D

[basix]

Fragt sich, warum der 16C auf die doppelte 8C-Performance nochmal 6,5% drauflegt. Normales Verhalten wäre eher, dass es knapp weniger als 1:1 mit Kernen skaliert, selbst wenn bei festem Takt (dynamisch würde der 8C sogar höher takten, weil mehr PPT pro Kern)

89W PPT vs. 240W PPT ;)

[Der_Korken]

89W PPT vs. 240W PPT ;)

Ja, so kann man das rekonstruieren. Aber warum sollte man so testen? Finde das macht die Zahlen fishy.

[basix]

Der grosse 16 Kerner wird sicher bei 240W laufen (siehe 7950X). Beim 8-Kerner kommt es aufs Modell drauf an und welche Taktraten max. anliegen (TDP, Boost-Clock). Vielleicht sind die Zen 5 CPU super Clocker und das 8C Modell läuft mit 8C All-Core im 5.5 GHz Taktmaximum und der 16 Kerner bei 5.9 GHz. Who knows.

Die Unterschiede 12C zu 16C sowie auch 8C zu 6C deuten zumindest ebenfalls in diese Richtung. Die Dinger könnten einfach in ihr Clock Limit laufen.

Anyways: We will see ;)

[MSABK]

Ich bin eher auf die dicken APUs gespannt.:)

[TheAntitheist]

Ja, so kann man das rekonstruieren. Aber warum sollte man so testen? Finde das macht die Zahlen fishy.
du wirst schon Recht haben, natürlich sind die Merkwürdig. Auch wenn der 16C mehr Takt haben sollte, das skaliert nicht alles 100%. Die Zahlen sind mal wieder fake, AMD wird overhyped und dadurch wird die Enttäuschung umso höher sein

und der 16C ist ja auch eine APU im Prinzip. hast ja alles dabei. CPU, GPU und die Northbridge.

[reaperrr]

Der grosse 16 Kerner wird sicher bei 240W laufen (siehe 7950X). Beim 8-Kerner kommt es aufs Modell drauf an und welche Taktraten max. anliegen (TDP, Boost-Clock). Vielleicht sind die Zen 5 CPU super Clocker und das 8C Modell läuft mit 8C All-Core im 5.5 GHz Taktmaximum und der 16 Kerner bei 5.9 GHz. Who knows.

Die Unterschiede 12C zu 16C sowie auch 8C zu 6C deuten zumindest ebenfalls in diese Richtung. Die Dinger könnten einfach in ihr Clock Limit laufen.
Gut möglich, dass AMD hier schon mögliche SKUs (9950X, 9900X, 9700X und 9600(X)) getestet hat und die Taktabstände vielleicht auch um 100 MHz je SKU höher ausfallen als bei der Zen4-Gen.
Also z.B.
9950X - 5.3 all-core, 6.0 Turbo
9900X - 5.1 all-core, 5.8 Turbo
9700X - 4.9 all-core, 5.6 Turbo
9600X - 4.7 all-core, 5.4 Turbo

Wenn der IPC-Sprung so groß ist, schadet es auch nicht, wenn die niedrigeren SKUs beim Takt gegenüber Zen4 weniger/nicht zulegen, und dann helfen die größeren Taktabstände, um die teureren SKUs noch etwas attraktiver zu machen.

[Der_Korken]

Werden mit engineering samples wirklich geplante SKUs simuliert? Ich hätte eher gedacht, dass man ein 16C-Sample nimmt und das mal mit verschiedenen Kern-Configs durchbencht. Eventuell gar mit fixem Takt und Spannung und ohne für jede Kernzahl vorher im BIOS das PPT anzupassen.

[reaperrr]

Werden mit engineering samples wirklich geplante SKUs simuliert? Ich hätte eher gedacht, dass man ein 16C-Sample nimmt und das mal mit verschiedenen Kern-Configs durchbencht. Eventuell gar mit fixem Takt und Spannung und ohne für jede Kernzahl vorher im BIOS das PPT anzupassen.
Zen5 ist nicht mehr so weit weg, soll vmtl. zur CES vorgestellt werden und spätestens Anfang Q2 rauskommen.
Da werden die auch bei der SKU-Gestaltung schon relativ weit sein. AMD will schließlich auch wissen, wie die jeweilige SKU mit den jeweiligen Taktraten/PTs ca. performen würde.

[Zossel]

Fragt sich, warum der 16C auf die doppelte 8C-Performance nochmal 6,5% drauflegt.

Die Zahlen sind stark gerundet und du rechnest darauf Pipi Prozente.

Hast du keine Lehrer gehabt die dir für unsinnige Genauigkeiten Punkte in Klausuren abgezogen haben?

[HOT]

https://www.pcgameshardware.de/CPU-CPU-154106/News/TSMC-Apple-3-nm-Fertigung-gebucht-Jahr-1426228/
Damit dürfte AMDs Turin compact auch erst in Richtung Q4 erscheinen.

[w0mbat]

Ich glaube nicht, dass Apple die komplette N3B & N3E Kapazität gebucht hat.

[Zossel]

https://www.pcgameshardware.de/CPU-CPU-154106/News/TSMC-Apple-3-nm-Fertigung-gebucht-Jahr-1426228/
Damit dürfte AMDs Turin compact auch erst in Richtung Q4 erscheinen.

Warum macht man zu etwas was schon seit Jahren so läuft so einen Aufriss?

[Der_Korken]

Die Zahlen sind stark gerundet und du rechnest darauf Pipi Prozente.

Hast du keine Lehrer gehabt die dir für unsinnige Genauigkeiten Punkte in Klausuren abgezogen haben?

Die Pipi-Prozente sind ein Vielfaches vom erwarteten Rundungsfehler. Außerdem ist es hier egal wie man rundet, selbst bei 48500 vs 23499 ist die Skalierung für 16C bei >100% und das finde ich komisch. 7950X vs 7700X sind in CB23 "nur" 89% Skalierung. Erst auf den 7700 non-X sind es +106% (49k vs 23k sind +113%).

[Nightspider]

Wenn dieses "Jahr" schon im 1. oder 2. Quartal begann, dann muss das gar nix bedeuten.

Wir wissen nicht wann die Belichtungsmaschinen bei TSMC angelaufen sind.
Die müssen auf jeden Fall schon seit Monaten laufen damit die fertigen Produkte im September auf den Markt kommen können.

Wann beginnt das Jahr? Sobald die erste Charge der finalen Revision in kleiner Stückzahl schon viele Wochen vor der richtigen Massenproduktion vom Band fielen?

Das ist ein sehr schwammig definierter Zeitraum.

[r3ptil3]

Zen5 Spekulation

Cinebench 23 pts (Zen5 - Engineering Sample)
16C = 49.000
12C = 36.000
8C = 23.000
6C = 17.000

Vergleich:
7950X 16C = 38.000
12900K = 27.000

Das wäre ein Boost von mind. +28% ggü. dem Zen4 7950X 16C. :eek:

https://www.techspot.com/articles-info/2535/bench/CB23-1.png

13-14% zwischen 7600X und Zen5 6C.

Muss jeder für sich selber entscheiden, ob das nach 1.5 Jahren ausreichend ist.

[Zossel]

Die Pipi-Prozente sind ein Vielfaches vom erwarteten Rundungsfehler.

Mehr als die Botschaft das die neue CPU noch mal mehr als nur ein bisschen zulegt würde ich da nicht raus lesen. Also nichts was für einen Dreisatz reicht.

[latiose88]

Also man kann sagen so breit wird amd die CPU doch nicht gemacht haben. Wie schon einer geschrieben hatte würde es sonst bei 2 Kerne Skalierung stehen. Dem ist ja nicht so. Also gehe auch mal davon aus das das meiste durch den erhöhten takt von statten geht. Durch den 4nm also verbesserten 5 nm hat man mehr Luft für nen höheren takt. Und wenn diese CPU dann wirklich 240 Watt brauchen würde wäre ja echt schrecklich. Das ist ja ne falsche richtung. Ich ging ja von 200 Watt weiterhin aus. So das ich dann auf die 5 % verzichten kann um auf 142 Watt zu kommen so mein Plan bei Zen 5. Aber wenn das nun anderst kommt, würde ich ja nicht nur 5 % sondern sogar 10 % an leistung verlieren.

Aber gut werden ja eh sehen wie es kommt und ob sich auf Zen 5 zu warten gelohnt hatte. Zen 4 war mir zu wenig gewesen. Ich spekuliere halt auf noch mehr leistung. Ich hoffe das sich das ganze gelohnt hat. Denn das Geld ist bis dahin zusammen gespart für nen kompletten am5 system. Soll sich ja zum am4 richtig abgeben, sonst mache ich den Aufwand nicht.
Zen 5 wird hoffentlich die Rettung sein für mich. Zen 4 war es das jedenfalls nicht gewesen.

Und ich bin gespannt ob meine Anwendung noch eine ipc Steigerung sehen wird, weil bei Zen 4 war es das jedenfalls nicht gewesen. Der reine cpu takt war die Erlösung gewesen. 6 GHz allcore wird bestimmt richtig rein hauen gegenüber 5,1 GHz.
Alleine von 4 auf 5,1 GHz waren es ja schon 20 % gewesen.
Ist also nicht ganz diese starke Steigerung.

Bei threadripper pro wird 6 GHz wohl bestimmt hart werden. Weil Temperaturen und Stromverbauch wird da explodieren. Temps sind dauer Zustand 100 Grad und mehr dann und Stromverbauch bei 500 Watt ganz sicher.

Das will sich dann ne private person ganz sicher nicht mehr antuen. Bleibt halt die frage ob es beim 8950x mit seinen 240 Watt auch so sein wird.

Ich wollte das schon nicht bei Intel also wird es das auch bei AMD so sein. Aber im Gegensatz zu Intel kommt bei amd trotz der starken drossel kommt die leistung bei AMD dennoch rüber. Bei Intel würde diese sehr stark einbrechen.

Das lobe ich mir bei AMD so.
Woher ich das weiß selbst mit Intel mal ausprobiert. Wenn durch die starke drossel es dann keine 5 sondern 50 %weniger Leistung dabei raus kommt, dann ist das mir ein Dorn im Auge.

[iamthebear]

Also irgendetwas stimmt mit den Zahlen nicht. "Mid to high 2000" würde ich um die 2600-2800 interpretieren. Das wären 30% mehr als Zen4. Beim 16 Kerner stimmt das ja noch aber beim 6/8 Kerner nicht mehr.

Einzig mögliche Erklärung die ich sehe:
Die 6/8 Kerner kommen mit deutlich niedriger TDP und sind deshalb langsamer.

[vinacis_vivids]

https://www.techspot.com/articles-info/2535/bench/CB23-1.png

13-14% zwischen 7600X und Zen5 6C.

Muss jeder für sich selber entscheiden, ob das nach 1.5 Jahren ausreichend ist.

Ich komme vom 3900X 12C ~18.000 pts auf ~49.000 pts +172%

Mir wäre ein 16C Zen5 wohl wert für ein Upgrade (leistungsmäßig). Mal schauen wie die Preise dann werden.

[latiose88]

Oder aber die 6 und 8 Kerne leiden unter massiven Temperatur Problemen. Weshalb dann die CPU gedrosselt wird und damit auch die Leistung massiv sinkt. Das werden wir ja von AMD noch früh genug erfahren.

[HOT]

Da könnte auch einfach der Samplestatus sein. Das hat keine Aussage. Es zeigt halt nur, dass es in Richtung 30% mehr Performance geht, ungefähr - was echt ne Menge ist und die frühere AMD-Mitarbeiteraussagen erklärt, warum man sich auf Zen5 freuen sollte.

[Zossel]

Da könnte auch einfach der Samplestatus sein. Das hat keine Aussage. Es zeigt halt nur, dass es in Richtung 30% mehr Performance geht, ungefähr - was echt ne Menge ist und die frühere AMD-Mitarbeiteraussagen erklärt, warum man sich auf Zen5 freuen sollte.

Vielleicht sollte man dieses Forum von 3dcenter in 3satzcenter umbenennen :-)

BTW: Gibt es eigentlich Infos/Gerüchte über neue PCIe-IO-Extender/PCIe-Switche die mit den neuen CPUs kommen könnten? Oder das die neuen CPUs mehr PCIe-Lanes haben?

[Nightspider]

Zen5 soll ja angeblich Ladder-L3-Cache bieten. Einen großen L3 der dennoch kurze Latenzen bietet.

Jetzt könnten wir anfangen zu spekulieren welche Änderungen AMD beim V-Cache der 3. Generation umsetzen wird.

Wird es wieder ein 64 MB Slice geben? Wird es ein 96MB Slice in einem neuen Prozess?
Werden es zwei 64 MB Slices? :naughty:

[HOT]

Das einzige, was Zen5 noch bringen könnte wäre ne direkte Verbindung zwischen den CCDs, um das Caching effizienter zu machen. Würde ja auch zur Ladder passen. Ansonsten ändert sich überhaupt nichts, AM5 bleibt, das IOD wird bleiben, gibt wieder 1 oder 2 CCDs pro Package. Zen6 soll ne neue Plattform CXL3.0 samt entsprechendem Speicher bringen offenbar, mal sehen. AMD hatte CXL-Unterstützung ja auch für Consumer-Plattformen angekündigt.

[Nightspider]

Ansonsten ändert sich überhaupt nichts

Wenn der Aufbau des Caches anders ist muss sich der V-Cache definitiv auch ändern.

Hast du nicht damals auch gesagt das sich der IO bei Zen4 nicht ändern wird, obwohl er es getan hat?

Wobei ich selbst die Wahrscheinlichkeit dieses mal bei Zen5 als sehr hoch erachte, das der IO bleibt, weil zwischen Zen4 und Zen5 wenig Zeit vergangen ist.

[latiose88]

so so Zen 6 soll ne neue Plattform werden,woher weist du das denn oder rätst du nur?
Könnte ja sein das AMD unter richtiger Protest der Fans dazu genötigt fühlt Zen 6 doch noch für AM5 raus zu bringen wer weis oder liegt es an den extras das es ne neue Plattform nötig gemacht wird und heißt das etwa da kommt dann DDR6 dann anstatt DDR5 raus zu bringen.Was sagst dh denn dazu oder gibt es indizerin die diese Aussage untermauern?

[HOT]

Wenn Zen6 CXL unterstützt wirds garantiert ne neue Plattform geben. Ich denke aber, wie werden vorher noch nen Zen5 Refresh in N3X sehen.

Nightspider
Der VCache wird dann auch Ladder, aber das bleibt dann auf einem CCD. Es würde nur effizienter, weil die Latenz zum anderen CCD drasdisch sinkt.

[CrazyIvan]

Zen5 soll ja angeblich Ladder-L3-Cache bieten. Einen großen L3 der dennoch kurze Latenzen bietet.

Jetzt könnten wir anfangen zu spekulieren welche Änderungen AMD beim V-Cache der 3. Generation umsetzen wird.

Wird es wieder ein 64 MB Slice geben? Wird es ein 96MB Slice in einem neuen Prozess?
Werden es zwei 64 MB Slices? :naughty:

Bei dieser Ladder bin ich immer noch skeptisch:
Ich verstehe darunter, dass man dem Ring einige Querverbindungen spendiert, die sich nicht kreuzen. Der aktuelle Ring im CCD wird vermutlich aus 10 Teilnehmern bestehen (8 Kerne + 2 IFoP).
Wenn man vereinfacht von 8 Teilnehmern ausgeht, dann liegt der mittlere Hop-Count für den Ring bei 2,3. Der würde bei einer "Leiter"-Topologie auf 2,0 sinken - also gerade mal 15% für eine Erhöhung der Verbindungen um 25% (10 statt 8). Klingt für mich erst einmal nicht so toll. Natürlich wirkt es sich hinsichtlich Congestion positiv aus, wenn wirklich viele Kerne mit einander kommunizieren wollen. Aber die Mehrverdrahtung gibt es halt nicht geschenkt.


Ring:
O - O
| |
O O
| |
O O
| |
O - O

Ladder:
O - O
| |
O - O
| |
O - O
| |
O - O

[reaperrr]

Ich denke aber, wie werden vorher noch nen Zen5 Refresh in N3X sehen.
3,5fache Leakage in Kauf nehmen für 5% mehr Takt ggü. N3P?
Wohl kaum.

Zen5 kommt in N4P und N3B oder -E (Zen5c-16C-Chiplet), danach kommt direkt Zen6 in N3P (Desktop/Mobile), und Zen6c eventuell schon in N2, wenn alles glatt geht.

Zen6 wird kein großes Architektur-Update, das einzige was Zen6 evtl. davon abhalten könnte, schon 15-18 Monate nach Zen5 zu erscheinen (von China mal abgesehen...), wäre wenn sowohl Consumer als auch Server mit Zen6 auch exklusiv auf neue IO-Dies und Plattformen umsteigen (durchaus möglich) und diese länger reifen müssen.

Aber wie gesagt, N3X ist so gut wie auszuschließen und Zen5-8C-CCD-Shrink auf irgendeine N3-Variante wahrscheinlich auch.
Wenn für AM5 nach Zen5X3D noch was kommt, dann direkt Zen6-Chiplets mit AM5-kompatiblem IOD.

[Gipsel]

Bei dieser Ladder bin ich immer noch skeptisch:
Ich verstehe darunter, dass man dem Ring einige Querverbindungen spendiert, die sich nicht kreuzen. Der aktuelle Ring im CCD wird vermutlich aus 10 Teilnehmern bestehen (8 Kerne + 2 IFoP).
Wenn man vereinfacht von 8 Teilnehmern ausgeht, dann liegt der mittlere Hop-Count für den Ring bei 2,3. Der würde bei einer "Leiter"-Topologie auf 2,0 sinken - also gerade mal 15% für eine Erhöhung der Verbindungen um 25% (10 statt 8). Klingt für mich erst einmal nicht so toll. Natürlich wirkt es sich hinsichtlich Congestion positiv aus, wenn wirklich viele Kerne mit einander kommunizieren wollen. Aber die Mehrverdrahtung gibt es halt nicht geschenkt.
So eine einfache Leiter ist schlechter als eine "twisted ladder" (die hat genau so viele Verbindungen), die AMD vermutlich einsetzen würde.
O - O
| |
O O
| X |
O O
| |
O - ODie maximalen Hops sind da nur 3 statt 4, die 4 Eckkerne können 2 Kerne mit einem Hop erreichen, 3 Kerne mit 2 Hops und die übrigen 2 Kerne mit 3 Hops, die mittleren Kerne erreichen 3 Kerne mit einem Hop und die restlichen 4 Kerne mit 2 Hops, was im Mittel dann 1,785 Hops ergibt. Ein Ring mit 8 Teilnehmern liegt bei 2,285 und ist somit 28% schlechter. Dafür lohnt sich vermutlich 25% mehr Verdrahtungsaufwand. ;)
Wie Du gesagt hast, hat der Ring vermutlich 10 Teilnehmer (2x IFOP), nicht nur 8, so daß da die Kalkulation nochmal etwas anders aussieht (mittlere Entfernung sind dann schon 2,78 Hops).
Im Prinzip wird man bei einer Leiter (egal in welcher Variation) jeden Knoten mit 3 Verbindungen ausstatten. Und wie man sieht, werden bei einer Leiter / verdrehten Leiter nicht überall alle 3 Verbindungen genutzt, selbst wenn man annimmt, daß die 2 IFOP-Links 2 der 4 freien Verbindungen nutzen würden. Praktisch würde man also mit hoher Wahrscheinlichkeit eine "improved/enhanced twisted ladder" benutzen, die z.B. mit einer zusätzlichen Verbindung den oberen linken Kern direkt mit dem unteren linken verbindet und somit dann quasi eine geschlossenene twisted ladder erzeugt (hat AMD afair bei den alten Opterons auch gemacht und so nutzt man an jedem Knoten alle 3 möglichen Verbindungen). Das verringert die durchschnittliche Anzahl der Hops noch mal etwas (auch 2 der 4 Eckkerne können alle anderen mit maximal 2 Hops erreichen, die anderen beiden Eckkerne [von denen ein Link zum IFOP geht] brauchen nur noch zu einem Kern 3 Hops, alle anderen gehen auch in maximal 2) auf dann nur noch 1,64 Hops. Das wäre schon eine merkliche Verbesserung zu einem 8er-Ring mit 2,28 (~39% schlechter) oder gar dem 10er-Ring mit 2,78 Hops (69% schlechter). Und wenn die IFOPs nicht Teil dieses Netzwerks sind, wären es gar nur noch 1,57 Hops (weil man dann die Leiter auf beiden Seiten schließen kann). Denn so ein wenig bezweifle ich noch, daß die Verbindungen zu den IFOP-Links Teil des Rings sind, aber egal.
Ein 10er-Ring hätte 10 Verbindungen (inklusive IFOPs, 2,78 Hops), ein 8er-Ring logischerweise 8 (ohne IFOPs, 2,28Hops), die Leitern jeweils 10 (oder 12 mit Verbindungen zu 2 IFOPs, twisted Variante 1,78 Hops), die verbesserten/geschlossenen Versionen dann wahlweise 12 (IFOPs nicht Teil des Ganzen, 1,57 Hops) oder 13 (inklusive IFOPs im Netzwerk, 1,64 Hops).

Variante 1 - IFOP sind nicht Teil des Netzwerks:
2,28 Hops vs. 1,57 Hops (45% Verbesserung und +100% Bisection-Bandbreite) bei 12 vs. 8 Verbindungen. Lohnt sich.*

Variante 2 - IFOP sind Teil des Netzwerks:
2,78 Hops vs. 1,64 Hops (69% Verbesserung und +75% Bisection Bandbreite) bei 13 vs. 10 Verbindungen. Lohnt sich noch mehr.

*): Soweit ich weiß, leidet Zen4 nicht gerade unter zu geringer L3-Bandbreite. Im Prinzip könnte man da fast vermuten, daß AMD dann vom (gerüchteweisen) Doppelring auf einfache Verbindungen gehen würde, also die Breite der einzelnen Verbindung jeweils halbiert, was dann die Bisection-Bandbreite konstant halten würde. Aber das ist dann vielleicht auch schon zu viel gespart. Eventuell senkt man auch den Takt des Caches ein wenig (momentan läuft der doch mit vollem Takt des gerade schnellsten Kerns), damit der Stromverbrauch in Grenzen bleibt.

[latiose88]

hm was hat das mit den Hops zu tuen,ist das bei AMD aktuell bei jeder CPU so also egal ob Zen 3,Zen 4 oder das kommende Zen 5?

[Gipsel]

Guten Morgen! (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=13370319#post13370319) ;)

[Der_Korken]

Die Frage, die ich mir bei solchen Diskussionen immer stelle ist, warum Intel sowas nicht schon längst benutzt, denn dort hatte man schon bei Comet Lake 10 Kerne, plus noch eine iGPU. Von Raptor Lake mit 12 L3-Slices (plus Gedöns) ganz zu schweigen.

[Gipsel]

Die Frage, die ich mir bei solchen Diskussionen immer stelle ist, warum Intel sowas nicht schon längst benutzt, denn dort hatte man schon bei Comet Lake 10 Kerne, plus noch eine iGPU. Von Raptor Lake mit 12 L3-Slices (plus Gedöns) ganz zu schweigen.Es ist eben deutlich schwieriger, sowas zu verbauen, insbesondere latenzarm. Bei intel hat man ja auch bei deren Meshes gesehen, daß die Latenz deutlich leiden kann, selbst wenn man weniger Hops benötigt. Die Anzahl der Hops ist eben längst nicht Alles.
Insofern ist es auch eine ernstzunehmende Möglichkeit, daß das Alles nur ein Mißverständnis seitens AdoredTV ist bzw. noch etwas Anderes meint als der Wechsel von einer Ringbus-Topologie zu einer (twisted) Ladder bei der Verbindung der Cache-Slices. Vielleicht hat sich ja nur irgendjemand etwas unklar ausgedrückt, als er von einer verbesserten "latency ladder" mit Zen5 sprach (und damit einfach eine optimierte Cache-Hierarchie [Größe/Latenz] meinte, ohne an Implementationsdetails überhaupt zu denken) und dann kommt sowas raus. Also quasi eine Art Version von "Stiller Post". Wer weiß?

[Zossel]

Die Frage, die ich mir bei solchen Diskussionen immer stelle ist, warum Intel sowas nicht schon längst benutzt, denn dort hatte man schon bei Comet Lake 10 Kerne, plus noch eine iGPU. Von Raptor Lake mit 12 L3-Slices (plus Gedöns) ganz zu schweigen.

Eigentlich suche ich seit ein paar Jahren den roten Faden im Design der Intel CPUs und finde ihn einfach nicht.
Seitdem Intel im x64 Markt ernsthafte Konkurrenz hat laufen die nur noch wie ein aufgeschrecktes Hühnchen kreuz und quer durch die Gegend.

[Zossel]

Insofern ist es auch eine ernstzunehmende Möglichkeit, daß das Alles nur ein Mißverständnis seitens AdoredTV ist bzw. noch etwas Anderes meint als der Wechsel von einer Ringbus-Topologie zu einer (twisted) Ladder bei der Verbindung der Cache-Slices. Vielleicht hat sich ja nur irgendjemand etwas unklar ausgedrückt, als er von einer verbesserten "latency ladder" mit Zen5 sprach (und damit einfach eine optimierte Cache-Hierarchie [Größe/Latenz] meinte, ohne an Implementationsdetails überhaupt zu denken) und dann kommt sowas raus. Also quasi eine Art Version von "Stiller Post". Wer weiß?

Denkbar wäre auch das mit so einer Topologie ein höherer Core-Count pro L3 vorbereitet wird.

[CrazyIvan]

@Gipsel
Ja, an eine Twisted Ladder hatte ich aus naheliegenden Gründen auch schon gedacht. Vermutlich erhöht das aber den Aufwand erheblich, da die Bahnen sich kreuzen müssen - Interferenzen und so.
Deine Mutmaßung bzgl. stiller Post halte ich für sehr wahrscheinlich. Man sagt Zen5 doch schon seit einiger Zeit größere Änderungen an der Cache-Hierarchie und damit ggf. auch den Latenzen der einzelnen Stufen nach.
Falls es wirklich 10 Nodes sind, dann wäre eine "Sparse Ladder" mit nur einer Verbindung zwischen den mittigen Nodes sicher ein gutes Kosten/Nutzen-Verhältnis.

Off Topic:
Ich habe schon öfter danach gesucht, aber gibt es im Web wirklich keinen Hop-Calculator, bei dem man vorher irgendwie die Topologie, Anzahl Nodes, etc. angeben kann? Das Ausgezähle wird bei mehr als 4 Teilnehmern und/oder komplexer Topologie schnell anstrengend.

[Nightspider]

Red Gaming Tech hyped Zen5 ja ganz schön.

Wenn da tatsächlich 25-30% mehr Leistung herauskommen sollten hat Intel weiterhin keine Chance.

[robbitop]

Intel schläft ja nicht. Sind ja für Arrow Lake und Lunar Lake bereits neue P Cores geplant.

[iamthebear]

Ich darf mal daran erinnern, dass Zen5 erst Ende 2024 kommt. Zu dieser Zeit sollte dann (falls es nicht weitere Verzögerungen gibt) auch Arrow Lake bereit sein.

Bei 2 Node Jumps auf einmal gegen 0 von AMD wäre müsste ARL schon sehr hart failen, damit sie nicht unter Low TDP Bedingungen deutlich aufholen würden.

Was den Desktop bzw. Gaming im Speziellen angeht wird man sehen.

Ich sehe in Zen5 aber ehrlich gesagt nicht das große Gaming Monster wie damals bei Zen3:
.) L3 bleibt gleich groß und es werden vermutlich wieder die Modelle ohne VCache zuerst launchen
.) Bei L2 und DRAM Anbindung wird sich auch nicht viel ändern außer vielleicht etwas mehr Speichertakt
.) Es bleibt weiterhin bei 8 Kernen pro CCD. Bei zukünftigen Spielen ist das aber vermutlich schon nicht mehr ideal und alles über 8 Kernen hat das Problem der 2 CCDs und nicht geshartem L3.

Was Arrow Lake angeht kann ich nicht viel dazu sagen, da wir noch zu wenig wissen. Falls Intel auf Adamantine für die CPU Cores setzt könnte das jedoch einen ähnlichen Boost wie VCache bei AMD auslösen.

[w0mbat]

Ich sehe Zen 5 eher Anfang 2024, bzw. H1.

[Nightspider]

Ich darf mal daran erinnern, dass Zen5 erst Ende 2024 kommt.

Im Moment deutet alles auf das 1. bis 2. Quartal hin.

[reaperrr]

Bei 2 Node Jumps auf einmal gegen 0 von AMD wäre müsste ARL schon sehr hart failen, damit sie nicht unter Low TDP Bedingungen deutlich aufholen würden.
N4P ist elektrisch zu N5 ca. so wie N5 zu N7P, und fast so gut wie N3B. Die Packdichte steigt kaum, aber elektrisch ist es zumindest knapp ein HalfNode-Sprung, nach heutigen Maßstäben.

Daran, dass die Angstrom-Prozesse auf Sicht (ab 18A) richtig gut werden habe ich keine Zweifel, aber ARL wird für den fetten IPC-Zuwachs m.E. auch mit einem fetten Transistorzahl-Anstieg bezahlen, und die Kombination aus "deutlich mehr Transistoren" und "neuer, noch nicht so ausgereifter Prozess" macht es für mich unsicher, ob man wirklich gleich den Perf/W-Sprung sehen wird, den man von 2 Node Jumps erwarten würde.

[robbitop]

Ich darf mal daran erinnern, dass Zen5 erst Ende 2024 kommt. Zu dieser Zeit sollte dann (falls es nicht weitere Verzögerungen gibt) auch Arrow Lake bereit sein.

Bei 2 Node Jumps auf einmal gegen 0 von AMD wäre müsste ARL schon sehr hart failen, damit sie nicht unter Low TDP Bedingungen deutlich aufholen würden.

Was den Desktop bzw. Gaming im Speziellen angeht wird man sehen.

Ich sehe in Zen5 aber ehrlich gesagt nicht das große Gaming Monster wie damals bei Zen3:
.) L3 bleibt gleich groß und es werden vermutlich wieder die Modelle ohne VCache zuerst launchen
.) Bei L2 und DRAM Anbindung wird sich auch nicht viel ändern außer vielleicht etwas mehr Speichertakt
.) Es bleibt weiterhin bei 8 Kernen pro CCD. Bei zukünftigen Spielen ist das aber vermutlich schon nicht mehr ideal und alles über 8 Kernen hat das Problem der 2 CCDs und nicht geshartem L3.

Was Arrow Lake angeht kann ich nicht viel dazu sagen, da wir noch zu wenig wissen. Falls Intel auf Adamantine für die CPU Cores setzt könnte das jedoch einen ähnlichen Boost wie VCache bei AMD auslösen.

Also ich weiß nicht, ob Cache jetzt so indikativ für die Gamingperformance ist. Insbesondere in der VCache Version ist das Cache Setup bei Zen ggf. einfach schon sehr gut ausbalanciert und kein echter Bottleneck mehr.

Man schaue sich an, was L2 Cache Vergrößerung bringt. Insbesondere unter Berücksichtigung von sqr2 für die Reduktion der Missrate und des Gesetz des sinkenden Grenzertrags.

Sunny Cove -> Willow Cove 512 kiB -> 1,25 MiB (fast Faktor 2,5) brachte Taktnormiert nicht so viel
Golden Cove -> Raptor Cove 2 MiB (Faktor 2) brachte taktnormiert 3%
Zen 3 -> Zen 4 512 kiB -> 1 MiB brachte taktnormiert laut AMD ~2-3% (auf der AMD slide schwer zu erkennen)

Ich würde sagen, dass man die L2 Cache Größe primär erhöht um die Fabric zwischen den Kernen zu entlasten, weil es dort immer mehr Teilnehmer (Kerne) gibt.

Dass es pro CCX weiterhin "nur" 8 Kerne gibt ist wahrscheinlich kaum problematisch, da Spiele eh nicht wirklich effektiv über 8 Cores / 16 Threads hinaus skalieren.
Der Vorteil am CCX ist, dass die Teilnehmeranzahl relativ begrenzt ist und man so die L3 Cache Latency noch schön niedrig halten kann, was für die Spieleperformance viel wichtiger ist.
Dinge die stark parallelisiert sind hingegen leiden nicht so sehr an höherer Inter CCX Latency. Eigentlich ist das ein sehr guter und sehr bewusster Kompromiss. Den CCX größer zu machen bedeutet halt auch Latenzen zu erhöhen und das ist nicht gut für Spiele (und/oder man muss die Hitrate lokal am Kern erhöhen damit das geht -> und da bezahlt man dann mit lokalem Cache der dummerweise mit modernen Fertigungsprozessen nicht mehr skaliert).

Ich halte VCache und Adamantium für sinnvoll weil sie das was schlecht skaliert mit günstigeren Fertigungsprozessen aus dem Core nehmen und dank vertikalem Stacking auch die Latenz noch sehr gut machen (Abstand ~ Latenz).

Will sagen: einfach nur stumpf alles breiter und größer machen führt nicht zwangsweise zu einem guten Resultat. Im Ernstfall führt es zu einem unbalancierten, durstigen Kern.
Siehe Samsung's Exynos M Kerne (M1-M5). Viel breiter als die jeweiligen Pendants von ARM aber kaum schneller pro Takt und dafür viel durstiger und auch niedriger getaktet.
Bei ARM sieht man von Generation zu Generation manchmal sogar einen Rückschritt was Breite oder low level Cache angeht (oder auch kürzlich bei Ampere dem ARM CPU Hersteller, dessen eigenen Kerne eine deutliche Verkleinerung des L1 Caches ggü den Neoverse Vorgängern mitgemacht haben und wohl trotzdem schneller sein werden).

Das muss alles wohl ausbalanciert sein. Zen 3 ist ein sehr gutes Beispiel, dass das so ist. Zen 3 hat aus High Level Perspektive fast nichts gegenüber Zen 2 geändert. In der Implementierung war es aber wohl ein Redesign. Und es gab innerhalb der Zen Serie bis dato den höchsten IPC Sprung und noch dazu sehr sehr enegieeffizient (vor allem im mobile Bereich verglichen mit Alderlake mobile). Da hat man einige Dinge in der Implementierung gefunden, die ein bottleneck waren.

AMD passt mit Zen 5 erstmalig die Breite der Decoder seit Zen 1 an - ein großer Schritt. Das macht man nicht für kleine Gains zumal laut der Chipsandcheese Analyse bei Zen 4 die Decoder kein klares Bottleneck waren. Das in Verbindung mit dem bisherigen guten Ausbalancieren der Zen uArchs könnte bedeuten, dass man die Decoder nun auch besser auslasten kann - was widerum bedeuten kann, dass da auch ordentlich etwas bei herauskommt.

Einfach nur high level Daten zu vergleichen, führt IMO nicht zu einer zuverlässigen Prognose. Wenn es so wäre, würden die CPU Hersteller diese high level Daten einfach maxen.

Frage:
"Wieviel Cache/Decoder/ROB etc wollen sie?"

Die Antwort lautet:
"ja / alles" ;D

Was erfrischend im CPU Markt ist, dass sich keiner auszuruhen scheint. AMD liefert alle 2 Jahre ordentliche Leistungssprünge ab und Intel scheint auch wieder langsam in den Tritt gekommen zu sein. Die roadmap ist voller neuer uArchs. Jetzt müssen sie es nur noch schaffen, bei der Fertigung nicht mehr zu failen (oder auf TSMC setzen).

[robbitop]

Daran, dass die Angstrom-Prozesse auf Sicht (ab 18A) richtig gut werden habe ich keine Zweifel
Ehrlich? Bei dem Trackrecord? Wann kam der letzte neue Intelprozess, der auf Anhieb super war? 10 nm (Intel 7) brauchte 4x Anläufe. 14 nm brauchte 2-3 Anläufe). Intel 4 scheint auch 2x Anläufe zu brauchen (wenn es die überhaupt bekommt) um Intel 7 vom Takt schlagen zu können. Je nach Ansicht war der letzte Prozess der ab Einführung nicht enttäuscht hat 22 nm wenn nicht sogar 32 nm. Bei TSMC gab es Taktregressionen IIRC noch nie.
Jetzt will Intel innerhalb von 2 Jahren Intel 4, Intel 20A und Intel 18A bringen. Wow - 3 Fertigungsnodes in 2 Jahren.

Es wäre absolut super, wenn es klappt (weil das Konkurrenz ggü TSMC bringen würde, die die Industrie dringend braucht). Aber bis dato gibt es noch keinen positiven Trackrecord zu neuen Intelprozessen in letzter Vergangenheit (in Bezug auf Taktregression zum Vorgänger).
Zumindest skeptisch kann man da sein IMO.

[fondness]

Ehrlich? Bei dem Trackrecord? Wann kam der letzte neue Intelprozess, der auf Anhieb super war? 10 nm (Intel 7) brauchte 4x Anläufe. 14 nm brauchte 2-3 Anläufe). Intel 4 scheint auch 2x Anläufe zu brauchen (wenn es die überhaupt bekommt) um Intel 7 vom Takt schlagen zu können. Je nach Ansicht war der letzte Prozess der ab Einführung nicht enttäuscht hat 22 nm wenn nicht sogar 32 nm. Bei TSMC gab es Taktregressionen IIRC noch nie.
Jetzt will Intel innerhalb von 2 Jahren Intel 4, Intel 20A und Intel 18A bringen. Wow - 3 Fertigungsnodes in 2 Jahren.

Es wäre absolut super, wenn es klappt (weil das Konkurrenz ggü TSMC bringen würde, die die Industrie dringend braucht). Aber bis dato gibt es noch keinen positiven Trackrecord zu neuen Intelprozessen in letzter Vergangenheit (in Bezug auf Taktregression zum Vorgänger).
Zumindest skeptisch kann man da sein IMO.

Einspruch. Es ist völlig normal, dass ein neuer Prozess zu beginn Probleme mit hohen Taktraten hat, das war schon immer so. Hohe Transistorperformance erfordert sehr viel Optimierung. Die Frage ist einzig und alleine wann ich einen Prozess einsetze. Beispiel TSMC N5. Apple hat N5 sehr viel früher verwendet, schlicht weil sie nur sehr niedrige Taktraten fahren und nicht auf die HP Variante angewiesen waren. AMD hat auf die HP Variante gewartet, weil hohe Taktraten für ihr Design elementar sind. Bis inkl. 22nm konnte es sich Intel eben leisten den Prozess lange genug zu optimieren, bevor man ihn einsetzte. Jetzt ist man auf den Perf/Watt-Vorteil angewiesen, auch, wenn man dadurch Taktregressionen in Kauf nehmen muss. Aber es hat schon einen Grund, warum LP-Designs in der Regel als erstes auf einem neuen Prozess kommen.

[robbitop]

Naja schau dir mal die Zeiträume bei Intel bei den Prozessen (bis sie liefen) an. Das ist seit 14 nm (bzw spätestens mit 10nm/Intel 4) eine Katastrophe verglichen mit 22nm und davor. (obwohl da eventuell mehr optimiert wurde).
Es mag sein, dass TSMC Nx nicht besser ist als N(x+1)P aber der NxP Prozess kommt wie ein Uhrwerk. Also alle ~2 Jahre gibt's einen neuen Fertigungsprozess, der in jeder Hinsicht besser ist als der alte. Und es ist in der Regel bloß 6-9 Monate vom Nx zum NxP.

Zum konkreten Beispiel mit N5 vs N7P:
Wenn man sich N5 vs N7P anschaut, ist der laut TSMC Angaben aber auch besser bei Speed.

N7P vs N7 +7% speed
N5 vs N7 +15 % speed

https://en.wikichip.org/wiki/5_nm_lithography_process#N5
https://en.wikichip.org/wiki/7_nm_lithography_process#N7P

Egal wie man es dreht und wendet. TSMC liefert ab wie ein Uhrwerk bei bleeding edge Prozessen und von echten Taktregressionen ist in einem fairen Vergleich (vanilla vs vanilla und P vs P) nichts zu erkennen. Und es sieht auch nicht mal so aus als würde es einen Taktrückgang bei Nx vs N(x-1)P geben.

Ob AMD jetzt wirklich "warten" musste, bis TSMC den Takt bei 5 nm hinbekommen hat: dafür gibt es für keine stichhaltige Indizienbeweise. Angeblich hat sich Zen 4 verspätet und war schon Anfang 2022 geplant und hat sich dann bis in Q3 verspätet. TSMC N5P wurde in Volumenproduktion in 2021 gestartet. Wir wissen nicht, ob sich da was bei AMD verspätet hat oder ob die Kapazität für AMD nicht reichte oder wo das Problem sonst war.

[latiose88]

ja ist egal,die warheit werden wir wohl nie erfahren was wirklich war.Fakt ist Zen 4 ist gekommen um für ne gewisse Zeit zu bleiben,bis dann Zen 5 Zen 4 ersetzen wird.Weil die Show muss ja weiter gehen,so viel ist sicher.

[rentex]

Hat man schon Spekulationen über den Speichercontroller und seine Standardgeschwindigkeit?

[davidzo]

Die Frage ist einzig und alleine wann ich einen Prozess einsetze. Beispiel TSMC N5. Apple hat N5 sehr viel früher verwendet, schlicht weil sie nur sehr niedrige Taktraten fahren und nicht auf die HP Variante angewiesen waren. AMD hat auf die HP Variante gewartet, weil hohe Taktraten für ihr Design elementar sind. Bis inkl. 22nm konnte es sich Intel eben leisten den Prozess lange genug zu optimieren, bevor man ihn einsetzte. Jetzt ist man auf den Perf/Watt-Vorteil angewiesen, auch, wenn man dadurch Taktregressionen in Kauf nehmen muss. Aber es hat schon einen Grund, warum LP-Designs in der Regel als erstes auf einem neuen Prozess kommen.

Genau da sehe ich den Punkt weshalb ich den neuen Prozessen die unter Gelsinger entstanden sind noch nicht ganz traue. Das neue Prinzip bei der µArch ist nicht mehr auf feature complete zu warten, bzw. erst dann wenn alles signifikant besser als der Vorgänger ist, sondern eher eine art rolling Release wie bei Ubuntu: Alles was von den geplanten features bis zum Tag X implementiert, getestet und für gut befunden ist kommt rein. Alles andere was zwischenzeitlich fertig wird kommt dann in den nächsten release.
Dasselbe gilt prinzipiell auch für die Fertigungsnodes. Intels Plan von 2021 war jedes Jahr einen neuen Node zu starten, unabhängig davon ob zu Anfang schon alle features verfügbar sind. Es ist also gar nicht klar ob wir gleich zu Anfang schon ribbon-fet und Power Via sehen werden.
Insofern sehe ich die Vorschusslorbeeren die 20A und 18A hier schon bekommen kritisch. Es wäre nicht das erste mal dass von der Density und performance die Intel im labor erreicht hat im Massenprozess dann nichts mehr zu sehen ist.

Bei Zeitaussagen kann man Intel aber leider weiterhin nicht ernst nehmen.
Bloß weil da Intel4 für 2022 und intel3 für 2023 steht heißt das gar nichts. Die 2 Jahre alte "5 nodes in four years" Strategie ist schon vor dem ersten neuen node fast 2 Jahr ein Verzug, aber offiziell hält intel daran noch fest.

Spätestens nach dem Cannonlake debakel hat intel eben ein sehr dynamisches verhältnis dazu was der launch eines neues Prozesses bedeutet. Im Kleingedruckten steht seitdem immer dass das nichts mehr mit den Kundenprodukten zutun haben muss, sondern nur noch für den "internen Produktionsstart" bzw. "produktionsbereit" gilt. Dafür muss also kein Produkt gefertigt werden, sondern ein paar Testwafer reichen aus um "on time" zu sein. Ja für Produktionsbereit müssten es nicht mal testwafer sein, denn das Ziel wäre ja auch erreicht wenn alle Prozesslibraries und der workflow stehen, aber eben noch kein Produkt in Fertigung geht aber man eben "bereit" ist. Völliger Schmuh eben, mit dem man Anleger hinters licht führt weil die das Kleingedruckte eh selten lesen.

Und selbst wenn irgendwo "shipping to customer" steht bedeutet das nichts. Das können ein paar Testwafer sein die man an einen an einen OEM oder Hyperscaler schickt um damit ein bisschen Marketing für künftige Großbestellungen zu machen. Und für "shipped to customer" this year da reicht eben aus wenn man eine Test-CPU am 31.12. fedex übergibt.

Für Meteorlake und Granite Rapids war da noch im Juli 2021 die Rede von Produktionsstart in H2 2022 und Auslieferung beider Produkte in 2023. Genau ein Jahr später spricht niemand mehr von granite rapids und der production Ramp von Meterolake steht erst für H2 2023 an, wo er eigentlich spätestens launchen sollte. Btw, in 2023 sollte eigentlich die Produktion von Intel3 Produkten schon gestartet sein (vermutlich sierra forrest). Praktisch ist das genau ein Jahr später für MTL (Produktionsstart H2 2023 statt H2 2022 und Verkauf wohl eher 2024 statt 2023). Und bei granite rapids ist das noch schlimmer.
Wie man sich bei so kurzen Zeiträumen so gewaltig, also um 100% und bei GNR sogar Faktor 3 verschätzen kann ist mir unbegreiflich.

Also bevor wir nicht Produkte in den Regalen haben bin ich da immer noch sehr skeptisch was Intels Roadmapzusagen angeht. Bezogen auf Endkindenprodukte schätze ich die Roadmap eher so ein:
- Intel4 nicht in 2022-23 sondern 2024.
- 20A nicht in 2024 (geplanter ramp up) sondern in Produkten erst in 2026.
- 18A nicht in 2025 sondern frühestens 2027.


Auch bei AMD hat sich Zen4 um ein paar Monate verzögert und RDNA3 sogar um mehr als ein halbes Jahr. Aber das scheint keinen Dominoeffekt auf die Zeitpläne der nachfolgenden Produkte gehabt zu haben, Zen5 scheint eher Anfang des Jahres zu kommen und nicht erst im Dezember an einen großkunden gesampled wie Intel das macht.

[latiose88]

Grn soll wohl Größenordnung heißen nicht wahr?

Und ja ich sehe das auch so. Die cpus schlagen nicht ganz so ein wie es sich Intel da so vorgestellt hatte. Mir kann es ja egal sein, denn die Sprünge werden eh immer kleine, von daher kann man nix machen.

[Zossel]

Und ja ich sehe das auch so. Die cpus schlagen nicht ganz so ein wie es sich Intel da so vorgestellt hatte. Mir kann es ja egal sein, denn die Sprünge werden eh immer kleine, von daher kann man nix machen.

Also ich finde aktuell 128 Cores in einer CPU recht ordentlich, das ist schon ordentlich gegenüber dem was wir noch vor ein paar Jahren hatten.
Und ich habe auch lange niemanden mehr über langsame Telefone jammern hören.

[latiose88]

Ja an den Cores leidet es nicht. Hilft nur nix wenn die Anwendung damit nix anfangen kann. Ich habe gelesen das Zen 5 keinen höheren CPU takt haben wird. Haben fest damit gerechnet das es wenigtens auf 5,4 GHz alcore gehen wird aber das AMD auf den selben CPU takt bleiben wird, das finde ich nicht ganz so gut. Und ob mehr Einheiten die das steuern durch das mehr arbeiten gleichzeitig schneller gehen würde ist ne andere frage.

Ist wie wenn man sagen würde die Maschine ist nun breiter nun kann noch mehr Gleichzeitig abgearbeitet werden aber es ist nur die selbe Menge wo dann halt statt auf 5 Bänder auf 7 oder 8 Bänder aufgeteilt wird. Ist es dann schneller fertig als vorher , obwohl es nicht mehr sind geht nun mehr.

Oder ist es nun vergleichbar mit es kann nun mehr produzieren aber die Bänder ist die selbe Menge wie zuvor also gibt es dann ruckstau weil zu viel mehr produziert wird aber nicht abtransportiert werden als wie produziert wird.

[Complicated]

Der Takt alleine sagt überhaupt nichts über die Performance der CPU - daher ist es völlig egal welcher Takt für Zen5 angekündigt ist, solange man nicht weiß welche IPC dem zugrundeliegt. Wegen mir darf er mit 3 GHz takten, wenn er pro Takt das Doppelte rechnet.

[latiose88]

ja nicht wenn man ein Programm hat das von einer guten Single Core Leistung Profitiert.Wo dann durch das jeder Kern zusammen eine viel bessere Multicore Leistung durch das erreicht.Wo ein Programm von mehr CPU Takt halt sehr gut profitiert.Wenn der Takt bleibt,dann steigt die Leistung nicht ganz so stark an.Es wird sich noch zeigen ob die IPC noch ne wirkung hat,hoffe mal wenn schon Zen 4 nichts in diese richtung gezeigt hat,das es dann Zen 5 schon richten wird.Sollte es nicht so stark an mehrleistung gebe werde ich mir den dennoch holen,weil ist dennoch besser als Zen 4.
Sollte es jedoch garkeine mehrleistung dazu kommen weil solche Programme gibt es ja auch,dann kann ich wenigsten den Zen 4 CPU günstiger Kaufen.Hat also egal was ich mache so seine Vorteile.
Aber um ganz sicher zu sein,heißt es erst mal erscheinen.
Es spielen ja noch andere Sachen eine Rolle wie Ram und Mainbaord,wobei ich mir auch ein Mainboard mit nur 2 Ram Channel gönnen könnte,weil so viel Ram brauche ich nun auch wieder nicht.Und bisher waren es bis auf das eine mal immer nur Dualchannel gewesen mit nur 2 Ram Riegel maximal bzw ingesammt.
Es reist bei mir egal welcher Ramtakt nun nur noch die CPU raus.Ich bin also von Zen 5 abhängig.Erhoffe mir viel.Wenn schon von GPU und Ram kein wirklicher gewinn kommt wenigstens von der einen Komponenten.
Ich hoffe nur das die Erwartungen nicht zu hoch bei mir sind.Wenn CPU Takt gleich bleibt ,dann sind wenn es alles klappen sollte weniger als 20 % zu Zen 4 nur noch drinnen.In den 20 % haben ich den CPU Takt mit eingerechnet gehabt.Nun vor Zen 4 gab es bei mir immer so um die 10-15 % mehrleistung dank IPC und so.Zen 4 ist alles anderst.Nun man kann aber nur auf Basis einer Gen noch lange keine Rückschlüsse zum Nachfolger geben.Darum geht ja eh nur Abwarten.
Das gute ist,ich habe durch das mehr Zeit zum sparen.
Noch habe ich ja einen Zen 3 CPU mein eigenen.Man merkt jedoch weil ich einen 5950x habe das ich auf die gleiche Anzahl an Kernen schiele.

Wobei was geil wäre 6 ghz Allcore auf einen 16 Kerner von AMD,das wäre durchaus geil.Aber das wäre nur wunschdenken.Das gäbe nen sattes Plus an Leistung von 5,1 ghz auf 6 ghz.

[Complicated]

ja nicht wenn man ein Programm hat das von einer guten Single Core Leistung Profitiert...Schon deine Einleitung ist Unfug und es wird nicht besser....:freak:
Singlecore-Leistung steigt bei gleichem Takt, wenn die IPC erhöht wird zeitgleich. +10% IPC = +10% Performance

[Zossel]

Schon deine Einleitung ist Unfug und es wird nicht besser....:freak:
Singlecore-Leistung steigt bei gleichem Takt, wenn die IPC erhöht wird zeitgleich. +10% IPC = +10% Performance

IPC hängt von dem konkreten Code ab der ausgeführt wird.

[latiose88]

Ja sehe ich auch so. Der Code lässt sich irgendwann nicht mehr steigern. Unendlich eben nicht. Zen 4 hat es ja auch schon ipc steigerungen angeblich gegeben haben. Davon habe ich nix gemerkt gehabt. Da gab es ja auch single und multicore Steigerungen. Was war der der reine allcore takt machte ne starke steigerungen möglich. Darum bin ich ja auch auf einen möglichst hohen takt aus. Intels 13900k ist zurzeit in Führung mit seinen 5, 7 GHz allcore takt.
Das wird sehr schwer sein für Zen 5 da ran zu kommen.
Aber gut ich lasse mich da einfach überraschen.
Ipc scheint es jedenfalls auch bei Intel nicht zu sein. Sonst würde ja dieser bei 4,5 GHz nicht so viel Leistung verlieren. Das ist über dem Verhältnis kann man sagen.
Intel schafft es jedensfalls auch nicht richtig die Leistung auf die Strecke zu bekommen. Darum bin ich auch auf neue cpus zu erpicht. Liege schon auf die lauer und erhoffe mir sehr viel. Wenn auch die Steigerung mir einfach zu wenig ist.
Zum Glück gibt es auf der einen Plattform noch Zen 6, da wird dann sofort wenn es geht gewechselt.

Dann wird Zen 5 also nur 2 Jahre her halten. Zen 3 hätte ich dann rund 4 Jahre gehabt. Ich bleibe nie länger als 4 Jahre auf einer CPU. Weil ich einfach gierig nach noch mehr cpu Leistung aus bin.
Irgendwie wird der Rausch immer geringer warum auch immer.
Der Gröste sprung bei amd war definitiv Zen der ersten, dann gefolgt von Zen 1 zu Zen 2. Danach waren es nur noch Mini Sprünge gewesen.
Scheinbar gibt es da wohl auch ne Sättigung wie es scheint.
Aber gut zum Glück warte ich ja eh nicht mehr ewig darum auch so viele wechsel.

[robbitop]

Zen 4 soll keine IPC Erhöhung haben? Das ist absurd. Zen 4 hat eine höhere IPC. Hier die Messergebnisse (Takt- und Corenormiert):
https://www.computerbase.de/2022-09/amd-ryzen-7950x-7900x-7700x-7600x-test/#abschnitt_zen_4_vs_zen_3_ipc_takt__latenzen_im_vergleich

Zen 5 soll besonders hohe IPC Erhöhung mitbringen, was auch kein Wunder ist, wenn man das erste mal seit Zen(1) die decoder breiter macht.

Es ist auch absurd anzunehmen, dass wir da bereits am Ende sind. Man schaue sich Apples M2 P-Cores an. Die sind bei 3 GHz so schnell wie ein Zen 3 mit knappen 5 GHz. Und M3 kommt erst noch. Da ist noch Luft nach oben.

[Nightspider]

Zen4 mit V-Cache ist in einigen Anwendungen doppelt so schnell wie Zen2.

Wenn Zen5 nochmal 30% drauflegen sollte wird Zen5D manchmal 2,6 mal so schnell sein wie Zen 2.

Latiose was willst du denn noch.

[Complicated]

IPC hängt von dem konkreten Code ab der ausgeführt wird.Richtig und egal mit welchem Code ist eine IPC Erhöhung +10% das selbe in Performance. Das gilt natürlich nicht für anderen Code, doch dort ist die IPC entsprechend auch 1:1 skalierbar.

Der Takt hängt auch vom Code ab-siehe AVX bei Intel, wo eine geringerer Takt dafür mehr IPC ermöglicht und es insgesamt höhere Single-Thread Performance gibt.

[Nightspider]

Es sind ja eh immer Durchschnittsangaben.

Wenn jemand sagt, die IPC skaliert in einigen Anwendungen kaum oder nur 5%, dann könnte man genauso gut auch sagen, das die IPC manchmal mit 20% durchschlägt.

Sich an einzelnen Anwendungen aufzuhängen ist sinnfrei, wenn man über eine Mikroarchitektur spricht.

[latiose88]

OK durch den Decoder können ja mehr Aufgaben in der selben Zeit verteilt werden.
Ja gut Zen 2 brachte sehr viel wie ich ja auch sehe.
Dann gibt es ja vielleicht doch noch einen boost.
Das es das bei Zen 4 nicht gegeben hatte gebe ich die Schuld nicht an die CPU sondern an meiner verwendeten Software.

Scheinbar bringt ab einen gewissen Punkt immer noch mehr Power in die CPU zu stecken doch nix mehr.
Wenn es also ab einen gewissen Punkt nicht noch mehr Aufgaben verteilen kann, dann bringt nen breitete Decoder auch nichts mehr.
Nicht alles scheint unendlich skalierbar.
Noch dazu wenn man so wie ich h264 immer schneller umwandeln will.
Ein Update der Software erwarte ich nicht mehr.

Habe gehofft die CPU könnte dieses Problem ausgleichen. Es scheint so langsam der Punkt zu kommen wo immer noch mehr cpu Power auch nix mehr hilft.
Bin darum über 1 Minuten weil 2 gleichzeitig umwandeln tue. 2 Schwache läßt scheint das ganze auch nicht mehr zu retten.

Wobei das hieße ja mehr Arbeit wo da durch muss also Aufgaben. Villeicht bremste das ja bei Zen 4 das ganze.
Wobei dann müsste ich das auch schon bei der anderen gen auch so haben.
Aber warum die ipc nicht anstieg bei Zen 4 obwohl das die CPU hat aber dafür nur der höhere takt, das verstehe ich auch nicht.
Aber um sicher zu sein bräuchte ich halt ein ryzen 9 7950x mit rund 4 GHz um das wirklich heraus zu finden.
Beim RAM wird die Wirkung ja auch immer weniger bei der Steigerung. Sonst würde ich mir so was hartes wie 2, 5% zwischen ddr5 4800 zu 6200 MHz nicht erklären können. Ich selbst habe es testen dürfen. Getestet wurde es mit einem 7950x3d
Es spielt keine Rolle weil meine Anwendung von dem extra l3 cache nichts anfangen kann.
Darum merkt man den Unterschried beim RAM sehr gut.

Was ich will also noch viel schneller umwandeln das sich am5 auch rechtfertigt. Im. Moment lohnt es sich wegen nur 20% ja noch nicht.
Aber ist doch gut wenn es dann trotz weniger takt die Leistung gleich bleibt oder sowar nur minimal Leistung verliere. 5 % ist schon was bei 300 MHz weniger takt.
Und wenn das dann weniger Verlust ist, das freut mich um so mehr. Aber ganz ohne Verlust geht es dennoch leider nicht.

[Zossel]

Noch dazu wenn man so wie ich h264 immer schneller umwandeln will.


Diskutiere das mit den Entwicklern/Hersteller der Software.
Oder zerhacke den Kram vorher in kleine Schnipsel die man gleichzeitig befummeln kann und bau den Kram danach wieder zusammen. Es kommt ja immer ein I-Frame als Erstes. ffmpeg ist dein Freund.

[latiose88]

Ja die I frames sind doch das wo am meisten Leistung kostet und die b frames wo am wenigtens kosten und die p frames sind bei den kosten eher dazwischen. Oder liege ich damit falsch?
Und warum sollte ich 576i Serien folgen oder Filme sehr stark zerstückelt. Damit komme ich auch nicht schneller beim umwandeln voran.

[Gipsel]

Ja die I frames sind doch das wo am meisten Leistung kostet und die b frames wo am wenigtens kosten und die p frames sind bei den kosten eher dazwischen. Oder liege ich damit falsch?
Und warum sollte ich 576i Serien folgen oder Filme sehr stark zerstückelt. Damit komme ich auch nicht schneller beim umwandeln voran.Das tut weh. Eventuell erst mal über die benutzten Begriffe informieren.
Und hier sollte es immer noch um Zen5 gehen.
Letzter Stand der Gerüchteküche sind breiteres Design, deutliche IPC-Fortschritte und nur geringe (wenn überhaupt) Taktanhebungen bei weiterhin 8C-Chiplets und maximal 16C im Desktop (keine Zen5c-Chiplets dort, aber gemischte Zen5/Zen5c-Angebote im Mobilsektor), oder?

[latiose88]

Ja von takterhöhung bei Zen 5 war nie die Rede gewesen nur das es halt breitere design sein soll. Sodenke ich mal wird es schon kommen. Für mich mag es aber keine Rolle spielen wie stark die Steigerung ist. Sollte es doch nix werden, wird es halt Zen 4 weil dann spare ich wenigtens beim Preis dann. Naja ich lasse es wie immer erst mal andere kaufen. So habe ich es bisher gemacht und werde ich auch wieder machen. Das einer sich einen 8950x von AMD kaufen wird ist so sicher wie beim 7950x aktuell. Da kaufen auch wirklich mehr ein im Gegensatz zu einem threadripper.

Das ist ja das gute. Ich selbst profitiere auch noch von den günstiger werdenden restlichen Komponenten wie RAM usw ebenso noch. Wer Geduld hat der gewinnt am Ende.

[reaperrr]

RGT hat angedeutet, dass es laut seinen Quellen eher einen kleinen Rückschritt beim Takt geben könnte (vllt. 200 MHz weniger übers gesamte Line-Up? 5,5 Ghz ST-Turbo wäre bei ~25% mehr IPC immer noch völlig OK).

Wenn Zen5 wie es derzeit aussieht vor ARL rauskommt und die Gerüchte stimmen, dass ARL's P-Cores die ~40% mehr IPC mit einem auf <= 4,5 GHz crashenden Takt bezahlen (würde zufällig zu der von igor geposteten Perf-Projektion von ARL-S passen und erklären, wie man mit ~40% mehr P-Core-IPC auf nur 7-20% mehr Leistung kommt), reicht das auch.

[robbitop]

+40% IPC (ARL) ist schon mal ein dickes Brett. Wäre der größte IPC Anstieg von Gen zu Gen bei Intel seit Jahrzehnten. (und ARL scheint ja eher ein Tock von MTL zu sein)
Auf jeden Fall wäre das beeindruckend und würde bedeuten, dass Intel in die IPC Regionen von Apple stößt - aber ohne auf 3,x GHz abzusinken.

[w0mbat]

So wie ich es aktuell verstehe ist MTL eher ein Tock von ADL/RTL und ARL quasi der Vorläufer zum "Royal Core". ARL soll ja auch schon kein SMT mehr haben.

[robbitop]

Naja RTL war ja der Tock zu ADL. MTL wäre dann der Tock-Tock? (ja wer ist da? X-D)
Wäre eigentlich nicht Intel typisch. Aber gut, Dinge können sich ja auch verändern.

Kein SMT war IIRC ein Gerücht, welches wieder verworfen wurde. IIRC sollten "rentable units" eher später kommen - wobei das auch noch sehr Gerüchtemäßig ist. Gerade die Intel Gerüchteküche ist IMO sehr dynamisch und manchmal auch verwirrend. Ggf. hab ich das auch falsch abgespeichert.

[reaperrr]

Kein SMT war IIRC ein Gerücht, welches wieder verworfen wurde. IIRC sollten "rentable units" eher später kommen - wobei das auch noch sehr Gerüchtemäßig ist. Gerade die Intel Gerüchteküche ist IMO sehr dynamisch und manchmal auch verwirrend. Ggf. hab ich das auch falsch abgespeichert.
Das Gerücht kam von MLID und laut ihm war es von Intel auch ursprünglich nicht so beabsichtigt.
Aber da SMT im aktuellsten Stepping wohl nicht funktioniert und es wohl auch kein so kleiner Bug ist, dass sie das mal eben schnell beheben können und man wohl nicht deswegen verschieben will, soll ARL halt ohne kommen.
Dafür soll die ursprünglich auf Eis gelegte Variante mit 8P/32E-Cores jetzt doch noch kommen, zusätzlich zur anfänglichen 8P+16E Variante (bloß halt später).

[HOT]

https://www.3dcenter.org/news/news-des-28-august-2023

Mir war von Anfang an klar, dass Zen5 das gleiche IOD nutzt wie Zen4. Mal sehen, ob es trotzdem Veränderungen gibt, in dem man die CCDs jetzt auch verbindet. Das ist ja der große Pferdefuß bei Zen4. Damit wäre auch ein 2CCD X3D effizineter.

[robbitop]

Nochmal zu den +40%. Ob da der Adamantium Cache ggf mithilft? Wir wissen ja alle, wie sehr schneller, großer LLC hilft. Das allein kann schon grob die Hälfte der Leistungssteigerung erklären. Dann sind die +20% eher typisch für einen uArch Sprung. Aber +40% IPC rein aus einem uArch Sprung wäre schon krass. Dafür braucht man normalerweise mehr als 2 bis fast 3 uArch Generationen.

[Der_Korken]

Was am alten IOD ungeil sein könnte, wäre der hohe Idleverbrauch. Theoretisch könnte der zwar wie bei Dragon Range auch geringer sein, aber Strom sparen hat bei AMD nicht so Priorität, abgesehen von Volllast auf allen Kernen. Und es bedeutet auch, dass am IOD kein CPU-genutzter Cache hängen kann, weil die Bandbreite über IFoP zu gering dafür wäre (und ineffizient sowieso).

[HOT]

Das war ja eh ein Märchen, weil das Auslesen ja mit HWInfo z.B. nicht funktioniert hat, es konnte nur Ryzen Master den Idle-Verbrauch richtig anzeigen. Ich weiss aber nicht, ob der Fehler immer noch drin ist. Das Ding hat keinen hohen Idle-Verbrauch, das ist Blödsinn, nur mal als Hinweis: Das Teil gibts auch mobil ;). Das alte IOD hatte hohen Idle-Verbrauch, wenn man die Spezifikation von höchstens DDR3200 verlässt, das ist hier aber nicht mehr der Fall.

[RitterRost]

... Das Ding hat keinen hohen Idle-Verbrauch, das ist Blödsinn, nur mal als Hinweis: Das Teil gibts auch mobil ;)...

Es hilft mir auf dem Desktop aber nichts, wenn AMD die Stromsparfunktionen bei den mobilen Zen4 anschaltet.
Der idle-Verbrauch bei der Desktop AM5 Plattform ist mir auch zu hoch.

[HOT]

Es hilft mir auf dem Desktop aber nichts, wenn AMD die Stromsparfunktionen bei den mobilen Zen4 anschaltet.
Der idle-Verbrauch bei der Desktop AM5 Plattform ist mir auch zu hoch.
Beweise und zwar solche, die schlechte Mobo-Steuerung ausschließen.
Ich sag dir, das ist purer BS.

[RitterRost]

Wenn ich heute Abend Zeit habe, suche ich Dir die Messungen von der c't raus.
Soweit ich mich erinnere, war AM5 ein paar Watt sparsamer, als AM4 - aber immer noch weit über 20W in idle. Und, 20W kann sich die mobile Version bestimmt nicht erlauben...

Und das traurige daran ist, dass zumindest Intel vor ein paar Jahren schon unter 20W idle-Verbrauch war (im Desktop)...

[Complicated]

Was am alten IOD ungeil sein könnte, wäre der hohe Idleverbrauch.
Das liegt eher weniger am IO-Die, sondern an der Anbindung der Dies und den Stromkosten Daten darüber zu schieben.

Hier gibt es ja schon Gerüchte, dass Zen5 die Anbindungen weiter entwickelt und das Cache-Design umbaut für weniger Hops und somit weniger Strom/Transfer:
https://wccftech.com/amd-next-gen-zen-5-cpus-feature-reworked-cache-design-larger-l2-cache-per-core-rumor/

The first major change rumored for AMD's Zen 5 CPU core architecture is the use of a new "Ladder" shared cache. The earlier Zen architectures had the L3 cache split into two 16 MB blocks shared by the two CCX's within each CCD. Each CCX could only access 16 MB of L3 cache pools.

With Zen 3, AMD change this and dropped the dual CCX to a singular CCX which featured a shared 32 MB L3 cache pool that was connected to all 8 cores within the die in a ring configuration.

AMD kept the same design on the Zen 4 chips but with Zen 5, this is rumored to change once again to a new 32 MB L3 "Ladder' cache.
This structure is said to drastically reduce the inter-core latency and communication bottlenecks compared to the ring interconnect design. Now the figure shown here is just to provide a visual perspective of how the new L3 cache structure would work & we cannot say for sure if the L3 cache will stick to 32 MB or get a boost.

[Complicated]

Soweit ich mich erinnere, war AM5 ein paar Watt sparsamer, als AM4 - aber immer noch weit über 20W in Idle. Und, 20W kann sich die mobile Version bestimmt nicht erlauben...
1000W Netzteil im Desktop mit Notebook verglichen - na herzlichen Glückwunsch für den Idle-Vergleich.

Zumal der Monitor und GPU da eher eine Rolle spielt als die CPU. Mobil kommen auch APUs zum Einsatz (wer die 16-Kern CPUs verbaut denkt über so etwas nicht nach)

[HOT]

Wenn ich heute Abend Zeit habe, suche ich Dir die Messungen von der c't raus.
Soweit ich mich erinnere, war AM5 ein paar Watt sparsamer, als AM4 - aber immer noch weit über 20W in idle. Und, 20W kann sich die mobile Version bestimmt nicht erlauben...

Und das traurige daran ist, dass zumindest Intel vor ein paar Jahren schon unter 20W idle-Verbrauch war (im Desktop)...
Gesamtmessungen des Sytems sind eh Unsinn, daraus kannst du rein gar nichts auf den Prozessor ableiten.

[latiose88]

Nochmal zu den +40%. Ob da der Adamantium Cache ggf mithilft? Wir wissen ja alle, wie sehr schneller, großer LLC hilft. Das allein kann schon grob die Hälfte der Leistungssteigerung erklären. Dann sind die +20% eher typisch für einen uArch Sprung. Aber +40% IPC rein aus einem uArch Sprung wäre schon krass. Dafür braucht man normalerweise mehr als 2 bis fast 3 uArch Generationen.

Ok krass wenn die hälfte auf dem Cache zurück zu führen ist.
ALso eines weis ich Cache ist schon mal das wo meine Anwendung nicht mehr skaliert.Merkte ich ja schon bei Zen 4 wo L2 Cache doppelt so groß geworden ist.
Ist halt auch die Frage welcher Cache für die Steigerung so stark führt.Aber wenn das nicht gegeben wäre was auch immer das für ein Adamantium ist.
Zieht man das ab,kann man nur noch auf 20 % kommen.Dann braucht noch irgendwas anderes sein wo zum zürück führen von Leistung zu minderung kommt.Sagen wir mal es sind dann 300 mhz weniger Allcore takt.
Das wären in meinem Fall 5 % weniger Leistung.So viel kann also IPC Steigerung nicht kommen um das alles abzufedern.Man kann sagen,joa am Ende kommt dann 15 % mehrleistung zu Zen 4 raus.Der rest kommt dann nur noch auf die Anwendung drauf an.

Nimmt man alle Programme raus die Cache Lastig sind,wäre der Durchschnitt bei 15 %.Das heißt es könnten auch Anwendung kommen die nur 10 % mehrleistung haben.Zumindest 10 % ist schon mal sicher.Alles andere ist dann nur noch ein Bonus kann man sagen.

[latiose88]

Zumal der Monitor und GPU da eher eine Rolle spielt als die CPU. Mobil kommen auch APUs zum Einsatz (wer die 16-Kern CPUs verbaut denkt über so etwas nicht nach)

Na das stimmt so fall nicht.Ich verbaue zwar 16 Kerne,will dennoch im idle ne möglischt sparsame CPU haben.Intel hatte damals als noch für mich interessant sehr gute Idle Werte aber bei Allcore Last war Intel sehr schwach gewesen.
Wenn ich beides also haben würde,das wäre das beste aus beiden.Aber bisher habe ich immer nur eines davon bekommen gehabt.Entweder viel Leistung aber dafür schlechte Idle Stromverbrauch oder gute Idle Stromverbrauch aber dafür nicht genug Allcore Leistung und dafür im gegenzug sehr hohe Allcore Stromverbrauch.
Also nicht so gut bisher.Aber ich denke mal AMD wird das schon noch hin bekommen,da bin ich mir sicher.

[Complicated]

Na das stimmt so fall nicht.Ich verbaue zwar 16 Kerne,will dennoch im idle ne möglischt sparsame CPU haben.
Notebook!!! Kontext!!!

Du darfst grundsätzlich bei meinen Beiträgen davon ausgehen, dass ich deine persönlichen Vorlieben und dein System nicht meine.

[Der_Korken]

Das war ja eh ein Märchen, weil das Auslesen ja mit HWInfo z.B. nicht funktioniert hat, es konnte nur Ryzen Master den Idle-Verbrauch richtig anzeigen. Ich weiss aber nicht, ob der Fehler immer noch drin ist. Das Ding hat keinen hohen Idle-Verbrauch, das ist Blödsinn, nur mal als Hinweis: Das Teil gibts auch mobil ;). Das alte IOD hatte hohen Idle-Verbrauch, wenn man die Spezifikation von höchstens DDR3200 verlässt, das ist hier aber nicht mehr der Fall.

Mein Zen 3-System verbraucht an der Dose 66W mit DDR3200 und wenn absolut nichts läuft mit ca. 17W Package Power laut Ryzen Master (das kleinste Hintergrundprogramm erhöht die Package Power auf über 30W und den Verbrauch an der Dose um 13-15W). CB hat zum Zen-4-Launch gemessen: https://www.computerbase.de/2022-09/amd-ryzen-7950x-7900x-7700x-7600x-test/2/#abschnitt_leistungsaufnahme_in_anwendungen_ab_werk

- 55W für einen 5900X, d.h. deren Board/Restsystem ist sogar noch 11W sparsamer als meins.
- 47W für einen 5800X, d.h. das zweite CCD zieht offenbar ordentlich Saft im Idle.
- 64W für einen 7700X
- 66W für einen 7950X

Zen 4 hat ein anderes Board und anderen RAM. Wenn du jetzt aber behauptest, Zen 4 hätte keinen hohen Idleverbrauch, dann müsste deren AM5-Board ja nicht nur 11W mehr verbrauchen als das AM4-Board, sondern mehr als das, denn ein 5900X ist ja offensichtlich schon ein Säufer im Idle. Ich kann nicht ausschließen, dass das AM5-Board wirklich so ein Säufer ist, aber die Zahlen sprechen erstmal für meine Behauptung.

HWInfo sagt weiter unten, dass Zen 4 immerhin 2-3W sparsamer als Zen 3 ist, aber immernoch deutlich höher als Intel. Die 13000er liegen übrigens auch alle um die 7W.

Bezüglich mobile Versionen: https://www.notebookcheck.net/AMD-Ryzen-9-7945HX-Analysis-Zen4-Dragon-Range-is-faster-and-more-efficient-than-Intel-Raptor-Lake-HX.705034.0.html

Hier konnte AMD den Package-Verbrauch auf 8,3W drücken, was für mich akzeptable Werte für eine Desktop-CPU wären. Nur scheint AMD kein Interesse daran zu haben solche Stromspartechniken auch Desktop-Usern zugänglich zu machen. Im übrigen kommt auch hier Intel mit 5,8W relativ deutlich besser weg und zwar nicht nur auf dem Papier, sondern auch:

Our two reviews of the Zen4 notebooks also showed short battery runtime in practical scenarios.

Beweise und zwar solche, die schlechte Mobo-Steuerung ausschließen.
Ich sag dir, das ist purer BS.

Liefer doch erstmal Indizien, warum die verlinkten Zahlen nicht stimmen sollten. Oder Messungen, die meinen widersprechen.

Das liegt eher weniger am IO-Die, sondern an der Anbindung der Dies und den Stromkosten Daten darüber zu schieben.

Hier gibt es ja schon Gerüchte, dass Zen5 die Anbindungen weiter entwickelt und das Cache-Design umbaut für weniger Hops und somit weniger Strom/Transfer:
https://wccftech.com/amd-next-gen-zen-5-cpus-feature-reworked-cache-design-larger-l2-cache-per-core-rumor/

Sind andere Anbindungen (wie z.B. das Fan-Out von N31) denn kompatibel mit den PHYs im IOD? Ansonsten schließt ein Beibehalten des IOD ja auch aus, dass andere Übertragungstechniken genutzt werden.

Das mit dem Ladder-Cache bezieht sich in meinen Augen auf den Cache innerhalb des CCDs. Das hat aber nichts mit Idle-Verbrauch zu tun, selbst wenn die Hitrate des Caches höher läge, denn der Verbrauch fällt anscheinend durchgehend an, nicht nur wenn viele Daten übertragen werden.

[Pirx]

Den 5700G hat CB bei 38 W fürs System Idle - das hat AMD immerhin und ganz freiwillig dem Desktop-User zugänglich gemacht. https://www.computerbase.de/2021-08/amd-ryzen-5600g-5700g-test/3/

[Der_Korken]

Den 5700G hat CB bei 38 W fürs System Idle - das hat AMD immerhin und ganz freiwillig dem Desktop-User zugänglich gemacht. https://www.computerbase.de/2021-08/amd-ryzen-5600g-5700g-test/3/

Phoenix gibt es nicht für AM5 und ist mit 16MB L3-Cache auch zu langsam in Games.

[Mangel76]

- 55W für einen 5900X, d.h. deren Board/Restsystem ist sogar noch 11W sparsamer als meins.
- 47W für einen 5800X, d.h. das zweite CCD zieht offenbar ordentlich Saft im Idle.
- 64W für einen 7700X
- 66W für einen 7950X

Zen 4 hat ein anderes Board und anderen RAM. Wenn du jetzt aber behauptest, Zen 4 hätte keinen hohen Idleverbrauch, dann müsste deren AM5-Board ja nicht nur 11W mehr verbrauchen als das AM4-Board, sondern mehr als das, denn ein 5900X ist ja offensichtlich schon ein Säufer im Idle. Ich kann nicht ausschließen, dass das AM5-Board wirklich so ein Säufer ist, aber die Zahlen sprechen erstmal für meine Behauptung.


Der 5900 ist ein Säufer? Der verbraucht im Idle genau 1 Watt mehr als i5-12600K. Mal abgesehen davon, dass die Werte eh nicht vergleichbar sind wegen verschiedener Boards. Und was sagt es, dass der 7950 nur 3W mehr braucht als der 7700? Der Unterschied zwischen 1CCD und 2CCD ist deutlich gesunken gegenüber Zen3, was doch dafür spricht, dass die CCD im Idle kaum etwas brauchen. Hier wäre wirklich der Effekt der Boards interessant. Ich vermisse hier die 13er CPUs von Intel mit DDR5, eventuell spielt das auch ne Rolle.

[HOT]

Mein Zen 3-System verbraucht an der Dose 66W mit DDR3200 und wenn absolut nichts läuft mit ca. 17W Package Power laut Ryzen Master (das kleinste Hintergrundprogramm erhöht die Package Power auf über 30W und den Verbrauch an der Dose um 13-15W). CB hat zum Zen-4-Launch gemessen: https://www.computerbase.de/2022-09/amd-ryzen-7950x-7900x-7700x-7600x-test/2/#abschnitt_leistungsaufnahme_in_anwendungen_ab_werk

- 55W für einen 5900X, d.h. deren Board/Restsystem ist sogar noch 11W sparsamer als meins.
- 47W für einen 5800X, d.h. das zweite CCD zieht offenbar ordentlich Saft im Idle.
- 64W für einen 7700X
- 66W für einen 7950X

Zen 4 hat ein anderes Board und anderen RAM. Wenn du jetzt aber behauptest, Zen 4 hätte keinen hohen Idleverbrauch, dann müsste deren AM5-Board ja nicht nur 11W mehr verbrauchen als das AM4-Board, sondern mehr als das, denn ein 5900X ist ja offensichtlich schon ein Säufer im Idle. Ich kann nicht ausschließen, dass das AM5-Board wirklich so ein Säufer ist, aber die Zahlen sprechen erstmal für meine Behauptung.

HWInfo sagt weiter unten, dass Zen 4 immerhin 2-3W sparsamer als Zen 3 ist, aber immernoch deutlich höher als Intel. Die 13000er liegen übrigens auch alle um die 7W.

Bezüglich mobile Versionen: https://www.notebookcheck.net/AMD-Ryzen-9-7945HX-Analysis-Zen4-Dragon-Range-is-faster-and-more-efficient-than-Intel-Raptor-Lake-HX.705034.0.html

Hier konnte AMD den Package-Verbrauch auf 8,3W drücken, was für mich akzeptable Werte für eine Desktop-CPU wären. Nur scheint AMD kein Interesse daran zu haben solche Stromspartechniken auch Desktop-Usern zugänglich zu machen. Im übrigen kommt auch hier Intel mit 5,8W relativ deutlich besser weg und zwar nicht nur auf dem Papier, sondern auch:





Liefer doch erstmal Indizien, warum die verlinkten Zahlen nicht stimmen sollten. Oder Messungen, die meinen widersprechen.



Sind andere Anbindungen (wie z.B. das Fan-Out von N31) denn kompatibel mit den PHYs im IOD? Ansonsten schließt ein Beibehalten des IOD ja auch aus, dass andere Übertragungstechniken genutzt werden.

Das mit dem Ladder-Cache bezieht sich in meinen Augen auf den Cache innerhalb des CCDs. Das hat aber nichts mit Idle-Verbrauch zu tun, selbst wenn die Hitrate des Caches höher läge, denn der Verbrauch fällt anscheinend durchgehend an, nicht nur wenn viele Daten übertragen werden.

Die ganzen "Messungen" kannste sowas von in die Tonne treten... warum misst Igor wohl keinen Idle-Verbrauch? Richtig, weil das verdammt noch mal extrem schwer ist. Du müsstest dann den Verbrauch hinter den SpaWas abgreifen, was nur schwer umzusetzen geht.
Die AMD-Boards sind schon sehr unterschiedlich in ihren Idle-Verbräuchen, die CPU ist da schlichtweg unverdächtig. Die ganze CPU wird im voll-Idle nicht mehr als 10W brauchen, egal ob 1 oder 2 CCD.

Am nächsten an den idle-Verbrauch kommt du mit Ryzen Master, meine Werte mit dem 5800X, an dem ich grad sitze, wären im voll Idle 5W CCD + 12W IOD (wegen DDR4 3600). Die Varianz beim IOD zwischen überhaupt nix los und ach du scheisse ist hier viel Datenverkehr macht beim IOD übrigens phänomenale 0,5W aus. Wie damit ein exorbitanter Idle-Verbrauch zustande kommen soll ist mir ein Rätsel.
Die CPUs sind im idle aber alle gleich sparsam und werden ca. 9W brauchen ohne Übertaktung. Bei Intel sinds halt 7, welch irrer Unterschied. Vielleicht sind die Bestückungen und Konfigurationen bei Intels Boards restriktiver, das würde durchaus zu besseren Idle-Verbräuchen auf Intels Siete führen, aber das ist nicht die CPU in Schuld.

[Zossel]

Die ganzen "Messungen" kannste sowas von in die Tonne treten... warum misst Igor wohl keinen Idle-Verbrauch? Richtig, weil das verdammt noch mal extrem schwer ist. Du müsstest dann den Verbrauch hinter den SpaWas abgreifen, was nur schwer umzusetzen geht.

Warum nicht mit einer Wasserkühlung und messen wie lange es braucht eine bestimmte Wassermenge von x Kelvin auf y Kelvin zu erwärmen?

[Der_Korken]

Der 5900 ist ein Säufer? Der verbraucht im Idle genau 1 Watt mehr als i5-12600K. Mal abgesehen davon, dass die Werte eh nicht vergleichbar sind wegen verschiedener Boards. Und was sagt es, dass der 7950 nur 3W mehr braucht als der 7700? Der Unterschied zwischen 1CCD und 2CCD ist deutlich gesunken gegenüber Zen3, was doch dafür spricht, dass die CCD im Idle kaum etwas brauchen. Hier wäre wirklich der Effekt der Boards interessant. Ich vermisse hier die 13er CPUs von Intel mit DDR5, eventuell spielt das auch ne Rolle.

Der 5900X verbraucht laut AMD-Tool hier 17-18W und das empfinde ich schon als viel. Beim kleinsten Epsilon an CPU-Last (kann irgendein völlig harmloses Hintergrundprogramm sein, das laut Taskmanager 0,x% CPU-Last erzeugt) steigt der Verbrauch auf >30W an. Den Verbrauch der CPU selber kann ich nicht messen, aber die Differenz zwischen den beiden States kann ich an der Dose messen und sie entspricht ziemlich genau der Differenz der vom Ryzen Master ausgelesenen Package Power, plus 1-2W. Mit RAM >3200Mhz liegen die >30W dauerhaft an.

Dass der 5900X bei CB nur 1W über dem 12600K liegt, heißt erstmal nicht viel, da die Board-Verbräuche sehr unterschiedlich sind. Die 5800X und 5800X3D liegen 7W unter dem 5900X, d.h. das muss letzterer on top verbrauchen. Dass der 5600X dann allerdings dazwischen liegt ist wieder komisch, das muss ich zugeben.

Die ganzen "Messungen" kannste sowas von in die Tonne treten... warum misst Igor wohl keinen Idle-Verbrauch? Richtig, weil das verdammt noch mal extrem schwer ist. Du müsstest dann den Verbrauch hinter den SpaWas abgreifen, was nur schwer umzusetzen geht.
Die AMD-Boards sind schon sehr unterschiedlich in ihren Idle-Verbräuchen, die CPU ist da schlichtweg unverdächtig. Die ganze CPU wird im voll-Idle nicht mehr als 10W brauchen, egal ob 1 oder 2 CCD.


Man muss den Idle-Verbrauch natürlich über einen längeren Zeitraum hinweg (also z.B. 15s) ermitteln, weil der sehr unruhig sein kann und viele Mini-Peaks dazwischen sind. Die letzte Aussage möchte ich aber mal ganz hart anzweifeln. Im von Pirx verlinkten Test verbraucht das 5700G-System mal eben 14W weniger als das sparsamste Vermeer-System mit dem 5800X.


Am nächsten an den idle-Verbrauch kommt du mit Ryzen Master, meine Werte mit dem 5800X, an dem ich grad sitze, wären im voll Idle 5W CCD + 12W IOD (wegen DDR4 3600). Die Varianz beim IOD zwischen überhaupt nix los und ach du scheisse ist hier viel Datenverkehr macht beim IOD übrigens phänomenale 0,5W aus. Wie damit ein exorbitanter Idle-Verbrauch zustande kommen soll ist mir ein Rätsel.

Das Addieren von CPU-Power und SoC-Power funktioniert nicht. Bei 18W Package Power habe ich 0,5W CPU-Power und 4W SoC-Power. Mit Steam im Hintergrund sind es 22W PP, 2-3W CPU und 4W SoC. Und mit 3DC offen habe ich wegen des sich drehenden ;D-Smileys 30W PP, 4-5W CPU und 4-5W SoC. An der Dose sehe ich die Differenz zwischen 18W PP und 30W PP aber, das sind keine Phantom-Werte.

Wo sind die anderen 10,5W hin? Bei 32W Package Power habe ich 0,5W CPU-Power und 17W SoC-Power. Da fehlen sogar 14,5W.

[RitterRost]

1000W Netzteil im Desktop mit Notebook verglichen - na herzlichen Glückwunsch für den Idle-Vergleich.

Zumal der Monitor und GPU da eher eine Rolle spielt als die CPU. Mobil kommen auch APUs zum Einsatz (wer die 16-Kern CPUs verbaut denkt über so etwas nicht nach)

Dragon Range hat natürlich eine nach oben beschnittene TDP, aber besteht aus den gleichen Chiplets wie der Ryzen 7000.
https://www.computerbase.de/2023-03/dragon-range-amds-schnellste-mobilprozessoren-starten-in-den-markt/

Gesamtmessungen des Sytems sind eh Unsinn, daraus kannst du rein gar nichts auf den Prozessor ableiten.

Also, in c't 26/2022 ist der 13W (idle) PC mit Intel 12400 und B660 Mainboard aufgebaut.
In Heft 18/2023 sind AM5 A620 Boards getestet. Das sparsamste hat 29W idle-Verbrauch (iGPU genutzt).
Ja, bei den 29W sind auch die ganzen Zusatzchips dabei - die gibts bei Intel oder im Notebook aber auch.

Natürlich muss Euch das Thema nicht interessieren, für mich wäre es ein Kaufargument, wenn AMD die AM5 Plattform sparsamer im idle machen würde.

[HOT]

Dann braucht das Board halt so viel. Grad Billigbretter sind nicht sonderlich mit Effizienz gesegnet.

Klar ist aber: Die CPUs haben keine sonderlich großen Unterschiede bei ihrem Idle-Verbrauch. Du vergleichst immer Äpfel mit Birnen, wenn du unterschiedliche Plattformen vergleichst.
Ein RPL wird immer zwischen 7 und 9W im idle verbrauchen, ein 1 CCD-CPU immer 10-12W. Darauf kommt das Board. Das kann den Verbrauch mal lässig verdoppeln, je nachdem wie das beschaltet ist. Der hohe CPU-Idleverbrauch ist ein Märchen, das sich hartnäckig hält - es gibt keine CPU im im Idle über 20W braucht, das ist Unsinn. Sowas gibts schon seit Jahren nicht mehr im Desktop. Man sollte viel eher mal verschiedene Bretter testen, wie effizient die wirklich sind, das wäre für viele ja ein echtes Auswahlkriterium wie ich das hier sehe. Einigen scheint das ja wichtig zu sein.

[aufkrawall]

Dann braucht das Board halt so viel. Grad Billigbretter sind nicht sonderlich mit Effizienz gesegnet.

Eher ist das Gegenteil der Fall, wenn nicht lauter unnütze Phasen draufgeklatscht sind.

[ChaosTM]

Der Idle Verbrauch Laptop (5900HQ) vs 5800X3D (beide AMD) ist mit 60+ Watt beim Standgerät unfassbar hoch. (50 vs 110 Watt)
Mit all den selben externen USB Geräten angeschlossen. Und das sind viele.

Fiel mir bisher nicht auf. Da hats definitiv was. Gigabyte ?

[Platos]

Idle ist ja auch absolut Praxis irrelevant. Oder wer lässt seinen Rechner ständig laufen ohne je in den Energiesparmodus oder ähnliches zu wechseln? Vlt. sollte der dann dort mal ansetzten...

Wichtig ist der Stromverbrauch bei niedriglast/Teillast (und damit meine ich nicht diese sinnfreien Tests von den bekannten Testseiten, in denen ein single-core Cinebench durchgeführt wird)

Sondern Dinge wie Webseiten laden, Webseiten scrollen, Maus bewegen, Videos schauen auf Youtube (die iGPU gehört schliesslich auch zur CPU und Videos schauen zum alltag vieler) usw.

Idle sagt nämlich so ziemlich gar nichts über den Stromverbrauch bei Niedriglast/Teillast aus. Ausser vlt, dass der Idle sicher nicht höher ist, wie die anderen beiden. Aber ein niedriger idle Stromverbrauch sagt erstmal gar nichts über Niedriglast/Teillast aus.

Da ist AMD ja

[latiose88]

also ich habe den Pc überwiegend im idle laufen. Ich lade was runter sowie vom Handy Videos auf das Netzlaufwerk kopierend und schalte dann den Bildschirm aus.Das dauert einige Stunden dann.Also doch viel Idle verbrauch.ALso wichtig.

[bbott]

Die (AM4) APUs kommen auf Idle unter 20W mit Optimierungen, ich habe schon Beiträge mit unter 10W (AM4) im HWLuxx gesehen.
Mein AMD Ryzen 5 PRO 5650G, 32GB ECC und ASUS TUF Gaming B550M-Plus liefen auf 18-20W unter Linux und mit Windows 10 nochmal 1-2W weniger (Steckdose). Darunter kommt man mir besserem NT für niedrige Lasten.
Mit AM5 APUs sollte es auch möglich sein, allerdings dürfte dies nur mit Mainboards OHNE PCIe 5 möglich sein. Als auch ohne maximal Ausstattung und RGB etc.

Im Hardwareluxx habe einige auch die Chiplett CPUs ziemlich weit herunter bekommen.

[latiose88]

ja danke für die Info.Das bestätigt auch das was ich so vor habe.Wenn ich mal Zen 5 habe mit AM5 dann will ich die Onbaord GPU verwenden.Dedzierte GPU kommt also garnicht mal mehr rein.
Die Onbaord GPUs dürften beim Idle um einiges sparsamer sein.Ich rechne mit rund 5 Watt im Idle.
Dazu dann der verzicht auf PCI Epxress 5,2 Ramslots Maximal.Als Ram kommt dann sowas wie DDR5 5600 oder wenn DDR5 5200 mhz billiger ist dann das.Timinings sollten es zumindest 28 sein.Der Ramtakt ist nicht so schlimm.Gezockt wird ja eh nur was altes.Wenn ich sogar bei einem meiner PCS mit nur einer gtx 750 ti unterwegs bin ,dann ist das garkein Problem. Gezockt wird auf Full HD.Einer meiner hat zwar 144 Hz aber dürfte ja kein Problem sein.
Das Netzteil habe ich eines wo bei rund 275 Watt 92 % Wirkungsgrad bei Gold erreicht.Werde allerdings wohl drunter kommen.Eine Stufe höher das lohnt sich dennoch kaum.Ich müsste schon auf 400 Watt runter gehen das ich einen sicheren 50 % Auslastung erreichen kann.
Auf der CPU seite werde ich immer mal wieder Richtung 100 % kommen.Mir wollte wer das abraten weil das was die Onbaord GPU so verbraucht geht mir dann bei der CPU an Rohleistung verloren.Es sei denn ich lasse die CPU auf 200 Watt dann nicht.Wenn ich allerdings auf 142 Watt runter gehen würde,wäre die Leistung um einiges schlechter.Es sei denn ich haue die Watt wo die GPU verbraucht oben drauf.Denke mal mehr als 20 Watt maximal wird die Onbaord GPU nicht verbrauchen.Ist immer noch sparsamer als die gt 1030.Weil mit der hatte ich auch schon mit dem Gedanken gespielt gehabt.

Mit dieser Aufstellung dürfte ich sowohl im idle als auch unter Last einen sparsamen Computer haben.
Der Fokus richtet sich halt mehr auf die CPU Leistung.
Ich bin halt wenn ich zocke passen die ganzen Spiele gut ins untere Bereich also lowend zocker.
Spiederman 2016,Worms Amageddon,C&C die Stunde Null,CS Source nicht die neueren Counterstirikes vielleicht hole ich mir noch Battle Field 1942,Serious sam 2 habe ich auch noch.
Und wenn ich Bock drauf habe wäre das neueste Game A way Out von 2018.
Mehr als 144 fps brauche ich nicht.Onbaord hat nur leider ein Problem,man kann im Treiber leider keine FPS Limits eingeben.Das ist halt ein großer Nachteil wie ich finde.
Wenn ich von meinem jetzigen Pc jedoch die gtx 1650 nehme hat der wo ich gerade nutze keine GPU mehr.Das Problem ist diese GPU braucht im Idle 13 Watt.

Das würde mich also etwas von meinem Ziel abbringen möglist sparsam unterwegs zu sein.
Und ja wenn ich ganz hart drauf wäre,würde ich mir ein 24 " Bildschirm mit Native HD für den Pc zum zocken holen.Aber so übel bin ich dann doch nicht drauf.
Ich denke mal weiter runter kommt man da echt nicht mehr.Es sei denn ich würde die CPU Leistung nicht brauchen.Aber da ich das halt einige male immer wieder brauche,kann ich da echt nix weiter runter gehen.Ich könnte auch Sata Anschlüsse Opfern.Nur eines brauche ich wirklich und zwar einige USB Anschlüsse.
Also wenn ich akribisch drauf wäre,könnte man ja im Bios alle Sata Anschlüsse deaktivieren.
Ich selbst habe nur noch ein externes Bluray Laufwerk da.
Zum schneiden werde ich neben der SSD doch eine HDD brauchen weil die SSD ist mir zu unsicher bei ner starken Nutzung.
Aber wenn dann schaue ich das bei der HDD ne USB wäre oder nutze ich doch einmal Sata wer weis.

Sollte doch noch mehr Strom sparen gehen,dann kann mir ja gerne wer Informieren.Nehme gerne Ratschläge an.
Ausgeschaltet lassen geht echt nicht.Dann wenigstens so wenig Strom wie möglich.
Achja das gute an dem ganzen ist,da ich garkein Raytracing nutze brauche ich auch keine Raytracing GPU.Das ist ein weiterer Vorteil für mich.Das ganze habe ich schon seid Jahren so.
Ob sich da jemals was bei mir nach über 10 Jahren ändern wird,da habe ich echt meine Zweifel.Ich denke mal nicht.

Wenn man weis was man braucht,ist ein Kauf viel leichter.Da muss man sich weniger Kopf drüber machen.Das finde ich gut so.

[Daredevil]

Idle ist ja auch absolut Praxis irrelevant. Oder wer lässt seinen Rechner ständig laufen ohne je in den Energiesparmodus oder ähnliches zu wechseln? Vlt. sollte der dann dort mal ansetzten...

Wichtig ist der Stromverbrauch bei niedriglast/Teillast (und damit meine ich nicht diese sinnfreien Tests von den bekannten Testseiten, in denen ein single-core Cinebench durchgeführt wird)

Sondern Dinge wie Webseiten laden, Webseiten scrollen, Maus bewegen, Videos schauen auf Youtube (die iGPU gehört schliesslich auch zur CPU und Videos schauen zum alltag vieler) usw.

Idle sagt nämlich so ziemlich gar nichts über den Stromverbrauch bei Niedriglast/Teillast aus. Ausser vlt, dass der Idle sicher nicht höher ist, wie die anderen beiden. Aber ein niedriger idle Stromverbrauch sagt erstmal gar nichts über Niedriglast/Teillast aus.

Da ist AMD ja
Je mehr Kerne deine Kiste hat, desto mehr Kerne werden auch im Idle sein, selbst wenn man mal ne Runde zockt, oder? Insofern ist das ggf. nicht monetär wichtig, aber aus Prinzip, zumindest meinem. :D
Relevant wird es aber letztendlich, wenn man mobil Leistung mit Laufzeit verbinden möchte, da kann Intel/AMD gerne mal Cores entwickeln, die mit Apple aufschließen und diese dann in den Desktop Bereich bringen.
Die Kiste im Ally macht es ja schon mal ganz gut, nicht jeder braucht nen Desktop PC mit Unmengen an Anschlussmöglichkeiten, die unnötig Ressourcen verbrauchen.

Es ist eigentlich ziemlich witzig, das all meine Batterie betriebenen Geräte dauerhaft an sind im AlwaysOn/Idle ( iPhone, iPad, MacBook ), während die Stromunkritische Komponente PC lieber ausgeschaltet bleibt, weil sie viel Strom verbraucht. 4-5w Idle für das komplette MacBook ( Old Gen M1 Max ) vs. 60w beim Gaming Rechner ( 5600x/3090 ) fühlt sich so an, als hätte man noch nen Xeon in der Kiste, der einfach keinen Idle Mode hat. :D

Mein nächster Gaming Rechner wird definitiv auch eher minimalistisch von der CPU/MB Seite her. Die ganze Peripherie, die ich mitbezahle und Strom säuft, nutzen die meisten ja eh nicht.
Wenn man natürlich ne Workstation hat mit hunderten von GB an RAM und allen belegten PCIe Slots, ist das natürlich eine andere Sache. Hier lutscht der MacPro mit gleichen dann ja auch mehr als der MacStudio mit gleicher Ausstattung, dieser ganze PCIe gedöns kostet halt.

[dildo4u]

Paar Infohappen und Wunsch Konfiguration.


b2aD3aIAeMo

[Zossel]

fühlt sich so an, als hätte man noch nen Xeon in der Kiste, der einfach keinen Idle Mode hat. :D

HLT gibt es seit dem Jahr 1994:

https://de.wikipedia.org/wiki/HLT_(Maschinenbefehl)

[Platos]

@Daredevil: Handy ständig laufen lassen? Dein Handy wechselt soch bestimmt nach 30-120s in den standby? Das wäre dann auch kein idle...

Selbiges gilt für Tablet und Laptop. Warum sollte der ständig laufen?

also ich habe den Pc überwiegend im idle laufen. Ich lade was runter sowie vom Handy Videos auf das Netzlaufwerk kopierend und schalte dann den Bildschirm aus.Das dauert einige Stunden dann.Also doch viel Idle verbrauch.ALso wichtig.

Dafür sollte man sich nen mini-pc zulegen, der 7w im idle zieht oder sowas. Zum Downloaden nen fetten Desktop-PC hinstellen ist schon absurd.

Oder ein alter Laptop geht auch. Hardware ausbauen (oder auch nicht) und den nutzen als Download-PC.

[Der_Korken]

Dafür sollte man sich nen mini-pc zulegen, der 7w im idle zieht oder sowas. Zum Downloaden nen fetten Desktop-PC hinstellen ist schon absurd.

Finde ich a) verschwenderisch, sich eine zusätzliche Maschine nur dafür zu kaufen, weil die Hersteller für größere Maschinen es nicht hinbekommen, Stromsparmechanismen vernünftig umzusetzen. Und b) nervig, weil es ein Gerät mehr ist, wo man seine Sachen mit synchronisieren muss. Es hat ja keiner verlangt, dass Gaming-Rechner ab jetzt nur noch 5W im Idle verbrauchen dürfen, aber 60, 80 oder gar 100W müssen es auch nicht sein, wenn das nicht durch entsprechende Peripherie gerechtfertigt ist.

[bbott]

@latiose88

Das gibt nur die Richtung vor, ABER das ASUS TUF Gaming B550-Plus (ATX) ist genauso sparsam wie das ASUS TUF Gaming B550M-Plus (mATX). Vergiss die NT Gold, Platinum etc. Zertifizierung, frage lieber in einem Forum z. B. Hardwareluxx nach praktischer Erfahrung. Da haben teils Gold, Silber NTs bessere Werten in solch niedriger Belastung. wir reden hier von unter 1-2% NT Belastung bei z.B. 850W.

Weder das Mainboard noch die CPU sind dann ausschlaggebend (Sub ~20W), das NT ist in diesem Bereich der größte Faktor und die CPU der kleinste.
Z.B. mit dem ASUS TUF Gaming B550M-Plus und irgend einer AM4 APU kommt man auf ~10W mit dem richtigen ATX NT (Notebook Netzteile mit ATX Converter kann ~8W). Das sind nochmals 10-12W (>50%) weniger.

[Complicated]

Das mit dem Ladder-Cache bezieht sich in meinen Augen auf den Cache innerhalb des CCDs. Das hat aber nichts mit Idle-Verbrauch zu tun, selbst wenn die Hitrate des Caches höher läge, denn der Verbrauch fällt anscheinend durchgehend an, nicht nur wenn viele Daten übertragen werden.
Der Laddercache verringert die Zahl der "Hops" im CCD und dadurch spart es auch Strom, während auch die IPC verbessert wird. Du hast Recht mit dem Hinweis auf die Fanouts/Interconnects. Doch diese werden nicht in den einzelnen Chips integriert, sonder können zugefügt werden mit InFO-LSI. Die Chips nutzen die vorhandenen TSV und das Standard Flipchip-Verfahren um an dem Interconnect verbunden zu werden. Siehe hier bei Anand beschrieben: https://www.anandtech.com/show/16031/tsmcs-version-of-emib-lsi-3dfabric
InFO is TSMC’s fan-out packaging technology, where a silicon die from a wafer is picked out and placed on a carrier wafer, upon which the further bigger structures such as the copper RDL (Redistribution layer), and later the carrier substrate is built upon.
TSMC’s variant of InFO with integration of an LSI is called InFO-L or InFO-LSI, and follows a similar structure with the new addition of it integrating this new local silicon interconnect intermediary chip for communication between two chips.

Hier ist eine sehr Interessante Zusammenstellung wie die einzelnen Technologien dann aussehen:
https://overclock3d.net/gfx/articles/2021/08/23110814324l.jpg

Eher ist das Gegenteil der Fall, wenn nicht lauter unnütze Phasen draufgeklatscht sind.
Genau so sieht es aus - wem Idle wichtig ist verzichtet auf die ganzen Steroid-Phasen des OC-Marketings für die Mainboards.

[davidzo]

Es hat ja keiner verlangt, dass Gaming-Rechner ab jetzt nur noch 5W im Idle verbrauchen dürfen, aber 60, 80 oder gar 100W müssen es auch nicht sein, wenn das nicht durch entsprechende Peripherie gerechtfertigt ist.

Ich denke das wäre technisch schon möglich. Das muss man dann nur bei der Entwicklung priorisieren. Sprich man bräuchte ein EU-Gesetz oder kalifornisches Gesetz o.Ä. das die Hersteller dazu zwingt in bessere Idle-Modi zu investieren. Vorher bewegt sich nichts.
CPU und mainboard so tief power zu gaten ist ne reine firmwaresache und dass das geht sieht man ja an labtops die praktisch das gleiche Silizium benutzen und geringere Idle-verbräuche schaffen.
Bei GPUs sehe ich noch das Problem dass der GDDR6 sich nicht weit genug herunter takten lässt. Gerade AMD hat hier Probleme, womöglich mit dem Speichercontroller. Wenn die DRAM Hersteller hier aber auf neue Power Modi achten müssen und die Speichercontroller so konstruiert sind dass sie auch mit wenig Takt und Spannung keine Bitfehler machen, bzw. man einfach einen respin braucht wenn sie so schlecht sind wie bei AMD jetzt, dann kriegt man das auch hin. Nur war es diese Generation für AMD halt egal. Es war wichtiger die Produkte endlich aus der Tür zu bekommen. Aber technisch unmöglich wäre es sicher nicht!

[Zossel]

Ich denke das wäre technisch schon möglich. Das muss man dann nur bei der Entwicklung priorisieren. Sprich man bräuchte ein EU-Gesetz oder kalifornisches Gesetzt o.Ä. dazu das die Hersteller zwingt in bessere Idle-Modi zu investieren. Vorher bewegt sich nichts.Leider rasten bei solchen Gesetzen gewisse Teile unserer Mitbürger völlig aus.Wenn die DRAM Hersteller hier aber auf neue Power Modi achten müssen und die Speichercontroller so konstruiert sind dass sie auch mit wenig Takt und Spannung keine Bitfehler machen, bzw. man einfach einen respin braucht wenn sie so schlecht sind wie bei AMD jetzt, dann kriegt man das auch hin. Nur war es diese Generation für AMD halt egal. Es war wichtiger die Produkte endlich aus der Tür zu bekommen. Aber technisch unmöglich wäre es sicher nicht!Das "LP" in LPDDR steht für "Low Power", es ist ja nicht ja nicht so als das es dort keine Möglichkeiten gäbe.

[davidzo]

Leider rasten bei solchen Gesetzen gewisse Teile unserer Mitbürger völlig aus.
Völlig ohne Grund, davon profitiert im Endeffekt jeder. Geringerer Energieverbrauch -> geringere Stromkosten -> geringere Nachfrage -> sinkender Energiepreis. Und letzteres wünschen sich ja gerade die Coal-roller die viel verbrauchen. Die sollten mal ein bisschen dankbarer sein wenn Andere freiwillig weniger verbrauchen, denn am Ende profitieren die Vielverbraucher am meisten davon.
Und wenn ich weiterhin gerne bis an die Kotzgrenze Takte hindert mich daran ja keiner. Die effizientere Firmware ist ja bloß der Werkszustand, danach kann ich das Vieh übertakten wie ich möchte. Solange das nicht verboten ist kommt auch niemand in die Wohnung und kontrolliert ob der PC übertaktet ist. Für die Coal-roller unter den PC-Enthusiasten gibts also keine Einschränkungen. Es gibt nur mehr Optionen für Leute die Energieeffizienz schätzen und für die Allgemeinheit sinnvollere Default-Konfigurationen.

Erst die kalifonische Energiebehörde und die Ökodesignrichtlinie haben für durchgehend 80+ Netzteile gesorgt und damit für erhebliches Momentum im Netzteilmarkt. Ohne 1600Watt Gold oder Platinum Netzteile wären moderne Highend CPUs und GPUs kaum denkbar. Bei der 60-70prozentigen Effizienz die in den 2000ern bis 2010ern vorherrschte würde so ein Netzteil verglühen oder müsste tatsächlich dreimal so groß sein.


Das "LP" in LPDDR steht für "Low Power", es ist ja nicht ja nicht so als das es dort keine Möglichkeiten gäbe.
Genau, ich wäre auch dafür bei Entry to midrange Chips einfach den GDDR6 durch ein breiteres LPDDR Interface zu ersetzen. So wie bei Apple oder der DG1. Dann ist auch gleich das Problem der zu kleinen VRAM Menge bei entry-Karten gelöst.

[rentex]

Paar Infohappen und Wunsch Konfiguration.


https://youtu.be/b2aD3aIAeMo


Also DDR5 5600 als Standard RAM Takt...

[HOT]

Ich denke eher, dass man 6400 mit Expo offiziell freigeben wird, wie bei Ryzen 5k 3200 mit XMP.

[rentex]

Ich denke eher, dass man 6400 mit Expo offiziell freigeben wird, wie bei Ryzen 5k 3200 mit XMP.

EXPO ja vllt. Schrieb vom Standardtakt, der bei Ryzen 7000 bei 5200 liegt.

[HOT]

Nope, beim 5k gibt es auch offzielle 3200er Jedec-Module, das wirds bei 6400 sicher auch geben. Also offizieller Speichertakt 6400, realisiert meist eben durch EXPO, aber auch high-latency-Module nach JEDEC-Spezifikation. Da wird einfach der offizielle Speichertakt von 5600 auf 6400 angehoben würde ich sagen. 5600er wird definitiv nicht mehr der offizielle Maximaltakt sein. Mindestens 6000, ich denke aber 6400. 7200 wie Tom von MLID postuliert wirds ganz sicher aber nicht ;).

[Lehdro]

Genau so sieht es aus - wem Idle wichtig ist verzichtet auf die ganzen Steroid-Phasen des OC-Marketings für die Mainboards.
Mein altes Asrock Z68 hatte IES (https://www.asrock.com/feature/ies/index.asp?c=Interface), was automatisch im idle alle bis auf 1-2 Phasen ausgeschaltet hat. Das musste man damals allerdings händisch aktivieren. Hätte eigentlich gedacht dass so etwas heutzutage weitverbreitet und automatisch im Hintergrund auf Boardebene aktiv ist, aber näher befasst habe ich mich damit nicht...

[rentex]

Nope, beim 5k gibt es auch offzielle 3200er Jedec-Module, das wirds bei 6400 sicher auch geben. Also offizieller Speichertakt 6400, realisiert meist eben durch EXPO, aber auch high-latency-Module nach JEDEC-Spezifikation. Da wird einfach der offizielle Speichertakt von 5600 auf 6400 angehoben würde ich sagen. 5600er wird definitiv nicht mehr der offizielle Maximaltakt sein. Mindestens 6000, ich denke aber 6400. 7200 wie Tom von MLID postuliert wirds ganz sicher aber nicht ;).

7200 glaub ich ebenfalls nicht. Tippe max. 6000 MHz. Ob AMD am Speichercontroller mehr macht, bezweifle ich.

[Fusion_Power]

Leak deutet auf AMD Ryzen 8050 mit stärkerer RDNA 3.5 iGPU und Hybrid-Design mit 12 Zen 5-Kernen
(https://www.notebookcheck.com/Leak-deutet-auf-AMD-Ryzen-8050-mit-staerkerer-RDNA-3-5-iGPU-und-Hybrid-Design-mit-12-Zen-5-Kernen.746719.0.html)
Mit Ryzen 8050 "Strix Point" plant AMD offenbar ein Hybrid-Design mit Performance- und Effizienz-Kernen, ähnlich wie Intel Raptor Lake. Ein Leak deutet auf die Kern-Konfiguration und die stärkere iGPU auf RDNA 3.5-Basis, die offenbar bei AMDs Laptop-Prozessoren der nächsten Generation zum Einsatz kommen werden.

https://www.notebookcheck.com/fileadmin/_processed_/7/0/csm_AMD-STRIX-POINT-APU-GPU-SPEC_5b40ebd198.jpg

https://www.notebookcheck.com/fileadmin/_processed_/9/d/csm_AMD-STRIX-POINT-APU-SPEC_4c6071904a.jpg

I-GPU mit 16 Compute Units, Das hört sich doch schon mal vielversprechend an. :)

[MSABK]

Der braucht aber ordentlich Speicherbandbreite.

[Der_Korken]

Die Cache-Größen sehen komisch aus auf dem Screenshot. 2x1M L2 für 8 E-Cores? Zen 4C hat 1MB/Core, warum so ein Rückschritt? Und nur 8MB L3 für den ganzen Chip, wo die Vorgänger schon 16MB hatten?

[HOT]

Quatsch, das ist ein Anzeigefehler. Es muss 8x1MB heißen und 32MB L3$ (16+16).

[robbitop]

Der braucht aber ordentlich Speicherbandbreite.
Ja sehr schade, dass AMD keinen kleinen IF$ spendiert. Selbst 16 MiB würden schon ordentlich helfen.

[HOT]

Strix Point soll 128Bit LPDDR5X 8533 untersützen. Das ist schon sehr viel. Nur im Desktop wäre dann DDR5 6400 normal, das ist aber egal für den IGP. Mobil ist sowieso nur LPDDR5X ernstzunehmen. Man wird die Möglichkeit für LPDDR5X ernster nehmen als noch mehr Die-Space zu verballern.

[rentex]

Gesetzt den Fall, man möchte auf AM5 von ZEN4 auf ZEN5 Desktop umsteigen und der Standardtakt erhöht sich von 5200 auf 6400, müsste man schon entsprechend taktbaren RAM im Sys haben. Bin mal gespannt wie das Ablaufen wird.

[robbitop]

Strix Point soll 128Bit LPDDR5X 8533 untersützen. Das ist schon sehr viel. Nur im Desktop wäre dann DDR5 6400 normal, das ist aber egal für den IGP. Mobil ist sowieso nur LPDDR5X ernstzunehmen. Man wird die Möglichkeit für LPDDR5X ernster nehmen als noch mehr Die-Space zu verballern.
Das sind nur 13% mehr als das was Phoenix unterstützt. Und man will doch hoffentlich schneller als nur +13% werden. Und bereits Phoenix ist ziemlich Bandbreitenlimitiert.
Zu erwarten sind +33% mehr WGPs/CUs und sicherlich etwas mehr Takt. Das sollten dann in Summe sicherlich gute +50% werden. Da ist die Erhöhung der Bandbreite um nur 13% ein Tropfen auf den heißen Stein.

[HOT]

Vermutlich ist das AMD egal, wenn sehr bandbreitenbasierte Scenarien nicht toll laufen ;).

[Der_Korken]

Dann hätte man auch bei 12 CUs bleiben können und Die-Area sparen können. Oder den Platz der 4 zusätzlichen CUs stattdessen in Cache für die GPU investieren können.

[HOT]

Wieso, es gibt doch auch Scenarien, die nicht so bandbreitenlimitiert sind. Außerdem wirst mobil eh nicht so irre viel Takt halten können. Mehr Breite und näher am Sweetspot ist doch gut.

[davidzo]

Und als ob die 80kb L1 cache jetzt gegenüber den bisherigen 64kb groß ins Gewicht fallen.

Schade, es wird wohl gekleckert statt geklotzt. Ganz anders bei Intels Royal Cores wo der L1 verdoppelt wird und der L2 im Vergleich zu den letzten Jahren verdreifacht. Hat AMD nun auch nicht so nötig, aber es wäre doch al schön für den Konsumenten wenn auch das schnellste Pferd mal etwas höher springen würde.

Dementsprechend erwarte ich auch abseits vom Cachesystem keinen "ultra breiten" Core, sondern eher behutsame Verbesserungen. Ja, es wird mindestens ein 5wide decoder, vermutlich bekommen wir einen zusätzlichen load/store port und vielleicht sogar noch eine integer oder FP unit. Die Sprungvorhersage bekommt das übliche Makeover wie in jeder Gen und dann kommen durch die Fertigung 15% weniger Energieverbrauch bzw. 5% mehr sustained Multicore Taktraten bei gleichem Verbrauch, was für sich gesehen auch nicht schlecht ist. Dazu eine bessere XDNA Engine, also AI accelerator und aktuellere Videocodecs und fertig ist das 8000er Produkt für 2024.

Die +25% IPC gains auf dem Hypetrain der Gerüchte sehe ich irgendwie noch nicht kommen. Wo sollen die her kommen? Der L3 laddercache macht den zwar nochmal minimal latenzärmer für 1T Workloads, aber soll das wirklich soviel bringen?

[KarlKastor]

Quatsch, das ist ein Anzeigefehler. Es muss 8x1MB heißen und 32MB L3$ (16+16).
Quelle?
8+16 sind ja auch im Gespräch.

[Zossel]

und aktuellere Videocodecs

Hat sich da was in den letzten Jahren getan?
Die Zeiten wo jeder Monat einen neuen Codec brachte sind ja schon länger vorbei.

[HOT]

Quelle?
8+16 sind ja auch im Gespräch.
8+8 oder 8+16, 8+16 passt nicht. 2 c-Kerne belegen soviel Platz wie ein großer.

[davidzo]

Hat sich da was in den letzten Jahren getan?
Die Zeiten wo jeder Monat einen neuen Codec brachte sind ja schon länger vorbei.
Der AMD AV-1 Codec ist von der Quali so meh. Also enkodieren meine ich. Und da meistens auch mit jeder Gen ein schnelleres Mipi-csi Kamerainterface kommt, wäre es nicht schlecht wenn man das bessere Videosignal dann auch besser kodieren kann. Apple hat immerhin prores seit ewigkeiten was x86 praktisch aus dem professionellen Videoschnitt-markt rausgekickt hat weil scrubbing durch 8K 422 raw footage auf einem 13" ultrabook plötzlich mehr spaß macht als auf einer 56Core Rackmount Maschine mit Quadro GPU. Ich würde also auch nicht ausschließen wollen das ein x86 Player irgendwann mal sowas verbaut, das wäre mal was für den Sarlak i/o DIE.

[Fusion_Power]

Strix Point soll 128Bit LPDDR5X 8533 untersützen. Das ist schon sehr viel. Nur im Desktop wäre dann DDR5 6400 normal, das ist aber egal für den IGP. Mobil ist sowieso nur LPDDR5X ernstzunehmen. Man wird die Möglichkeit für LPDDR5X ernster nehmen als noch mehr Die-Space zu verballern.
Steckbar wirds wohl dann vermutlich eh wieder nicht so schnell werden beim RAM wie wenn er verlötet ist. Spielt ja schon ne Rolle wenn man auf eine iGPU setzt. für ordentlich mehr Speed würde ich beim Laptop aber den Kompromiss von verlötetem RAM eingehen. Ich sehe mich in Zukunft jedenfalls mehr und mehr als iGPU-Gamer. :cool:

[latiose88]

Und als ob die 80kb L1 cache jetzt gegenüber den bisherigen 64kb groß ins Gewicht fallen.

Schade, es wird wohl gekleckert statt geklotzt. Ganz anders bei Intels Royal Cores wo der L1 verdoppelt wird und der L2 im Vergleich zu den letzten Jahren verdreifacht. Hat AMD nun auch nicht so nötig, aber es wäre doch al schön für den Konsumenten wenn auch das schnellste Pferd mal etwas höher springen würde.

Dementsprechend erwarte ich auch abseits vom Cachesystem keinen "ultra breiten" Core, sondern eher behutsame Verbesserungen. Ja, es wird mindestens ein 5wide decoder, vermutlich bekommen wir einen zusätzlichen load/store port und vielleicht sogar noch eine integer oder FP unit. Die Sprungvorhersage bekommt das übliche Makeover wie in jeder Gen und dann kommen durch die Fertigung 15% weniger Energieverbrauch bzw. 5% mehr sustained Multicore Taktraten bei gleichem Verbrauch, was für sich gesehen auch nicht schlecht ist. Dazu eine bessere XDNA Engine, also AI accelerator und aktuellere Videocodecs und fertig ist das 8000er Produkt für 2024.

Die +25% IPC gains auf dem Hypetrain der Gerüchte sehe ich irgendwie noch nicht kommen. Wo sollen die her kommen? Der L3 laddercache macht den zwar nochmal minimal latenzärmer für 1T Workloads, aber soll das wirklich soviel bringen?
Villeicht kommen ja noch 200-300 mh Allcore Takt noch oben drauf,so das es dann wenigstens 20% dabei rum kommt.Das sehe ich als realistisch an.Wie viel Strom es am Ende brauchen wird,das sehen wir dann auch noch.Oder hast du das etwa damit gemeint gehabt?
So viel erwarte ich ebenso nicht wie du auch.

[robbitop]

Und als ob die 80kb L1 cache jetzt gegenüber den bisherigen 64kb groß ins Gewicht fallen.

Schade, es wird wohl gekleckert statt geklotzt. Ganz anders bei Intels Royal Cores wo der L1 verdoppelt wird und der L2 im Vergleich zu den letzten Jahren verdreifacht. Hat AMD nun auch nicht so nötig, aber es wäre doch al schön für den Konsumenten wenn auch das schnellste Pferd mal etwas höher springen würde.

Dementsprechend erwarte ich auch abseits vom Cachesystem keinen "ultra breiten" Core, sondern eher behutsame Verbesserungen. Ja, es wird mindestens ein 5wide decoder, vermutlich bekommen wir einen zusätzlichen load/store port und vielleicht sogar noch eine integer oder FP unit. Die Sprungvorhersage bekommt das übliche Makeover wie in jeder Gen und dann kommen durch die Fertigung 15% weniger Energieverbrauch bzw. 5% mehr sustained Multicore Taktraten bei gleichem Verbrauch, was für sich gesehen auch nicht schlecht ist. Dazu eine bessere XDNA Engine, also AI accelerator und aktuellere Videocodecs und fertig ist das 8000er Produkt für 2024.

Die +25% IPC gains auf dem Hypetrain der Gerüchte sehe ich irgendwie noch nicht kommen. Wo sollen die her kommen? Der L3 laddercache macht den zwar nochmal minimal latenzärmer für 1T Workloads, aber soll das wirklich soviel bringen?

Die Frage ist immer was limitiert. Damit ein Kern effiziwnt ist, muss alles schön ausbalanciert sein. Ansonsten verballert man nur Transistoren oder Energie. Wenn es nur darum geht alle high level specs zu matchen wären die Samsung M1-5 Kerne ein Erfolg gewesen. Sie wurden von den schlankeren ARM Cores geschlachtet.

Gleiches gilt für die Coves. Sehr schnell (bei hohem Takt vor allem) aber auch total breit und durstig in Relation zu den Zen äquivalenten was man im mobile Markt stark zu spüren bekommt.

Was hat die extremwe Vergrößerung der L2 Caches bei Intel (isoliert) denn gebracht? Von 256 kib bis zu den heutigen 2 MiB?
Wohl kaum viel. RTL brachte im Durchschnitt Taktnormiert gerade mal 3% mehr in Spielen ggü ADL. Bei Zen 4 brachte die Verdopplung des L2 Caches nur ein Fitzelchen des nicht gerade großen IPC Sprungs laut AMD slide.

Gerade bei den X3Ds ist das Cachesystem schon echt gut ausbalanciert über alle Cache Levels hinweg. Und wenn ich die chipsandcheese Analyse von Zen 4 richtig verstehe ist das kein großer Bottleneck.

Wenn man nur auf high level specs schaut hätte Zen 3 fast nichts bringen dürfen - high level wurde da fast nichts ggü Zen 2 verbessert. Aber es war innerhalb der Zen Linke bis dato der größte IPC Sprung. Weil viel von der Implementierung liegt. Und nicht darin wer maximale Zahlen bei Cache, ROB, decoders, backend resources hat.

AMD balanciert seine Zen Kerne bis dato sehr überlegt aus und erhöht alles nur um das was es muss damit es ausbalanciert bleibt.

Ggf reicht die leichte Anpassung des L1 Cache auch einfach um die erhöhte Decoderanzahl sinnvoll zu nutzen. Ggf werden auch andere Dinge noch angehoben. Ich kann mir aber vorstellen, dass in der Implementierung selbst vieles verbessert wird, damit die Performance steigt.
AMD war mit der Verbreiterung bis dato sehr zurück haltend. Mit Zen 5 das erste Mal mehr decoder. Da kann man davon ausgehen, dass sie es entsprechend balancen und auch ein ordentlicher Schluck an Performance herauskommen sollte. +25% finde ich da nicht unrealistisch

PS
Ich finde man kann auch diese super breiten Designs wie M1/2 mit ihren 3+ GHz auch schwer mit den etwas schmaleren die fast 6 GHz erreichen vergleichen. Klar wenn man den Frequenzverlust mit IPC wieder wettmachen kann und dabei energieeffizienter wird ist es okay. Wird aber nicht leicht.

[latiose88]

ja sehe ich auch so.AMD hat seid Zen 1 den Decode nicht mal angefasst ,ist somit gleich geblieben.
Ist also schon verwunderlich mit welchen Schritten AMD hier es verbessert.Und 5 Anstatt 4 Instruktionen pro Zyklus ist wirklich beeindruckend.
Dann ein weniger mehr CPU Takt,dank größeren L1 können dann auch mehr in den kleinen Cache passen und das hilft schon weiter.
Nicht alle Software wird davon gleich stark Profitieren.Klar ist das sowas auch Transistoren Fläche kosten wird.Blöd wird es wenn die Anwendung wo man verwendet nicht von dem größeren L1 Cache sondern vom CPU Takt profitiert aber genau der dann was weis ich um 200-300 mhz Allcroe Takt sinkt.Dann wird das Plus das man dazu erhalten würde gleich wieder zu nichte gemacht,was echt schade wäre weil durch das mehr Leistung schwierig wird.

[reaperrr]

Und als ob die 80kb L1 cache jetzt gegenüber den bisherigen 64kb groß ins Gewicht fallen.
Das heißt, einer der beiden Caches ist um 50% verbreitert worden, was normalerweise auch mit 50% höherer Assoziativität und Cache-Bandbreite einhergeht.
Seit Zen2 (der den L1I halbiert, aber Assoz. verdoppelt hat) gab es keine nennenswerten Änderungen am L1 mehr, das ist schon ne Änderung, die ordentlich ist. Ice Lake hatte auch nicht mehr, und hat 18% IPC auf CFL draufgepackt.


Schade, es wird wohl gekleckert statt geklotzt. Ganz anders bei Intels Royal Cores wo der L1 verdoppelt wird und der L2 im Vergleich zu den letzten Jahren verdreifacht.
Jep, und im Ergebnis schafft Zen5 dann dafür wahrscheinlich MultiCore einen höheren Takt mit 16 Kernen als Arrow's 8 P-Kerne, bei halbem Verbrauch :wave:

[latiose88]

mit Cfl ist wohl Coffe Lake gemeint nicht wahr?

Ja gut es gibt ja auch Anwendung die ab einen gewissen Punkt nicht mehr Cache Lastig ist.Und ist die Frage wenn man genug L1 und L2 Cache hat,ob man dann L3 Cache reduzieren kann also halbieren ohne wirklich verluste zu haben oder geht das nicht gut?

Und wenn man mehr Decode hat,kann dann die CPU den COde dann noch mehr verkleinern und dann draus mehr Aufträge machen so das auch die Bandbreite damit sehr stark als Abhängigkeit reduziert werden kann oder funktioniert das nicht so einfach und man kann ab einen gewissen Punkt es nicht noch mal extra verkleinern die ganzen Arbeiten für die CPU?

[KarlKastor]

8+8 oder 8+16, 8+16 passt nicht. 2 c-Kerne belegen soviel Platz wie ein großer.

Was soll das bedeuten? Ziemlich kryptisch.

[latiose88]

was er meint sind wohl zen 4c also wo mehr kerne aber weniger L3 und weniger CPU Takt.Hat er wohl verwechselt gehabt.Ja sowas wäre auch interessant,dann würde ich endlich wissen ob dank L2 und mehr L1 die Abhängigkeit von L3 sich verringert hat oder nicht.Weil es hat sich ja doch im vergleich zum 5700g etwas verändert bei der ganzen Sache.Wobei am meisten wohl der CPU Takt merken würde.Aber genau das würde mich echt interessieren wo denn aktuell so die Rohleistung steht wenn der Takt nicht mehr so hoch ist.Und zwar nicht nur kurz sondern schon ein wenig mehr Testen.

Wird es ja auch unter Zen 5 geben,da sieht man es dann besser das Ergebnis dann.

[KarlKastor]

was er meint sind wohl zen 4c also wo mehr kerne aber weniger L3 und weniger CPU Takt.
Das ist ja noch kryptischer. Soll das irgendwas erklären?

[latiose88]

Nun AMD macht mit dem Schema ne neue CPU.Durch den Verzicht von L3 weil halbiert und weniger Takt schafft AMD platz um mehr Kerne auf einem Wafer drauf zu bekommen.Durch das geht dann auch 16 Kerne auf einem Chiplet drauf.Allerdings verliert man durch das an Allcore Takt ,die hälfte an L3 und man kann nicht mehr einen 3d Cache mehr drauf bekommen darum nennt AMD das Zen 4c und der Nachfolger Zen 5C.
Das ist die Alternative für die wo mehr Kerne brauchen aber wenig Cache oder nicht vom Takt so Profitieren.Alles hat so seinen Preis.
AMD wird daher auch ein 8+16 Kern CPU Anbieten und das sind 2 Chiplets.Das ist die ALternaitve von den e cores von Intel.
Nur das diese sonst gleich sind.Man verliert also nur durch den L3 und dem CPU Takt an Leistung und hat sonst die volle Leistung.
Ob das die Zukunft von AMD ist,kann ich nicht sagen.Der Platz den sie auf dem Wafer durch das einsparen ist ernorm.CPU Takt und L3 Cache kostet eben auch Transistoren das sie durch diese Aktion einsparen können.Darum auch kleinere CPU und darum geht auch mehr Kerne auf ner kleineren Fläche.
Recht viel kleiner wird AMD das wohl nicht mehr schaffen.

Ich halte davon allerdings nichts,weil ich habe ja Anwendung wo von CPU takt Profitieren.Bei L3 Cache bin ich mir allerdings nicht sicher.Schade das es nicht auch ne Option nur weniger L3 Cache aber mehr Kerne als Option zur Auswahl gibt.
Der CPU Takt wird allerdings nicht so stark gesenkt höchstens so 300-500 mhz.Dafür ist ja von 32 MB auf 16 MB der L3 Cache gesunken.
Das heißt dann das es 2x16 MB auf 24 Kernen trifft.

Das wird bei Bargo eingesetzt.Ob das auch in der Mainstraim zum Einsatz kommt wird sich noch zeigen.Chancen hat es und es spart kosten ein.Für uns wäre das die Preiswerte Option.

[HOT]

Zen5c wird wieder annähernd halb so gross sein wie zen5, das bedeutet, es gibt pro zen5c Kern halb so viel L3-Cache.
Bei Strix Point ist das sicherlich ein CCX aus 4 Zen5 und 8 Zen5c Kernen mit einem Gesamt L3 mit 16 oder 32MB.
Man realisiert also das Hybrid CCX mit 12 Kernen auf der Flächen eines normalen 8 Kern CCX.

[basix]

In etwa so stelle ich mir das auch vor. Ich tippe auf 16MByte L3$ (4*2 + 8*1 MByte), damit das klein und energieeffizient bleibt. Damit sollte Strix Point nicht viel grösser als Phoenix werden, die paar CUs mehr machen nicht viel aus. Es kommt zwar noch ein etwas vergrösserter AI Accelerator dazu. Sagen wir mal anstatt bei 178mm2 kommt Strix bei ~190mm2 raus.

Ich hoffe allerdings, dass AMD die 12 Kerne zu einen Unified CCX zusammenfassen kann. Sonst wäre das etwas wenig L3-Cache pro CCX.

[Der_Korken]

Ich hoffe allerdings, dass AMD die 12 Kerne zu einen Unified CCX zusammenfassen kann. Sonst wäre das etwas wenig L3-Cache pro CCX.

Dazu wäre es hilfreich, wenn je zwei P-Cores ein "Cluster" bilden und zusammen nur ein Client am L3 wären. Dann wären es wie bei den bisherigen CCX genau 8 Clients bei 4+8. Vom Platz her könnte das auch fast hinkommen. Die L3-Latenzen sind bei den P-Cores dann etwas schlechter, aber who cares.

[robbitop]

In etwa so stelle ich mir das auch vor. Ich tippe auf 16MByte L3$ (4*2 + 8*1 MByte), damit das klein und energieeffizient bleibt. Damit sollte Strix Point nicht viel grösser als Phoenix werden, die paar CUs mehr machen nicht viel aus. Es kommt zwar noch ein etwas vergrösserter AI Accelerator dazu. Sagen wir mal anstatt bei 178mm2 kommt Strix bei ~190mm2 raus.

Ich hoffe allerdings, dass AMD die 12 Kerne zu einen Unified CCX zusammenfassen kann. Sonst wäre das etwas wenig L3-Cache pro CCX.

Das würde dann allerdings Latenz kosten. Bis dato sind CCX ja aus dem Grund maximal 8 Kerne groß. Der CCX ist ja genau die Konstruktion, die den Kompromiss aus Skalierbarkeit und (dann nur lokaler) Latenz möglich macht. Man kann aber nicht beides haben. Latenz und Skalierbarkeit.

Ggf. wäre für eine APU ein LLC außerhalb des CCX sinnvoll (und dafür ein kleinerer L3). Könnte der GPU helfen, spart Strom weil höhere Gesamthitrate aus GPU und CPU, kostet aber wahrscheinlich etwas CPU Leistung weil die Latenz eines LLCs außerhalb der CCX deutlich langsamer wäre. Ggf. bekäme man den auf 60 ns.

Dazu wäre es hilfreich, wenn je zwei P-Cores ein "Cluster" bilden und zusammen nur ein Client am L3 wären. Dann wären es wie bei den bisherigen CCX genau 8 Clients bei 4+8. Vom Platz her könnte das auch fast hinkommen. Die L3-Latenzen sind bei den P-Cores dann etwas schlechter, aber who cares.
Das wären dann doch aber 10 clients. 2+8
Ggf lieber eher für die E Cores wie bei Intel. Dann wäre es 4+4. Oder meintest du das und hast dich vertippt? Andererseits könnte ich mir vorstellen, dass man die Cores dafür schon gestalten muss. Bei Intel teilen sich E Cores ja zB auch den L2 Cache.

[HOT]

Das Ding ändert sich kaum ggü. früher in der Funktion, außer, dass die kleinen Cores deutlich weniger Takt haben. Das spielt aber für Cache und Ring (oder besser Ladder) keine Rolle. Die vom OS priorisierten Kerne sind die großen und fertig.

[basix]

Das würde dann allerdings Latenz kosten. Bis dato sind CCX ja aus dem Grund maximal 8 Kerne groß. Der CCX ist ja genau die Konstruktion, die den Kompromiss aus Skalierbarkeit und (dann nur lokaler) Latenz möglich macht. Man kann aber nicht beides haben. Latenz und Skalierbarkeit.

Ggf. wäre für eine APU ein LLC außerhalb des CCX sinnvoll (und dafür ein kleinerer L3). Könnte der GPU helfen, spart Strom weil höhere Gesamthitrate aus GPU und CPU, kostet aber wahrscheinlich etwas CPU Leistung weil die Latenz eines LLCs außerhalb der CCX deutlich langsamer wäre. Ggf. bekäme man den auf 60 ns.

Gab ja Gerüchte, dass AMD bei Zen 5 den LLC etwas umbaut: Ladder Cache (was auch immer das sein soll). Vielleicht sind es auch 2x CCX, doch man kann relative latenzarm auf den LLC des jeweilig anderen CCX zugreifen. Mal schauen.

Was ich aber schon erstauntlich finde ist, dass bereits Zen 5 Engineering Samples - sogar in APU Form inkl. Zen 5 & Zen 5c - im Umlauf sind. Das deutet auf einen Release in H1/2024 hin.

[Zossel]

Gab ja Gerüchte, dass AMD bei Zen 5 den LLC etwas umbaut: Ladder Cache (was auch immer das sein soll)https://www.forum-3dcenter.org/vbulletin/showthread.php?t=605954&highlight=ladder&page=56

[Der_Korken]

Das wären dann doch aber 10 clients. 2+8
Ggf lieber eher für die E Cores wie bei Intel. Dann wäre es 4+4. Oder meintest du das und hast dich vertippt? Andererseits könnte ich mir vorstellen, dass man die Cores dafür schon gestalten muss. Bei Intel teilen sich E Cores ja zB auch den L2 Cache.

Ja, war ein Vertipper, sollte jeweils "E-Cores" bei mir heißen. Gerade bei den P-Cores sollte die L3-Latenz jetzt nicht unnötig verschlechtert werden :D.

[HOT]

Gab ja Gerüchte, dass AMD bei Zen 5 den LLC etwas umbaut: Ladder Cache (was auch immer das sein soll). Vielleicht sind es auch 2x CCX, doch man kann relative latenzarm auf den LLC des jeweilig anderen CCX zugreifen. Mal schauen.

Was ich aber schon erstauntlich finde ist, dass bereits Zen 5 Engineering Samples - sogar in APU Form inkl. Zen 5 & Zen 5c - im Umlauf sind. Das deutet auf einen Release in H1/2024 hin.

Das war ja auch offensichtlich der Plan für H1:
Granite Ridge -> N4
Strix Point -> N4

später dann
Zen5c CCD -> N3(vermutlich B) (soll evtl. auch schon früh erscheinen)
Granite Ridge X (gibt Stimmen die sagen Ende 24, es gibt auch auch Stimmen die sagen direkt zum Start von Zen5, vermutlich ne strategische, keine technische Entscheidung)
Strix Halo -> N4 (Mobil-GPU-Ersatz)
Strix little -> N4 (Phoenix2-Nachfolger)

Nicht vergessen, dass Pheonix2 schon 4 c-Kerne hat.

Ich könnt mir gut vorstellen, dass es in 25 dann eine neue Zen5-APU als Strix-Nachfolger in N3E oder P geben wird und auch ein N3 CCD für Zen5 wäre möglich.

[davidzo]

Das heißt, einer der beiden Caches ist um 50% verbreitert worden, was normalerweise auch mit 50% höherer Assoziativität und Cache-Bandbreite einhergeht.

... was normalerweise mit erhöhter Latenz einhergeht.

Arms kleine Kerne gibt es schon seit gefühlten Jahrzehnten mit einem 64kb großen L1D Cache, also sogar doppelt so groß wie Zen4. Die würde ich trotzdem nicht als high performance CPUs bezeichnen.


Ice Lake hatte auch nicht mehr, und hat 18% IPC auf CFL draufgepackt.

Ja aber die IPC kommt nicht von den Caches, im Gegenteil. Der 50% größere L1 Cache hat auch 1 cycle mehr Latenz, also 5 statt 4.
ChipsandCheese hat das mal simuliert und der alte 32kb L1D von Skylake war schneller: https://chipsandcheese.com/2022/02/11/going-armchair-quarterback-on-golden-coves-caches/
Eine 20% Latenzregression für den gesamten L1D haut im Zweifelsfalle mehr ins Kontor als der leicht frühere Spillover in den L2.



Jep, und im Ergebnis schafft Zen5 dann dafür wahrscheinlich MultiCore einen höheren Takt mit 16 Kernen als Arrow's 8 P-Kerne, bei halbem Verbrauch :wave:
Und genau das Taktmonster sehe ich gerade nicht.
Ein vergrößerter L1D bedeutet eines von beiden:
- Latenzregression, dadurch fast kein IPC-Gewinn trotz 50% mehr cache
- Taktregression, dadurch fast kein Takt-Gewinn trotz neuer Fertigung
Wenn AMD doch einen Weg gefunden hat diesen Tradeoff zu umgehen, dann haben die Ingenieure bei AMD und Intel die letzten 10 Jahre echt nur gepennt. Das ist sehr unwahrscheinlich.


Das war ja auch offensichtlich der Plan für H1:
Granite Ridge -> N4
Strix Point -> N4

später dann
Zen5c CCD -> N3(vermutlich B) (soll evtl. auch schon früh erscheinen)
Granite Ridge X (gibt Stimmen die sagen Ende 24, es gibt auch auch Stimmen die sagen direkt zum Start von Zen5, vermutlich ne strategische, keine technische Entscheidung)
Strix Halo -> N4 (Mobil-GPU-Ersatz)
Strix little -> N4 (Phoenix2-Nachfolger)


Macht Strix Point nicht eher Sinn in N3? Sonst muss man die 5C Cores für zwei Prozesse auflegen.
Auch Sarlak wäre wesentlich erfolgsversprechender in N3 imo.
EDIT: MLID sagt beides ist N4

[HOT]

Es gibt mMn nur 2 N3-Produkte dieses Jahr: Das Zen5c-CCD und MI400. Damit wird AMD seine Kontingente auch voll auslasten können. Die ganzen Mainstreamsachen dürften alle N4 sein.

[robbitop]

- Taktregression, dadurch fast kein Takt-Gewinn trotz neuer Fertigung
Wenn AMD doch einen Weg gefunden hat diesen Tradeoff zu umgehen, dann haben die Ingenieure bei AMD und Intel die letzten 10 Jahre echt nur gepennt. Das ist sehr unwahrscheinlich.


Naja "neue Fertigung". N4 ist ein cost down node von der N5 Reihe und in etwa auf dem Performance Level von N5P und IIRC ist Raphael bereits in N5P gefertigt.
Gerüchte besagen auch aktuell eine leichte Taktregression für Granite Ridge. Aber angebliches Target war 6 GHz. (alles MLID also mit einem kg Salz und Skepsis zu genießen ^^)

Es gab ja auch in jüngster Vergangenheit auch positive Beispiele (allerdings im L2 Cache) wo die Größenzunahme enorm war und der Hit auf die Latenz echt klein war. Warum soll sowas nicht auch für den L1 gelten?

"Gepennt für die letzten 10 Jahre" ist auch etwas hart. Es entwickelt sich alles weiter. Innovation durch R&D. :)

[HOT]

Etwa so wie bei ARL:

Zen5: Massiv mehr IPC, leichte Taktregression
ARL: Massiv mehr IPC, heftigere Taktregression, kein SMT mehr, starke littles
dürfte in etwa ähnlich rauskommen leistungstechnisch

Übernächstes Jahr könnte AMD 8+16 bringen im Desktop und Intel 8+32, das passt dann auch wieder.
Wirklich spannend ist eigentlich nur Zen6 vs. Panther Lake wegen der rented units und deren massiver IPC-Gewinn, aber da sind wir schon in 26 ;).

[latiose88]

rented units also vermietede Einheiten,was wie.Und woher weist du jetzt schon das es bei beiden massiver IPC Gewinn werden wird,weist du etwa mehr als wir?

[reaperrr]

Und genau das Taktmonster sehe ich gerade nicht.
Ein vergrößerter L1D bedeutet eines von beiden:
- Latenzregression, dadurch fast kein IPC-Gewinn trotz 50% mehr cache
- Taktregression, dadurch fast kein Takt-Gewinn trotz neuer Fertigung
Wenn AMD doch einen Weg gefunden hat diesen Tradeoff zu umgehen, dann haben die Ingenieure bei AMD und Intel die letzten 10 Jahre echt nur gepennt. Das ist sehr unwahrscheinlich.
Stop!

Ich habe nicht gesagt, dass ich Zen5 als Taktmonster sehe.
Wenn schon RGT meint, dass Zen5 laut seinen Quellen evtl. eher etwas niedriger als Zen4 taktet, gehe ich eher von 5,5 als 6 GHz ST-Turbo aus, und auch 100-200 MHz niedrigeren MultiCore-Taktraten.

Bloß köchelt in der Gerüchteküche rum, dass ARL möglicherweise nicht mal 4,5 GHz schafft, weil die P-Kerne halt extrem fett sind und schon in diesen Taktbereichen anfangen zu saufen wie ein Loch.

[HOT]

Die werden von den e-Cores abstammen, daher die Taktregression. Mehr Apple-M weniger .cove.

[Nightspider]

Bis zur CES sinds noch genau 4 Monate.

Bin gespannt was AMD dort alles so aus dem Hut zaubern wird.


Strix Halo interessiert mich sowieso mehr als Strix Point.

Kleiner als 15-16 Zoll wirds bei mir eh nicht und in ein 16 Zoll Laptop passt auch eine leise 50W Strix Halo Variante.

Aber es wird dennoch interessant welche Verbesserungen RDNA3.5 besitzen wird.
Selbst wenn sich RDNA3.5 ""nur"" 20% höher takten lässt würde das trotz des Bandbreitenmangels in mehr Leistung resultieren.
Mit 13% mehr Bandbreite könnten am Ende trotzdem >20% bei der GPU herauskommen.

//

Falls die PS5 Pro mit sowas wie RDNA 3.7 kommen sollte, dann bitte auch einen schönen SoC für ein SteamDeck 2 auflegen mit 8 Zen5c Cores und potenter GPU der selbigen Generation. :)
Für Spiele würden ja die dicker gepackten Zen5c Kerne reichen die mehr im Sweetspot takten. Ist zumindest selten der Fall das man bei so einer Lösung beim Spielen im CPU Limit hängt.
Für Gaming Handhelds machen 8 der neuesten c-Kerne jedenfalls mehr Sinn. Selbst Zen4 liegt ja schon weit über den Playstation Kernen. Dann lieber den Platz für die GPU (Caches) nutzen.

[Complicated]

Wirklich spannend ist eigentlich nur Zen6 vs. Panther Lake wegen der rented units und deren massiver IPC-Gewinn.
Ähm, darauf kann man sich sicher freuen im Consumer-Bereich:
https://www.hpcwire.com/2023/01/11/intels-rental-service-on-chips-could-face-buyer-backlash/
Intel is bringing subscription and rental services to semiconductors as it explores new business models, but it remains to be seen if buyers warm up to the idea of paying extra to unlock features on a chip.
Intel is bringing an “on-demand” feature to its new Xeon CPUs codenamed Sapphire Rapids, which the company launched (https://www.hpcwire.com/2023/01/10/intel-officially-launches-sapphire-rapids-and-max-series/) on Tuesday after long delays.
The Intel On Demand (https://www.intel.com/content/www/us/en/products/docs/ondemand/overview.html?s=31) program involves paying a fee to activate specific features on chips. The on-demand service is like renting a movie – you pay a fee to unlock the content.
Intel in a press document explained on-demand as a feature to “expand and/or upgrade accelerators and hardware-enhanced features available on most 4th Gen Xeon processor SKUs.”

[w0mbat]

Rentable United Units hat nichts mit Ausleihen oder einen Bezahlmodel zu tun. Das ist einfach Intels Name für CMT, also was AMD mit Bulldozer versucht hat.

[Complicated]

Existiert das, ausser dem Begriff, schon irgendwo als Quelle?

[robbitop]

Es gibt dazu nicht so viel.
https://www.hardwaretimes.com/intel-15th-gen-cpus-to-get-rentable-units-why-hyper-threading-is-going-away/amp/

Ansonsten haben MLID und Co davon erzählt und Jim Keller soll wohl auch recht offen mit irgendwelchen Leuten darüber geredet haben.

Richtig detailliert gibt es mW nichts dazu. Das was es gibt geht aber tatsächlich ein wenig in die Richtung CMT.

[HOT]

Rentable United hat nichts mit Ausleihen oder einen Bezahlmodel zu tun. Das ist einfach Intels Name für CMT, also was AMD mit Bulldozer versucht hat.
rentable units :D (autokorrektur ftw :D). Der erste Kern kann sich also Einheiten des 2. mieten.
Also: Im Grunde ja, das ist schon CMT, nur geht das weiter als BD. Offenbar kann mann die Ressourcen von 2 Kerne für einen Thread nutzen und so die IPC um ein paar % erhöhen. Ansonsten spart man sich Platz und Anbindung dadurch, dass 2 Kerne jetzt ein Cluster sind. Bulldozer wäre ja auch nur der erste Schritt gewesen und die Kerne waren einfach zu schmal designt und hatten noch andere Nachteile. Lion Cove sind ja richtig große, vollständige hoch-IPC-Kerne. Das CMT-Konzept stammte ja schon aus den 90ern, auch dieses "reverse-SMT", was rentable units ja quasi sein soll. Aber man sieht, es geht erst mit jetziger Fertigung überhaupt da ansatzweise ranzukommen, dass das sinnvoll wird.

[Complicated]

Aber man sieht, es geht erst mit jetziger Fertigung überhaupt da ansatzweise ranzukommen, dass das sinnvoll wird.
Wo kann man das sehen?

[HOT]

BD z.B. ;).