AMD Ryzen 7 5800X och Ryzen 5 5600X

En lite rimligare jämförelse är att ställa M1 mot de absolut snabbaste bärbara modellerna, blir väldigt många faktorer utanför CPU som skiljer väl mycket. Sedan toppar AMDs desktopmodeller på ~160 W, det är vad 105 W TDP modellerna har i "total package power" medan M1 toppar på strax under 20 W.

Bara genom att ställa 4800U mot 4800H borde ge en rätt kraftig vink var majoriteten av skillnaden i perf/W mellan x86_64 och ARM64 återfinns. Genom att öka effekten från 15 W till 45 W, faktor 3x, går det att skruva upp all-core-frekvensen från 1,8 GHz till 3,0 GHz, d.v.s. en faktor 1,7x.

perf/W skalar horribel med ökad frekvens, men ökad frekvens är väldigt tacksamt då allt som är CPU-bundet blir snabbare med högre frekvens. Samma gäller IPC, allt blir snabbare om IPC ökar.

Enda som spelar roll i slutändan är faktisk prestanda, d.v.s. frekvens * IPC.

Visst är det dyrare att avkoda x86, men det lär inte handla om flera heltalsfaktorer utan sett till total ökning på effektbudget är det nog mer något man kan räkna i tiotals procent.

Det är dyrare att upprätthålla x86 minneskonsistensmodell. ARMv8 (så gäller dagens även 32-bitars ARM) har en modell som är en perfekt match till modellen de populära programspråken använder. Så här är ARMv8 inte bakåtkompatibel med ARMv7, inget problem för 64-bitars Arm då ARMv8 är första specifikation där det finns.

x86 har implicita beroende mellan nästan alla instruktioner, de uppdaterar implicit delat globalt tillstånd, vettigt när man räknade cykler per instruktioner men alla som håller på med parallellprogrammering vet att delat globalt tillstånd är parallellismens värsta fiende. Bara väldigt specifika ARM64 gör något sådant. Här är också den största skillnaden mellan 32-bitars Arm (har samma problem som x86) och 64-bitars Arm.

x86 har en grundläggande storlek på mappning från "virtuella adresser", de alla program använder, till "fysiska adresser", de RAM och minnesmappade I/O-enheter använder, om 4 kB. En storlek i praktiken alla valde under 80-90 talet då det var en optimal balans då. ARM64 stödjer 4, 16 och 64 kB. Idag är 16 kB en bättre balans än 4 kB och det är också vad Apple använder. Linux-kärnan stödjer andra storlekar än 4k, men där kör de flesta fortfarande med just 4 kB då det finns enstaka lågnivå program/bibliotek som gör antagande om storlek. Lär fixas med tiden, finns egentligen inget som hindrar x86 från att också lägga till 16 kB stöd.
Den här punkten är förklaringen till varför Apple kan använda 128-192 kB L1$ och ändå hålla latensen riktigt låg. Finns ett beroende mellan TLB (en cache för översättning från virtuella till fysiska adresser, en av de absolut mest prestandakritiska delarna i en modern CPU) och L1$. Följande olikhet måste vara uppfylld för att uppslagning i TLB och L1$ ska kunna ske parallellt

L1$-size / L1$-ways <= page-size

Problemet med att ha allt för många "ways" (uppdelningar av cachen där address M lagras på en specifik offset i exakt en av dessa "ways") är att strömförbrukningen ökar med ökande antal "ways". Man söker typiskt i alla "ways" parallellt då man initialt bara vet vilken offset det man letar på ligger, om det alls finns i cache.

x86 instruktioner man vara allt från 1-15 bytes. Skulle nog kunna vara en OK fördel även idag om det inte vore för att väldigt många av de instruktioner som är riktigt korta är sådana som inte lägre är relevanta. Finns forskning/simulering på hur mycket man skulle kunna vinna på att återanvända opkoder för sådant som inte längre är relevant (vilket idag lär vara majoritet av alla x86 instruktioner). Det jag sätt när samma program kompileras till x86_64 och ARM64 är att de är väldigt snarlika i storlek, men lite fördel för ARM64. Så ingen fördel från den komplexa kodningen längre, detta var länge en fördel "CISC" hade över "RISC" (32-bit ARM och även RISC-V stödjer variabel längd på instruktioner, dock bara 2 eller 4 bytes). Är en annan punkt där 32-bitars ARM och 64-bitars ARM skiljer sig rejält, 32-bitars ARM är betydligt kompaktare än x86_64 och ARM64, vilket också visar att kompakt kod är inte allt. Det finns en debatt om variabel instruktionslängd för RISC-V var ett misstag eller ej, det är rent formellt en extension men verkar vara en extension som i praktiken förutsätts idag.

Finns många fler exempel. Så handlar inte om en sak som kan förklara allt. Är mer "death by a thousand cuts" för x86 del runt dess perf/W. Primära förklaringen är att ARM64 har visat sig väldigt lämpad för att designa kretsar med väldigt hög IPC -> hög prestanda per kärna vid låg frekvens.

Cortex A78 sett till "bredden" väldigt jämförbar med Zen2/Skylake, ändå har den ~30 % högre IPC. Just ~30 % är den genomsnittliga fördel jag sett på RPi4 om man ställer 32-bitars ARM-kod mot 64-bitars (Cortex A72 är bara 2-wide, så vinsten här lär knappast ha speciellt mycket med ökad parallellism att göra). Varierar rätt mycket i specifika program, allt från 0 % till ~100 %, men det är nog ändå en liten vink om hur mycket man kan förvänta sig kommer från just att instruktionsuppsättningen är bättre.

Cortex A78 ska enligt ARM dra 1 W per kärna vid 3 GHz på TSMC 5 nm. Hade varit bättre om man visste motsvarande för TMSC 7 nm, där har vi 4800U som drar <2W per kärna vid 1,8 GHz. Cortex A78 har bättre per/W än Firestorm, men sämre än Icestorm. Värt att notera här är att Zen2 @ 1,8 är ändå "bara" ungefär en faktor 4 efter Cortex A78 @ 3,0 GHz i perf/W.

Så TL;DR frekvens är förklaringen, 1,5-3 GHz verkar vara området som är optimalt för maximal perf/W. Vi har ju GPUerna i detta områden också, där är perf/W väldigt mycket det som sätter gränsen för hur kraftfull man kan göra kretsen.

Då M1 @ 3,2 GHz når Zen3/Willow Cove prestanda när de senare ligger ~5 GHz är nog en klar majoritet av förklaringen.

Se bara på Zen3 vs Zen2, i princip 100 % av ökningen i perf/W kommer från ökad IPC. Få mer gjort utan att skruva upp frekvens!

5600X beställd till grabbens speldator, beställde från Komplett och (det flaggat osäkra) leveransdatumet är satt till 8 december. Bara det blir innan jul är jag nöjd!

Hade tänkt ge honom min 3900X och skaffa en 5900X själv, men vi ser i testerna just hur man inte ska välja fler kärnor än man behöver för att "vara framtidssäker". Givet vad AMD sagt om Zen4 över Zen3, om det stämmer är det "framtidssäkra" valet att köpa det som uppfyller kraven idag och sedan byta till nästkommande billigaste modell som också uppfyller kraven.

3900X är klart passerad av 5600X i spel, han bryr sig ju bara om spelprestanda. För egen del använder jag enbart 3900X till just de saker där 12C/24T spelar roll. Givet diskussionen ovan: måste vara perf/W som dikterar lyften för all-core då det i många fall som skalar riktigt bra med CPU-kärnor är rätt mediokert lyft från 3900X till 5900X.

Jag klagar inte, kör 3900X på ett "knäckebrödsmoderkort" med B350 chipset (som jag haft sedan min första Ryzen 1600). Givet att den datorn rätt ofta tuggar timvis med väldigt nära 100 % last har det nu lite blivit ett test för att se om moderkort tänker ge upp eller ej. Rätt säker moderkortet kommer överleva så länge datorn är värd att ha strömsatt.

Det är inget problem, det skall vara så, fläkten fixar du med fläktkurvor