Rykte: Macbook med ARM avtäcks 27 oktober – kapar tusenlappar

Börjar inte det bli uppenbart? Apple har en CPU som lanserades september förra året som är snabbare än de absolut snabbaste CPUerna Intel/AMD har släppt så här långt med 15-25 W TDP.

I maj i år lanserade ARM sin första CPU-design som primärt fokuserar på rå prestanda. D.v.s. precis som Apple var det OK att göra saker med relativt dålig perf/transistor bara det ökade totalprestanda "tillräckligt" mycket. Man nådde inte A13 nivå, men Cortex X1 förväntas utföra ~60-65 % mer per cykel jämfört med Skylake/Zen2 och den kan klockas något högre än Apples CPUer (upp till 3,3 GHz enligt ARM).

Endera är Intel/AMD hopplösa på CPU-design, fast känns det då inte lite väl osannolikt att man hamnat på så väldigt snarlik IPC trots rätt olika design. T.ex. så kör Zen-serien med s.k. distribuerad schemaläggare för heltal (valet av ALU-port görs direkt och är en separat kö per port) medan Core-serien kör med central schemaläggare (valet av ALU-port görs så sent som möjligt för att maximera utnyttjandet av ALU-portar men den designen tar fler transistorer).

Det pekar snarare på att båda slagit i samma fundamentala begränsningar med hur mycket ILP som är realistiskt att extrahera ur typiskt x86-kod. ARM64 har självklart också en ILP-gräns, men än vet vi inte riktigt var den ligger. Finns ändå indikation på att Apple inte riktigt kan öka IPC fullt så mycket lägre, så man börjar kanske närma sig gränsen (som i så fall verkar ligga 80-100 % högre än för x86).

Det går bara spekulera om. Gissar att vare sig AMD eller Intel är speciellt intresserade att gå till något annat än x86, Intel tjänar trots allt väldigt mycket pengar och AMDs siffror pekar rakt upp just nu.

GPGPU, NPU och liknande kommer bli allt viktigare framöver. Men kommer alltid finnas saker som bäst utförs på en CPU, en specifik sådan sak är uppgifter som inte effektivt kan spridas över många kärnor: dessa utförs klart mest effektivt på just en CPU.

Ett problem med Windows on ARM64 är att Windows är extremt hårt bundet till x86 och där fungerar bara emuleringen på 32-bit x86.

Apple verkar redan från start ha viktiga program som Adobes program, Microsoft Office serie och självklart alla Apples egna program färdiga i ARM64 version. Ovanpå det stödjer MacOS (Rosetta 2) emulering av både 32-bit och 64-bit x86 kod.

Många som har Mac som programmeringsdator kör saker som Homebrew och liknande. Alla program där stödjer redan idag ARM64, så de kommer ju finnas i native smak från dag 1 (på Windows kan man göra samma sak genom att köra WSL2 + Ubuntu, för där finns också allt som ARM64 native, problemet på Windows är bedrövligt win32 stöd för något annat än x86).

SweClockers har rapporterat om prestandaförlusten att köra x86_64 på ARM64 via Rosetta 2, det verkar vara ~35 % snabbare i ren native (så ~25 långsammare med emulering) vilket pekar på att Rosetta 2 är extremt bra, klart bättre än Microsoft emulering där det var typ halva hastigheten.

Om vi antar att Apple lyckas hålla sin normala årliga ökningstakt av enkeltrådprestanda på 20-25 % kommer faktiskt ARM64 Mac:arna att kunna köra x86_64 kod ungefär i samma fart som i7-1065G7 och R7 4800U. Och om de håller den takten kommer Mac:arna köra ARM64 kod snabbare än någon x86 CPU kör x86_64, om nu inte Zen3 och/eller Rocket Lake S slår även de vildaste spekulationerna i IPC ökning.

Självklart finns risken att Apple slår i en hård gräns så IPC inte alls ökar alt. att man inte ändrat mikroarkitektur speciellt mycket då A14 är på en ny nod, TSMC 5 nm mot tidigare 7 nm, (d.v.s. man kanske gör en Intel "tick"). Man kan nog förutsätta en liten ökning av frekvens.

Beror på vilket popularitetsindex man väljer. I Tiobe index gick C lite oväntat upp i ledningen vid senaste mätningen.

Det språk Apple pushar hårdast är ju Swift, vilket är en av rätt få språk designade för realtid och systemprogrammering som dykt upp på senare tid (d.v.s. ett språk med deterministiskt minneshantering som kompileras direkt till maskinkod). Men har hänt en del sedan "din tid" även i gamla språk som C och C++.

Apple använder sig nästan uteslutande av ett projekt som heter LLVM. LLVM är uppdelat i en front-end: Clang för C och C++, rustc för Rust och även Apples swift kompilator är en LLVM front-end.

En LLVM front-end tar något programspråk och spottar ur sig LLVM-IR. Det är en form av högnivå maskinkod som gör det möjligt att spara massor med jobb då majoriteten av alla optimeringar och så kan göras så det kommer alla CPU-arkitekturer till gagn!

LLVM-IR är egentligen det enda LLVM projektet jobbar med, det projektet handlar om att dels göra optimeringar på LLVM-IR men också genom olika "back-ends" översätta LLVM-IR till verkligen maskinkod för x86_64, ARM64 etc.

Denna uppdelning gör livet för systemprogrammerare väsentligt enklare än det brukade vara. Framförallt mellan x86_64 och ARM64 då dessa har samma endianness och båda är 64-bit, så man får inga sådana buggar när man hoppar mellan dessa. För det är ju samma front-end oavsett vilken CPU man vill köra på -> man slipper de problem man (framförallt som C++ programmerare) stötte på innan där de miljontals rader kod man precis lyckats byggt i t.ex VC++ bara vräkte ur sig kompileringsfel när man kompilerade för, säg SPARC64 (så var det på "min tid" i början av karriären...) med SUNs C++ kompilator.

Clang/LLVM och GCC är tack och lov extremt kompatibla med varandra och Microsoft har börjat stoppa in allt mer av Clang-kod i MSVC++ så det är faktiskt rätt små problem att hoppa mellan kompilatorer idag. Än mindre är det på MacOS då det i praktiken bara finns en relevant kompilator för Swift eller för ObjC för de som är självplågare

Edit: Lite mer om Swift kompilatorn

Ni lär ju vara redo att köra från dag#1!

Precis som @Mindfighter nämner kommer MS Office finnas för ARM64 på MacOS från start.

PyCharm är ju utvecklat i Java och Python, finns noll anledning varför det inte skulle fungera på alla plattform som har native-stöd för Java och Python. Så provade att ladda ner "community ed" av PyCharm och stoppa in det på min RPi4 som kör ARM64 versionen av Ubuntu server:

Ser ut att fungera (men ni borde ta en titt på VS Code...)