Wall Street Journal: "Nvidia mycket nära att köpa ARM"

Det är tyvärr en rätt inkoherent härva att reda ut vad "Arm" exakt är, namnet används för vitt skilda saker.

"Arm" borde egentligen bara referera till företaget som eventuellt Nvidia kommer köpa. Ett företag vars huvudsakliga produkter är

• specifikation för idag tre separata instruktionsuppsättningar: A32, T32 samt A64

• sälja specifikationer för CPU-design (Cortex A/R/M), designer som företag som Qualcomm, Samsung, Mediatek, m.fl. licensierar och stoppar in i sina kretsar

• sälja specifikationer för GPU-design (Mali), designer som precis som CPU-designern kan licensieras av kretstillverkare

Det som ofta faller bort när Arm ställs mot x86 är just att Arm har flera instruktionsuppsättningar. De misslyckade försöken att ta sig in på server- och desktopmarknaden har gjorts med A32, d.v.s. Arms 32-bitars instruktionsuppsättning med rötter från 80-talet. Orsaken att man misslyckades var flera, på serversidan var hela idén att gå in med en 32-bitars design när övriga redan gått över till 64-bit ett bombsäkert sätt att idén var DoA.

På desktop föll det på att man enbart kunde pusha "bra perf/W". Perf/W är absolut inte irrelevant, framförallt inte för bärbara datorer. Men prio #1 för desktop är (och lär förbli under överskådlig framtid) hög absolut enkeltrådprestanda. Ingen A32 design kan mäta sig med moderna x86 från AMD/Intel på denna punkt. AMDs framgång med Ryzen beror inte primärt på att man har femtielva kärnor, det är att man har en design som helt kan mäta sig med Intels bästa i prestanda per kärna (80:20 regeln, för 80 procent är fler än en handfull kärnor meningslöst i praktiken då allt de gör använder 1-2 kärnor).

A64 är en distinkt ISA, den har ungefär lika mycket att göra med A32 som RISC-V har att göra med MIPS. Faktum är att RISC-V är mer lik MIPS än vad A64 är lik A32.

A64 är specifikt designad för

• förenkla så mycket som möjligt att skriva kompilatorer, "ingen" skriver längre kod direkt i assembler. x86 innehåller en brutal mängd instruktioner som i praktiken är värdelösa för kompilatorer, moderna x86 program använder typiskt några enstaka procent av alla instruktioner som finns av bakåtkompatibilitetsskäl

• maximera ILP, det går inte att öka frekvensen på något relevant sätt. Ingen instruktionsuppsättning innan A64 och RISC-V har egentligen hårt optimerat för att man ska kunna maximera ILP, x86 har en rad designbeslut som försvårar extraktion av ILP. A32 är rent vansinnigt designad om man är ute efter hög ILP!

• optimera för multicore. CPUer med flera kärnor är ett rätt nytt påfund, även om tekniken i sig funnits sedan 60-talet (vad hade inte IBM gjort redan på 60-talet?) så blev det populärt långt senare. Var först i slutet av 90-talet man insåg att interaktionen mellan trådar i program måste formaliseras, Java var först med detta (och tog ett par misslyckade försök innan man fick till något). Ingen ISA som designats innan programspråken började designa kring detta har minneskonsistensmodeller som på HW-nivå matchar vad man i slutändan kom fram till är den mest optimala modellen (används av Java, C#¹, C, C++, Rust, Go, Swift, m.fl.). ARMv8² och RISC-V är enda som har en perfekt match på ISA/HW-nivå mot vad som idag faktiskt används i de populära programspråken

T32 används primärt i ARMs Cortex M serie, är det enda som stöds där. Cortex A/R stödjer också T32 men används sällan då T32 må ge kompaktare program, men det är på bekostnad av hastighet programmet typiskt körs med ställt mot A32. A32 är redan det kompaktare än i princip allt annat utom möjligen RISC-V med "C" extensionen (RISC-V med compress extensionen är väldigt likt hur T32 fungerar för ARM, fast bättre designat).

¹ C#/.NET är ett exempel på problem man kan få när något i praktiken bara används på en enda ISA. Enligt specifikation hos C# har det samma minneskonsistensmodell som de andra, men när man väl började köra på A64 insåg Microsoft att en allt för stor andel av existerande program hade likartade buggar som "råkar" fungera på x86 just då den ger vissa garantier som man ansåg vara onödiga i modellen man valde (kostar prestanda och i >99 % fallen behövs det inte) . Lösningen blev att man fick fixa samma garanti även på ARM, något som tyvärr betyder att C#/.NET program är mindre effektiva på ARM än de borde vara

² Ännu ett exempel på hur komplext "Arm" är... ARMv8 specificerar A64, A32 och T32. En sak man ändrade mellan ARMv7 (som saknar A64 stöd) var minneskonsistensmodellen. Arm råkade kunna fixa detta även för A32/T32 utan att paja bakåtkompatibilitet då ARMv7 ger för lite garantier i frånvaro av explicit synkronisering, för x86 kan man inte fixa det utan att bryta bakåtkompatibilitet då man idag ger för stora garantier.

POWER ISA lanserades initialt 1990. IBM gjorde ett väldigt bra jobb, PowerPC (som initialt var en nedskalad variant av POWER, senare slogs de ihop igen) var ju under många år en favorit bland de som jobbade med högpresterande inbyggda system just då saker var så logiskt designade jämfört med i princip allt annat.

Men POWER är inte lika optimal för dagens krav som A64, bl.a. lider det av det som alla tidiga RISC (med undantag för A32/T32) led av: det krävs fler instruktioner med större kodsegment som följd att beskriva samma program i maskinkod jämfört med x86.

Just att A32 och än mer T32 inte alls passar in i den modellen visar att RISC/CISC aldrig varit en bra uppdelning. Bättre att prata om "store/load" vs "inte store/load" (också kallat "register/register" vs "register/memory") designer. x86 är en typiskt "register/memory" design, POWER och A32 är båda "register/register" designer, men A32 (och A64) är väldigt CISC:iga när det kommer till sätten man kan refererar minne på samt hur man kan sätta upp och ta ned kontext i programfunktioner.

POWER är bättre än x86 på vissa saker, sämre på andra. I praktiken har det aldrig funnits någon fördel för POWER över x86 sett till prestanda vare sig för desktop eller servers. Länge var nog hela branschen övertygad att Intels käpphäst "enda som spelar roll är mikroarkitektur och mikroarkitektur är till stor del frikopplad från ISA" var helt korrekt.

A64 har med förödande tydlighet visat att med fokus på rätt saker kan ISA spela väldigt stor roll. Endera det eller så måste både Apple och Arm ha ingenjörer som spelar i en helt annan liga än resten. Hur förklarar man annars att Apple har en CPU som utför ~80 % mer per cykel jämfört med Skylake/Zen2 på ungefär samma transistorbudget medan Arm har en design som utför 50-60 % mer per cykel jämfört med Skylake/Zen2 på ungefär halva transistorbudgeten?

Går se viss del av den effekten på RPi4, även om Cortex A72 inte alls är kapabel att dra full nytta av den extra ILP som A64 erbjuder över A32. Kompilerar man samma program för A32 och A64 kommer det senare typiskt köra 0-50 % snabbare på samma CPU bara genom att gå från A32 till A64 (exakt hur stor vinsten blir beror väldigt mycket på vad programmet gör). Det är inte något som man bara ser för att A64 har 64-bitars register, i sådana fall är vinsten typiskt närmare 100 % men samma gäller ju även mellan x86 och x86_64 där.

POWER saknar också den perfekta match mot minneskonsistensmodeller i programspråk som ARMv8/RISC-V har.

Tyvärr saknar RISC-V vissa av egenskaperna hos A64 som visat sig väldigt användbara när kompilatorer genererar kod. A64 möjliggör i många lägen kod som saknar hoppinstruktioner i fall likt dessa

int foo(int a, int b) { return a < b ? a * b : a - b; }

d.v.s man testar något, om det är sant görs något rätt enkelt om det är falskt gör något annat rätt enkelt. Väldigt vanligt förekommande i kod. Det är möjligt att även göra detta utan hopp både på A32 och x86, dock på ett sätt som är mindre effektivt än A64 (svårare att extrahera ILP), för x86 verkar gcc och clang vara oense om vad som är optimalt här (gcc hoppar medan clang inte gör det, värt att nämna är att gcc typiskt är något snabbare i heltalsintensiva program för x86 men är väldigt liten skillnad och inte alltid sant).

Rimligen lär Nvidia fortsätta utveckla kretsar med Arm CPUer i, enda poängen jag kan se med att köpa Arm är att kunna styra fokus för framtida Arm CPUer. Nvidia lär accelerera fokus på riktigt högpresterande CPUer riktade mot servers och bärbara datorer.

Samtidigt vore det rent korkat att skrämma iväg nuvarande kundbas för Arm. Är därför inte alls osannolikt att Arm behålls relativt separat från övriga Nvidia. Visst kan man se problem med att Nvidia då kan använda Arm utan licenskostnad, men det är en relativt marginell kostnad sett till BoM på en hel produkt samtidigt som licenskostnaden faktiskt ska täcka den FoU som man själv slipper göra genom att licensiera färdig IP.

Finns ju en hel del mervärde Nvidia skulle kunna erbjuda på rätt kort sikt, som t.ex. fixa stöd för CUDA och all den programvara som bygger på CUDA (vilket är en helt del, framförallt på serversidan men allt mer också på klientsidan) även för Mali. Man kan i.o.f.s. tänka sig att Mali (Arms GPU) skulle ryka direkt, men tror Nvidia istället kan vidareutveckla den då fokus där är annorlunda än för deras Geforce linje. Bara en sådan sak som att Mali är en TBDR design gör den långt mer lämplig för batteridrivna enheter än Geforce.

Det om varit unikt hos x86 är det utbredda stödet i utvecklingsverktyg och mängden väloptimerade bibliotek. Det var något Arm hade insett redan innan man lanserade A64 2011, så man har lagt väldigt mycket resurser på att få liknande stöd för A64. Arm själva hade aldrig kunnat matcha allt det jobb som plöjs in i x86, att det ändå gått så extremt samt beror väldigt mycket på att Apple och Google plöjt in enorma resurser p.g.a. deras intresse i mobilmarknaden. Nu har även Amazon börjar använda sin gigantiska kassakista för A64 optimeringar riktade mot datacenter.

Där ligger RISC-V stora dilemma just nu, man är inte närheten mognadsgraden i OS-stöd, kompilatorstöd och specifika optimeringar i bibliotek som A64 och x86_64. Så även om man delar nästan alla fördelar med A64 sett till "modern ISA" så ligger man efter på en väldigt kritiskt punkt. Arm har dock redan uppförsbacke på de billigaste kretsarna, mikrokontrollerns med RISC-V har börjat tagit fart och där blir verkligen Arms licenskostnad ett problem, 32-bitars RISC-V baserade mikrokontrollers ligger prismässigt på vad man tidigare såg hos 8-bitars mikrokontrollers!

På sikt lär därför RISC-V slå ut Arm på low-end, fast undrar om Nvidia bryr sig speciellt mycket om Cortex M. Risken på lite längre sikt är i.o.f.s att saker brukar komma underifrån. Arm har växt sig därifrån, x86 började ju sina dagar som ett lågpresterande budgetalternativ till de snabba RISC-arna (se 80- 90-talet).

Om man ska tro det jag läst om Apple och Arm så ska Apple ha en s.k. "perpetual license" för A64. D.v.s. de har en licens som gäller i alla oändlighet. Det kan förklara varför Apple inte såg något värde i att själva köpa Arm, Apples affärsmodell är inte att designa och bygga kretsar eller i Arms fall en design som kan realiseras i en krets av andra.

Är egentligen inte en perfekt match för Nvidia heller, det är ett företag som säljer färdiga GPU-kretsar. Man säljer däremot inte sin design till andra. För Nvidia misstänker jag att man primärt vill åt möjligheten att styra utvecklingen för framtida Arm CPUer, Arm visade med Neoverse N1 att man är fullt kapabel att designa servers som i sin v1.0 var fullt konkurrenskraftig mot AMD/Intels senaste toppmodeller.

Tror vi om någon månad, när Qualcomm och Samsung börjar få ut sina Snapdragon och Exynos kretsar, också kommer se att Arm numera också har något som mer liknar vad Apple har för konsument CPUer. Då lär de första kretsarna med Cortex X1 hitta ut och förväntad prestanda är att nå ungefär dit Apple låg med A12, d.v.s. utföra 50-60 % mer per cykel jämfört med Skylake/Zen2.

Redan med Cortex A76 (lanserad 2018) nådde Arm samma prestandanivå som x86 sett till prestanda per Hz. För att maximera energieffektiviteten har varken Arm eller Apple byggt kretsar som kan klocka speciellt högt, designen toppar runt 3 GHz. Så Qualcomms/Microsoft SQ1, som bygger på Cortex A76, kan inte riktigt konkurrera med AMD/Intel då man hamnar för långt efter i enkeltrådprestanda p.g.a. lägre peak-frekvens. Cortex X1 "löser" problemet tack vare långt högre IPC än Cortex A76.

På serversidan är frekvensen redan ett icke-problem, där klockar faktiskt Amperes Altra (företaget som tillverkar Neoverse N1 baserade ARM-servers, inte Nvidias GPU) redan högre än AMD/Intel när alla kärnor jobbar. Altra toppar på 80 kärnor @ 3,3 GHz (modell med 128 kärnor på väg ut under Q4) medan AMD/Intels toppmodeller åker ned under 3,0 GHz sträcket när CPUn är fullt lastad, så där räcker N1 till trots att den "bara" har likvärdig prestanda per Hz.

Om förväntningen är att denna affär ska presenteras "i början av kommande vecka" känns det lite som man siktar på måndag, det skulle väldigt mycket förklara varför Nvidia i så fall sköt på Ampere embargot. Man vill slå upp detta rejält om det händer.

Skrämmande nyhet.
Nvidia arbetar för slutna system och motarbetar öppna standarder.

Tja, Arm har aldrig varit en öppen standard så just den delen passar ju som hand i handsken då!

Så vad är skrämmande? Har hört ett talesätt relaterat till förhållande till teknik som nog passar väldigt väl här:

"Var passionerad, men bli inte förälskad"

Känns som många är förälskade i vissa företag. Man ska undvika förälskelse (i kontext av teknik) då kärleken är blind!

Har inget känslomässigt band till något av dessa företag (har tyvärr också sålt mitt innehav både i AMD och Nvidia innan de nådde dagens crazy-nivåer), är inte alls övertygad att Arm faller i händerna på Nvidia eller att om nu Apples kommande Mac CPU är så bra jag tror den är på något sätt skulle vara "optimalt för oss konsumenter på lång sikt".

Men ser inte varför jag på något sätt skulle undvika att köpa dessa produkter om de råkar vara det som ger mig mest värde för stunden!
På lite kortare sikt ser jag båda händelserna som något positivt, vi har kört fast sett till CPU-prestanda och allt som kan påskynda en övergång från x86 till A64 kommer ge en relevant boost i prestanda (på ett sätt som är relevant för 80-delen av 80:20 regeln).

På länge sikt borde det rimligen även kunna ge andra insikten att man ibland måste ta ett steg tillbaka för att kunna nå längre än där man stod. Risken är i.o.f.s att det inte finns så många med resurser att utmana A64, i alla fall inte om Nvidia faktiskt sköter Arm-delen på ett sätt som inte skrämmer iväg existerande kunder.

Så kanske är just Nvidia som borde äga Arm om man tror att det leder till att existerande kunder väljer något annat! I alla fall om man är någon som skådar väldigt långt in i horisonten. Själv ville jag ha snabbare kretsar igår

Du får gärna förklara detta lite mer. Jag har svårt att se logiken i ditt påstående. Tittar man på deras balansräkning så verkar det inte vara helt tomt i ladorna så att säga.

Det vore en katastrof för branschen om nVidia köper ARM. Hoppas verkligen inte att det händer.