Apple Macbook Air med M1 imponerar i första resultat

Jag är en SW-person, inte HW-person. Tänkte på det när jag lyssnade på Intel och AMD intervjuerna igår, där pratade HW-människor som inte är SW-personer (kort och gott, ibland var de i spenaten vilket jag lär vara för HW till och från).

Men i grunden finns i alla fall två stora problem med x86_64 som inte finns i ARM64

1. ARM64 hanterar minneskonsistensen mellan saker som kör på olika CPU-trådar på ett sätt som skalar bättre med stort antal kärnor. Detta kan absolut fixas i x86 om man skippar bakåtkompatibilitet, metoden man har nu råkar bara vara något man tyckte kändes rätt för ~30 år sedan när det definieras (när första dual-socket x86 dök upp)

2. ARM64 har fix storlek på alla instruktioner, de är 4 bytes vilket gör det trivialt att hitta gränserna mellan instruktionerna, vilket gör det möjligt för Apple att avkoda 8 instruktioner per cykel. x86 instruktioner är 1-15 bytes, idag är det bara nackdelar för genomsnittligs längden på en instruktion passerar ofta 4 bytes idag så x86_64 program är något större än motsvarande ARM64. Fixar man detta är det inget kvar av x86.

Vi jämför för att Apples ARM är uppe och nosar på Intel och AMD top-of-the-line desktop CPU:er, Single Core får de redan smisk, återstår Multi Core. På vilket sätt är det inte en rättvis jämförelse?

Apple’s lilla M1 slår redan ”högpresterande CPU som Ryzen 5000 serien” 5950X i Single Core prestanda.

Tror det tar ungefär till slutet av nästa vecka innan folk faktiskt effektivt kan använda den till något som behöver hög beräkningskraft.

Spel håller jag med dig! Men det är för XBX/PS5 har x86 CPU:er.

Vill man ha x86 kompatibilitet på en annan mikroarkitektur är det enda vettiga att göra det i programvara, d.v.s. exakt vad Apple gör med Rosetta 2 och Windows on ARM gör (x86_64 emulering kommer till Windows detta kvartal, Microsoft primära problem är att de lanserade sin ARM64 innan de var klara på programvarusidan).

Hade det bara handlat om aggregerad prestanda skulle x86 ha varit död och begraven för länge sedan. Aggregerad prestanda handlar nästan bara om en enda sak: perf/W. Ju bättre perf/W, ju fler kärnor kan man trycka in i samma krets då det idag är effektbudget som stoppar skalningen av CPUer mer än något annat.

Varför dödade då inte t.ex. SPARC och POWER x86? Båda dessa har haft massor med modeller som fått x86 server-kretsar att se ut som leksaker sett till aggregerad prestanda.

Därför att de aldrig kunnat slå Intels x86 på fingrarna sett till prestanda per kärna. Även på serversidan är väldigt mycket begränsat av någon kritisk del, kritisk del som definitionsmässigt är något man inte kan snabba på genom att slänga fler kärnor på problemet.

Vi har sett flera 32-bitars ARM server-kretsar crash-and-burn. Alla dessa har haft helt OK aggregerad prestanda, långt bättre perf/W än x86, men de har inte varit i närheten sett till prestanda per kärna.

AMDs Zen är inte primärt framgångsrik för att de har fler kärnor än prismässigt motsvarande Intel, Zen är en framgång för man lyckades komma tillräckligt nära Intel i prestanda per kärna för att med Zen3 faktiskt passera.

Så det kritiska med Apples ARM64 är just dess enkeltrådprestanda. Då perf/W är heltalsfaktorer bättre än x86, samtidigt som antal transistorer per CPU-kärna i jämförbar med high-end x86 handlar resten bara om att faktiskt bygga en krets med tillräckligt många kärnor för att även ta över ledartröjan i aggregerad prestanda. Apple verkar inte intresserad av servermarknaden, men redan idag lär Ampere computings 80-kärniga Altera (ARM Neoverse N1 baserad) slå alla existerande x86 CPUer sett till aggregerad prestanda.

För Apples del får vi vänta till de släpper sin ARM64 för MacPro, min gissning är att när den lanseras spelar det inte längre någon roll vad vi jämför i form av desktop CPUer.

På lite längre sikt ser det rätt mörkt ut för x86, å andra sidan brukar alla imperier falla bara man har tillräckligt lång tidshorisont.

På kortare sikt: Windows är tyvärr en rätt rejält garant för att x86 kommer vara relevant ett bra tag till.

De prestandasiffror Apple nämner är till att börja med PR, så "bästa fall". Det man jämför mot är samma typ av dator, modellen innan i instegskonfiguration. Så 13" MBP med M1 jämförs med sista Intel-baserade 13" MBP med i5, etc.

Bl.a. Intel har tidigare, med fog givet prestandaresultaten, alltid påpekad att allt som betyder något är mikroarkitektur medan ISA bara är ett sätt av flera att representera en visst program. Dels har ingen lyckats göra en ISA som är lika bra eller bättre på varje punkt ställd mot x86 (nu har vi två sådana i ARM64 och RISC-V), dels kunde Intel alltid kompensera för ineffektiviteten då man under väldigt lång tid låg 0,5-2 noder före alla andra.

ARM64 (som är väldigt annorlunda från 32-bitars ARM) är bevisat bra. Apple har ungefär lika många transistorer per kärna som AMD/Intel, men deras design utför nästan dubbelt så mycket per cykel. Arm har bl.a. Cortex A76 som utför lika mycket som Zen2/Skylake, fast där varje kärna tar ~1/3 av kretsytan mot Zen2 på samma TSMC 7 nm.

D.v.s. det är ingen liten skillnad, det är en till två heltalsfaktorers fördel för ARM64. I teorin borde RISC-V kunna vara ungefär lika effektiv som ARM64, men innan vi exakt förstår varför ARM64 verkar så brutalt effekt för att skapa designer med riktigt hög absolut prestanda (32-bitars ARM har aldrig nått i närheten av x86 i absolut prestanda även om perf/W varit lysande) så är det svårt att veta om RISC-V också kommer visa samma egenskaper. Det finns många likheter mellan ARM64 och RISC-V, men finns och ett par skillnader som kan vara relevanta.

Exakt. För att ta ett konkret exempel

Antag att du har ett program med två CPU-trådar. Dessa trådar läser/skriver båda till tre globala variabler, A, B och C. Antag att A, B och C initialt är 0.

Antag att tråd#1 gör detta

A = 17
B = 42
C = 1

Medan tråd#2 gör detta

if (C == 1) {
    print(B)
    print(A)
}

Vi ignorerar de optimeringar kompilatorn kan göra här, vi antar att minnesoperationerna verkligen lagts ut i den ordning som listas här både för x86 och ARM64.

På x86 garanteras att tråd#2 endera inte skriver ut något alls (om tråd#2 kolla värdet på C innan det sätts till 1), eller så skrivs 42 och 17 ut. Det trots att det inte finns någon explicit synkronisering, d.v.s. x86 ger massa garantier som i praktiken är onödiga -> kostar prestanda när flera kärnor jobbar på delad data.

På ARM64 man man få fallet att inget skrivs ut, [0,0], [0,17], [42,0] samt [42,17]. Detta kanske känns konstigt för en människa, men det är faktiskt vad man får i det mest rimliga/effektiva HW-implementationen som inte ger mer garantier än vad som egentligt specificeras här. Alla moderna programspråk har specifika sätt att uttrycka minnesoperationer som har regler relaterad till andra minnesoperationer som hänt före/efter just denna minnsoperation.

"Normala" minnesoperationer står för >99% av alla man gör i ett typiskt program, de kräver ingenting om minnesoperationer som utförs på andra variabler. Vill man få x86 resultatet på ARM64 gör man detta

Antag att tråd#1 gör detta

A = 17
B = 42
C.store(1, release)

Medan tråd#2 gör detta

if (C.load(acquire) == 1) {
    print(B)
    print(A)
}

ARM64 har en speciell "store" operation som kallas "store-release". Den garanterar att alla minnesoperationer som hände innan denna kommer vara synliga av alla andra kärnor som gör en "load-acquire" och läser det nya värdet som lagras. Så load-acquire är den andra änden, det säger att om man läser det nya värdet som gjorts i en store-release till samma variabel så är man garanterad att alla efterföljande läsningar kommer se de värden i övriga variabler som skrevs innan store-release.

Kan låta komplicerat, men är exakt hur "lås" (mutex/binär-semaphore) fungerar i multitrådade program.

D.v.s. ARM64 är på instruktionsnivå en perfekt match till hur vi idag skriver multitrådade program som behöver dela data mellan trådar. x86 ger massor med garantier som i praktiken inte tillför något i majoriteten av fallen, men man kan inte ändra beteendet då det finns enstaka program som är beroende av hur x86 är specificerad att fungera.

Nästan 100 % fallen när program "fungerar" på x86, men får märkliga buggar vid lite udda tillfällen på ARM64 har programmet ett logisk fel av typen "data-race", men det råkar fungera i 100 % eller nära 100 % på x86 då den har så väldigt lite möjlighet att optimera ordningen för läsning/skrivning mot minne.

Och här sitter jag och kör macOS som huvudoperativsystem på alla mina datorer för att jag knappt står ut med det lappverk som Windows är Smaken är som baken dvs! Jag skulle snarare gissa på att bristen på andel av OS-marknaden beror på att du behöver hårdvaran också, vilket över lag ligger i det dyrare skiktet. Det finns inga direkt billiga Macar.