ARM64 är nu 10 % av PC-marknaden

Den länken innehåller en av huvudargumenten varför fler borde önska att ARM64 tar över även på Windows plattformen.

Länge var konsensus att instruktionsuppsättningen, ISA, inte spelade speciellt stor roll kring vilken prestanda en krets får. I praktiken var det så, primärt av två orsaker

• ISA har visat sig långt viktigare nu när normen är CPUer med flera kärnor än vad som var fallet när CPU hade en eller max två kärnor

• Tidigare försök, Intels IA64 är nog det mest välkända, till en ny ISA fungerade väl inom vissa specifika områden men var ingen vinst över x86/x86_64 sett till det genomsnittliga fallet. ARM64 och RISC-V är de första fallen som uppvisar i praktiken konsekvent bättre egenskaper än x86_64, båda dessa designades och lanseras (2010) efter att vi gått in i multi-core eran"

"The process of eliminating 32-bit and optimizing for the 64-bit ISA exclusively has been a 2-step process. With the Cortex-X2, the underlying circuitry used for handling 32-bit architectural-related elements was removed, saving on transistors and simplifying some structures. With the new Cortex-X3, the design team took the time to start optimizing specifically for AArch64. In particular, many optimizations to fetch and decode took place taking advantage of the more predictable and regular nature of the AArch64 ISA."

Helt övertygad om att en viktig orsak (finns flera) till att Apples M1 kan ha så brutalt mycket högre "IPC" jämfört med vad Intel/AMD kan få till (M1 utför åtminstone 50-60 % mer jobb per cykel jämfört med Golden Cove och Zen3, även Cortex X2 ligger ~20 % högre) kommer av möjligheter med ARM64.

Apple droppade 32-bit stödet för Arm rätt tidigt. Här är det viktigt att inse att ARM64 inte är en utökning utav 32-bit Arm likt hur x86_64 är en utökning av x86 (IA32). ARM64 är en helt egen ISA som inte har samma kodning av instruktion som 32-bitars Arm, det är lika stor skillnad mellan ARM64 som mellan t.ex. MIPS och PowerPC.

ARM64 har dels fördel att alla instruktioner är samma längd, x86_64 instruktioner kan vara allt från 1 till 15 bytes. Trots att ARM64 är en "RISC" (vilket idag är en rätt meningslös term) med fast instruktionsstorlek blir program nästan alltid mer kompakta med ARM64 än med x86_64.

Detta beror mycket på att ARM64 (likt RISC-V) designats för att vara enkla att optimera kompilerad kod för. x86_64 må ha långt fler instruktioner än ARM64, men ARM64 är "rätt" instruktioner för en kompilator.

ARM64/RISC-V implementerar rätt exakt den minneskonsistenmodell som alla de stora programmeringsspråken efter mycket bollande fram och tillbaka kommit fram till är "optimalt" för multitrådade program. I princip alla andra tidigare RISC:ar valde en lite för tillåtande modell, d.v.s. för lite garantier ges mot hur Java, C#, C++, Rust, Go etc förväntar sig att saker ska fungera. x86_64 har valt en långt striktare modell än nödvändigt.

RISC:arna får därför stoppa in extra synkronisering, så de tappar de fördelar de hade på pappret. x86_64 lämnar en hel del prestanda på bordet, att fixa detta skulle byta att alla existerande multitrådade program skulle sluta fungera -> går inte att fixa för då försvinner huvudpunkten med att dras med x86_64: dessa bakåtkompatibilitet.

Arm har historiskt varit rätt spot-on kring de IPC förbättringar man lovat, så Cortex X3 borde inte vara något avsteg från det. 11 % IPC (geometriskt medel över ett gäng applikationer) är betydligt bättre än vad Intel verkar få i Raptor Cove och vad AMD kommer få i Zen4 (och tänk då på att det är 11 % mot X2 som lanserades 2021, Intel verkar få några enstaka procent sen Alder Lake och AMDs förbättringar med Zen4 är vid lansering mot en 2 år gammal Zen3).

11 % är ändå inte tillräckligt för att man ska komma riktigt nära Apple, och för att ARM64 på Windows ska ta fart behövs något likt M1/M2 (d.v.s. i praktiken lika bra eller bättre på varje punkt jämfört med Intel/AMD, och väsentligt bättre på ett par).

Artikeln nämner att Qualcomm ska använda Cortex X3 i nästa generation Snapdragon. Tror man kan tolka det positivt givet vad denna tråd handlar om: det betyder kanske att Qualcomm/Nuvia CPUn verkligen är till 100 % designad för laptop/PC, det skulle ge dem möjligheter att trumfa Apples M1/M2 serie då Apple bara har en "big-core" design som de använder från Iphone och uppåt.

100 % säker att svaret är NEJ!!!

Anledning: det har testas flera gånger, pitchen har varje gång varit hur mycket effektivare och hur mycket snabbare dessa CPUer varit än Intel/AMD sett över alla kärnor.

Ett av de mer extrema fallen var TILE64 som på pappret gjorde mos av Intels bästa CPU tack vare att TILE64 hade hela 64 kärnor, det redan 2007. Prestanda per kärna var öken, men summan av alla 64-kärnor var långt mer än vad Intel/AMD hade på den tiden. I praktiken var kretsen hopplös att använda utanför extremt smala nischer.

Problemet är att på desktop, och långt oftare även på servers än vad man kanske tror, är prestanda per kärna brutalt mycket viktigare än totala prestanda över alla kärnor.

M1 är framgångsrik till väldigt stor del då den vid lansering var den CPU med högst prestanda per kärna, punkt! D.v.s. den CPU Apple kunde köra i en fläktlös M1 var snabbare per kärna än något Intel och AMD då hade (faktum är att M1 fortfarande är snabbare per kärna än alla AMDs modeller, är bara Intels absolut högst klockade Golden Cove modeller som är snabbare idag).

Qualcomm kommer lyckas etablera ARM64 på Windows om de kan göra en M1. Och det betyder inte att de kan matcha M1, det betyder att de vid lansering måste ha en krets vars prestanda per kärna måste slå alla Raptors Cove och Zen4 modeller.

Höga krav, men givet vilka som grundande Nuvia (företaget Qualcomm köpte förra året och som jobbar på deras nya CPU-design) så tror jag det faktiskt är fullt realistiskt. Intel och AMD har ett allt tyngre ankare att baxa med sig i form av x86_64. Så även om det är Qualcomms första försökt på en "desktop class high-end CPU" rent praktiskt har de som jobbar med CPUn tidigare både jobbat med M1 (flera av grundarna till Nuvia har gjort det) och Intels/AMDs CPUer (Nuvia har lockat över flera personer från Intel/AMD).

Vid lansering hade M1 högsta prestanda per kärna av alla då existerande CPU-modeller. AMD/Intel hade självklart modeller som tack vare fler kärnor presterade bättre totalt sett.

Vad det gäller perf/W var (är) det total kross. AnandTech har kikat på det ett par gånger, lite beroende på användarfall är fördelen för M1 ~2-3 gånger i enkeltrådade fall och 3-6 gånger i multitrådade fall. Så just på bärbara är det Intel/AMD levererar just nu direkt pinsamt.

Det är möjligt för Intel/AMD att väsentligt minska detta gap, AMD gör det också till viss del när man kör på batteridrift. Problemet är att det kräver väsentligt lägre CPU-frekvens, man minskar gapet i perf/W men man hamnar då rejält efter i prestanda.

De >20 % som jag sett i flera applikationer är ju på Linux + även om Apple har fantastisk vertikal integration så är de benchmark jag baserar mina jämförelse på sådana som bara beror på CPUn.

Det Apples vertikala integration ger är ju utöver vad man får från CPUn. Jobbar t.ex. inte med videoredigering, men det är ett exempel där fler delar av M1-systemkretsen samarbetar med OS och programvara och då ger helt fantastiskt resultat.

M1 presterar CPU-mässigt lika väl under Docker/Linux som under OSX. Under Linux finns inga Apple/MacOS specifika tricks, utan det man har är HW i M1 samt arbetet som Arm, Apple, m.fl. stoppat in i projekt som GCC (Arm har jobbat mycket med denna) och LLVM (Apple lägger väldigt mycket krut här då Clang/LLVM är officiell C/C++ kompilator för alla deras system).

Att många register är förklaringen kommer ofta upp, det kan bara förklara en väldigt liten del av prestandaförbättringen då t.ex. x86 såg väldigt liten vinst från att gå från 8 heltalsregister till 16 heltalsregister. 8 var absolut för lite, 32-bit Arm hade 15 heltalsregister (16 men en var ju programräknare) till 32 heltalsregister (exklusive programräknare, men inklusive ett zero-register).

Sant att synkronisering inte sker vid varje instruktion, men det sker vid varje minnesoperation (även om CPUn kan göra en hel del tricks så länge bara en CPU-kärna petar på minnet). Har för mig att ett program typiskt har en minnesoperation per varje 3 till 5 instruktioner (lite beroende på vad det gör). Men är primärt multitrådade program där denna fördel visar sig, och då allt mer ju fler kärnor systemet har och aktivt använder.

De >20 % jag pratar om är primärt i program där varje tråd jobbar väldigt oberoende av andra trådar.

Den absolut största designmissen i 32-bit Arm är att i princip alla instruktioner är villkorade, uppfylls inte villkoret blir instruktionen i praktiken en NOP. Det är förödande om man försöker designa en CPU som ska spekulera långt framåt, en sak Apples M1 ligger i topp på är just hur många instruktioner den kan ha parallellt "in-flight". ARM64 har i praktiken helt eliminerat detta.

Samtidigt är detta en av 32-bitars Arm största styrkor. Den må kallas "RISC", men denna egenskap känns väldigt "icke-RISC" och den medför att 32-bit Arm program tenderar vara riktigt kompakta, kompaktare än motsvarande x86 (medan motsvarande program på t.ex. PowerPC, MIPS, SPARC i princip alltid blir större än på x86).

Vidare har 32-bit Arm och framförallt x86/x86_64 egenheten att nästan alla instruktioner påverkar CPU-flaggorna, d.v.s. de modifierar ett globalt tillstånd. Vad har vi lärt oss om att skriva till globalt delad data i program där saker potentiellt sker parallellt (vilket det gör även i enkeltrådade fall i dagens high-end CPUer)? Det är en skitdålig idé då det begränsar mängden parallellism.

I ARM64 (och RISC-V) har majoriteten av alla instruktioner ingen påverkan på något globalt tillstånd, de tar indata via register och producerar endast utdata i ett register. HÄR tror jag en av de riktigt stora fördelarna med ARM64 ligger, om så är fallet borde även RISC-V kunna skalas upp på liknande sätt!

Intel/AMD kan inte fixa något av ovan, alla existerande program skulle gå sönder om man gjorde det.

jag tror svaret varför inget hände på x86 är mycket enklare än så: "architectural versus physical registers"! Redan när övergången till x86_64 i praktiken hände var x86 CPUerna så pass avancerade att de hade så pass avancerad OoO att antalet fysiska register vida översteg register synliga i ISA. Det kombinerat med att x86 sedan PIII-tiden hade dedicerad HW för att hantera push/pop (bl.a. register spills).

Cortex A serien var ju betydligt mer avancerad än en PIII klass CPU när ARM64 introducerades, framförallt hade man även på Arm sidan gått över till OoO på de mer avancerade modellerna -> även där fanns långt fler fysiska register än ISA register. Möjligen kan CPUer som Cortex A53, A55 och A510, som alla är in-order designer, se lite mer utväxling.

Just då jag sett denna diskussion förut + jag läst att "optimala antalet register" är någonstans 16-20 st gjorde jag för en tid sedan analys av ett gäng program och kollade lite hur mycket olika register användes (har dock inte superbra modell för att specifikt mäta registerspill).

På x86_64 använda rätt konsekvent 3 register (r9, r10 och r11) i mindre än 1 % av fallen (de användes dock i alla program jag kikade på). På x86 användas ah/al/ax/eax/rax (teknisk sett samma register, bara olika delar) långt mer än andra register, vilket inte är förvånande givet x86 historik där vissa instruktioner måste använda det registret. bx, cx och dx har även de vissa specifika användningar som delvis kvarstår, vilket gör att även dessa är lite mer välanvända än de ny r9-r15.

På 32-bit Arm finns det teknisk sett 5 "specialregister", r10 (sl = stack limit, är på Linux ett "vanligt" register), r11 (fp = frame pointer, likt "bp" på x86 används detta register i debug-byggen, men typiskt är det ett "vanligt" register i optimerade binärer), r12 (ip = Intra-procedure scratch register, i praktiken ett vanligt register), r13 (sp = stack pointer, är stack pointer), r14 (lr = link register, sätts till återhoppsadress vid anrop av subrutiner), r15 (pc = program counter).

Även här finns register som i praktiken används väldigt lite, här kan man också scanna efter push/pop för att kolla om det finns fall som sparar/laddar alla register (hittade noll sådana fall, men finns fall som sparar/laddar nästan alla register). Klart högst tryck på r3 och r0 då dessa används som första argument samt returvärde. Inget register användes typiskt mindre än 1 % av tiden, 4-6 register användes dock rätt sporadiskt (låga enstaka procent).

Så 32-bit Arm har absolut inget överflöd av register, men verkar inte heller som det är en skriande brist alt. så skulle GCC kunna vara halvkass på att optimera för Arm (vilket jag inte tror).

På ARM64 är xN och wN samma register, bara 64- resp 32-bit variant. Så behandlade t.ex. w0 och x0 som samma register i mätningar. Alla register används, men 10-12 register användes < 1% av fallen. Endast 8 st register används i mer än 5 % av fallen. Här verkar man kommit till en punkt där det nästan allt finns fler register än vad en kompilator kan använda till något vettigt. Det stämmer också med de uttalande jag sett kring "optimalt antal register".

Det finns fall där väldigt många register är fördelaktigt, men det handlar nästan alltid om flyttalstunga applikationer. Är nog inte för intet som Intel slängt in 32 flyttals/SIMD register med AVX-512, upp från tidigare 16st!

Vore det så bra med fler register skulle man absolut kunna öka antalet på x86 och ändå vara bakåtkompatibel. Bara lösa på det sätt man alltid löser det på x86: ännu ett prefix!

Visade sig att det faktiskt går att styra hur många register som ska användas i ett program som byggs för ARM64

Upp till 16 register kan "reserveras" via flaggan "-ffixed-<REGNAME>". Får det inte att fungera med den gcc/c++ kompilator jag installerat på Mac:en, men fungerar med LLVM/Clang.

Det man får tänka på är att vissa register har dedicerade uppgifter, så när man reserverar 16 register har man effektivt klart färre än 16 register att använda fritt. Följande reserverad register finns (och dessa kan därför inte reserveras med -ffixed-<REGNAME>)

x0-x7 används för argument och returvärden

x8 används för systemanrop, vilket systemanrop man gör ligger där
x16-x18 används för att lagra information som ibland används över funktionsanrop
x29 är "frame-pointer" (används sällan i optimerade binärer, men blir svårt att debugga utan frame-stöd)
x30 är länkregister
x31 är stackpekare (och i andra lägen zero-register)

Av dessa verkar ändå kompilatorn använda x16 (men inte x17 och x18). Också lite förvånad att den inte använder x0-x7 som "fria" register, utan de används just som argument och returvärden även när man stryper tillgången på register.

Så uppenbarligen är användningen av register i LLVM/clang designad runt det antal register som faktiskt finns, "normal/tänkt" användning av -ffixed-<REGNAME> är att kunna reservera något enstaka register i t.ex. inbyggda-system eller liknande.

Tog ett par av programmen från "benchmark-game" och jämförde fallet "alla register tillgängliga" mot "16 st reserverade".

Som mest blev det en prestandaförlust om 10 % (fannkuch-redux, heltalstungt i praktiken helt utan minnesreferenser) medan mer minnesintesiva och flyttalsintensiva applikationer gjorde någon enstaka procent. Binary-trees, som rätt mycket är ett "pointer-chasing test", såg <0,5 % skillnad.

Så fler än 16 register ger absolut en boost, men svårt att se hur den kan förklara mer än en mindre del av vinsten man får att kompilera om kod från 32-bit Arm till ARM64 för t.ex. RPi3/4. Körde mina tester på en M1Pro.

Edit: På Linux fungerar switchen med GCC/G++ (det gjorde den inte på MacOS), testade på en RPi4 med ARM64 versionen av Ubuntu 20.04

Tog mina 2017 års advent of code lösningar gjorda i C++ och byggde dem så alla register får används resp. med 16 st register reserverade. Skiljer ~1,5 % mellan de två versionerna, så ännu mindre än vad jag såg på M1. Är just på RPi4 jag såg 0-30 % vinst att köra ARM64 över 32-bit Arm, orsaken är rimligen primärt andra saker än fler register!