ARM:s arkitekturer får högre prestanda, säkerhet och maskininlärning

Liten nit-pick: "I ARMv9 introduceras även den senaste versionen av tekniken Scalable Vector Exentions (SVE), som utvecklats i samarbete med Fujitsu."

SVE introducerades redan i ARMv8, men där hanteras det som en extension medan det är en del av grundspecifikationen för ARMv9.

Detta är väldigt likt hur NEON hanterades, det är ett valbart tillägg i ARMv7 medan det ingår som standard i ARMv8.

SVE blir spännande att se, det är förhoppningsvis en bättre design för framtida utökningar jämfört med hur SSE/AVX fungerar där man i praktiken måste definiera om alla instruktioner för varje bredd, d.v.s. så här långt för 128, 256 och 512 bitar.

I SVE stöds logiskt allt från 128 till 2048 bitar, så instruktionerna finns för alla varianter. HW skalas oberoende av det, är fullt möjligt att köra SVE i en telefon med endast 128-bitars fysisk bredd. En 2048 bitars instruktion tar då 16 cykler att köra om det tar 1 att köra med 2048 bitars HW.

SVE har redan visat hur väldesignat det är. Världens snabbaste superdator är ARM64 baserad (ARMv8.2A + SVE-utökning) och det har nått förstaplatsen utan att pumpa sin beräkningskapacitet med massa GPUer. SVE med lite större HW-bredd betyder i praktiken att man har en integrerad GPU i CPU!

Edit: nit-pick till det jag skrev ovan här... Som nämns i artikeln är det SVE2 som introduceras i ARMv9, verkar som om SVE2 lite blir unionen av NEON+SVE

Jag har väldigt lite förståelse för de exakta skillnaderna, men övergången till ARM är nog det mest intressanta som hänt i hårdvarubranschen det senaste decenniet. Inte bara en förbättrad teknik, men även nya tillverkare och marknadsstruktur.

HYPE.

Vad tror du om tex framtida graviton 3 kretsar ? Redan nu är arm 40 %effektivare , 20 lägre kost samt 20 prc snabbare om man tittar på graviton 2 hos aws

Intressant, men vem blir egentligen först ut med att släppa en entusiastplattform baserad på ARM? Tänker mig alltså något liknande AM4 eller LGA1200.

Sockelbar processor, upplåst för överklockning, etc. Samt så klart något slags avtal med Microsoft så att man kan köra Windows på plattformen i fråga (eller ännu hellre att de bara släpper ARM-Windows fritt retail...)

Den dagen det kommer, så är det ganska stor chans att jag hoppar på.

Vet inte om du läst denna artikel, detta sammanfattar rätt bra vad jag tror

"The Graviton3 will likely be based on ARM's Neoverse V1 architecture. As I wrote on my recent article titled "Intel And AMD: History Repeats - X86 Faces Obsolescence", the Neoverse V1 performance jump is so large that it's to be expected that the x86 world in general will face significant trouble. This trouble will be exacerbated in the server room."

AnandTech har skrivit tidigare om Neoverse V1. Deras spekulation om att Neoverse V1 blir först med ARMv9 stöd känns än mer sannolikt nu.

Neoverse V1 är rätt mycket servervarianten av Cortex X1, släktskapet kanske blir lite svagare än vad som är fallet mellan nuvarande Neoverse N1 som väldigt mycket är server varianten av Cortex A76.

Cortex X1 matchar inte Apples Firestorm, men det är ändå en mikroarkitektur som utför mer per cykel än både Zen3 och Cypress Cove. Inte alls säkert att ens Golden Cove kommer matcha denna i utfört arbete per MHz.

På serversidan har vi ju sett att de Neoverse N1 baserade servers som finns (N1 har ungefär samma prestanda per MHz som Skylake/Zen2) kan klockas högre jämfört med Intel/AMD när alla kärnor används. Just Graviton2 är ett undantag med dess väldigt låga 2,5 GHz klocka (ändå högre än vad viss x86 serverkretsar når i praktiken), Amazon ville få ned 64-kärnor under 100 W TDP, finns andra kretsar som klockar till 3,3 GHz med upp till 80 kärnor (128 kärnors varianter är på ingång).

Intel/AMD måste verkligen dra en kanin ur deras magiska x86-hatt om de ska fortsätta vara relevanta. De har lite kuddar (tack Microsoft), t.ex. att dotnet är rätt populärt och även om det fungerar redan nu på ARM64 lyckades folk ändå göra så mycket buggar som bryter mot VM-specifikationen för dotnet, men "råkar" fungera korrekt på x86. "Fixen" för detta leder tyvärr till att dotnet på ARM64 presterar något sämre än vad som annars vore fallet. Det är ett exempel, finns flera och sådant är ett hinder.

Molntjänsterna körs primärt på Linux, Linux är faktiskt större än Windows även på Microsoft Azure numera, så där är barriären väsentligt mindre än för Windows. Finns ändå lite saker som x86 gänget kan hålla fast sig i, t.ex. så ser OneAPI väldigt lovande ut och Intel har lagt massor med resurser på att få ut maximalt ur både x86 och deras kommande GPUer. Nu finns även ARM64 stöd, dock saknas så vitt jag vet SVE/SVE2 stöd (NEON stöd finns), vilket är ett problem då en av huvudnumren för OneAPI är att dra maximal nytta av SIMD (SSE/AVX på x86, NEON/SVE på ARM64).

På sikt lär Intel/AMD kunna hålla emot om det hela tiden kommer mer effektiva och snabbare ARM64 kretsar som i fallet Graviton2 också kostar mindre. Blir ju affärsmässigt vansinne för användarna att klamra sig fast vi x86 då.

32-bitars ARM != ARM64, de är två helt olika instruktionsuppsättningar.

32-bitars ARM är inte heller den en "traditionell" RISC, Arm är lite unik bland "RISC" CPUerna i att de har rätt komplexa instruktioner. RISC vs CISC är helt enkelt en rätt suddig klassning.

Rent generellt brukar RISC leda till fler instruktioner och större program jämfört med RISC. Vidare har de flesta RISC-varianter instruktioner av en fast storlek. Instruktioner för 32-bitars ARM kan vara 2 eller 4 bytes, och programmen är i princip alltid mindre än motsvarande x86_64 program.

32-bitars ARM har en stor designmiss: det som gör programmen väldigt kompakta är också något som gör det extremt svårt att bygga riktigt högpresterande CPUer.

64-bitars ARM, ARM64, rättar till misstagen. Där är alla instruktioner 4 bytes, programmen är inte lika kompakta som 32-bitars ARM, men fortfarande lika kompakta som x86_64 eller något kompaktare.

ARM64 tillsammans med RISC-V är de enda instruktionsuppsättningar som designas efter att man formaliserade saker som atomära instruktioner och andra saker relaterat till kodning av multitrådade program i programspråk som C, C++, Java m.fl. Man tog vara på den kunskapen och skapade en "perfekt" instruktionsuppsättning för dessa krav.

Så för egen del känns det riktigt surt att denna generations konsoler stannade på stenåldern. De hade definitivt kunna använda Cortex A77 och man hade mycket väl kunna få in Cortex X1. Det hade gett konsoler med högre absolut CPU-prestanda samt väsentligt mycket bättre prestanda/W. Lär väl hända nästa generation...

RPi4 är utrustad med fyra Cortex A72 kärnor. De gynnas överhuvudtaget inte av ARMv9 då de inte implementerar den specifikationen. Cortex A72 implementerar ARMv8.0-A.

Vad man kan göra med RPi4 är att välja en Linux-distro som använder sig av ARM64. Tror även Raspbian har ARM64 stöd numera, har själv kört ARM64 versionen av Ubuntu 20.04 på min RPi4 sedan release. ARM64 är så mycket bättre designad jämfört med 32-bitars ARM att man kommer få bättre prestanda, hur mycket varierar från fall till fall men 10-30 % högre prestanda kan man nog förvänta sig.

Apple M1 är baserad på ARMv8.4-A, innebär det att nästa generation kommer ha ytterligare +30%?

Hoppas alla i framtiden kan köra vilken arch dom vill. Alla program är LLVM IR, som byggs specifikt för ens processor och extensions innan exekvering.

Grejen är: M1 kan inte köra x86_64 kod! Rosetta 2 gör flera saker, men den största och viktigaste är att den tar ett x86_64 program och binäröversätter detta till ett logiskt motsvarande ARM64 program.

Det blir tyvärr inte lika effektivt som att kompilera direkt från källkod till ARM64 kod, men det coola är att vissa tillkortakommanden hos x86_64 kan lindras då det är rimligt att göra mer avancerad statisk analys på x86_64 än vad som är möjligt i en CPU som måste fatta rätt många beslut på (sub)nanosekund nivå.

Vad M1 verkar ha (Apple har inte officiellt sagt att det är så, men allt pekar på att så är fallet) är stöd för att på HW-nivå köra samma minneskonsistensmodell som x86_64.

Den modell som x86_64 använder är mindre effektiv än den ARM64 använder för multitrådade program, problemet är att om ARM64 modellen används för x86_64 minnesoperationer så har man nästan garanterat introducerat data-race! Är logiskt fullt möjligt att implementera x86_64 modellen inom ramen för ARM64, är så Microsoft gör i deras x86_64 "emuleringslager" (rent tekniskt är det binäröversättning även där, inte emulering).

Rosetta 2 sätter M1 i x86_64 modellen (som kallas TSO) när den kör kod som översatts från x86_64, annars kör den en mer effektiv ARM64-modell.

Rätt säker att x86_64 lägret redan lurat på om något i ovan inkräktar på någon IP, men de lär får svårt att hitta något i HW just p.g.a. att CPUn kör faktiskt endast ARM64 instruktioner. TSO är en gammal och välkänd modell, långt ifrån unik för x86.

På ett sätt är det sant att Windows också är i en övergång. På många kritisk sätt är det milsvid skillnad mellan vad Apple gör och vad Microsoft gör. Apple har gjort helt klart: ARM64 är framtiden och vill man vara relevant på MacOS måste man erbjuda "riktiga" ARM64 binärer.

Microsoft har rudimentärt stöd för ARM64, "ingen" vågar i nuläget satsa sitt företags framtid på att ARM64 på Windows kommer bli stort.

Att göra en Rosetta-klon lär vara hyfsat komplicerat p.g.a. alla udda-fall som måste hanteras. Det positiva är ändå att grovjobbet med att översätta x86_64 instruktioner till ARM64 finns i LLVM (är det Rosetta 2 använder och skulle bli förvånad om Microsoft inte bygger sin lösning på den tekniken). LLVM är öppen källkod med en "företagsvänlig" licens, d.v.s. det är inte GPL utan Apache License 2.0.

Evolution kan inte jämnföras med människors system. Vore det evolution skulle intel och amd blivit uppätna, större risk att dom går ihop eller tillverkar en egen arm cpu. Det sker inte i naturen eftersom där tar små steg flera miljoner år. Sen har vi att vissa företag kan släppa en produkt helt och göra nått helt annat.

Kul att arm sätter lite press på marknaden.

Rent affärsmässigt: vad är poängen/fördelen med Linux på desktop?
Har själv väldigt svårt att se någon direkt fördel. Allt för få gör något superkrävande på skrivbordet och samtidigt har Windows blivit betydligt bättre, är egentligen bara nätverksprestanda samt allt runt Cgroups och namespace isolation (det "container-tekniken" bygger på) där Linux är helt överlägset Windows.

Läser man Linux-trådarna här på SweC är en väldigt vanligt fråga: hur kör jag spel (som är primärt designade för Windows) under Linux. Men sådana krav är det kontraproduktivt att gå ifrån Windows.

För mig var den sista spiken i kistan för Linux som ett mainstream OS på skrivbordet när Apple börjar gå riktigt bra. Huvudpoängen med Linux på skrivbordet är att ha en UNIX-baserad miljö med lysande skrivbordsstöd. OSX/MacOS löste det, samtidigt som man alltid haft det företagskritiska stödet från MS Office, program för bild/filmredigering och annat som Linux aldrig haft. Idag har vi även WSL2 på Windows.

Kollar vi däremot på områden Linux har lyckats, vilket är typ de flesta förutom desktop, kan man ställa frågan: varför har det gått så bra där? Linux total-dominerar "molnet", orsaken är det med råge är den bästa tekniska lösningen. Till och med på Microsoft Azure är Linux det dominerande OS:et, har själv väldigt svårt att se varför någon skulle vilja plåga sig sig själv med Windows i sådan miljöer.

Apple har inte ens försökt göra en MacOS lösning av "containers", kör man Docker på MacOS är det Linux som körs i alla containers.

M1 får Intels/AMDs nuvarande produkter att te sig patetiska på laptops, just nu är Apples bärbara både snabbare och billigare än produkter i motsvarande segment på Windows-sidan. Om/när något med samma tekniska överlägsenhet blir tillgängligt för Windows är affärsvärdet uppenbart, förutsatt att det faktiskt finns stöd på Windows. Idag skulle det inte hjälpa om M1 kunde köra Windows (vilket jag tror är möjligt numera), Microsoft har inte gjort det som krävs för att ARM64-stödet ska vara bra nog.

Tekniken finns redan, finns också väldigt rykte att Microsoft själva jobbar på en ARM64 lösning men den kan eventuellt bara rikta sig på server/moln-sidan. Det hade varit fullt möjligt att släppa en Cortex X1/A78 krets designad för Windows-laptops i slutet av Q4 2020, hade inte matchat M1 men hade ändå varit bra nog att slå allt som Intel/AMD har på marknaden. Får se om man tar chansen i år, Cortex X2 kommer antagligen lanseras i maj i år och i så fall är det realistiskt för Microsoft att ha en krets ute till slutet av året om man verkligen vill satsa.

Stationära kommer ha lägst prioritet, det är en sådan försvinnande liten del av marknaden. Men om man satsar på bärbara och servers kommer även stationära följa med tids nog.

Om Torvalds har rätt, vilket jag tror han har, om vilken fördel det är att köra samma ISA på desktop som för de system man utvecklar programvara mot finns en väldigt stort affärsvärde för Microsoft att få till ARM64 stödet på Windows: ARM64 dominerar redan på mobilerna, ARM64 dominerar högre segmentet för inbyggda system (32-bitars Arm dominerar de lägre) och allt mer pekar på att ARM64 kommer växa rejält på server/molnsidan. Endera fixar de bra ARM64 stöd på Windows eller så tvingas utvecklarna till MacOS!

Redan idag är MacOS långt mer populärt bland utvecklare än vad det är på marknaden i stort, iOS är en viktig del där. Balmer hade kanske inte rätt i allt han sa... men en sak han ofta pekade på var nog helt sant: Windows framgångar har väldigt mycket kommit från att Windows (mycket tack vare Visual Studio) tidigt blev utvecklarnas mest populära OS. Tappar man den ledartröjan har man ett stort problem. Saker som WSL2 är ett genidrag, Linux har redan "vunnit" molnet, WSL2 gör det möjligt ändå köra allt "native" på sin Windows-burk, i alla fall fram till att även ARM64 blir ett krav.

Hur kan jag läsa artikeln du länkar, den är ju bakom pay-wall?

Det jag primärt baserade mitt påstående på är vad jag sett under de ~20 år jag jobbat med inbyggda system, varav 15 som arkitekt för ett OS som stödjer x86, x86_64, ARM, ARM64, MIPS och PowerPC.

Testa gärna själv och experimentera med Compiler Explorer, där är det enkelt att se resultatet för kodsegment i en rad olika kompilatorversion och CPU-arkitekturer.

Här är två exempel (båda C++ program) kompilerade med GCC version 10, alla med "-O2" optimering och "-static" (så man får "self-contained" binärer helt utan beroende på externa bibliotek)

Andra sätt är att t.ex. jämföra storleken på binärer mellan en viss version av Ubuntu för Arm, AArch64 och x86_64. 32-bitars Arm är rejält mycket kompaktare än de andra, AArch64 och x86_64 brukar ligga rätt nära varandra.

Men det finns aspekter som är långt viktigare, något som t.ex. denna rapport belyser (ej bakom pay-wall).

Detta är vad 32-bitars Arm saknade och vad som gör ARM64 (AArch64) unik

ARM64 ställer helt devisen "RISC har färre och enklare instruktioner" helt på huvudet, i alla fall när man tittar på hur program faktiskt skapas idag: via språk på högre nivå än assembler som kompileras till maskinkod. Ett typiskt program tar färre instruktioner på ARM64 än andra ISA, just den punkten var svagheten hos tidigare RISCs ställd mot x86.

Man noterar också att x86 är "over-serialized", d.v.s. den har lägre ILP (instruction level parallelism) jämfört med ARM64. Kort och gott, en viss mikroarkitektur kommer prestera bättre med en ARM64 front-end jämfört med en x86_64 front-end.

Just "over-serialized" är 32-bitars Arm stora svaghet. Det som gör koden så extremt kompakt har tyvärr också bieffekten att instruktioner har extremt mycket beroende mellan varandra -> det var rätt hopplöst att designa 32-bitars Arm CPU som matchade x86 i prestanda. Det lär varit huvudanledningen att Arm valde att designa ARM64 från scratch i stället för, som i princip alla andra, utöka den existerande 32-bitars ISAn till 64-bit.

Den effekten kan studeras med t.ex. RPi4 då den stödjer både ARM och ARM64. Samma program är i praktiken alltid snabbare om det byggs för ARM64, hur mycket varierar rejält beroende på vad som är primär flaskhals. NEON optimerade program ser typ ingen skillnad då flaskhalsen är flyttalskapacitet, medan extremfallen kan visa på upp till dubbla prestanda. Känslan jag fått är att man ser ~20-30 % högre prestanda enbart från ISA, då är Cortex A72 knappas något som utnyttjar all inneboende ILP i ARM64 då det är rätt "smal" design.

RISC-V kan vara lika bra som ARM64 på ILP punkten, men svårt att vara säker innan det finns faktiskt produkter med bredd likt Apples Firestorm.