Apple Silicon vs x86

Tycker detta är ännu ett exempel på hur pass bra Geekbench 6 ändå är på att svara på frågan "hur snabb är denna CPU".

Varför? Jo, kolla deltesterna. Är viss varians även mellan Intel och AMD, men den är typiskt inom ±10 % i deltester på två CPU-modeller med ungefär samma totalpoäng. Skillnader under ~20 % lär i de absolut flesta fall vara irrelevanta.

Variansen mellan t.ex. Intel och Apple där totalpoängen är den samma är i deltesterna ±35 %. Så vad som är "bäst" kräver mer kontext.

Vet inte var du hittar någon konsensus, skulle hävda att det är långt ifrån någon konsensus på denna punk.

Vad man i.o.f.s. rätt objektivt kan säga är att just perf/W och även perf/cykel är långt bättre på high-end ARM64. Den senare är så pass mycket bättre (och inte bara på "Apple Silicon" utan även på Arm Cortex X4/X925 och Qualcomm Oryon) att det även leder till högre absolut prestanda i de flesta fall, men inte alla trots ~6 GHz peakfrekvens för x86 mot ~4 GHz peakfrekvens för dagens ARM64.

Sen finns inget som fysiskt hindrar att bygga en ARM64 som når 6 GHz. Den kommer ha väsentligt sämre perf/W mot dagens ARM64, men skulle få högre absolut prestanda. Det är ett visst motsatsförhållande mellan perf/cykel och en design som klockar väldigt högt, men det kan inte alls förklara skillnaden i perf/cykel mellan t.ex. M3/Oryon och Zen4/Raptor Cove (de förra har 40-50 % bättre perf/cykel).

Det jag gissar många inte riktigt har koll på är just att i många fall är idag en ARM64 CPU-modeller den som är snabbast i absolut termer. Det känns liksom orimligt att 15-30 W modeller (beroende på vad man tar med är den snabbaste ARM64 M4 i Ipad eller M3 Max om bara datorer räknas) kan, i absoluta termer, vara snabbare än Intel/AMDs desktop-monster som dra 200-300 W.

Ser väl rätt väntat ut, eller?

När man ställer ARM64 mot x86_64 skiljer det rätt mycket i relativ prestanda beroende på vad man testar. Tar vi GB6 som testar ett 20-tal olika fall är det just de som primärt jobbar med 3D-grafik med CPUn där x86_64 presterar bäst relativt ARM64, fördelen är i nivå med vad man ser här.

Finns nog flera förklaringar här, den viktigaste är nog att för de ARM64 CPUer som använder sig av ARMv8.x standarden finns bara tillgång till NEON som närmast kan liknas vid AVX2 som begränsas till 128 bitars databredd.

Nyheten i M4 och även i Cortex X4 (men inte Oryon som av allt att döma kör ARMv8.x) är att de använder sig av ARMv9 och får därmed tillgång till SVE2 (Scalable Vector Extensions v2) och SME (Scalable Matrix Extensions) som motsvarar AVX-512 och AMX hos x86.

3D-beräkningar som utförs i 64-bit precision får en hyfsat lyft att gå från 128-bitar till 256-bitar (512-bitar spelar rätt liten roll för just detta), så att x86_64 har tillgång till AVX2 är en fördel i just denna applikation över ARMv8.x.

Men omvänt har ARM64 den största fördelen i kompilering, där är M3 runt 30-35 % snabbare än 7950X/14900K per kärna. Detta är en "ren" heltals-last som inte påverkas av något annat än hög frekvens, hög perf/cykel samt att färre instruktioner behövs. Det sista är något som historiskt varit till fördel för x86_64, ett typiskt x86_64 program har färre instruktioner än ett PowerPC eller MIPS program (RISC). Även här är ARM64 unik, det krävs typiskt färre ARM64 instruktioner än x86_64 instruktioner för att göra samma sak i heltal (flyttal är mycket mer 1:1 så där blir det viktigare att ha "optimal databredd" för problemet).

Alla som tror att x86 ska dö inom överskådlig framtid har nog lite dålig koll på hur det sett ut historisk. x86_64 var under väldigt lång tid både billigare och snabbare än SPARC och POWER maskiner som var det "enda seriösa för servers" när jag började jobba på 90-talet. Det fanns under många många år en marknad för dessa, POWER finns ju fortfarande kvar men det är otroligt nischat och därmed relativt dyrt.

Alla 3D beräkningar är till viss del data-parallella, så de kommer få bättre prestanda om man använder sig ett av bra bibliotek. Kör man med 32-bit float är 128-bitar optimal databredd (man behöver 96 till 128 bitar beroende på typ av koordinatsystem för att hantera 3 dimensioner med ett register) medan 64-bit float behöver 265-bitar (192 till 256 bitar beroende på koordinatsystem).

Sen är det fullt möjligt att problemet inte är uppgifts-parallellt, d.v.s. det kan bara effektiv använda en CPU-kärna. Det är typiskt fördel x86_64 då de har brutal maxfrekvens, men perf/cykel är i många fall så mycket högre att det ändå blir snabbare på ARM64. CAD verkar vara ett exempel på där x86_64 tokhöga frekvens i slutändan är viktigare, kompilering är ett fall där perf/cykel är så mycket högre hos ARM64 att den är snabbast.

Att det finns rätt stor varians mellan olika fall. Men även i det som verkar vara "worst-case" kan man ändå se i den benchmark du presenterar här att perf/W är på en helt annan nivå även då för ARM64, det är nästa en tiopotens bättre.

Att perf/W är så viktigt är för att det är den mest kritiska egenskapen för de trender vi har.

Datacenter går mot allt fler CPU-kärnor. Hur bra perf/W + hur mycket kisel som behövs per kärna är begränsade faktorer. Hos AWS, Azure och Google Cloud får man som kund lägre priser för samma kapacitet om man kör på ARM64 instanser.

Bärbara har länge haft en trend mot kompakta enheter samtidigt som de i allt större grad ersätter stationära datorer på arbetsplatserna. Lång effekt är en förutsättning för formen, men man vill ändå ha hög prestanda för att klara krävande uppgifter. Perf/W är därför kritiskt.

Stationär desktop lär vara där x86_64 stannar längst. Här är fördelar minst med ARM64. Är möjligt att skapa väldigt högt klockade ARM64 baserade mikroarkitekturer, det kanske händer men lär hända sist då denna marknad totalt sett är den minsta och därmed ekonomiskt minst viktiga.

Vet inte om jag skulle kalla MacBook "populär" på SweC. Detta är primärt en webbplats där en av de stora gemensamma nämnarna är spelintresse.

Sen är det lättare att "prata förbi" varandra idag än för 10-15 år sedan, saker har blivit mer hetrogena.

För 10-15 år sedan kunde jag som i första hand alltid prioriterat prestanda för programutveckling med fördel använda spelbenchmarks som proxy. Det som gav bra spelprestanda gav också bäst prestanda i "mitt" områden. Det stämmer rätt dåligt idag, 7800X3D som är toppvalet för spel är en bra bit från toppen för programutveckling, AI etc.

Det som gör 7800X3D till en väldigt bra spel-CPU, dess gigantiska LLC, ger märkligt nog nära noll utdelning i nästan alla andra CPU-krävande fall. Så spel har blivit ett väldigt udda-fall med avseende på CPU-krav!

Sen har också trenden i spel ändrats, undrar om vi någonsin varit så lite CPU-begränsade i spel som vi är idag? Blev rätt förvånad vilken icke-uppgradering grabbens dator gjorde när den gick från 5600X till 7800X3D. Har man "bara" ett 4070Ti och spelar i 2560x1440 skulle jag gissa att ingen skulle kunna avgöra vilken av dessa CPUer som används i typ 98 av 100 spel.

Är ju fortfarande så att det vi ser i 1280x720 med ett 4090 i form av CPU-skalning rimligen kommer vara bli relevant "i framtiden". Skillnaden är att för 10-15 år sedan var det normalt "nästa GPU-generation", nu är det nog mer "i alla fall om 2-3 GPU-generationer". Problemet är att dagens CPUer lär vara omsprunga flera gånger om 4-6 år från nu...

Det andra vi ser är ju antal CPU-kärnor. Rätt säker att både Intel och AMD idag medveten håller ned prestanda på deras 6-kärniga desktopmodeller, om man inte skulle göra det skulle det bli poänglöst för "gamers" att köpa dyrare modeller.

Sen har vi det vi ser med t.ex. CAD. För ett specifik område kan det fungera "sådär" med att använda något genomsnitt av tester. Är CAD det enda man optimerar för ska man naturligtvis titta på CAD-benchmarks, för det som också hänt på senare tid är att variansen inom specifika områden mellan CPU-modeller har ökat rätt mycket.

Och då är nog ändå CAD ett relativt "milt" fall, inom AI lär vi få se enorm varians mellan CPU-modeller. Finns ett par exempel redan nu (som även det går att se i GB6 deltester). Vissa typer av AI operationer kan vara nära dubbelt så snabba på Zen4 (som har AVX-512) mot Zen3 (som inte har AVX-512). Samma går att se hos M4 (som har SME) och M3 (som inte har SME).

AI är förövrigt det många på SweC skrek efter när modeller som Zen 1800X släpptes: här har vi något som "normalanvändaren" kan köra som, om man väljer alt. kör fall som lämpar sig bäst för CPU, skalar otroligt väl med CPU-kärnor givet tillräckligt stor/komplicerad modeller
Så om/när spel börjar använda ML som AI kanske även speldatorer med 16 kärnor blir relevant (nåja, är normal vid träning och inte vid inferens det tenderar skala väl, men ändå).

Här är inte CAD unikt. Även om det finns enstaka fall som skalar väl med CPU-kärnor är vi tyvärr fast med att det finns, och kommer finnas inom överskådlig tid, massor med fall där det viktigaste är absolut prestanda i single-core fallet.

ARM64 vs x86_64 lägger på ännu en dimension på variansskalning givet hur stor varians det är inom olika specifika fall. Så kommer bli allt svårare att välja "optimal" konfiguration framåt. Lär bli mycket dåliga förslag då det som är optimalt för mig mycket väl kan vara långt ifrån optimalt för dig. Något vi ser i CAD vs programming t.ex...

Positiva är att ISA aldrig varit så liten tröskel att ta sig över som idag. Apples övergång från x86_64 till ARM64 gick otroligt snabbt. Listan program som redan idag finns i ARM64 version är förvånansvärd stor redan innan första "riktigt" Windows-baserade ARM64 plattform ens nått marknaden.

Man måste rätt mycket göra "idiotiska saker" för att det ska krävs mer än en omkompilering, eller ingenting om man kör .NET, Java, Python, etc. för att gå från x86_64 till ARM64. Även när man håller på med C eller C++ är tröskeln långt mindre från x86_64 till ARM64 än t.ex. x86_64 till PowerPC eller MIPS.

Att byta OS kan vara ett stort steg, framförallt om man startar från Windows som på många sätt skiljer sig mer från MacOS och Linux än vad MacOS och Linux skiljer sig från varandra.

Men i detta specifika fall var det just "enkelt" då Fusion 360 redan fanns till MacOS/x86_64. Att då fixa en MacOS/ARM64, vilket man gjort, är typiskt ett väldigt litet jobb.

Om två dagar finns kommer första "riktiga" ARM64 baserade Windows-plattformen ut på marknaden.

Dels har Microsoft gått ännu längre än Apple i deras "köra x86 program på ARM64 CPU" än Apple gjort med Rosett 2 då Windows 11 även stödjer en variant där man laddar in både ARM64 (typiskt själva huvudprogram) och x86_64 kod (t.ex. plugins som bara finns i binärformat) i samma adressrymd! Det gör ju att gamla program, som rimligen inte har några problem att köra på moderna CPUer, fungerar direkt.

Och dels verkar inte detta försök vara den halvmesyr alla tidigare försök att köra Windows på icke-x86 vara. Program som MS Office, Visual Studio, Photoshop, m.fl. finns redan som ARM64. .NET har gått från att "kan köra ARM64 med presterar sådär" till att i .NET 8 faktiskt utnyttja fördelarna i ARM64 så det finns prestandafördelar som kommer kvarstå till om/när Intel någonsin får till sin APX-utökning.

Givet att Fusion 360 redan finns till MacOS/ARM64 samt Windows/x86_64 måste det vara trivialt att erbjuda det till Windows/ARM64 också.

Är själv positivt överraskad hur bra ARM64 versionen av Windows 11 fungerar. Enda anledning att jag använder den (på en M3 Max Mac via Parallells) är just för ett fall som beror av Windows men inte på något sätt är fast med x86.

Håller med om att första portningen är den mest utmanande.

Men tröskeln har minskat jämfört med tidigare. Har gjort rätt många projekt i C som hade stöd för x86, Arm, MIPS, PowerPC, SH4 och SPARC. Bara ett enda av de värsta hålen för att stödja alla dessa finns kvar för att gå x86_64 <-> ARM64: minneskonsistensmodellen.

Men även om man av någon anledning skulle vilka stödja big-endian MIPS och x86_64 finns ju en annan anledning till varför tröskeln är långt mindre idag: allt mer skrivs i andra språk än C där man lärt sig av misstaget just kring portabilitet. Kompilerande språk som Go och Rust ser till att nästan ingen av fallen "råkar" fungera på x86 även om det är "undefinied behavior" i C/C++ samt "det fungerar på x86 men är en dålig idé av prestandaskäl, fast kraschar tyvärr på MIPS/SPARC/PowerPC" passerar kompilatorn.

Vidare skrivs allt mer i plattformar som .NET, JVM, Python, Node/JS etc där problemet överhuvudtaget inte finns om man inte verkligen gör korkade saker för att få det bundet till x86. Möjligen undantag gamla .NET framework, där var det kanske lite väl lätt att använda x86-specifika saker, men ett icke-problem i dagens .NET Core.

Testade gratisversionen av Autodesk Fusion 360. Givet att det ser ut lite som något från 90-talet kan jag tänka mig att detta har rätt mycket legacy i sig. Men hindrade uppenbarligen dem inte ändå från att fixa en MacOS/ARM64 version som tydligen fungerar riktigt bra om man ska tro det som sägs i videon.

Det stämmer inte. Problemen i x86 är mer fundamental än så, man behöver i praktiken bryta kompatibilitet med dagens 64-bit design för att nå ARM64.

Intel kommer göra ett försök att inom ramen för x86 komma så nära ARM64 som möjligt via deras APX.

Men går att säga redan nu att man kommer inte nå ända fram. "Risken" är väl att man mycket väl kan nå "tillräckligt nära". Säger risk för då fortsätter vi med en sämre teknik än vad som redan finns på marknaden.

Problemet med APX är att det i sig ger ingenting i form av prestanda. För att utnyttja det måste man kompilera om programmen så de utnyttjar APX, fast då får man ett program som inte fungerar på någon av dagens x86_64 CPUer. I det läget: varför inte bara gå till ARM64 om man ändå måste kompilera om?

Fördelen med APX är att det kan införas gradvis då CPU-modeller som stödjer detta kommer kunna köra dagens x86_64 binärer utan emulering. Fast om binäröversättning fungerar bra, har man då vunnit något?

Framförallt givet att det har visat sig vara en barriär för Arm CPUer som haft stöd både för 32-bit Arm och ARM64 (som är två helt separata ISA, ARM64 är inte en utökning av 32-bit Arm). Hos Arm, Apple och nu Qualcomm har man sett ett klart lyft i perf/cykel hos den första modell där man helt släppt 32-bit stödet. Detta då det finns designbeslut i 32-bit Arm (och dessa finns även hos x86_64) som gör det svårt att designa en extremt "bred" mikroarkitektur med bra effektivitet.

I.e. för att få full utväxling på APX kanske man likt ARM64 behöver släppa stödet för den "gamla" ISAn. Problemet med APX är att den inte är en total reset av ISA likt ARM64 helt utan bagage, utan man klämmer i praktiken in ett nytt ISA i samma "namespace" som dagens x86_64 upptar. En nackdel Intel nämner är att genomsnittlig längd på APX instruktioner kommer bli >4 bytes (fast man tror det går på ett ut totalt sett då, likt ARM64, APX ger samma program på färre instruktioner. ARM64 gör detta dock med 4 bytes per instruktion så fördel mot APX)...

Vidare tror jag användningen av ARM64 i "molnet" är större än många tror. Om man använder Java, .NET, Python, Go, Rust, Node/JS etc i det man kör: vad är problemet att byta till ARM64?

Man får mer för pengarna om man väljer ARM64, kostar "upp till 40 % mindre" (exakt siffra beror på det specifika fallet) att få samma råkraft på en ARM64 instans hos AWS mot att få det på x86_64.

Hittade denna från 2021, redan då var 14 % av alla EC2 instanser ARM64 baserade och ca 50 % av de som vid tidpunkten adderades var ARM64 baserad (vilket i.o.f.s. låter högre än jag väntat mig, men folk är kanske bättre på att jämföra två siffror än man tror...).

Är helt med på att väldigt mycket, för att inte säga det mesta, som skrivs i Java och C# nog inte skrivs med compute-prestanda som top-prio. Blir liksom meningslöst om man blandar in en RDB som ändå blir som att köra med ankaret nere.

Det tog typ 20 år, men idag är kod som kör i moderna JVM:er och .NET miljöer prestandamässigt väldigt nära C++ om man prioriterar prestanda när man utvecklar.

Sen är jag fullt medveten om "Det mesta bygger ändå på kod skriven i C++, även de språk du räknar upp förlitar sig på kod skriven i C/C++.". Man vinner inget på att köra PyTorch och TensorFlow som C++ program, det går lika fort i Python fast är långt enklare att använda. Detta då de prestandakritiska delarna körs av samma C++ bibliotek oavsett.

Men alla dessa C/C++ saker finns ju redan för ARM64, så de presterar ingen tröskel. Eventuell tröskel finns i "din" kod och den skrivs i allt större utsträckning i andra språk än C++.

Vad är problemet att sitta med Apple, så har kan min desktop se ut. Har ofta behov av att köra på MacOS, Windows och Linux

Klicka för mer information

Visa mer

Allt detta körs på samma M3 Max dator

Spännande! Vilken algoritm används?
Frågar då jag har en civ.ing i kemiteknik från KTH och gjorde examensarbete i kvantkemiska simuleringar för att bestämma effekt av molekyler som inhibitorer i protein. Detta är länge sedan nu, men krävdes med dåtidens datorer väldigt mycket beräkningskraft (använde Hartree Fock) och skrev av prestandaskäl programmet i C++.

Men då var C++ bara näst snabbaste språk, Fortran var (och är nog än) snabbare för just detta (finns optimeringar just kring matrisberäkningar som går att optimera mer med Fortran än C++, går att runda med extensioner till C/C++). Men kunde inte Fortran då och kan det inte idag heller

Ett problem med CAD verkar ju vara dålig skalning. Har man "halvbra" skalning med kärnor finns ännu en anledning att köra ARM64, den minneskonsistensmodell som används där är mer effekt jämfört med den i x86 när kärnor behöver synkronisera med varandra (vilket i princip alltid är orsaken till att saker inte skalar perfekt).

Nu fattar jag att detta har en lång historik. Men om man kan starta från scratch finns fall där Rust ger bättre prestanda än C++, av samma orsak som Fortran gjorde det på 90-talet: definitionen av C/C++ förhindrar vissa typer av kompilatoroptimeringar och i vissa fall finns inte motsvarande begränsning i Rust p.g.a. hur man valt att definiera saker där.

Att skriva SIMD i maskinkod har aldrig fungerat speciellt bra utanför relativt enkla fall. Det är nog allt för stort steg i hur man måste resonera kring logik för optimal SIMD utnyttjande kontra hur vi människor normalt tänker kring problem.

Är detta fall Nvidia så elegant knäckte med CUDA. Intel har gjort en liknande sak för CPUer med deras ISPC (som även kan generera Arm NEON kod). I båda fallen används ju en dialekt av C++ med lite extra extensioner som gör det möjligt att beskriva vad en SIMD-lane ska utföra och kompilatorn kan sen generera väldigt effektiv SIMD kod för vald output (t.ex. SSE4, 128-bitars AVX, 256-bitars AVX, 128/256/512 bitars AVX-512 etc).

Så om inte GPGPU fungerar (som om det fungerar lär vara långt snabbare) bör ni kika på ISPC!

AWS verkar maxa på 64-kärnor för "bare-metal" instanser just nu. Azure verkar ha samma maxgräns (men ser att Microsoft hävdar "upp till 50 % bättre perf/$ för deras ARM64 instanser").

Sen är det väldigt viktigt att ha med sig här, framförallt om man gör "tunga beräkningar" över alla kärnor. En 64 vCPU instans med x86_64 är i praktiken 32 kärnor / 64 trådar. En 64 vCPU instans med ARM64 är alltid 64 kärnor / 64 trådar vilket för beräkningstunga fall nästan alltid betyder märkbart bättre beräkningsprestanda per vCPU om alla lastas!