News AMD Strix Point: Ein konkreter Termin und Benchmarks mit Ryzen AI 300

[stefan92x]

Mehr Kerne bedeutet mehr Fläche, mehr Kosten und mehr Stromverbrauch. Es macht wenig Sinn, einen Mainstream-Laptop-Chip zu designen, der 24 Kerne hat. Wie willst du die denn sinnvoll nutzen, welche Anwendung siehst du dafür? Bin da gerade wirklich neugierig, weil ich wirklich keinen sinnvollen Anwendungsfall dafür sehe.

 

[blackiwid]

Hab grad die aktuell Folge von Moore's law angeschaut geht immer einige Stunden, da verliere ich schon mal die Aufmerksamkeit, ich hab vermutlich 2 Sachen vermischt er spekuliert das die X3D chips also vermutlich vor allem das 7800 äquivalent die 8 Core Variante gleich viel Takt wie die normalen Ryzen haben könnte, das war bisher ja nicht der Fall, aber ja die C cores haben auch die selbe IPC von daher ist die Unterscheidung immer noch Fragwürdig selbst wenn sie nicht sich so hoch takten lassen.

 

[Northstar2710]

es scheint so das die 5c cores mit max 3,3ghz takten. im endeffekt wie beim 4c core.

https://videocardz.com/newz/amd-ryzen-ai-9-365-zen5-apu-tested-ahead-of-launch-ipc-uplift-measured

 

[ETI1120]

Zu APUs und Games

Ich denke es hat 2 Aspekte.

Es gibt einen riesigen Fundus an Games. Je leistungsfähiger die iGPU wird, desto mehr Games lassen sich mit der iGPU spielen.

Neue Games werden leistungshungriger, und hier verschiebt sich ständig die Messlatte.

Wenn man vor allem aktuelle Spiele zockt, dann ist es tatsächlich so, dass die APUs hinterherhecheln und wenn sie aufgeholt haben, ist die nächste dGPU Generation schon viel weiter vorne.

Es gibt auch jede Menge Klassiker, die gerne gespielt werden obwohl sie schon älter sind und hier verschiebt sich die Grenze nicht.

IMO kommt es vor allem darauf an was man zockt.

Ja hier gehts aber um den 5c dort gibt es diese Unterschiede meines Wissens nach nicht mehr, sicher die 5 werden stärker übertaktbar sein, dürfte aber für normale User egal sein

Wie soll das gehen? Die Flächenreduktionreduktion des kompakten Kern rührt daher, dass er für eine niedrigere Zielfrequenz entworfen wurde. Wenn ich die Zielfrequenz erhöhe, steigt der Flächenbedarf. Womit ich wiederum das eigentliche Ziel torpediere.

Wenn es stimmt dass AMD die Zen 5 CCD in N4P und die Zen 5c CCD in N3E fertigen lässt, dann ist hier mehr Spielraum für Zen 5c.

Bei Strix Polint werden beide in N4P gefertigt, also wird an der Frequenzdifferenz zwischen classic und dense nicht viel ändern

David Huang, der für ein paar Stunden an ein Laptop mit Strix Point heran konnte, nennt 3,3 GHz als Frequenz für Zen 5c.

Er bestätigt im Übrigen dass es 2 CCX sind, eines mit 4 Zen 5 + 16 MB L3 Cache und eines mit 8 Zen 5c + 8 MB L3 Cache

Allerdings gibt es jede Menge Überraschungen.
Laut David Huang verwendet Strix Point nicht dieselben Zen 5 Kerne wie das Zen 5 CCD für Server und Desktop. Das erklärt warum die "Die Shots" der Zen 5 Kerne von CCD und Strix Point nicht zusammen passen.

Der Zen 5 Kern im Strix Point hat nur den halben SIMD-Durchsatz der CCD-Version und dementsprechend auch die L1-Cache Bandbreite. D. h. im Vergleich zu Zen 4 gibt es was Z1 Bandbreite und SIMDPerformance angeht bei Strix keine Verbesserung was dazu führt dass auf Ryzen AI 9 365 der Spec Int bei derselben Frequenz nur um 9,7 % zulegt.

Bei Zen 5 wird die Performance gab zwischen APU und CCD größer als bisher üblich ausfallen.



Das eigentlich Interessante ist jedoch was die parallel dual pipe decoder anbelangt.

Lt. David Huang können sie in 2 Modes agieren:

• Single Thread: hier arbeiten beide pipes für den selben Thread
• Dual Thread: hier arbeiten beide pipes separat für jeweils einen Thread, damit ergibt sich mit 4 Decoder ein 8 wide decode.

Leider hat David Huang keinen multi thread test mit Spec Int 2017 gemacht. Aber seine tests mit Geek Bench 5 und 6 zeigen, dass Zen 5 in Strix Point im Multi Threading überproportional zulegt.

Was die Latenzen anbelangt hat liegen die kerne in Strix Point bei L1 bei 4 zyklen, bei L2 bei 14 Zyklen und bei L3 bei 46 Zyklen. D. h., L1 und L2 sind unverändert während L3 um 4 Zyklen besser ist als Phoenix.

@Philste
Wenn ich mir das so anschaue halte ich es für möglich dass die Silicon Gang echte Zahlen mitbekommen hat. Die Silicon Gang hat sie allerdings, wie es Laien nur zu leicht passiert, komplett falsch interpretiert.

Es ist eben ein Anfängerfehler von der Multithreading Performance auf die Single Threading Performance zu schließen. Oder sich einzubilden dass AMD Kerne entwirft dass sie in Games gut ausschauen.

 

[Philste]

• Single Thread: hier arbeiten beide pipes für den selben Thread
• Dual Thread: hier arbeiten beide pipes separat für jeweils einen Thread, damit ergibt sich mit 4 Decoder ein 8 wide decode.

Sicher? Ich verstehe das so, dass im Singlethread nur eine Hälfte aktiv ist, dass halbe Frontend also dementsprechend brach liegt. Erst im Dual Thread aktiviert sich das ganze Frontend.

Wenn ich mir das so anschaue halte ich es für möglich dass die Silicon Gang echte Zahlen mitbekommen hat. Die Silicon Gang hat sie allerdings, wie es Laien nur zu leicht passiert, komplett falsch interpretiert.

Die wussten gar nicht, außer ihrem "96C Turin ist 40-50% schneller als 96C Genoa in SpecINT". Das das auch 400W vs 500W waren, wurde geflissentlich ignoriert. Und da der IO Die gut und gerne 100W zieht reden wir hier über 300W vs 400W aka 33% mehr Energie pro Kern.

Zusammen mit dem Wechsel von N5 auf N4P und dem Fakt, dass das Takt/Power Scaling in dem Taktbereich, in dem sich diese Server CPUs bewegen, noch halbwegs human ist, kann man hier locker von 25-30% mehr Takt beim Turin Sample ausgehen. Und schon passen die Werte auch miT 10-15% IPC.

Oh und btw. Die 10% IPC von David Huang sind INT, da dürfte sich auch mit der aufgebohrten FPU der Desktopchips nichts dran ändern. Ich mutmaße einfach mal 10% INT und 20% FP, da kommt man dann im Durchschnitt bei AMDs 16% raus. AVX512 stellenweise noch etwas mehr. Es wurde ja auch schon Geekbench 5 getestet, wo es im AES-XTS laut AMD 35% IPC gibt. Mit der Strix point FPU bleiben laut David Huang keine 15% übrig.

Also ist Strix in INT 10% besser als Golden Cove, in FP gleich. Granite Ridge hat dann in beidem etwa 10% Vorsprung. Bei AVX512 logischerweise mehr.

Ergänzung (22. Juni 2024)

Das Interessanteste wird für mich, wie das öffentlich kommuniziert wird. Nachdem man ja bei ZEN4c damit geworben hat, dass es die gleiche uArch ist, hat es schon etwas Geschmäckle, wenn jetzt nicht mal mehr ZEN5 im Desktop und ZEN5 in Mobile die gleiche uArch ist.

 

[blackiwid]

Wie soll das gehen?

Hab grad die aktuell Folge von Moore's law angeschaut geht immer einige Stunden, da verliere ich schon mal die Aufmerksamkeit, ich hab vermutlich 2 Sachen vermischt er spekuliert das die X3D chips also vermutlich vor allem das 7800 äquivalent die 8 Core Variante gleich viel Takt wie die normalen Ryzen haben könnte,...

 

[ETI1120]

Sicher?

Im Vorfeld der Veröffentlichung hat er folgendes geschrieben:

Ich verstehe das so, dass im Singlethread nur eine Hälfte aktiv ist, dass halbe Frontend also dementsprechend brach liegt. Erst im Dual Thread aktiviert sich das ganze Frontend.

David Huang schreibt dass beide Decoder an unterschiedlichen Verzweigungspunkten desselben Threads arbeiten können.

Die wussten gar nicht, außer ihrem "96C Turin ist 40-50% schneller als 96C Genoa in SpecINT". Das das auch 400W vs 500W waren, wurde geflissentlich ignoriert. Und da der IO Die gut und gerne 100W zieht reden wir hier über 300W vs 400W aka 33% mehr Energie pro Kern.

Das stimmt so nicht, die hatten 50 % Verbesserung und haben 10 % abgezogen weil Turin 20 % mehr Power hatte. So kamen die 40 % zustande. Wahrscheinlich haben die sich eingebildet, damit auf der sicheren Seite zu sein.

Zusammen mit dem Wechsel von N5 auf N4P und dem Fakt, dass das Takt/Power Scaling in dem Taktbereich, in dem sich diese Server CPUs bewegen, noch halbwegs human ist, kann man hier locker von 25-30% mehr Takt beim Turin Sample ausgehen. Und schon passen die Werte auch miT 10-15% IPC.

25 % bis 30 % mehr Takt würde mich überraschen.

AMD hat auf der Hotchips 35 folgendes präsentiert:

Ich konnte bei den Argumenten der SiliconGang nie nachvollziehen warum von 4 auf 6 ALUs zu gehen keinen Einfluss auf den SMT Uplift haben sollte.

Also haben wir 4 potentielle Faktoren bei der MT Performance von Zen 4 zu Zen 5:

1. IPC-Anstieg im ST
2. Taktanstieg aus N5 -> N4P (TSMC gibt 11 % mehr Performance an, aber es kann sein dass AMD diesen Wert gar nicht erreicht)
3. Taktanstieg aus mehr Power (Hier wird AMD bei den Servern sehr vorsichtig agieren)
4. Änderung des SMT Uplift

Und da AMD offensicht auch bei den Decodern ordentlich nachgelegt hat, würde es mich sehr überraschen, wenn bei Zen 5 der SMT Uplift nicht nochmal ansteigen sollte.

Oh und btw. Die 10% IPC von David Huang sind INT, da dürfte sich auch mit der aufgebohrten FPU der Desktopchips nichts dran ändern.

Wer sagt denn, dass die SIMD Einheit nur Floating Point Werte verarbeiten kann?

525.X265 hat bei Strix Point nur um 3,2% zugelegt und David Huang hat explizit gesagt, dass er beim Desktop bessere Werte erwartet.

Außerdem sagt David Huang dass AMD bei Zen 5 den MikroOps-Cache im Vergleich zu Zen 4 reduziert hat.
Er führt die Regression bei 531.deepsjeng_r darauf zurück. Es würde mich interessieren, ob dies eine weitere Spezialität bei Strix Point ist oder generell gilt.

Warten wir unabhängige Messungen am Server und am Desktop Zen 5 ab und halten uns somit an Grace Hopper:
"One accurate measurement is worth a thousand expert opinions"

Das Interessanteste wird für mich, wie das öffentlich kommuniziert wird. Nachdem man ja bei ZEN4c damit geworben hat, dass es die gleiche uArch ist, hat es schon etwas Geschmäckle, wenn jetzt nicht mal mehr ZEN5 im Desktop und ZEN5 in Mobile die gleiche uArch ist.

Das erste Grundgesetz beim Marketing ist, "was interessiert mich mein Geschwätz von gestern, nur was ich heute sage ist wichtig". Das ist doch jetzt keine Neuigkeit.

Zen 4c musste dieselbe Mikroarchitektur wie Zen 4 haben. Mit den damals bereitstehenden Resourcen hätte AMD gar keine 2 verschiedene Mikroarchitekturen umsetzen können.

Auf das was es ankommt ist, dass die Kerne einer Generation dieselbe ISA haben. Auch bei einer Hybridarchitektur ist das essentiell dass alle Kerne dieselbe ISA haben.

So wie es aussieht haben Zen 5 und Zen 5c in Strixpoint dieselbe Mikroarchitektur. Also ergeben sich für den Scheduler daraus keine Herausforderungen.

Die Desktop-CPUs und die APUs hatten schon immer eine andere Charakteristik. D Wer as ergibt sich aus der Anpassung an verschiedene Anwendungsfälle. Bei Zen 5 werden die Abweichungen zwischen CPU und APU größer. Wo ist das Problem? Wer APUs kauft, will sehr hohe Effizienz und nicht absolute Performance.

Es fällt auf dass Zen 5 und Zen 5c im "Die Shot" von Strix Point als gleich groß dargestellt werden.
Die Messungen von David Huang zeigen, dass der Frequenz Malus noch immer besteht und dass sich die Performance von Zen 5c im Rahmen dieser Frequenzdifferenz bewegt.

Ich denke da wird noch einiges zu Zen 5 und Zen 5c erzählt werden.

 

[Philste]

David Huang schreibt dass beide Decoder an unterschiedlichen Verzweigungspunkten desselben Threads arbeiten können.

Ja, aber im Blog mit den Ergebnissen schreibt er jetzt folgendes:

"In diesem Test ist ersichtlich, dass die Befehlsabruffähigkeit von Zen 5, die einen 2-Byte-NOP in einem einzelnen Thread ausführt, keine offensichtlichen Vorteile gegenüber Zen 4 aufweist (mit Ausnahme der leichten Verbesserung des Durchsatzes im Makro-Op-Cache)."

Hört sich für mich an, als würde man im Singlethread effektiv bei einem 4 wide Decode bleiben.

 

[ETI1120]

Das Decodieren eines Programms, das nur aus NOP besteht, sollte nicht der Standardfall sein.

Du könntest einfach Mal das Summary am Ende dieses Abschnitt lesen:

• The Zen 5 uses a similar but wider multi-front-end design to the Tremont, using two 4-wide x86 decoders with at least an 8-wide macro-op cache to achieve an 8-wide rename;
• Consider the following phenomenon
  • Zen 5 single-threaded running of consecutive NOP instructions does not allow the x86 decoding bandwidth to exceed 4;
  • Tests in the Instruction Throughput subsection yield that it can handle two taken branches in a single cycle;
• It is reasonable to assume that instead of using a Gracemont-like predecode ILD caching scheme, Zen 5 must have the branch predictor predict the occurrence of a taken branch in order for both decodes to work at the same time, i.e., it is straightforward for one of the decoders to go and start decoding from the next branch destination address. From this perspective, AMD still needs to rely on macro-op cache to achieve high throughput in sparsely branched scenarios;
• Zen 5 must not only support decoding x86 instructions from two locations in the same cycle, but also fetch instructions from two locations in the macro-op cache in the same cycle, in order to process two taken branches per cycle within the coverage of the macro-op cache;
• When the core is running two SMT threads, it is possible to have an exclusive decoder for each to bring the x86 decode throughput limit for the entire core to 8 in most cases.

Translated with DeepL.com (free version)

Ich verwende die Englische Übersetzung, da ich finde dass diese Übersetzung klarer ist als die Deutsche.

Hier bitte beachten, der Blogbeitrag heißt Sneak Peek. Er hatte noch keine Zeit seine Hypothesen die er oben darlegt zu verifizieren. Deshalb diese vagen Formulierungsmuster.

In seinen Tweets brachte David Huang übrigens zum Ausdruck, dass die Zeit in der eine IPC-Steigerung von 10 % jährlich möglich waren vorbei ist.