Windows 10 för ARM körs på Apples M1

Ser onekligen otroligt lovande ut.
Tror det kommer hända en hel del framöver.

De kör Apples egna hypervisor-API/ramverk, precis som jag misstänker att alla kommer få göra. Stöd från Parallells och VMware är på gång och kommer släppas, frågan är bara om det faktiskt kommer en variant av Windows man kan licensiera och att det finns vettiga drivrutiner. Sen behöver ju Windows på ARM mogna en del också, för företag är det nog bättre att rulla vidare på Citrix/RDS ett tag till.

Är väl en oneliner i terminalen? Ungefär lika krångligt som att disablea UAC på Windows?

En spännande framtid! Apple har visat att det går att göra en grym APU med ARM.

Inget hindrar andra från att använda X1an. *Host* Nintendo *Host* Här kunde det vara med en Ampere grafikdel.

Imponerad över Apples framtidstänk och risktagande

Men om Linuxanvändarna får säga sitt så är de inte bra förens de kan köra sitt som de vill

Här är jag lite kluven. Det är onekligen så att nätet blir alltmer osäkert för varje dag som går, och om alternativet är Norton Antivirus så tar jag Gatekeeper alla dagar i veckan. Däremot tycker jag ibland att Apple går för långt i sin envishet att blockera kryphål. Än så länge kan man stänga av allt sånt där, och allt tyder på att man kommer att fortsätta kunna göra det. I så fall är det OK, även om jag naturligtvis hade föredragit om vi sluppe all sån skit.

Det här håller jag egentligen alldeles med om. Jag har kört Macar som en av mina datorplattformar sen 80-talet (jag har dock aldrig varit helt trogen mot dem, utan haft andra prylar där det passar) och just nu utvecklas MacOS och stora delar av Macens hårdvara åt ett håll jag inte gillar. Får se hur jag gör med det där nästa gång. Fördelen är ju naturligtvis att de håller så länge, så det är inte bråttom att bestämma sig.

Personligen så tycker jag att det är en positiv utveckling, kanske är skadad eftersom jag jobbar med IT-säkerhet. Samma fenomen finns i Windows, har flera gånger fått disablea Defender för att installera ett program som Microsoft tycker är opassande.

Det kan absolut vara positivt för Obj-C och Swift prestanda, men finns ju ingen möjlighet för Apple att utnyttja det i kod som översätts från x86_64 (där alla sådana trick är borta då det inte går att representera i x86_64 maskinkod) till LLVM-IR för att sedan översättas till ARM64 (vilket är vad Rosetta 2 gör).

Om det skulle vara någon relevant förklaring skulle också prestandafördel för Firestorm vara mindre i C, C++, Rust m.fl. som normalt inte använder motsvarande teknik samt miljöer med tracing GC som JavaScript, Java, C# m.fl. Där jag sett största fördel för Firestorm över Skylake/Zen2 är NodeJS (JavaScript för back-end), men svårt att veta med ObjC/Swift då det ytterst sällan används utanför iOS/MacOS (fast stödet finns, körde morgonens Advent of code i just Swift, fast på Ubuntu+Emacs).

TL;DR en mycket sannolikare förklaring verkar vara att Intels/AMDs designteam rätt mycket är clowner jämfört med Apples. Åter igen, glaset halvfullt så är det bra för det betyder att det rimligen borde finnas en hel del att hämta även om man är fast på x86_64!!!

Det finns tillägg i stil med ClearURLs som rensar bort mycket av URL trackingen som läggs dit.

Tack för tipset! Önskar det vore lika lätt på mobilen, där vissa banktjänster tvingar mig till specifika webbläsare idag.

Kommer man framöver kunna bygga en PC med en ARM CPU på samma sätt som man nu kan bygga med x86? Tänker med lösa moderkort, grafikkort, minnen, etc. Eller blir det troligen fastlödda saker med eventuellt SoC?

Den beskrivningen jag sett om Rosetta 2 är att den bygger på binary lifting. D.v.s. man tar hela x86_64 programmet och "kompilerar det baklänges" till LLVM-IR. Det man har med LLVM-IR är rätt samma sak som hur shaders distribueras i moderna spel (där kör man SPIR-V med Vulkan eller DXIL med DX12, båda använder internt LLVM så SPIR-V och DXIL är båda varianter av LLVM-IR). När man har LLVM-IR har man egentligen en binär som kan köras på alla CPUer där det finns en LLVM-backend, vilket i stort sätt är alla idag relevanta CPU-arkitekturer.

I framtiden kanske det skulle vara vettigt att även "vanlig" program skeppas som LLVM-IR, för inom ramen av LLVM-IR skulle det vara fullt möjligt att behålla den meta-data som krävs för t.ex. effektiv användning av tagged-pointers på ARM64.

Att gå från källkod->LLVM-IR->ARM64 (vilket är den normala processen för C/C++/Swift på MacOS) är mer effektivt än källkod->LLVM-IR->x86_64->LLVM-IR->ARM64 (vilket är vägen man tar med Rosetta 2). De två LLVM-IR fallen innehåller olika kod, men de representerar samma logik. Det man får från x86_64->LLVM-IR steget är av sämre kvalité då man inte har lika mycket information om saker på högre nivå, t.ex. de du beskrev om pekare i ObjC/Swift.

Apples egna JS motor i Safari har helt klart raketer anslutna, framförallt när den körs på M1. Fast jag körde med NodeJS byggd från source, det är samma C++ källkod baserad på Google V8-motor som används på alla andra system där NodeJS finns.

Prestandan på "emulerad" (översatt) C-kod är i absoluta termer inte fantastisk, både Tiger Lake och Ryzen 5000 presterar bättre. Den är också 60-80 % av motsvarande program direkt kompilerad till ARM64 (d.v.s. kod->LLVM-IR->ARM64, Apples officiella kompilator är LLVM baserad).

Däremot givet att det faktiskt handlar om översatt kod och givet att "ingen" (inklusive jag själv) trodde det var realistiskt att någon skulle skapa en CPU körande något som inte är x86_64 som är kapabel att emulera x86_64 i samma hastighet som toppmodellerna från AMD/Intel (vilket är fallet om man håller sig inom segmentet för bärbara) så är prestandan på saker emulerade genom Rosetta 2 definitivt fantastisk.

Jag trodde definitivt inte själv att Intel/AMD drog benen efter sig. Innan Apple fanns det inte heller något som visade motsatsen.

Apple köpte PA-semi som startskott för deras CPU-satsning. PA-semi hade redan när de pillade med PowerPC designer som radikalt skilde sig från andra, men dels han de inte få ut så mycket av de coola sakerna de jobbade med, dels är PowerPC en ISA som ställd mot x86_64 har för- och nackdelar (ARM64 är rätt unik i att den egentligen inte har någon egenskap som gör den sämre än någon annan existerande ISA, Arm slog verkligen bollen ur stadion) men framförallt var det PA-semi hade tidigt väldigt lågt klockat vilket även längde gällde ARM64 designerna. Ändå var man hela tiden i framkant jämfört med andra mobil SoC.

Huvudpoängen här är: har väldigt svårt att se hur hela Apples försprång kan förklaras med ARM64, de ligger på rätt exakt dubbla prestanda per MHz mot Skylake/Zen2 och tog AMD/Intel två decennier att dubbla deras IPC till var de är idag. Ryktet gör som sagt gällande att Golden Cove ska upp ~50 % mot Skylake medan Ocean Cove (antar att det är första på 7 nm) ska upp ~80 % mot Skylake.

Innan Apples framfart hade jag varit väldigt skeptiskt till att det ens vore möjligt. Nu känns det mer som, det måste vara möjligt och varför har det inte hänt innan?

Om allt går som respektive företag förväntas sig under 2021 kommer ju även Arm, eller rättare sagt de som kommer bygga saker med Arms Neoverse N2, klart kliva förbi AMD/Intel på serversidan. Visst x86_64 är gammalt, men är det verkligen möjligt att förklara hela skillnaden bara genom ISA? Om svaret faktiskt är "ja" så är det verkligen så att ju snabbare x86 dör desto bättre, men har svårt att tro att fördelen verkligen är så stor och förklaringen delvis kanske ligger i att AMD och Intel sneglat för mycket på varandra (för vem annan skulle de titta på för 5-10 år sedan?) och missat en den av de trender "uppstickarna" plockat upp.

Edit: det finns ett rykte kring varför Rosetta 2 presterar så pass bra som det ändå gör, förutom ISA finns en annan sak som radikalt skiljer sig mellan x86_64 och ARM64: minneskonsistensmodell. Är väldigt svårt att effektivt emulera x86_64 på ARM64, det omvända är lättare. Ryktet säger att Apples M1 implementerar två minneskonsistensmodell

• normalt används ARM64 modellen, den är "optimal" i bemärkelsen att den på instruktionsnivå är en perfekt match till vad språk som C/C++/Java/C#/Rust m.fl. behöver för sina modeller

• i Rosetta 2 används en modell kompatibel med x86, d.v.s. TSO (en väldigt välstuderad modell då den dels är lätt för människor att förstå, dels används den av x86 och SPARC)

Om det är sant tappas en del av prestandan där, ARM64 modellen tillåter mer parallellism (högre IPC) men finns inget sätt att översätta x86_64 maskinkod till optimal ARM64 då information gått förlorad i översättningen från LLVM-IR till x86_64.

Blir en mac mini 2nd gen för mig sen.