🐉 Illustration mikroarkitektur Zen5, Lion Cove, Airmont, X925

Alla är välkomna att spekulera vidare i denna tråd. Är på semester och hade lite tid över...

Slogs av känslan att high-end mikroarkitekturer för CPU börjat konvergera till en rätt snarlik design oavsett tillverkare.

För att få lite bättre överblick ritade jag upp en översikt för Zen 5 (vilket märkligt nog är den som finns absolut minst konkret information kring trots att den snart börjar säljas), Lion Cove, Skymont och Cortex X925.

Zen 5 och Lion Cove är på många sätt väldigt lika varandra. Skymont är betydligt mer lik high-end Arms, nu tittade jag på senaste Cortex X, Skymont är än mer lik Cortex X2/X3 (den är inte lika "bred" som X4/X925).

Också sett både Chips&Cheese och YT-profilen high-yield (som har en riktigt bra video om Lion Cove och Skymont i Lunar Lake)

Några observationer:

Backend x86 big-core
Om man går efter "back-end" är numera Skymont den "bredaste" x86 designen som existerar. Vem hade trott det när Atom lanserades...

Sett kommentarer kring att många exekveringportar gör det svårare att klocka en krets riktigt högt. Zen 5 och Lion Cove är väldigt lika här med färre men långt mer komplexa portar.

Split decoders i Skymont och Zen 5
I Gracemont gjorde Intel en lite udda sak med front-end. För att komma runt att komplexiteten är kvadratisk för x86 (p.g.a. att längden på instruktioner kan vara allt från 1 till 15 bytes) med ökad bredd gjorde man istället två st 3-wide avkodare.

2*3^2 = 18, 6^2 = 36

så betydligt mindre komplex med 2 st 3-wide decoders jämfört med 1 st 6-wide.

I Airmont ökar man det till 3 st 3-wide. Samtidigt introducerar Zen 5 också detta, man går till 2 st 4-wide medan Lion Cove går till 1 st 8-wide (den sista är lite osäkert, men det är vad allt pekar på).

Arm kan smaska på med 1 st 10-wide, där är alla instruktioner lika lång så komplexiteten är hyfsat nära linjär med bredd. Det skrivet: vad ska man med flera avkodare till???

Det både Skymont och Zen 5 använder det till är att direkt kunna börja avkoda den instruktion ett taget hopp skulle landa vid. Ovanpå det ska Zen 5 också göra så att om båda CPU-trådarna används får den en 4-wide avkodare var (just detta har testas med gott resultat i Freescales PowerPC e6500, det typ inversen av vad man gjorde i Bulldozer).

I fallet Airmont finns ingen SMT, så det är det just för att öka IPC. Med 3 st avkodare kan den hantera 2 tagna hopp per cykel. Tydligen har Intel kika på både 2 st 4-wide och 3 st 3-wide för Airmont, men de kom fram till att den senare ger mer utväxling för IPC (men gissar att den förra vore bättre om man haft SMT med 2 CPU-trådar).

Issue

Alla x86 designerna verkar vara kapabla att skicka in 8 st instruktioner till back-end.

Exakt information för Zen 5 är rätt osäker här, mesta är baserat på GCC-patchar för Zen 5. Stämmer den är man kvar på samma kapacitet som Zen 4 där issue och retire är symmetriska.

Skymont har väldigt hög retire-kapacitet, 16 instruktioner. Det ska stämma och Chips&Cheese har fått info om att Intel valt att göra så då det frigör utrymme snabbare i back-end och att deras simuleringar visade att det kostade mindre transistorer att göra så mot att öka storleken på ROB (som ändå nu är helt i "big-core" x86 nivå, men en bit efter "big-core" ARM64).

Just ROB är något Intel historiskt lagt rätt mycket resurser på. Lion Cove får en ganska liten minskning från Golden Cove, men även här har man nu högre "retire" kapacitet, 12 uops, jämfört med vad som kan stoppas in.

Flyttal

Här finns definitivt två läger!

"Big-core" x86 har gått efter instruktioner som var för sig kan hantera väldigt mycket data. En av de stora nyheterna i Zen 5 är ju att SIMD-delen nu blir 512 bit bred. Zen 4 har AVX-512 stöd, men den processar dessa över två iterationer då den internt är 256-bit bred.

Lion Cove är 256-bit bred med 2 FMA och 2 add/div kapabla portar. Zen 5 har också 4 portar.

Arm (även Apple och av allt att döma Qualcomm) har en helt annan approach här. De har 128-bit databredd, fast istället har man fler portar (Apple har 6 st, det har nu också Arm medan det är oklart för Oryon men givet prestanda är den nog också 6 wide).

Båda har fördelar och nackdelar. Är lättare att fullt ut utnyttja fler fast smalare SIMD, men det kräver totalt sett mer transistorer.

"Look at the size of that thing" när man ser backend på Cortex X925... Kommer bli spännande att se den i aktion i slutet av året!

Men även Skymont är bred!

Tänker inte försöka mig på att få in saker som latens. Dels tror jag det bara för Lion Cove de är känt av dessa i nuläget, men är nog bara Zen 5 man kan säga något om cache-policy (och det bara om vi förutsätter att den är samma som Zen 4).

Men en tabell på storlek går ändå att göra, ihop med en procentuell förändring från föregående generation

Får se vad Lion Coves 1,5 L1$ kommer ge. Intel vill kalla den L1 och det som tidigare var L1 för L0... Men tittar man på latens och bandbredd är det de kallar L0 vad man normalt kallar L1.

Den nya cachen är dock verkligen "ny" i bemärkelsen bandbredd är mer lik L2, men latensen är ca halva den mot L2 (och latens mot L2 är ungefär samma som för Raptor Cove).

Undrar varför de lagt till denna??? Kanske ännu en i raden av saker de verkar försökt kopiera från Apple Silicon, hela Lunar Lake verkar ju vara x86-varianten av grundmodellen av M-serien (vilket faktiskt kan visa sig vara en bra sak).

Skippade L3, det är inte en del av CPU-kärnan och blir därför lite stökigt i tabellform.

Desktop Zen 5 har 32 MB L3$ per chiplet.

Strix Point har 24 MB.

Arrow Lake har 3 MB per "slice". En sådan per P-core och en per 4 st E-cores. D.v.s. totalt 36 MB i 8P+16E

Lunar Lake har 3 MB per "slice". Där är det bara en sådan per P-core, så 12 MB i 4P+4E. Däremot har Lunar Lake också 8 MB "system cache" som alla delar, även E-cores, GPU och NPU kan använda och blir i praktiken L4$ för P-cores.

Cortex A925 har ingen specifik storlek. I praktiken har alla moderna systemkretsar en "system cache" (som nu också Intel inför i Lunar Lake) på typiskt 8 MB eller mer. M3 Max antas ha 48 MB system-cache och är väl den största så här långt (men den har också 32 MB L2$ till P-cores!).

Tittar man på Intel och AMD så börjar de väl rätt mycket konvergera även här... Kanske inte så konstigt att Lion Cove och Zen 5 av allt att döma får nära nog samma IPC och samma maxfrekvens.

Är inte heller med på hur de får ihop det sista och när jag sökte lite på bättre förklaring insåg site:en jag använde som källa för bilden hade missat den större presentation och egentligen visade den mindre intressanta slide:en.

Oklart hur man kommer fram till perf/area/effekt, den som är det relevanta här är att om man fysiskt tar bort transistorerna för HT blev det +15 % perf/power jämfört med att ha HT tillgängligt i kisel, ha det aktiverat men bara använda en tråd.

+5 % per/power är fallet där HT är avstängt, men där transistorerna fortfarande är var på kretsen.

Orsaken att SMT överhuvudtaget är en bra idé är detta

d.v.s. använder man faktiskt HT ökar mängd arbete kärnan utför med 30 % medan effekten bara ökar 20 %.

För en laptopkrets tror jag inte det råder något tvivel vad som är bäst. För en server-krets har SMT om inte annan den stora fördelen att det ger två "vCPU" som molnleverantörerna kan ta betalt för (en av flera orsaker varför ARM64 instanser är så mycket mer prisvärd, där får man "riktiga" kärnor för pengarna och de är typisk ändå billigare per vCPU vid likvärdig prestanda).

Får se vad de gör i Arrow Lake. Om man nu vinner +15 % i perf/watt känns det faktiskt som en no-brainer där också givet att desktop-kretsarna trots allt har 6-8 P-kärnor + 8-16 E kärnor. Så SMT är en belastning så länge man använder färre än 14-24 CPU-trådar (d.v.s. till varje P och E kärna har en aktiv tråd).

Då det finns mycket som pekar på att Qualcomms exklusivitet på Windows/ARM64 tar slut under detta år är det väldigt spännande att kika på vad Arm har för sig.

För om nu ryktet att Nvidia ger sig in i Windows/ARM64 marknaden under 2025, så är kan vi vara väldigt säkra på att de kommer inte göra det med en egendesignad mikroarkitektur utan det kommer vara Arms Cortex X925 (och är exakt den mikroarkitekturen som viskas om och är den man kommer använda i nästa server-design).

Även om Arm har släppt X925 redan, betyder det ju bara att ritningarna för att göra en sådan CPU är klar. Första kislet med X925 förväntas dyka upp runt oktober i år. Så för att få en känsla för vad den kommer prestera får man göra lite extrapoleringar från X4 i mobiltelefoner.

Så var står vi? Använder man GB6 och ställer Ryzen 8840HS mot Samsung S24 så är ST 2483 @ 5,0 GHz mot 2240 @ 3,4 GHz. D.v.s. perf/cykel är ~35 % högre i Cortex X4 jämfört med mobile Zen 4.

Historiskt har Arms påstådda IPC-ökningar varit rätt nära sanningen. I det specifika fallet GB6 lär de stämma rätt exakt då GB och SPEC är rätt ofta vad Arm använder när de sätter sina IPC-ökningar.

Så vad säger man om X925?

36 % är inte bara rätt långt mer än de 14-16 % Intel/AMD verkar mäkta med. Man ska också komma ihåg att Arm släpper en design per 12 månader, så i stort sätt dubbelt så ofta som Intel/AMD släpper en ny mikroarkitektur.

Kring frekvens verkar Arm fortsätta stanna under 4 GHz, de har sagt att X925 kan klockas upp till 3,8 GHz. Det borde lägga dem på ett GB6 ST resultat väl över 3000 poäng. D.v.s. högre än vad Strix Point och Lunar Lake ser ut att hamna på, också högre än Snapdragon X Elite!

Precis som Zen 5 kommer ökning för "AI" bli högre. I Zen 5 fall beror det på att desktop-versionen går till 512-bit datapath för AVX-512 (upp från 256-bit i Zen 4, rätt säker de 40 % bättre IPC som nämns för Zen 5 kommer från den här typen av laster).

I fallet X925 kommer det från Arms närmaste motsvarighet till AVX-512 VNNI (Vector Neural Network Instruction), SME (Scalable Matrix Extension). Är SME som ökade resultatet för ett av GB6 AI-test med nästan 100 % mellan Apple M3 (som inte har SME) till M4 (som har SME). Det är i.o.f.s. enda testet som verkar påverkas av SME, så totalpoängen påverkas inte jättemycket då det är ett geometriskt medel.

Känns också som Arm siktar förbi vad som är rimligt för en telefon med X925. Bara kolla på mikroarkitekturen, den är galet "bred" även ställd mot Intels/AMDs kommande mikroarkitekturer. Och då måste man komma ihåg att Zen 5 gick från 4-wide decode till 2x 4-wide, Lion Cove gick från 6-wide till 8-wide decode och Airmont gick från 2x 3-wide till 3x 3-wide. X925 är 10-wide!!!

Storlek på L2$ är upp till 3 GB, det är större än alla nuvarande x86_64, större än Lion Cove i Lunar Lake och matchar Lion Cove i Arrow Lake! Historiskt har Arms CPUer haft mindre L2$ jämfört med high-end x86_64 och Apple.

Men vi lär se telefoner med en X925, lite lägre klockad bara. De behöver trots allt den för att täppa till hålet mellan Iphone och high-end Androider.

TL;DR är ändå att 2025 kommer även de som använder Arm Cortex X serien vara på samma nivå som Intel, AMD och Qualcomm!

Som jag skrev initialt, finns relativt lite officiell information kring mikroarkitektur för Zen 5. Men en sak som ändå gör att jag är rätt säker på de förändringar i front-end som är i bilden ovan stämmer är detta från AMD

Den säger 3 saker.

1. 2x "For front-end instructions".

Det lär inte referera till micro-op-cachen, den är kapabel till 9 uops redan i Zen 4. Så detta måste referera till decoder. Att det handlar om 2x 4-wide och inte en 8-wide är från

"Parallel dual front-end..."

Ändå intressant här att Intel gick med 8-wide i Lion Cove. 8-wide är mer effektiv i att den oftare kan ge >4 instruktioner än vad 2x 4-wide kan. Men ändå lite frågetecken varför då det kostar rätt mycket med en så bred decoder på x86 + de verkar ju väldigt nöjda med den dual-decoder som Gracemont använder.

2. 2x "L2 to L1 and L1 to FP".

Det säger mest att man anpassat per-core cache så den kan hantera 512-bit databredd. Mycket möjligt att mobile Zen 5 inte har denna förändring då man verkar stanna på 256-bit databredd där (samma som Zen 4).

3. 2x "AI and AVX512 Throughput"

Det är i praktiken "vi har gått till 512-bit intern databredd" i klartext.

Får se hur detta påverkar effekt och frekvens när AVX-512 används. Första generationerna av Intel CPUer med 512-bit intern databredd fick klocka ned sig rätt ordentligt. Men sett spekulation kring att Intel nog gick dit förtidigt, de hade behövt vänta någon nod till så man kunde ha tillräckligt med transistorer för att hantera detta.

Så gissar att det kommer fungera fint i Zen 5, det fungerar ju bra i Xeons numera (medan man tog bort AVX-512 stödet i desktop/mobile).

Visade sig att gissningarna för Zen 5 var helt OK.

Stod innan >=8 uops för dispatch och retire då Zen 4 hade 8 uops och det lär inte minska. AMD har nu sagt att det är samma i Zen 5.
Sen sa man också ca "40 % more instructions in flight", så ca 448 instruktioner i Zen 5 (upp från 320 i Zen 4).

Tror också man kan dra en del slutsatser från denna bild

AMD säger att 27 % av IPC-ökningen kommer från "data bandwidth", vilket i praktiken är det som relaterar till 512-bit intern databredd för AVX-512.

Det lär tyvärr inte ge något för icke AVX-512 laster, vilket också stämmer med att sådana har mer legat på 8-12 % IPC ökning än några 16 %.

AMD kvantifierade nu också förväntad ökning för det som drar stor nytta av AVX-512, t.ex. AI. Där ska Zen 5 vara ~32 % snabbare jämfört med Zen 4, vilket är inkluderat i deras 16 % siffra.

Sist: spekulationen att mobil-versionen av Zen 5 stannar på 256-bit inter databredd stämmer. Så de deltest i GB6 som använder AVX-512 och som uppfört sig olika ställd mot Zen 4 visade precis det de borde visa

Zen 5 illustrationen är uppdaterad med denna ny info, egentligen bara >= 8 uops som ändrats till 8 uops samt inflight satt till 448 (i stället för >320).

Nu återstår att se hur P-core i Arrow Lake står sig i Zen 5. Sett till mikroarkitektur ska den ha högre IPC.

Men precis som Ian Cutress fråga i intervju med Zen 5 chefsarkitekt "varför bara 16 % IPC ökning trots rätt stora förändringar" finns det inget som pekar på att Lion Cove heller kommer någon direkt stor ökning. Den blir mer än 14 % (för det verkar den vara i Lunar Lake och Lion Cove i Arrow Lake har bl.a. mer L2$ och mer L3$), men lär inte bli mer än några procentenheter.

Inget som kommer i närheten av vad Arm mäktade med i Cortex X925!!