Apple Macbook med ARM-processor släpps sent 2020 eller tidigt 2021

Har inte Windows 10 funnits till ARM i ganska många år nu? .Net 5 ska väl vara CPU/OS-neutralt?

Jag har ju väldigt svårt att se programvaror som Archicad som idag finns både till Windows och Mac skulle gå att köra på ARM utan en skyhög investering. Det blir en Surface X eller iPad Pro+ av det här. OS-Kärnan är ju en extremt liten del av pusslet, den går ju alltid att virtualisera också. Processorarkitekturen är lite värre för tredjepartsmjukvara.

En annan lösning än emulering vore ju en molnlösning, dvs en remote desktop (sidecar).

För vissa tillämpningar skulle det säkert funka - till en kostnad - men inte för alla.

Vad det gäller .NET, har det någon relevant användning alls utanför ASP.NET? Majoriteten av alla Windows applikationer för desktop är primärt skrivna i C++. Utåt kan man se andra språk, det inte helt ovanligt att det också finns vissa möjligheter till scripting och C++ är inte ett lämpligt val där. Sedan har faktiskt inte Windows haft Aarch64 stöd speciellt längre, att man haft ARM stöd kvittar ju då Aarch64 (64-bitars ARM) och ARM (32-bitars ARM) är två helt distinkta instruktionsuppsättningar.

Det är långt mer än bara OS-kärnan som delas mellan MacOS och iOS, i princip alla grundläggande bibliotek delas också. MacOS är väldigt populärt bland utvecklare, saker som VIM, Emacs, VS Code finns ju redan för Aarch64, så även GCC och LLVM. När jag själv körde MacOS kom de flesta programmen från Homebrew (finns andra alternativ som MacPorts, Fink m.fl.), precis som för Linux finns majoriteten av alla de programmen även för ARM/Aarch64. ARM har inte alls samma fördelar över x86/x86_64 som Aarch64 har.

Archicad lär knappast ha någon direkt stor andel, men det verkar vara skrivet primärt i C++. Mycket möjligt att det är skrivet av folk som inte har koll på C++ standarden och p.g.a skrivit massor med kod som beror av "undefined behavior", men det faktum att programmet fungerar på mer än ett OS är en indikation på att man har hyfsad koll på hur man faktiskt skriver vettig C++. Svårt att se vad problemet skulle vara om det är ett program som fortfarande säljs, har primärt jobbat med C och C++ i projekt med miljontals rader kod som i början av karriären körde på SPARC och x86 (x86 var ju ett skämt i serversammanhang då), senare PowerPC, MIPS, ARM, x86 och x86_64 och nu är det primärt x86_64, ARM, Aarch64 samt RISC-V börjar så smått dyka upp.

Det finns definitivt programvara som inte svårt att flytta till en annan CPU-arkitektur, vanliga orsaker är att man använder sig av bibliotek som bara finns i binärform och som inte längre underhålls (fatta vilka säkerhetshål de lär vara...). Men kollar man på mer modern programvara så måste det ju tillhöra undantagen att den är hårt bunden till en viss CPU-arkitektur, i alla fall utanför superdatorscenen. Mobilerna har t.ex. säkerställt att alla större spelmotorer har ARM/Aarch64 stöd.

ARM/Aarch64 är helt dominerande för inbyggda system och undantaget mikrokontrollers kör dessa idag primärt Linux. Det medför att majoriteten av alla bibliotek och program som på något sätt kan vara relevanta för inbyggda system har riktigt bra ARM/Aarch64 stöd.

Intel har flera gånger pekat på att deras ledning i enkeltrådprestanda är det som gjort dem till standardvalet på skrivbordet. Jag tror de har helt rätt i det, just därför är det nu rätt läge att gå till Aarch64. På servers, där frekvensen inte ligger mer än 2,5-3 GHz, är man ju ikapp sett till enkeltrådprestanda (det med N1 som bygger på Cortex A76, Cortex A77 är nu ute och den har >20 % högre IPC).

Vet inte hur högt Apple kan tänkas kunna klocka A14, men nuvarande A13 klockar ~2,6 GHz och drar jämnt med desktop "big-core" x86 p.g.a. ~70-80 % högre IPC. I en laptop lär man i alla fall nå ~3 GHz, där har man trots allt 3-4 gånger mer TDP (15 W) att leka med jämfört med i en telefon.

Kan man jämföra IPC mellan olika arkitekturer? Är inte det som att bedöma GPUer efter TFLOPS? Trodde det fanns x86-instruktioner som krävde över 20 instruktioner i ARM för att utföra samma sak.

Nej, givetvis kommer Apple inte ha samma grafiska gränssnitt på laptop och på en telefon, men det hindrar ju inte dem att använda samma underliggande OS. Vilket Yoshman ju även påpekar att de till stora delar redan gör. Och jag tror absolut att iPad Pro kommer röra sig mer och mer mot att erbjuda ett laptop-liknande gränssnitt, kanske ett valbart, eller ett som aktiveras när man använder extern mus och tangentbord. Jag tror helt enkelt hårdvaran är för kraftfull för att inte erbjuda sådana möjligheter. Men den som lever får se

Om du ska dra det till sin spets kan inte IPC användas ens mellan olika x86 CPUer i alla lägen då de stödjer olika instruktionsuppsättningar, i just SIMD (SSE, AVX, AVX2 och AVX512) finns massor med fall där lägre IPC kan medföra väsentligt högre faktiskt applikationsprestanda.

"IPC" används i praktiken som en synonym/förkortning av "applikationsprestanda isofrekvens".

Den direkta motsvarigheten till TFLOPS för GPU vore att jämföra peak-flyttalsprestanda med SIMD. Det är rätt lätt att se hur totalt meningslöst det är på CPU-sidan, långt mer meningslöst än att jämföra just TFLOPS för GPUer (som ändå ger en vink). Närmaste jämförelsen vore att ställa frekvens * issue-width mot varandra, då hamnar man inte helt fel då det säger just att ARM N1 borde ligga i nivå med Intel/AMD på serversidan där frekvensen är ungefär lika samt att Apples A13 borde ha ett rätt rejält försprång.

Men det jag refererade till resultat i t.ex. SPECint, SPECfp, Geekbench 4/5. IPC är egentligen irrelevant, det enda som spelar roll är hur snabbt respektive system kan köra verkliga program. Med den måttstocken är ARM N1 (och Cortex A76 på mobila enheter) ungefär lika snabb som "big-core x86" vid samma frekvens medan Apples A13 är 70-80 % snabbare.

Slutligen. Nog för att x86 har väldigt många instruktioner, men majoriteten av dessa är i praktiken helt värdelösa idag när maskinkod skrivs av kompilatorer och inte människor. Skulle inte heller vara värt något att manuellt använda dessa komplexa instruktioner, sedan ungefär två decennier sedan är x86 internt en RISC så de hanterar bara den RISC-lika delen riktigt effektivt.

Kika gärna på hur olika program kompileras till assembler, t.ex. med Compiler Explorer. Majoriteten av alla instruktioner är load, store, register moves, add, sub, shift, tests och conditional jumps. Det oavsett om det handlar om x86, ARM, PowerPC etc. D.v.s. typiska RISC operationer. Aarch64 har typiskt en större flora av instruktioner som används, detta då den instruktionsuppsättningen är specifikt designad för att passa kompilatorer. Så i slutändan tar det något färre instruktioner att göra en viss sak där jämfört med x86, det var tidigare RISCs akilleshäl: de var enklare och kunde klockas högre, men krävdes klart fler instruktioner (kompilerar man för PowerPC och framförallt MIPS ser man att det typiskt blir fler instruktioner än för x86, men gäller inte för Aarch64 och RISC-V).

Är inte dessa benchmarks väldigt RISC-vänliga? Enkla instruktioner? För att kunna köras på en mängd olika arkitekturer? Menar du att dagens kompilatorer (ink Intels egna) inte skapar några instruktioner från alla de nya instruktionsuppsättningar Intel (och AMD) lagt till de senaste 20 åren? Kommer ihåg för 20 år sedan när visual studio hade kryssrutor för några av dessa (typ MMX).

Det anges: "Mest troligt är att Apple till stor del inledningsvis förlitar sig på emulering som låter x86-mjukvara köras på ARM-processorer, inte helt olikt hur Microsoft hanterar ARM-processorer i Windows." Men det är väl ändå lite fel beskrivet med "...hur Microsoft hanterar ARM-processorer i Windows", borde väl stått "...hur ARM-mjukvara körs i Windows". Brasklapp - OM det nu är så det fungerar?

Vanliga gamla .NET vet jag inte, men .NET Core är ju svingrymt! Kör det till typ allt på jobbet.

@NutCracker:
Tvärt om: Windows för ARM kan köra viss x86-mjukvara genom ett emuleringslager. Det handlar alltså inte om att köra ARM-programvara på x86, som tolkningen hade behövt bli om din mening skulle stämma.

Det var en av grejerna när Iphone släpptes 2007: ”it runs OS X”.

Ser inte varför det skulle vara en dålig ide att köpa en mac- de lär ju inte trycka delete på allt osx är idag bara för att de lanserar en ny hårdvaruplattform... Varför skulle du vänta två år? Om du redan har en macbook så har ju en ny x86_64 macbook samma system så inte som att du tappar något.. om du köper en ARM64 version så får du väl kolla att den stödjer de program du behöver, kan nästan garantera dig att den kommer ha en webbläsare, någon form av RDP, och något officeprogram...

Meanwhile har jag en bunt användare som behöver programmera diverse styrelektronik över RS232, rj45, några olika generationer av usb och diverse annat med program som definitivt inte byggs om varje gång någon ny plattform dyker upp, samt andra användare arbetar 90% remote, några användare som behöver arbeta lokalt med 3d-ritningar som kräver mer än 16GB ram, vissa användare som kommer arbeta på platser där det avsiktligt inte finns mobildata-täckning, så man kan tycka att det är förlegat med "lokalt på sin laptop" men alla andra industrier stänger inte ner och går hem bara för att tech-industrin har bytt arbetsflöde

Precis så: Du köper en dator för ett behov du har idag. Självklart finns "teh next shiny" alldeles om hörnet, men det har aldrig varit annorlunda i datorvärlden:
Jobbar du för ett företag, gör du ett överslag vad gäller hur mycket kraft du tror du behöver de närmaste tre åren, och så köper du en maskin.

Ska du ha datorn hemma är det med 99% säkerhet så att du antingen är en gamer, i vilket fall en Mac ändå inte är ett kostnadseffektivt val, eller att du behöver datorn för att lösa ett konkret problemområde: "beskära och piffa upp semesterbilderna", "spela in pianot, gitarren och två mikrofoner samtidigt".
Det som datorn klarar bra idag kommer den med största sannolikhet att klara lika bra om sju år; lite som ett kylskåp eller en kaffebryggare. Blir ni fler i familjen behöver du kanske ett större kylskåp. Bestämmer du dig för att redigera film kanske du behöver en kraftigare Mac. Men det är ju ingen som tvingar dig att byta förrän maskinen inte längre kan utföra sin uppgift, eller - vilket kan hända - det inte längre går att få säkerhetsuppdateringar till den.

Vad skulle "RISC-vänliga" betyda?

SPEC testar "riktiga" program, det med fokus på var som är relevant för servers.

Geekbench v3 och tidigare var rätt uselt, fanns micro-benchmarks som gav helt irrelevanta resultat. Gänget bakom GB lyssnade uppenbarligen på kritiken för GB4/5 använder "riktiga" program och bibliotek. Det är en riktigt bra benchmark för interaktiva laster.

Enda man kan klaga på för både SPEC och GB är att sättet de tester skalning med CPU-kärnor är lite väl optimistiskt. "Verkliga" fall skalar sällan i närheten lika bra som dessa benchmarks gör. Därför jag enbart pekar på att Aarch64 faktiskt är i nivå, eller i fallet Apple förbi, i enkeltrådprestanda. Ovanpå det har Aarch64 en mer optimal minneskonsistensmodell jämfört med x86, så i "verkliga" multitrådade fall ökar fördelen för Aarch64 där.

För övrigt: har skrivit att Cortex A77 är på väg ut då den finns i bl.a. Snapdragon 865. AnandTech har precis testat Samsung Galaxy S20+, de >20 % högre IPC som ARM lovat över Cortex A76 stämmer: det ser ut att vara ~25 % högre IPC för heltal och ~27 % högre IPC för flyttal om man tittar på SPEC.

25 % högre IPC på ett enda år när Cortex A76 redan matchar Skylake/Zen2. Det samtidigt som nya Snapdragon 865 är lika högt klockad som förra årets modell och drar samtidigt mindre ström. Är det inte smärtsamt uppenbart att x86 är helt omkörd? Ju snabbare vi kan lämna x86 till historieböckerna ju bättre. Det som skaver med Aarch64 är att ARM är envåldshärskare, förhoppningsvis vinner RISC-V i det långa loppet men just nu är Aarch64 det bästa man kan få rent tekniskt.

Vore rätt coolt (och just nu faktiskt rätt sannolikt) om Apples bärbara datorer kommer ge högre enkeltrådprestanda än stationära x86 datorer som drar nära nog en en tiopotens mer ström. Jag kommer då vara beredd att betala rätt mycket för en sådan bärbara!!!

När du säger IPC så menar du inte IPC eftersom du fortsätter jämföra helt olika arkitekturer med varandra mha begreppet IPC? Vad jag vet så har samtliga AAA-spel delar skrivna i assembler, utöver detta så kan ju visual studio och Intels kompilator optimera för alla extensions. SPEC benchmarksen mäter väl bara enkla instruktioner (passande för servrar, inte laptops/desktops), sådant som är minsta gemensamma nämnare mellan alla arkitekturer? Aida64 går väl inte ens att översätta till något som inte är x86 och skulle man göra det skulle väl en Aarch64-CPU inte ha en chans? Visst, Aarch64 har väl sina egna vektoroptimeringar men finns det implementerad i något som används på en laptop/desktop? Jag tror inte det är en liten sak att få Final Cut Pro att fungera, det hade ju annars redan funnits till iPad Pro.

Är ju rena gissningar innan vi har någon som faktiskt implementerar något med effektbudget i nivå med x86. Min gissning är ändå att det inte kommer vara en så dramatisk vinst som 2-3 gånger, 30-60 % är kanske mer realistiskt.

Hur extremt icke-linjär effekt/prestanda skalar är ser vi rätt bra hos Intel när de pushar ut de absolut sista 100-tals MHz samt även hos AMD där den mer avancerade temperaturövervakningen gör att man relativt sett kan pusha enkeltrådfallet hårdare än Intel, helt rätt strategi från AMD men det ger kanske 100-200 MHz till och högre effekt trots TSMC 7 nm mot Intels 14 nm

3900X drar väsentligt mer än 9900K när endast en kärna lastas.

Trenden är helt klart att ju mer man krymper transistorer, ju större blir krökningen runt inflexionspunkten där man går från bra perf/W skalning till dålig perf/W skalning. Är därför de flesta gissar att högsta möjliga frekvens kommer minska framöver, är 2-4 GHz där man verkar ha området med riktigt bra effektivitet och i det spannet förbättras fortfarande perf/W med mindre noder

Aarch64 kommer inte undan just den aspekten. Amazons Graviton2 har ju 64 ARM N1 kärnor (N1 är mot Cortex A76 vad Skylake SP är mot Skylake Y/U/H/S) klockade till 2,5 GHz där hela kretsen (inklusive 8 DDR4 3200 MT/s kanaler, okänt antal PCIe 4.0 kanaler men gissas var 64 st) drar runt 100 W.

Ampere Altra använder samma N1 kärnor, fast klockade till 3,0 GHz (20 % högre) och 80 st till antalet (25 % fler). Även här är det 8 DDR4 3200 MT/s kanaler, fast hela 128 PCIe 4.0. Svårt att jämföra I/O då vi inte ens vet hur det ser ut för Graviton2, men Altra är specificerad till 210 W. Gissar vi att det mesta av ökning kommer från 20 % högre frekvens och 25 % fler kärnor, vilket nog inte är helt galet gissat då relativt liten del av effekten i Zen2 system verkar komma från I/O-die, är det ungefär en fördubbling i effekt för "endast" 50 % högre total beräkningskraft.

Just i inlägget du kommenterar är IPC faktiskt helt korrekt då Cortex A76 och Cortex A77 implementerar exakt samma uppsättning instruktioner, båda implementerar ARMv8.2-A.

Rätt säker att majoriteten av alla dagens spel saknar helt delar skrivna direkt i assembler. Det finns väldigt liten poäng att ta till assembler, kompilatorer är i dag så bra samtidigt som moderna out-of-order CPUer är så icke-logiska för människor att mycket få personer är idag kapabel till att skriva något i assembler som ens är snabbare än vad en kompilator spottar ur sig, än färre fixar att göra något som är relevant mycket snabbare för att motivera den enorma merkostnad att knacka assembler.

I operativsystem använder man fortfarande assembler, men idag är det i väldigt begränsad form och orsaken är i princip alltid att man måste för att vissa saker man inte uttryckas i C. Det handlar alltså inte om prestandaoptimeringar, endast nödvändigt ont.

Har själv skrivit om vissa synkroniseringsprimitiver i ett OS där handskriven assembler ersattes med C11/C++11 atomics. Förutom att C11 atomics är betydligt lättare för än människa att förstå jämfört med fippla med motsvarande assemblerinstruktioner. Användning av s.k. memory-fences är extremt icke-intiutiva, kompilatortillverkare behöver få det rätt en gång, någon som skriver direkt i assembler måste göra rätt varje gång... Slutresultatet var i princip lika snabbt eller snabbare i varje testat fall, fördelen nu är att man kan välja att använda specifika instruktioner för en viss CPU-modell enbart genom att ändra flaggor till kompilatorn (är det skrivit i assembler kan inte kompilatorn göra något alls).

Tvivlar inte en sekund på att det finns enstaka funktion i program som Final Cut Pro som är SIMD optimerade. Fram till väldigt nyligen var egentligen det enda sättet att få till sådana optimeringar handskriven assembler, eller är sällan assembler utan man använder något som kallas compiler intrinsics så det blir mer som C-funktionsanrop. Resultatet blir ändå specifikt till CPUer som t.ex. implementerar AVX2 eller AVX512 om man väljer att använda sådana intrinsics.

Men sådan användning är oftast isolerade i bibliotek, så är ju "bara" att skriva motsvarande bibliotek för ARM NEON. Så fungerar t.ex. Matlab och andra programvaror som jobbar mycket med matriser. Där finns ett de-facto API på C-nivå, BLAS, detta API har implementationer för alla idag relevanta CPU-arkitekturer samt även för Nvidias GPUer.

Två saker gör dock handrullad SIMD kod mindre relevant framöver. Dels är mycket som kan optimeras med SIMD saker som en GPU (eller annan form av accelerator) kan göra ännu mer effektivt. Dels har man, efter rätt många misslyckade försökt, fått fram en programmeringsmodell där man kan skriva C/C++ (fler språk lär komma) med några enstaka utökningar tillagd och sedan väldigt effektivt kompilera den till önskad SIMD-instruktionsuppsättning. SPMD är en LLVM-baserad kompilatorn som kan producera SSE, AVX, AVX2, AVX-512 samt NEON instruktioner. SPMD är viktigt för Intel då det gör det långt enklare för programvaror att stödja AVX-512, det gör också så att man med samma kodbas även kan stödja ARM NEON.

Ditt argument för Final Cut Pro är samma som Apple försökte använda för PowerPC: visst är >90 % av allt man kör på datorn snabbare på x86, men kolla in hur mycket snabbare det här obskyra Photoshop-filtret är!!! Vi har samma läge här, fast nu är det Aarch64 som är x86 och x86 som är PowerPC. Om >90 % av fallen ser en förbättring, är då den kvarvarande minoriteten av fallen ett vettig argument för att inte byta (och de kommer ju fixas med tiden)?

Du nämner Aida64, det är ett exempel på en mikrobenchmark. Visst får man information från en sådan, men informationen är helt värdelös som måttstock för generell prestanda. Benchmarks som Cinebench testar ju fall från riktiga program, så de är långt bättre måttstockar än syntetiska mikrobenchmark. Men sådana benchmarks är fortfarande usla pekpinnar för generell prestanda då de bara testar ett enda specifikt fall.

SPEC och Geekbench 4/5 försöker ge en bredare bild. Där kör man "riktiga" program, SPEC tester bl.a. kompileringsprestanda med GCC medan GB gör det med LLVM, båda kör också skriptspråk och en rad moment med vanliga program och bibliotek. De har bara olika fokus, SPEC väljer program och dataset som kan anses "normala" för servers medan GB väljer program och dataset som kan anses "normal" för interaktiv användning (så fokus på typiska race-to-sleep fall).

Visst är det inte direkt IPC man jämför när man ställer olika CPU-arkitekturer mot varandra i SPEC/GB, det man mäter är långt mer användbart: faktiskt prestanda för en användare av systemen.

Jag är ganska övertygad att jag läst att alla stora spelmotorer har bibliotek som delvis är skrivna i assembler. Frågan är ju varför Intel och AMD skulle lägga till dessa funktioner om inga kompilatorer generar kod för de och ingen längre skriver assembler.

Linux har ju en klar fördel då det mesta av opensourceprogramvara bör vara relativt enkel att porta - i många fall så enkel som en omkompilering - bara man har hårdvarustödet. Men att det skulle medföra att de stora datortillverkarna skulle skeppa en majoritet av sina datorer med Linux istället för Windows - vilket är vad som skulle krävas för att sparka ner Windows från sin plats - är inte särskilt sannolikt.

Har aldrig skrivit att kompilatorer inte använder nya x86 instruktioner, faktum är att jag pekar på att det omvända är fallet. Men det är inte samma sak som att påstå att spel har delar skrivna direkt i assembler, så är inte fallet för det vore kontraproduktivt ur flera aspekter.

Vad jag säger är att "ingen" längre skriver direkt i assembler, det är helt enkelt bara dyrt och dåligt. Fördelen med att låta en kompilator välja lämpliga instruktioner har massor av fördelar, en är att man genom att ändra några argument kan använda SSE för att stödja gamla CPUer eller AVX2 för bättre prestanda på Haswell och senare. Men det betyder också att man enkelt kan kompilera för Aarch64.

Jag måste missförstått eller läst fel angående kompilatorer och deras användning av nya instruktionsuppsättningar. Hittar inget sådant i dina svar. Jag ber om ursäkt.

Jag menar ju så klart att de (subrutiner) är skrivna i assembler, det är ett sätt att prestandaoptimera i slutskedet av spelutvecklingsfasen. Ett krav hos de stora spelutvecklarna är väl att man ska kunna intrinsics i C++. Kommande Halo Infinite har stora delar av motorn skrivna med intrinsics, inte assembler men så nära man kan komma. Enligt 343 Studios är exempelvis C# ett scriptspråk... Annvänds för att scripta stora slag etc.

Precis min poäng, en glorifierad iPad Pro visst men hur intressant? För Apple så klart ekonomiskt gynnsamt att slippa betala Intel/AMD. Det var ju många år sedan Apple deklarerade PCn som död... iPads används fortfarande primärt till mediakonsumption. Undrar hur många pennor och tangentbord som ligger och skräpar i folks lådor.

Det finns för mycket legacy-mjukvara, se bara på Intels försök med IA-64, AMD gjorde det korrekt strategiska valet att inse att mjukvara är viktigare än hårdvara och vips var det x64 som gällde och ingen kommer ihåg IA-64.

Ska Aarch64 slå på desktop måste man hitta en lösning på legacy x86/x64, antingen i form av en hybridprocessor eller en molnlösning. Utöver detta så kommer det aldrig vara intressant så länge man inte kan slå stationära datorer i prestanda, än så länge existerar inte en sådan CPU.

Personligen hoppas jag på hybridprocessorer men det är väl ännu mer en pipedream än Aarch64 för desktop-användning.

Kan du peka på någon "post-mortem" rapport för spel där de visar vad som skrivit direkt i assembler. Inte ens AVX1 verkar ju använda i spel, för om så var fallet skulle de överhuvudtaget inte gå att starta på Core2Quad och Phenom.

Svårt att se vad man annars skulle använda assembler till. Möjligt att någon har försökt utan att faktiskt verifiera att det är snabbare, för det är extremt osannolikt att man faktiskt lyckats skriva något relevant i assembler där en människa slår en modern kompilator utanför SIMD-optimeringar. Oroblemet med SIMD är att det inte går att uttrycka sig i kod på ett sätt som kompilatorn kan effektiv översätta till SSE/AVX/NEON/AltiVec, i alla fall inte i standardvarianter av C/C++/Java/C# etc. Men är just det SPMD-kompilatorn samt funktioner i OpenMP 4.0 är till för, göra det möjligt att uttrycka sådant så man slipper skriva SIMD direkt.

Att man använder "intrinsics" är egentligen inget som garanterat låser fast koden i en viss instruktionsuppsättning. Man kan dela in intrinsics i tre huvudklasser

1. SIMD

2. atomära operationer

3. övrigt som t.ex popcnt, d.v.s. något som på vissa CPUer implementeras direkt som en instruktion

Spel lär använda sig av 1., men gissar att man håller sig till delmängden SSE (i många fall SSE2 då det garanterat existerar på alla x86_64) då AVX har nackdelen att heltalskod (som är långt viktigare för spel) blir något långsammare p.g.a. CPUn klockar ned sig något.

Lite googlande visade att spel garanterat använder sig av 2. och 3. Men dessa två är ett icke-problem om man vill köra Aarch64, 2. är faktiskt en av de saker som ger en direkt fördel för Aarch64 över x86_64 då hantering av atomära är mer effektiva där.

För 3. finns t.ex. popcnt, den kräver Sandy Bridge eller senare medan Aarch64 inte har en sådan instruktion. Men använder man intrinsics fixar kompilator till en eller en sekvens av instruktioner som gör rätt sak, d.v.s. i detta fall är det verkligen en "C-funktion" som i Aarch64 fallet blir 4 NEON instruktioner (och pre sandy brige blir 8-10 x86 instruktioner och fungerar då även på t.ex. Core2).

Så ställer mig frågande till att "assembler" verkligen används i den form man typiskt menar med det: d.v.s. skriva helt CPU-specifika saker som är bundna till en väldigt specifik CPU-modell.