Qualcomm: Spel ska funka utan portning på Snapdragon-datorer

Hade någon av ARM64 tillverkarna lagt in möjlighet att direkt avkoda och köra x86-kod hade vi med 100 % säkerhet sett en stämning.

Det både Microsoft och Apple gör är samma sak: man översätter x86_64 koden till ekvivalent ARM64 kod, det som sedan körs är ARM64 instruktioner. Detta är långt mer effektivt jämfört med emulering och undviker patentproblematik då ingen x86_64 baserad teknik behöver läggas in i CPUn

Det enda Apple lagt in i "Apple Silicon" och som jag tror vi kan förutsätta Qualcomm kommer lägga in i Snapdragon X Elite (givet att det är samma person som är arkitekt bakom båda designerna) är stöd för minneskonsistens-modellen i x86, TSO.

TSO är mindre effektiv jämfört med modellen ARM64 normalt använder, så det används bara när man kör översatt x86_64 kod. Men är mer effektivt att implementera TSO i HW jämfört med att implementera det med ARM64 instruktioner. TSO är en välkänd teknik som används sedan länge och används av långt fler än x86.

Tror att det Qualcomm säger här kan stämma bra även i verkligheten. Kör ARM64 versionen av Windows 11 (på en M3 Max via Parallels desktop), blivit positivt överraskad hur bra Windows motsvarighet till MacOS "Rosetta 2" fungerar.

Just spel tenderar vara rätt kraftigt GPU-bundna, framförallt med så snabb CPU som Snapdragon X Elite kommer vara kopplat med en iGPU. Krävs typ 4090 i 1920x1080 eller ibland även 1280x720 för att man ska vara speciellt CPU-bunden med moderna Intel/AMD CPUer, så den 10-30 % prestandaförlust man får av att köra binäröversatt spelkod lär vara försumbar.

Finns ändå klara vinster om spel skrivs om till "native" ARM64. Dels drar då CPUn mindre effekt då koden är mer optimal. Dels tar det en del tid att göra binäröversättning, något man noterar som rätt långa laddningstider hos program som körs via Rosetta 2 eller motsvarande i Windows.

Det är skillnad på att emulera och att översätta. Och här är det översätta det handlar om. Som @yoshman skriver blir inte overheaden vid översättningen så stor. Vi som kör Linux lever med diverse översättningar hela tiden tex direktX till vulkan och det har nästan samma prestanda som på Windows...

Märkligt att vi ska få en värld där utvecklare inte kan förmås byta plattform de utvecklar för utan att vi istället översätter till vad vi nu behöver ha.

"Emulera" är ett exempel på ord vars betydelse är så överlagrat att det blir lite poänglöst att använda termen.

Processen att kunna köra en ISA på en annan ISA kallas normalt "CPU emulering" eller "CPU simulering". Så ur den aspekten är det en form av emulering.

Precis som @klein skriver betyder ofta "emulering" att man måste göra något som tappar rätt mycket prestanda. Är specifikt här jag tror det är väldigt viktigt att särskilja det man typiskt menar med "emulering" från vad som faktiskt görs här.

Det som Rosetta 2 och Windows motsvarighet gör har långt mer gemensamt med just-in-time kompilering som Java, C#, m.fl. använder sig av för att kunna köra en virtuell maskinkod (intermediate representation, IR) på alla ISA som tekniken har en implementation för. I detta fall råkar IR-dialekten vara x86_64 kod!

Viktigast i kontext av spel är denna del av The Verge texten

"And while Qualcomm sees some slight hit to CPU performance when it’s translating or transitioning between x64 and ARM64, it only happens the first time a block of code gets translated — “subsequent passes are direct cache access,” Khalil says."

D.v.s. väldigt likt hur JVM/CLR kör kod och tror inte speciellt många anser att dessa tekniker leder till hopplöst långsam kod. Det betyder också att när väl översättningen är gjort, handlar det inte längre om "emulering" då man kör en ARM64 binär från cache.

Det är en kostnad att göra detta, resultatet blir bättre optimerat om man kompilerar direkt till ARM64 jämfört med att ta källkoden->x86_64->LLVM IR->ARM64 (vilket är vägen jag förstått både Rosetta 2 och Windows motsvarighet använder).

Testade några av mina egna Go-program. Go är väldigt trevligt för att testa detta då man enkelt kan välja vilket OS/CPU resultatet ska kompileras för.

Skillnaden mellan darwin/arm64 (i.e. MacOS native) och darwin/amd64 är att den senare kör på ~80 % av den förra.
Motsvarande med windows/arm64 och windows/amd64 i Windows 11 under parallels desktop ger att den senare kör på ~75 % av den förra. Så redan nu verkar Microsofts teknik vara väldigt nära Rosetta 2 i prestanda.

Och med 75-80 % effektivitet är min M3 Max lika snabb eller snabbare än min jobb-desktop med 5950X på att köra x86_64 (vilket i sig är helt galet), så kostnaden för "emulering" är inte alls jämförbar med den "order of magnitude" kostnad man brukar associera med emulering. Men ändå, det är egentligen inte fel att kalla det emulering men man ska nog ändå låta bli att göra det då det ger helt fel idé om vad tekniken är kapabel till.

Ovanpå det: specifikt för spel tenderar den effektiva kostnaden bli ännu mindre då OS-kärna, vilket inkluderar GPU-drivare, kommer köra "native" även om spelet är x86_64. Ett spel som är primärt GPU-bundet kommer då har det mesta av den CPU-kritiska delen som "native-kod".

För just spel fungerar Rosetta 2 väldigt bra. För andra saker fungerar det OK, och för vissa direkt uselt (kompilatorer och liknande som är relativt kortlivade processer som är kraftigt CPU-bundna).

Tror inte man ska förvänta sig en "gaming laptop"... De resultat som läck från lite olika benchmarks pekar på att denna kommer ligga någonstans mellan GPU i M3 och M3 Pro. För att sätta dessa i relation till något ligger M3 i nivå eller strax över AMDs 780M.

Så om Qualcomm vill bli relevanta som spelplattform behöver de längre fram släppa något med betydligt mer GPU-kraft. I ett första steg lär det vara långt viktigare att visa att det faktiskt fungerar.

Den här artikeln nämner "snabbare än M2", men Qualcomm har efter lansering av M3 också sagt, "snabbare än M3" (fast möjligen menar man där bara i MT ställt mot vanliga M3).

Om Snapdragon X Elite presterar på den nivå Qualcomm hävdar är ändå det viktigaste denna plattform tillför en CPU-design för bärbara som fixar lika CPU-tunga saker som Apple Silicon bärbara.

D.v.s. man kan få x86-desktop-klass-prestanda i en bärbar (så bättre än alla x86-baserad laptops utanför de "släpbara desktop-replacement modellerna på >3-4kg") som fortfarande är kompakt och inte försöker rymma från sin plats när fläktarna körs på maxfart. Det samtidigt som "det går att spela vissa spel, men glöm AAA-titlar i någon form av relevant kvalitétsnivå".

Historiskt var det helt klart så att samma program kompilerad till x86 tog mindre plats och innehåll färre instruktioner jämfört med t.ex. samma program kompilerad till MIPS eller SPARC.

Arm har alltid varit en uddafågel här. En fördel med 32-bitars Arm är att den tenderar leda till väldigt kompakt binär, ofta mindre än x86.

Problemet med 32-bit Arm ISA är att dessa "smarta" finesser visade sig sätta rätt många käppar i hjulen om man försökte skala upp en Arm-baserad mikroarkitektur till att bli väldigt superskalär. Så ARM64 och 32-bit Arm ISA skiljer sig rätt kraftigt på en rad områden.

Det som är "killer feature" för både ARM64 och även RISC-V är att de har designats mot bakgrund av att "ingen längre skriver assembler", allt går via en kompilator, JIT eller liknande. Man har fokuserat på att ha de instruktioner som passar bäst för en kompilator, något som gör att samma program tenderar bestå av färre ARM64 instruktioner än x86_64 instruktioner trots att den förra är "RISC".

Vilket i sig lite visar hur poänglös RISC/CISC separationen är idag, handlar mer om "load-store design" eller ej där den förra bara accepterar register som argument till instruktioner som utför något form av beräkning. De flesta, men inte alla RISC är "load-store designs" inklusive 32-bit Arm och ARM64.

Är man intresserad att testa lite är compiler explorer en lysande resurs. Där kan man jämföra kodsnuttar och se vad de kompilerar till på olika ISA.

Tar jag ett av de Go-program jag testade ovan består det av 208k instruktioner på x86_64 medan det är 171k instruktioner för ARM64 och 160k instruktioner för 32-bit Arm (alla kompileras då för Linux som OS).