Ny emulator kör Steam och spel på RISC‑V-processorer

Mnja...

1) Effektiviteten ser inte ut att vara något att hurra över, när enbart Steam-klienten äter upp rätt mycket av SpacemiT X60n och dess 8GB RAM.

2) De flesta spelen fungerar inte alls eller är rejält tröga. Även i sammanhanget lättdrivna sådana som Stardew Valley. Se kompatibilitetslista här eller här (den senare listan (som är mer detaljerad och är vad den första baseras på) visar att det där med "working" är en sanning med modifikation, Crysis exempelvis benämns "working" men också "very slow").

Visst finns det många som ivrigt hejar på x86-arkitekturens död, av en rad anledningar, men alternativen är helt enkelt inte där än. Ekosystemet kring x86 är alldeles för omfattande för att bara byta ut rakt av, och emuleringen är som sagt inte där än på långa vägar. Varken vad gäller kompatibilitet eller effektivitet/prestanda. (Se listan/listorna ovan för tydliga exempel.)

ARM64 får väl ändå anses vara där ur det perspektivet. Med både högpresterande hårdvara och bra emuleringslösningar för x86(-64) för att möjliggöra en gradvis övergång.

RISC-V är ju däremot inte där ännu prestandamässigt för mer krävande applikationer. Vad jag förstår inte ens "native" än så länge, men kul att se att folk bygger på emuleringslösningar ändå.

Har personligen inte sett några solida exempel på bra "universallösningar" för x86 på ARM än heller, även om den utvecklingen onekligen kommit längre. Vissa tillämpningar fungerar ju bra, och för en del är det säkert gott nog. Men en del målar upp det som lite mer fantastiskt än vad det kanske i praktiken är på ett bredare plan.

Däremot enig i att det är kul att det testas och utvecklas. Om kompatibiliteten och effektiviteten/prestandan kommer så nära 100% att diffen blir mer eller mindre totalt försumbar hade jag varit intresserad - det har jag inte sett (än). Inte minst då jag gillar att använda mina datorer till allsköns blandade grejer, både gammalt och nytt.

Och att försöka pusha nya ekosystem... då får vi imo problemet som går att se i det där med nya "fantastiska" standarder som ska göra intåg - de blir en i raden som bara gör tillvaron bökigare på de flesta sätt. På pappret är det mycket som är superbra, men sen kommer den där förbannade verkligheten och ställer till det.

USB i allmänhet och USB-C i synnerhet kommer på tanke. Dyra kablar med en uppsjö olika specifikationer vad gäller vilken effekt och hastighet/specifikation/protokoll de klarar, med kortare maxlängd än tidigare revisioner... ja, allt blev ju så mycket enklare och bättre när man slapp vända kontakten och allt skulle ha samma anslutning. Heh. /end offtopic rant. ^^

Att det går segt kanske inte är så konstigt när det dels handlar om ett projekt som bara verkar vara ett par månader gammalt.

Men framförallt finns ju inga high-end RISC-V CPUer ännu. Denna SpaceMIT X60 verkar vara lite piggare än den Ky X1 som sitter i bl.a. Orange Pi RV2. Har den senare och konstaterat att den presterar på RPi3 nivå (Cortex A53). SpaceMIT X60 verkar jämföras som ett par tiotal procent snabbare än Cortex A55, så ~50 % än Orange Pi RV2 per kärna. Fortfarande långsammare än RPi4...

Där vi verkar få se high-end RISC-V först verkar vara inom "AI". Är ett gäng företag som jobbar på RISC-V baserade AI-system, de första borde börja hitta ut på marknaden snart (Nvidia kommer porta CUDA till RISC-V #20928932

Den optimala lösningen är ju att "allt relevant finns i 'native' version". Apple verkar anse att man är så nära detta att utvecklingen av Rosetta 2 ska upphöra med MacOS 2027 (men gissar att det blir kvar ett bra tag till, OpenGL stödet är kvar och det har varit EOL under många år).

Men både Rosetta 2 och Microsoft motsvarighet Prism har väldigt bra kompatibilitet. Det finns nackdelar, men för mer "normal skalär kod utan krussiduller" (rätt många vanliga program) är effektiviteten på nivån 75-90 % av "native".

Sen vore det väl trevligt med en öppen standard för CPU ISA som omväxling? x86 stöds i praktiken bara av två företag, ARM64 kontrolleras av ett enda företag men är i alla fall ett gäng företag som bygger CPUer.

Med RISC-V kommer det fortfarande finnas barriärer i form av patent i hur man implementerar kretsarna. Men finns inga barriärer för någon ny som har kunskapen att bara hoppa in att skapa sin egen produkt.

Problemet just nu är att RISC-V är rätt omogen även på Linux. Alla grundläggande saker fungerar, tillräckligt bra för att man ska kunna bygga enklare lösningar redan idag (har inga problem att ersätta vissa av mina RPi-projekt med Orange Pi RV2 körandes Ubuntu Server 24.04). Men det är inte lika smooth sailing som att köra på ARM64 eller x86_64 än ens i headless fall...

Just det specifika fallet verkar folk ha kört med gott utfall med Parallel desktop + ARM64/Windows. Så problemet där är nog långt mer "någon del av emuleringen av Windows fungerar sådär".

Rent generellt fungerar kombon Parallel desktop + ARM64/Windows rätt bra för spel som är tillräckligt gamla/enkla för att köra DX11 eller tidigare. DX12 stöds inte.

Rätt säker på att allt strul vi såg på Qualcomms Snapdragon X med spel var långt mer GPU-relaterat än relaterat till emulering av x86.

Utanför spel har dels Microsoft gjort ett förvånansvärt bra jobb med att få till "native" varianter på Windows (inte lika snabbt som på MacOS, men långt snabbare än man kunde vänta sig). Nu verkar Nvidia ha strul med sin plattform, men om/när den släpps tror jag spel kommer vara rätt mycket ett icke-problem så länge man kör Windows/ARM64 med Nvidia GPU.

Vidare är Windows 11 variant av Rosetta 2, Prism, väldigt kapabel. Har fungerat över förväntan och även prestanda är riktigt bra förutsatt att applikationen inte är tung användare av SIMD. Med SIMD fungerar det ofta ändå, men med rätt rejält perf-hit

Har dålig koll på WoW, men det finns väl ändå "native" på MacOS/ARM64 sedan flera år tillbaka?

Jag skulle vilja påstå att när vi på rätt kort tid gått från "det råder inget tvivel om att världens snabbaste CPU-designer oavsett om man ser till absolut prestanda eller perf/Hz är en x86_64" till att Intel/AMD nu slåss om 4:e platsen så finns en del frågor att ställa.

Apple, Qualcomm och numera även Arm har alla klivit förbi Intel/AMD sett till perf/Hz med hyfsad marginal. Apple är även förbi i absolut prestanda.

Under väldigt lång tid var det rätt mycket konsens runt "ISA spelar rätt liten roll för prestanda, enda som spelar roll är mikroarkitektur". Känns som det nu ändrats, för känns extremt osannolikt att Intel/AMD helt plötsligt skulle bli oförmögna att göra lika snabba mikroarkitekturer (per cykel) som 3 andra tillverkare.

Nu är ett upp till bevis för RISC-V, finns forskningspapper som hävdar att i teorin bör RISC-V kunna vara lika effektiv som ARM64 sett till perf/Hz. Om detta är ett ISA problem för x86_64 är det den tekniskt viktigaste orsaken att lämna x86_64 bakom oss vi någonsin haft.

Du får hålla isär vad jag tror kommer hända, har sagt många gånger att x86 inte kommer försvinna inom överskådlig tid.

Sen kan man hoppas på att ARM64 eller ännu hellre RISC-V tar fart även för desktop. Vilket jag personligen gör av rent tekniska orsaker, bryr mig inte om det är Apple, Qualcomm, Nvidia eller någon annan bara det blir progress!

Arm är lite som Linux, de dominerar allt förutom desktop (well, Linux dominerar även servers det gör inte ARM64 än)... Såg någon notis om att under 2024 såldes fler Arm-baserad CPUer än alla andra ISA sammanräknat. Det tror jag RISC-V kommer ändra på relativt snart då det går väldigt bra inom MCU där volymerna är väldigt höga.

PowerPC gjorde väl rätt bra ifrån sig i Xbox 360, PS3 och Nintendo Wii?

Min gamla PowerPC 604e på hela 180MHz i Amiga 4000 är fortfarande en av de roligaste CPU:erna jag ägt.

Om SpaceMIT och Ky X1 är samma CPU, vilket inte känns helt orimligt då båda stödjer RVA22 och båda har 2 TOPS "AI-prestand" känns lite optimistiskt att hävda ~1,3 * Cortex A55 prestanda...

Detta är vad Phoronix fix när det testade Orange Pi RV2, den är en bra bit efter RPi4 trots att RV2 har 8 kärnor och RPi4 har 4 samtidigt som Phoronix ofta har lite väl mycket saker som skalar nära perfekt med kärnor i sina tester.

Men samtidigt känns det då positivt att stabiliteten går åt rätt håll. Har testat en del Rust, Go och Python kod på min Orange Pi RV2. Den är ingen raket, men den har varit stabil. Det lilla jag testat I/O-headern har också fungerat väl.

Så RISC-V må vara omoget än, men det verkar gå åt rätt håll

Fast då borde du också veta att PowerPC må ha haft en del fördelar jämfört med x86, men dessa var inte väsentligt bättre prestanda för "normal heltalskod".

PowerPC hade fördelar som gjorde de väldigt populära inom flertalet embedded områden under lång tid. Flyttalsdelen var också bättre än x86 under lång tid, men PowerPC var egentligen aldrig bättre på heltal (och som Torvalds sagt flera gånger, att x86 länge sög på flyttal spelade rätt liten roll då det är lång mindre viktigt än bra heltalsprestanda).

PowerPC (och än mer MIPS) var typiska "RISC:ar" i att samma kod typiskt genererar fler instruktioner jämfört med motsvarande x86_64.

Vidare var det först runt 2010 som man började få en bra idé om lämpliga primitiver för multicore etc. PowerPC (och MIPS) visade sig missa målet där rätt ordentligt, mer så än x86.

Även här är ARM64 och RISC-V unika. De har nära nog perfekt match sett till multicore primitiver och de tenderar också generera färre instruktioner jämfört med motsvarande x86_64 kod, trots att en styrka hos "CISC" ska vara mer avancerade instruktioner. ARM64/RISC-V verkar ha mer "rätt" instruktioner för vad moderna kompilatorer vill ha.

Sedan verkar "killer feature" i ARM64/RISC-V ISA vara att man där fått ned längden på "critical path" i beroende kedjor mellan instruktioner. Är rimligen detta som gör att perf/Hz kan vara så väldigt mycket högre ILP jämför med alla tidigare ISA. Tog rätt många misslyckade försök med t.ex. VLIW, men tillslut verkar man lyckats hitta en förändring av ISA som är högst relevant.

VLIW har sina fördelar. Huvudtanken där var att man såg att allt mer transistorer lade på att förutsäga dynamiska beteendet hos program. Tanken med VLIW var att flytta detta jobb till väldigt avancerade statisk analys som gjordes vid kompileringstillfället.

Tankevurpan var att CPU-hastigheten och minnes-hastighet bara fortsatte att divergera, vilket gjorde att sådan man bara kan veta när man kör programmet, d.v.s. dynamisk information, blev allt mer värdefull. VLIW fungerar väldigt bra på kod med hög lokalitet och där det är hyfsat enkelt att bedöma beteendet, hyfsat vanligt i flyttalstung kod men tyvärr väldigt ovanligt i mycket av "normal skalär heltalskod" vilket utgör majoriteten av vanliga desktop-program.

VLIW var en därför en bra idé på GPU-sidan fram till att shaders blev allt för avancerade och dynamiska i sina beteenden. Dagens GPUer har gått mot att vara allt mer skalära i sitt beteenden. Nvidia är alltid noga att påpeka att deras GPUer idag kör SIMT, inte SIMD, huvudskillnaden är att den förra har skalära register per tråd medan den senare har vektor-register med en slot per "lane".

TL;DR på hela detta är att vi aldrig tidigare haft någon ISA som rätt konsekvent är bättre än x86_64. Vi har nu minst en, ARM64, och av allt att döma är även RISC-V en sådan. DET är den viktiga tekniska skillnaden att nu önska en så snabb sorti som möjligt för x86_64, för det är ett ankare samtidigt som vinster i kiseltillverkning inte längre kan gömma problem den vägen lika lätt.

Finns forskning som tittat på "om vi kör på en specifik frekvens, säg 2 GHz, och antar en oändligt 'bred' mikroarkitektur, hur snabbt kan då ARM64 resp. RISC-V köra ett gäng olika program".

TL;DR på den är att ARM64 är i det fallet den mer effektiva ISAn, så ur den aspekten är den "mer optimal".

Positiva är att RISC-V inte är så långt ofter + om man antar en begränsad ROB-storlek så var faktiskt RISC-V lika bra eller bättre (i genomsnitt) jämfört med ARM64 upp till en ROB på 500 steg (high-end ARM64 är >500 idag, M4 antas ligga på runt 800-850 men svårt att veta exakt). Arm Cortex X925 har en ROB på ~780 steg.

Är rätt nytt på så "feta" ROBs. Zen4=320, Zen5=448, Raptor Cove=512, Lion Cove=576.

Är också så att man får dimishing returns i att öka ROB i många (kanske de flesta) fall, vilket man ser i denna graf. Så inget man bara kan fortsätta skruva upp i alla oändlighet. Gissningsvis är det just här där x86_64 tappar mot ARM64 sett till perf/Hz, man har helt enkelt inte lika hög teoretisk ILP i en hypotetisk "oändlig bred mikroarkitektur".

Men teori all ära. Innan någon faktiskt byggt ett par "high-end RISC-V" och innan kompilatorerna för RISC-V når liknande mognadsgrad som x86_64 och ARM64 har idag är det svårt att säga exakt hur bra/dålig denna ISA står sig.

Helt uppenbart är att just kompilatorstödet går framåt. Tar man ett par år gamla GCC/Clang versioner fick rätt MIPS-likt resultat ställd mot x86_64 och ARM64, d.v.s. RISC-V krävde i genomsnitt fler instruktioner för samma program jämfört med de senare. Tar man senaste versionerna ser det betydligt bättre ut, ibland slår man även ARM64.

Rent generellt är RISC-V bra (färre instruktioner för att göra X) i kod med många villkorade hopp tack vare att det är en instruktion att "jämföra register X med register Y/I och avgöra om hoppet ska tas baserat på det". Både x86_64 och ARM64 kräver två instruktioner för det.

Men å andra sidan är x86_64 och ARM64 (som är väldigt icke-RISC-ig på denna punkt) mer flexibla i hur de kan genera adresser för att läsa/skriva minne.