ARM är lite av en mess när det kommer till "vad är kompatibelt med vad...". ARMv7, v8, v9 refererar till ISA-specifikation och från ARMv8 finns två helt separata ISA med i specifikationen.
För OS är det primärt ISA-stöd som måste till, Android stödjer för närvarande både 32-bit ARM och ARM64. Allt fler high-end ARM CPUer har börjat droppa stöd för 32-bit ARM (Apple gjorde det tidigt, Cortex X2 saknar också 32-bitars stöd).
Ur den aspekten är RISC-V mer likt x86. Det 32-bit och 64-bit använder samma instruktionsuppsättning, OS-kärnor som stödjer 64-bit kan också hantera 32-bit applikationer.
Tyvärr är det inte bara en stor sak att lägga till bra stöd för en ISA, det är ett gigantiskt jobb!
Att få till grundläggande stöd i för en instruktionsuppsättning är i sammanhanget trivialt. RISC-V har sedan länge sådant stöd i kompilatorer samt standardbibliotek i C och C++ (som möjliggör enklare OS och IoT). RISC-V har också relativt moget stöd i Linux-kärnan.
För mer avancerade applikationer, som t.ex. de som används i HPC, krävs enorma investeringar för optimering av bibliotek och mer avancerade utvecklingsverktyg som kan utnyttja specialfinesser som vektorenheter. Rätt får företag som har något vidare track-record att lyckas på den delen, är egentligen bara Intel (x86 SIMD), Nvidia (CUDA) och Apple (Metal (GPU) och Accelerate(CPU-acceleratorer)) som har lyckats riktigt bra.
Ställer man x86 SIMD mot CUDA ser man att Intel har misslyckats rätt ordentligt på en punkt när det kommer till designen: varje gång man "breddar" SIMD (SSE->AVX->AVX-512) blir direkta vinsten i existerande programvara noll, medan program skrivna i CUDA i princip alltid ser en väldigt bra skalning till nya "bredare" designer utan att programmet ändras.
Upp till ARMv8 kallas SIMD stödet där för NEON (SVE är en valfri utökning till ARMv8), det har tyvärr samma fundamentala problem som AVX. Skillnaden här är att ARM verkar insett begränsningen och därför aldrig brytt sig om att bredda instruktionerna (NEON är fortfarande 128 bit även i ARMv9, SVE2 är skalbar från 128-bit till 2048 bit).
Det RISC-V har och ARM64 fått med ARMv9 är en SIMD design som kan skala existerande program likt hur Nvidia kan skala med CUDA. Så vad man i praktiken kan göra med dessa vektor-instruktioner är att bygga in en GPGPU-del i CPU som kan skalas på samma sätt som GPUer.
Fördelen med "integrerad GPGPU i CPU" för HPC är att vissa problem behöver har både skalära delar (hanteras bäst av CPU) och data-parallella delar (hanteras överlägset bäst med GPGPU), om dessa delar sker väldigt ofta blir latens mellan skalär-delen och vektor-delen kritisk, dGPU blir då en rejäl flaskhals p.g.a hög latens över PCIe (eller motsvarande).
Så här långt har inte RISC-Vs vektor-design visat att den fungerar även i praktiken. ARM har med sitt SVE (Scalable Vector Extension, deras "nya" SIMD design) genom Fugaku som var världens snabbaste superdator i två års tid (den har rätt nyligen blivit förpassad till plats 2).
Men givet att RISC-Vs vektor design konceptuellt är rätt likt SVE (som för övrigt förbättrades innan det integrerades i ARMv9, SVE2) pekar mycket på att det kommer bli bra. Intel har massor med bibliotek (framförallt OneAPI och specifikt MKL) och kompilatorer (för SIMD har de ISPC) som om de även fixar RISC-V stöd för snabbt kommer lyfta den ISAn till "riktigt bra för tunga beräkningar".
Skrivet av BMac:
"En superdator av zettascale-klass utför en triljard flyttalsoperationer per sekund vilket motsvarar beräkningskraften i drygt 25 miljoner Geforce RTX 3090 Ti exempelvis."
För en jämförelse mellan valfri modern x86 istället för ett spelkort fungerar ju inte?
För den typ av problem som är riktigt beräkningstunga börja CPUer bli lite passé (t.ex. vid presentationen av Ryzen 7000, hur är det relevant att man råkar vara tiotals procent snabbare än någon annan CPU i Blender när dagens GPUer är 10-30 gånger snabbare, avståndet lär öka än mer i höst med nästa GPU-generation).
Ett 3090Ti är typiskt tiotals gånger snabbare än 12900K/5950X inom dessa områden, så bara göra matten själv
Men som redan nämnts: jämförelsen mot GPU är i detta fall mer relevant då RISC-V och ARM64/SVE designmässigt mer lik en CPU med integrerad GPGPU del.
Skrivet av nick-li:
Går snabbare framåt för Risc-V än jag hade förväntat mig men har svårt att tro Intel kommer hålla sig till någon helt öppen arkitektur eller ISA.
Tror vi kommer se plattforms-inlåsningar till någon del.
RISC-V har en fri specifikation för själva instruktionsuppsättningen. Finns inga restriktioner på att mikroarkitekturen för kretsar som använder RISC-V ska vara öppen.
En farhåga som vissa lyft med RISC-V är att standarden har explicit stöd för "vendor specific extensions of ISA". Tror själv den farhågan är ogrundad, det är inte värre än vad vi idag sett hos x86 de senaste 20 åren. Finns en lång rad extensioner i x86 som accelererar specifika saker, de flesta extensioner finns i de senaste modellerna men är inte så att senare modeller alltid har alla extensioner från tidigare modeller (ovanpå det finns lite variationer mellan Intel och AMD).
Man får lösa det som på x86: några enstaka fall måste ha extensionerna, de fungerar då bara på specifika CPU-modeller. Majoriteten av alla fall kommer använda bibliotek som dynamiskt kollar vilka extensioner som finns och använda extensionerna när det finns en poäng.
ARM "löser" detta problem genom att i stort sätt förbjuda egna utökningar (finns dock ibland specifika utökningar från ARM som är valfria att lägga in, exempel är SVE i ARMv8, SVE2 är standard i ARMv9) från den version man licensierar (sedan ARMv7 är varje ny version ett strikt superset av versionen innan -> förenklar en hel del på programvarusidan).
Finns spekulation att Apple möjligt har ett undantag i form av någon matris-acceleration i M1/A13, men det verkar som det egentligen handlar om ett separat block som likt iGPU och NPUer är hjälpkretsar som råkar vara tight integrerad med CPU (så låg latens, effekten blir liknande den man skulle få genom att direkt utöka ISA).
