News AMD Zen 5 Update: Etwas mehr Theorie zur Architektur und noch keine Praxis

[CDLABSRadonP...]

Gerade die effizientere Teillast dürfte für die Akkulaufzeit in Laptops relevant sein. Eigentlich müssen auch Gaming Handhelds davon profitieren, wenn die CPU weniger belastet wird, weil die GPU das Gros an Leistung liefert.

Auch uneigentlich.

Entweder hat letztere mehr vom power budget (eher das) oder die Leistung wird besser.

Vor allen Dingen gibt es unterschiedliche Spiele. Die große Stärke der Z1-Extreme-Handhelds ist ja, dass sie schon heute mehr CPU-Performance bieten als die Current-Gen-Konsolen oder das SteamDeck. Denn die setzen nur auf Zen2 mit ähnlich niedrigem Takt. In wirklich hart CPU-limitierten Spielen sehen die dementsprechend kein Land.

Ihre Schwäche gegenüber dem Steam Deck (neben den Spezialitäten von diesem) hingegen ist bislang, dass sie nicht gut nach unten hin skalieren. Dadurch, dass jetzt die 5C-Kerne dabei sind, sollte sich das bessern.
Kraken Point wird aber mMn für Handhelds besonders interessant.

 

[Deinorius]

Auch uneigentlich.

Wos?

In wirklich hart CPU-limitierten Spielen sehen die dementsprechend kein Land.

Da stelle ich mir z.B. Anno 1800 vor. City Builders 2 lassen wir raus, sollen die erstmal optimieren. Ich müsste mir Benchmarks ansehen, wie es sich da verhält. Die größte Stärke der Handhelds, die kein Steam Deck sind, ist am ehesten noch, dass sie locker über 15 W gehen können. Wenn ich an die meisten Benchmarks denke, die bei 15 W getestet wurden, ist der Vorteil kaum vorhanden und dort liegt die CPU (fast?) nie bei 3,5 GHz.

Ihre Schwäche gegenüber dem Steam Deck (neben den Spezialitäten von diesem) hingegen ist bislang, dass sie nicht gut nach unten hin skalieren.

Was umso mehr dafür spricht, dass die effizientere Teillast besonders wichtig ist.

 

[CDLABSRadonP...]

Wos?

Ich hoffe, der Geck gefällt dir.

Da stelle ich mir z.B. Anno 1800 vor. City Builders 2 lassen wir raus, sollen die erstmal optimieren. Ich müsste mir Benchmarks ansehen, wie es sich da verhält. Die größte Stärke der Handhelds, die kein Steam Deck sind, ist am ehesten noch, dass sie locker über 15 W gehen können. Wenn ich an die meisten Benchmarks denke, die bei 15 W getestet wurden, ist der Vorteil kaum vorhanden und dort liegt die CPU (fast?) nie bei 3,5 GHz.

Hat trotzdem mehr PPC. (IPC ist ja, wenn man es genau nimmt, etwas anderes --- was ja auch gerade wieder diese AMD-Präsentation aufzeigt. Denn natürlich hat Zen 5 mehr PPC dank mehr L3-Cache, aber eben weniger PPC)

Was umso mehr dafür spricht, dass die effizientere Teillast besonders wichtig ist.

Definitiv sind sie das. So oder so sind vier Zen 5-Kerne wahrscheinlich Overkill für einen Handheld. Zwei würden wahrscheinlich auch reichen und der Rest halt als 5C. Die 5er sollen halt im Fall der Fälle das wegarbeiten, was sich nicht parallelisieren lässt.

 

[mae]

Ob es so eine gute Idee ist, bei Strix Point nur die 4 Zen5-Kerne an den 16MB-L3-Cache zu koppeln, und alle 8 Zen5c-Kerne an den 8MB-L3-Cache? Wenn man eine Anwendung hat, die 8 Kerne verwendet, werden dann zwar wohl alle 24MB cache verwendet, aber dafuer gibt's jede Menge langsamen Datenverkehr zwischen den beiden Caches. Da hat man ja schon bei Ryzen 3100 vs. 3300X gesehen, dass es besser ist, wenn die verwendeten Kerne alle am selben Cache haengen (wobei der 3100 noch das Handicap hatte, dass der Gesamt-L3 durch die Verwendung von zwei CCX nicht groesser wurde, anders als beim Strix Point).

 

[stefan92x]

Ob es so eine gute Idee ist, bei Strix Point nur die 4 Zen5-Kerne an den 16MB-L3-Cache zu koppeln, und alle 8 Zen5c-Kerne an den 8MB-L3-Cache?

Da die Topologie offenbar nach wie vor nur 8-Core CCX erlaubt, muss man es halt entweder so machen, oder einen Hybrid-CCX und einen mit 4 Zen 5c. Ich würde stark vermuten, dass das die schlechtere Idee sein könnte.

 

[ETI1120]

Ob es so eine gute Idee ist, bei Strix Point nur die 4 Zen5-Kerne an den 16MB-L3-Cache zu koppeln, und alle 8 Zen5c-Kerne an den 8MB-L3-Cache?

Es gibt in der Technik immer Trade Offs.

AMD wird sich dabei etwas gedacht haben.

Wenn man eine Anwendung hat, die 8 Kerne verwendet, werden dann zwar wohl alle 24MB cache verwendet, aber dafür gibt's jede Menge langsamen Datenverkehr zwischen den beiden Caches.

Es ist nun die Frage wie wichtig dieser Fall in der Gesamtheit aller Anwendungen ist.

Man kann sich für jedes Design einen Fall ausdenken bei dem es ungünstig ist. Die Frage ist immer wie relevant dieser Fall für die Anwender tatsächlich ist.

Da hat man ja schon bei Ryzen 3100 vs. 3300X gesehen, dass es besser ist, wenn die verwendeten Kerne alle am selben Cache haengen (wobei der 3100 noch das Handicap hatte, dass der Gesamt-L3 durch die Verwendung von zwei CCX nicht groesser wurde, anders als beim Strix Point).

Wenn AMD den Fall für wichtig gehalten hätte, dass eine Anwendung mit 8 fordernden Tasks auf Strix Point mit der maximalen Performance läuft, dann hätte AMD 8 classic und 4 dense Cores verbaut.

Die classic und die dense Cores jeweils ihren eigenen L3 zu geben muss wohl auch Vorteile haben. Sonst hätte es AMD nicht gemacht.

Bitte beachten Strix Point wurde für Notebooks entworfen, und da zählt Effizienz mehr als schiere Performance.

Da die Topologie offenbar nach wie vor nur 8-Core CCX erlaubt, muss man es halt entweder so machen, oder einen Hybrid-CCX und einen mit 4 Zen 5c. Ich würde stark vermuten, dass das die schlechtere Idee sein könnte.

Es gibt ein sehr interessantes Interview mit Mike Clark mit Toms Hardware bei dem das Thema Zen 5c behandelt wird.

Auf der einen Seite erklärt er wie die Flächenreduktion der Dense Cores zustande kommt (Spoiler: AMD verwendet für beide Varianten dieselben Libs, AFAIK sind es die HD und nicht die HP Libs) und dann geht er auf das Thema Dense Core und Desktop ein (Spoiler: er sagt es ist in Zukunft eine Option).

Level1Techs hat ein Interview mit Mahesh Subramony in dem Mahesh ziemlich deutlich schildert was die Ziele bei Strix Point waren: hohe Effizienz um eine lange Battrielaufzeit zu erreichen. Deshalb laufen die meisten Anwendungen auf den Dense Cores. Erst wenn die User aktiv werden wechselt die Anwendung auf den Classic Core. Und solbald die User Aktion beendet ist geht es zurück auf den Dense Core.

Ian Cutress sagt in seiner sehr langen Plauderei mit Cheese, dass die Unterschiede in den Frequenzen zwischen Classic und Dense bei Zen 5 nicht mehr so groß wären wie noch bei Zen 4. Es sollen nur noch ein paar hundert MHz sein und nicht mehr ca. 1,5 GHz (Phoenix). Er könnte recht haben, da AMD bei Zen 5 mit den Dense Cores nur noch 25 % der Fläche einspart. Bei Zen 4c waren es noch 35 %.

Als weitere Neuigkeit gibt es erste vage Hinweise auf Fire Range als Dragon Range Nachfolger um selben Sockel.

 

[Deinorius]

Ian Cutress sagt in seiner sehr langen Plauderei mit Cheese, dass die Unterschiede in den Frequenzen zwischen Classic und Dense bei Zen 5 nicht mehr so groß wären wie noch bei Zen 4.

Das wäre interessant. Fast wie bei Lunar Lake, wo die Differenz zwischen P- und E-Cores auch nicht mehr so groß ist.
Wenn ich in Richtung Steam Deck 2 spekuliere, denke ich immer an mind. 6x Zen5c, aber ich frage mich dann immer, ob 1x Zen5, 5x Zen5c nicht auch ginge (und falls Valve noch höhere Ambitionen entwickeln würde). Sofern die geringe Taktdifferenz zutrifft, wäre ich zu 99 % sicher, dass es nur Zen5c wird. Außer sie warten vielleicht sogar auf Zen6c.

 

[mae]

AMD wird sich dabei etwas gedacht haben.

Sicher, aber was?

Wenn AMD den Fall für wichtig gehalten hätte, dass eine Anwendung mit 8 fordernden Tasks auf Strix Point mit der maximalen Performance läuft, dann hätte AMD 8 classic und 4 dense Cores verbaut.

Das haette mehr Flaeche gekostet. Aber 4 Zen5c auf den CCX mit den 4 Zen5 cores zu verschieben, nicht. Und ob bei 5+ aktiven Cores bei dem Power Limit in eines Laptops das Clocklimit von Zen5c erreicht wird, ist die Frage. Wenn nicht, haetten mehr Zen5 cores nicht einmal einen Vorteil bezueglich der Performance.

Es gibt ein sehr interessantes Interview mit Mike Clark mit Toms Hardware bei dem das Thema Zen 5c behandelt wird.

Danke, sehr interessant. Da steht auch, dass die Zen5 und Zen5c Cores in Strix point keine grossen AVX-512-Einheiten haben, sondern AVX-256-Einheiten, die wohl wie in Zen4 fuer AVX-512 double-pumped betrieben werden. Es wird aber andere Zen5-Cores geben, die AVX-512-Einheiten haben. Vielleicht sollten wir da noch zusaetzliche Buchstaben fuer diese Varianten einfuehren.

Deshalb laufen die meisten Anwendungen auf den Dense Cores. Erst wenn die User aktiv werden wechselt die Anwendung auf den Classic Core. Und solbald die User Aktion beendet ist geht es zurück auf den Dense Core.

Das klingt nach einem Windows-Ding. Wobei Mike Clark da eine andere Unterscheidung nannte: Teams (was auch immer das ist) soll auf den Zen5c-Cores laufen, waehrend ein Browser bursty ist und daher auf den Zen5-Cores laufen soll. Wie AMD das anstellt, ist natuerlich die Frage.

 

[ETI1120]

Das Problem ist ein bisschen, dass sich mit jedem neuen Infofitzelchen das AMD raus lässt, gleich mehrere neue Fragen eröffnen.

Ich kann das Gemeckere von Charlie Demerjian teilweise nachvollziehen, dass die Präsentationen am Techniktag mehr Infos hätten haben sollen. Auf der anderen Seite waren die Hintergrundgespräche wohl für die meisten Teilnehmer sehr interessant. Aber da muss man eben auch fundierte Frage stellen können.

Aber es gibt eben keine klare Informationen wie sich die Kerne im Frequenzverhalten tatsächlich unterscheiden, Ich halte die maximale Frequenz z. B. für weit weniger Interessant als der Punkt an dem sich sich die beiden Frequenz Power Kurven schneiden.

Vor allem das es mit Zen 5 nun 4 Varianten gibt.

• Zen 5 mit 512 bit Data Path für AVX 512 (Granite Ridge und wahrscheinlich Turin)
• Zen 5 mit 256 bit Data Path für AVX 512 (Strix Point und wohl auch alle anderen mobil SoCs)
• Zen 5c mit 256 bit Data Path für AVX 512 (Strix Point und wohl auch alle anderen mobil SoCs)
• Zen 5c mit 512 bit Data Path für AVX 512 hier gibt es nur Anmerkungen von Mike Clark, dass AMD die AI Performance bei den Servern mitnehmen will

Sicher, aber was?

Dazu habe ich bisher keine klare Antwort von AMD gefunden.

Es wurde des öfteren die Spekulation geäußert, dass damit der L3 mit der für die jeweiligen Kerne optimalen Frequenz betrieben wird.

Das haette mehr Flaeche gekostet. Aber 4 Zen5c auf den CCX mit den 4 Zen5 cores zu verschieben, nicht. Und ob bei 5+ aktiven Cores bei dem Power Limit in eines Laptops das Clocklimit von Zen5c erreicht wird, ist die Frage. Wenn nicht, haetten mehr Zen5 cores nicht einmal einen Vorteil bezueglich der Performance.

Warum wohl ist AMD bei Strix Point auf das Verhältnis 1:2 gegangen?

Ich denke Mike Clark beantwortet dies bei seiner Antwort auf die Frage ob es Dense Kerne in Zukunft im Desktop geben wird.

Die classic Kerne decken den Fall der User Interaktivität ab, wenige Threads die möglichst schnell abgearbeitet werden müssen.

Danke, sehr interessant. Da steht auch, dass die Zen5 und Zen5c Cores in Strix point keine grossen AVX-512-Einheiten haben, sondern AVX-256-Einheiten, die wohl wie in Zen4 fuer AVX-512 double-pumped betrieben werden. Es wird aber andere Zen5-Cores geben, die AVX-512-Einheiten haben. Vielleicht sollten wir da noch zusaetzliche Buchstaben fuer diese Varianten einfuehren.

Solange es bei den einzelnen Anwendungen klar ist was verbaut ist, halte ich es für unnötig.

Schauen wir Mal, ob die Gerüchte stimmen, dass da noch ein Low Power Core kommt. Das und das Packaging ist das was mich bei Strix Halo am meisten interessiert.

Das klingt nach einem Windows-Ding.

Nein. Aber man erklärt es nun Mal am besten an einem konkreten Beispiel und das war Teams.

Wie AMD das anstellt, ist natuerlich die Frage.

Wenn ich die Anwort richtig verstanden habe, gar nicht. Das ist der Job des Schedulers im Betriebssystem.

 

[mae]

Es wurde des öfteren die Spekulation geäußert, dass damit der L3 mit der für die jeweiligen Kerne optimalen Frequenz betrieben wird.

Eine Idee in der Richtung ist noch, dass der 8MB-L3 weniger Strom im Betrieb braucht als der 16MB-L3, und daher auf einem Mobilgeraet besser geeignet fuer Dauerlaeufer ist. Die Zen5 und ihr L3-cache werden nur fuer Sprinter angeschmissen und sind die meiste Zeit in einem Low-Power-State, wo sie kaum Strom verbrauchen. Das Konzept geht aber nur auf, wenn die Dauerlaeufer auch bei 8MB L3 wenige Misses haben, weil sonst kosten die DRAM-Zugriffe mehr Strom als im L3 gespart wird.

Nein.

Doch:-) Die Idee von Vordergrundprozessen ("User aktiv werden") und Hintergrundprozessen ("User Aktion beendet") ist ein Windows-Ding.

Wenn ich die Anwort richtig verstanden habe, gar nicht. Das ist der Job des Schedulers im Betriebssystem.

Microsoft sieht sowas meines Wissens als Job fuer AMD, die halt ein Plugin o.ae. fuer den Scheduler bauen muessen, damit der dann die Sachen wie von AMD gewuenscht herumschiebt. Mussten die ja schon bei den 7900X3D und 7950X3D machen, um die richtigen Sachen auf den CCD mit und die richtigen Sachen auf den CCD ohne 3D-Cache zu schieben. In dem Fall sind sie m.W. auf den Namen des Programms oder sowas gegangen.

Und bei Linux koennen sie natuerlich auch drauf warten, dass sich ein Scheduler-Entwickler einen Strix-Point-Laptop kauft und dann den Scheduler dafuer optimiert, schneller geht's aber, wenn sie es selbst machen. Ich denke aber nicht, dass sie da mit einem Programmlisten-Ansatz durchkommen wuerden.

 

[ETI1120]

Eine Idee in der Richtung ist noch ... weil sonst kosten die DRAM-Zugriffe mehr Strom als im L3 gespart wird.

Nicht bestimmtes weiß man nicht.

Ich kenne mich in diesem Bereich nicht aus, deshalb würde es mich freuen, wenn es AMD erklären würde.
Es ist nun Mal der Job der Entwickler bei AMD es so zu entscheiden, dass es in Summe vorteilhaft ist. Irgendwelche Geschichten von Leuten die es auch nicht genau wissen und nur raten finde ich nicht hilfreich.

Deshalb habe lange gezögert etwas zu schreiben und ausdrücklich Spekulation geschrieben, ...

Doch:-) Die Idee von Vordergrundprozessen ("User aktiv werden") und Hintergrundprozessen ("User Aktion beendet") ist ein Windows-Ding.

Echt und andere Betriebssysteme mit Userinteraktion können das nicht? Also bei IOS klebt ein Thread der einmal von einem User gestartet wurde immer an einem Big Kern. Auch wenn er nur im Hintergrund dümpelt?

Microsoft sieht sowas meines Wissens als Job fuer AMD, die halt ein Plugin o.ae. fuer den Scheduler bauen muessen, damit der dann die Sachen wie von AMD gewuenscht herumschiebt. Mussten die ja schon bei den 7900X3D und 7950X3D machen, um die richtigen Sachen auf den CCD mit und die richtigen Sachen auf den CCD ohne 3D-Cache zu schieben. In dem Fall sind sie m.W. auf den Namen des Programms oder sowas gegangen.

Wir reden über zwei komplett verschiedene Dinge.

1. Threads entsprechend ihrem Bedarf an Rechenleistung den entsprechenden Kernen zuzuordnen.
2. Threads entsprechend ihrem Bedarf nach mehr L3-Cache bzw. nach weniger L3 Cache und mehr Frequenz den entsprechenden Kernen zuzuordnen.

Punkt 1 ist eine Standardanforderung an den Scheduler, da in jedem Prozessor sich alle Kerne unterscheiden. Laut allen Statements von AMD funktionieren ihre Hybrid-APUs genau nach diesem Prinzip.

Punkt 2 ist etwas für was AFAIK noch kein Scheduler ausgelegt ist und weshalb man hier bei 7900X3D und 7950X3D die Games manuell kennzeichnen musste.

Und bei Linux koennen sie natuerlich auch drauf warten, dass sich ein Scheduler-Entwickler einen Strix-Point-Laptop kauft und dann den Scheduler dafuer optimiert, schneller geht's aber, wenn sie es selbst machen. Ich denke aber nicht, dass sie da mit einem Programmlisten-Ansatz durchkommen wuerden.

Ganz davon abgesehen dass es AFAIK gar nicht notwendig ist, weil es die Scheduler schon können wäre das die letzte Option.

Die ersten 4 sind:

1. AMD beauftragt eigene Entwickler es zu programmieren.
2. AMD beauftragt einen Scheduler Entwickler damit und bezahlt ihn dafür.
3. AMD setzt eine Belohnung aus.
4. AMD schenkt einem Scheduler Entwickler ein Notebook mit Strix Point