Apple M1 – vi synar Apples första ARM-processor i sömmarna

Ja och nej

Det officiella namnet är AArch64, men Apple använder konsekvent ARM64 och verkar som allt fler verktyg tar efter den namngivningen.

Så i praktiken är svaret "ja", även om ARM64 inte är det officiella namnet.

Edit: liknande förvirring finns på x86, där ser man både x86_64 och AMD64 men dessa är egentligen två olika men rejält överlappade saker.

32-bitars x86 är enkelt, officiellt heter det IA32 men kallas ofta x86, i386 (eller i686 om man menar PentiumPro eller senare vilket var ett krav för rätt mycket på slutet). 64-bitars x86 har två varianter som faktiskt inte är helt kompatibla (men bara OS-kärnor som behöver bry sig om skillnaderna): AMD64 och Intel64. x86_64 brukar användas för det som är gemensamt mellan AMD64 och Intel64, vilket är allt som gäller "vanliga" program.

32-bitars Arm har en liknande story. Sett från applikationer är det x86-nivå på bakåtkompatibiliteten, är inte hundra på att dagens Arm kan köra kod från första versionen som lanserades 1985 men skulle gissa att så är fallet. ARMv4-ARMv7 är definitivt bakåtkompatibla på applikationsnivå (på OS-nivå finns viss inkompatibilitet, vilket är ett mindre problem då det ändå krävs jobb i OS-kärnan i form av drivrutiner).

ARMv8 är första versionen med 64-bitarsstöd. Värt att notera är att 32-bitarsstöd är en valfritt tillägg i ARMv8. Apple tog bort 32-bitars stödet (AArch32) för tre år sedan, A11 saknade sådan stöd. Från och med nästa generation Cortex A kommer även Arm att ha ARMv8 kompatibla designer som inte längre implementerar AArch32.

De ARMv8 CPU som implementerar AArch32 är bakåtkompatibla minst till ARMv4, så är inte bara för x86 det är viktigt med att stödja existerande program. Det Arm insåg var att man tagit flera beslut från 1985 och framåt som inte alls längre var optimala. Till skillnad från i princip alla tidigare övergångar till 64-bit startade Arm om från scratch.

AArch32 och AArch64 är två helt distinkta ISA, de har ungefär lika mycket gemensamt som t.ex. MIPS och POWER. D.v.s. båda är "RISC", men mycket mer än så har de inte gemensamt.

Tack och bock! Precis som @yoshman skriver är Apple sin vana trogna och kallar den egna varianten något annat än det officiella namnet Jag ändrade dock till genomgående Aarch64 i artikeln och nämner att Apple kallar sin variant ARM64 för tydlighetens skull.

Tycker ändå Apple har med stor tydlighet visat minst 3 saker

• idag är allt relevant utvecklat i "högnivåspråk" (i detta kontext, högnivå != assembler) så det är inte alls speciellt komplicerat att kompilera om ett program från x86_64 till ARM64. Framförallt inte då x86_64 och ARM64 båda är s.k. "little-endian", en hyfsat vanlig felkälla vid övergång mellan PowerPC och x86 var att deras byte-ordning är olika (PowerPC kan stödja little-endian, men nästan alla var big-endian)

• idag finns verktyg med "helt öppen licens" (BSD-licens) som kan konvertera x86_64 maskinkod till LLVM IR, när man har något på LLVM IR formen kan det i sin tur konverteras till i praktiken vilken annan ISA som helst -> även program man saknar källkod till kan med relativt liten arbetsinsats översättas till en annan ISA (sämre prestanda än att kompilera om, men Apple visade att genom smarta HW-val som TSO stöd i HW kan man öka prestanda en hel del)

• både Apple och även Arm rimligen visat att ARM64 är en så pass mycket bättre ISA än x86_64 att det ger relevant skillnad i prestanda/effektivitet

Givet punktera ovan, som visar att det finns en kortsiktig lösning för x86_64 kompatibilitet. Intel och/eller AMD skulle mycket väl kunna designa en ny ISA och bygga in lämpligt HW-stöd i kretsen så x86_64 kod översatt till denna nya ISA kan köras minst lika snabbt som den idag körs på deras snabbast CPUer.

Sett till IPC är ju exakt det Apple lyckats med, effektivt sett kör man x86_64 program med högre "IPC" än någon annan CPU. Skriver "IPC", rent tekniskt kör man fortfarande ARM64 med Rosetta 2 även om det är ARM64 genererad x86_64->LLVM IR->ARM64. Det är ändå "magin" för att nå högre effektiv IPC, då man verkar ha slagit i taket för hur mycket ILP som är realistiskt att dynamiskt extrahera ur x86_64 kod. Ett sätt att öka ILP för ett x86_64 program är att göra rätt mycket vad Intel försökte med IA64 (Itanium): gör en långt mer avancerad statisk ILP analys innan programmet körs och koda den informationen i en ny instruktionsuppsättning (i Apples fall ARM64).

Är inte alls ovanligt att bra idéer behöver tid att mogna. Ett exempel är AMDs "Fusion" (Apples M1 är rätt mycket AMDs vision om Fusion nu implementerad på i kisel, på OS-nivå och i all fler program), ett annat är att via kompilatorer exponera mer ILP till HW för att nå riktigt hög IPC, vilket var målet med IA64 (Itanium).

IA64 fallerade av (minst) tre orsaker

1. att utveckla tillräckligt avancerade kompilatorer visade sig vara långt mer komplicerat att man gissade, än idag gör man framsteg här utanför traditionella CPUer (t.ex. Nvidias CUDA, Intels OneAPI och en lång rad mindre projekt knutna till heterogena system + LLVM)

2. IA64 använde sig av en form av VLIW (man kallade varianten EPIC, Explicitly Parallel Instruction Computing). VLIW fungerar väldigt bra på några få nischade fall, men det har visat sig vara ett dåligt val för den typ av generella beräkningar vi typiskt gör på CPUer. Nog ingen slump att IA64 egentlige bara lyckade någorlunda väl i vissa superdatorfall.

3. IA64 lanserades innan "breakdown of Dennard scaling", så absolut enklaste och mest effektiva sättet att öka prestanda per kärna var att skruva upp frekvensen. Idag är enda sättet att få bättre prestanda per kärna högre IPC, x86 är allt annat än optimalt designad för riktigt hög IPC. Även AArch32^* fungerar uselt om man vill nå hög IPC, så till skillnad från tidigare där ISA i slutändan alltid varit mindre viktigt än mikroarkitektur har vi nu nått en punkt där ISA är högst relevant

För sista punkten kan man ställa sig frågan: vilka andra ISA lämpar sig för riktigt hög IPC? Möjligen RISC-V, men går inte att veta innan någon försökt. Vi lär få se hur väl POWER lämpar sig, ryktet säger att nästa POWER version ska påminna mycket om hur Apple designar sina CPU: extremt "bred" design som siktar på brutal IPC.

^* AArch32 är antagligen sämre än x86 givet att i stor sätt alla AArch32 instruktioner har ett potentiellt implicit beroende av tidigare instruktioner -> extremt sekventiellt flöde. Denna del är helt eliminerad i AArch64, där har man dragit den slidern åt motsatt håll och helt eliminerat implicit beroende mellan instruktioner nästan helt. AArch64 är rätt "icke-RISC:ig" i hur man implementera sådan där i stort sätt alla andra ISA har implicit beroende: jämförelse följd av hopp eller liknande beroende på hur jämförelsen gick, AArch64 har specifika instruktioner som slår ihop "jämförelse+beroende hopp" (typ explicit göra det Intel kallade "macro-op fusion" i Core2).

Lite allmänt svammel om "RISC" (personligen gillar jag inte termerna RISC och CISC).

Termen "RISC" myntades första gången i början av 80-talet i ett projekt som i förlängningen resulterade i bl.a. MIPS och SPARC ISAs.

I efterhand har man i praktiken satt "RISC" stämpeln på alla s.k. load-store ISA (ISA som bara utför aritmetiska operationer mot register). Finns "CISC" ISA med extremt simpla instruktionsuppsättning samt "RISC" ISA med rätt komplexa instruktionsuppsättning.

Wikipedia nämner att IBM 801 nog är den första RISC CPUn. Personligen tycker jag det visar ett av många problem med termen, ingen hade hört talas om "RISC" när IBM 801 lanserades, detta då lanseringen skedde innan RISC-termen först myntades. IBM 801 råkade bara vara första load-store designen med någon form av kommersiell framgång, så man har i efterhand stämplat RISC på den.

Givet vad RISC-projektet handlade om finns är det egentligen bara SPARC som utan tvivel kan kallas "RISC" då SPARC kommersialiserade grundidéerna från Berkeleys RISC-projekt.

Med den definitionen av RISC kan man konstatera att RISC var en dålig idé, för signumet för SPARC, register-hjulet, visade sig vara en rätt dålig idé medan filosofin från MIPS-projektet, att låta kompilatorn hantera register-allokering i stället för HW som i RISC/SPARC, visade sig betydligt mer framgångsrikt. Likt MIPS (och i mindre utsträckning PowerPC) hade SPARC och nackdelen med relativt dålig koddensitet (i alla fall ställt mot x86).

Är nog just p.g.a. resultaten från Berkeley RISC projektet, MIPS och SPARC, som detta lever kvar än

32-bitars Arm lanserades samma år som MIPS, d.v.s. 1985, men var nog långt senare någon kallade 32-bitars Arm för "RISC".

32-bitars Arm stämmer väldigt dåligt in på RISC-beskrivningen i bilden, utöver att det är en load-store design samt att den implementerar atomära instruktioner på "RISC" vis.

• finns väldigt "komplicerade" instruktioner för att läsa/skriva mot minne (mer avancerade än x86, t.ex. kan en enda instruktion ladda/spara valfri uppsättning register från/till RAM)

• 32-bitars Arm kod är, till skillnad från framförallt MIPS och SPARC, extremt kompakt (betydligt kompaktare än x86, som i sin tur är kompaktare än PowerPC, MIPS och SPARC). ARM64 och x86_64 är rätt likvärdig i kompakthet, de om något är ARM64 något kompaktare

• nästan alla 32-bitars Arm instruktioner kan ha villkor associerade med sig, om villkoret inte är uppfyllt gör inte instruktion något (detta är en orsak till att man kan göra 32-bitars Arm kod väldigt kompakt då många korta hopp kan elimineras)

• för att vara en "RISC" har 32-bitars Arm rätt få register, endast 16 st (varav 3 st har väldigt specifika uppgifter). 64-bitars Arm är betydligt mer "RISC" lik på denna punkt

Precis som (nästan) allt annat pillrade IBM med de grundläggande principerna runt RISC redan i början på 60-talet (vad har IBM inte gjort mellan 1950-69???). Och är väl egentligen dessa princip, framförallt hård separation av instruktioner som laddar/sparar information till/från RAM från/till register och att aritmetiska operationer endast utförs mot register, som vi idag egentligen menar med "RISC" (och med "CISC" menas då ISA som kan utföra aritmetiska operationer även mot RAM).

Fast varför då inte använda "load-store designs" för det vi nu kallar RISC-designs?

Den delen av AMD som tillverkar spelkonsolkretsarna heter ju "Semi-Custom Solutions" av en anledning. Hade varit fullt möjligt att ta rätt exakt den design man nu har, men använda Cortex A77, A78 eller X1 som CPU-del.

Redan om man kört med A77 (lanserades maj 2019) hade det gett fördelar i prestanda. Cortex A77 har något högre prestanda per MHz än Zen3 (konsolerna använder Zen2), så även vid de 3,3 GHz vissa mobiler kör A77 skulle man haft något med något högre absolut CPU-prestanda än vad PS5/XSX har.

Samtidigt skulle det också resulterat i att CPU-klustret drar mindre ström, något som endera kunde användas till något bättre GPU-prestanda eller lite mindre totaleffekt. Kretsen hade också blivit mindre då en Zen2 kärna tar nästan 3 gånger så många transistorer som en Cortex A77 kärna (Zen2 använder rätt exakt 3 gånger så många transistorer jämfört med Cortex A76).

Hade man stoppa i X1 hade det blivit riktigt intressant. Cortex A76, Zen2 och Skylake har alla väldigt snarlik prestanda per MHz. Cortex X1 har ~60 % högre prestanda per MHz jämfört med A76, d.v.s. vi kunde ha haft konsoler med högre CPU-prestanda än high-end gaming PCs!

Tror svaret på den frågan är rätt trist: dels riskminimering (PS5/XSX är egentligen bara en snabbare, men bakåtkompatibel version av PS4/XBO) men framförallt lär utvecklingsarbetet med PS5/XSX börjat i alla fall innan 2015 och då undrar jag om någon ens kunde gissa vilken brutal utveckling ARM64 skulle få.

Man måste komma ihåg att ARM64 (eller tekniskt korrekt, AArch64) fortfarande inte ens funnits ett decennium. Arm lanserade ARMv8.0 2011.

Svårt att se hur AMD skulle kunna ge ett bättre pris på Zen2 jämfört med Cortex A77/A78 (som består av ~1/3 så många transistorer) eller ens Cortex X1 (som består av ~1/2 så många transistor trots ~60 % högre IPC).

Tycker också Apple allt mer med brutal klarhet visar hur överskattat problemet med att byta ISA är. Har själv jobbat med C och C++ kod som används på x86, AArch32, AArch64, PowerPC, MIPS och RISC-V. Historisk har det absolut varit ett jätteproblem (nivån på kompilatorer var inte lika rolig på 90-talet...), men saker förändras och nu för tiden är dels nivån på kompilatorer långt bättre än den tidigare varit (så sällan några superproblem att kompilera om även väldigt komplicerade program), dels skrivs program i allt högre nivå språk. Visst, spel skrivs primärt i C++, men vi har i praktiken helt lämnat assembler bakom oss.

Man måste också komma ihåg att innan Cortex A76 (som lanserades maj 2018) var det nog få som trodde att Arm faktiskt var kapabel att designa CPUer som kunde slå high-end x86 på fingrarna sett till mängd utförd arbete per cykel. Med Cortex X1 har även Arm visat att man kan lämna x86 rejält akterseglad.

Innan M1 lanserades var det rätt många som helt avfärdade benchmarks som Geekbench med: det går inte att jämföra iOS med "riktiga" datorer. Nu borde det vara rätt uppenbart att GB hade helt rätt, handlar inte om "optimeringar i iOS" utan Apples enheter presterade bra i benchmarks därför att de drivs av en väldigt snabb CPU (från och med Firestorm är det världens just nu snabbast CPU räknat per CPU-kärna).