Microsoft utvecklar egna ARM-kretsar för datacenter och Surface

Vem vill redigera video på en ifån? @ase tror alltså att Arm bara finns i iPhone just nu och att Microsoft satsar på att återuppliva Windows Phone (vore iofs ball, jag gillade Windows Phone! )

Gillar Microsoft Surface datorer skarpt, är en av väldigt få Windows baserade datorer jag kan tänka mig för tillfället.

Oavsett om Microsoft fortsätter samarbete med Qualcomm eller bygger en egen systemkrets för Surface måste de ta lärdom av Apple: man måste gå all-in om marknaden ska ta en seriöst.

Som M1 MBA och MacMini ägare hade jag förväntat mig en del strul, och det finns absolut fortfarande saker som inte är helt finputsat än. Men redan nu, mindre än två månader efter M1 lanseringen, fungerar majoriteten av de saker jag behöver i ARM64 native läge.

Vissa saker är ännu i beta, men huvudpoängen är ändå att det är inte speciellt komplicerat att kompilera om program skrivna för x86_64 till ARM64. Mycket tack vare att ARM64 är så utbred bland telefoner, Linux har väldigt bra ARM64 stöd tack vare alla Android-enheter samt då Linux är standardvalet för inbyggda-system idag där Arm dominerar (Arm dominerar i inbygga system som är avancerade nog att köra ett OS likt Linux).

Apple kanske har ännu lite lättre då MacOS och iOS egentligen är samma OS, enda som skiljer är vissa bibliotek som hanterar UI, men även för UI delar dessa OS mer än man tror. Tittar man t.ex. Metal finns egentligen ingen skillnad alls mellan MacOS och iOS. Använder Swift för Advent of Code, de flesta kanske tänker på Swift som språk man använder för iPhone men det fungerar även på MacOS (och faktiskt på Windows och Linux).

Sedan måste Microsoft kopiera Apples genidrag i M1. Det verkar helt omöjligt att man kan köra x86_64 kod på M1 med högre IPC än vad någon AMD/Intel CPU är kapabel till. Men är exakt vad M1 är kapabel till i förvånansvärt många fall.

Orsaken är två

1. (Rykte, men allt pekar på att det är sant)
M1 har HW-stöd för en av de saker som skiljer mest mellan ARM64 och x86_64, hur man hanterar minnesoperationer i program med fler än en aktiv tråd. Spekulationen är att Rosetta 2 (Apples verktyg som översätter x86_64 instruktioner till motsvarande ARM64) sätter CPUn i ett x86_64 kompatibelt läger m.a.p. minnesoperationer, x86_64 är mindre effekt på detta än ARM64 men det går inte att ersätta läsning/skrivning från RAM 1:1 om man går från x86_64 till ARM64 då den senare helt enkelt tillåter fler optimeringar och vissa program förutsätter att vissa av de optimeringarna inte görs i x86_64 program.

Detta är ett genidrag dels då det inte finns några patent runt x86_64 minneskonsistensmodell, kallad Total Store Ordering (TSO). Dels då det överhuvudtaget inte finns någon bra match i ARM64 för att emulera "vanliga" minnesoperationer, i praktiken får man gödsla med extra så kallade "minnesbarriärer", något som rejält minskar prestanda. Framförallt på en CPU som M1 där prestanda kommer från väldigt hög IPC, "minnesbarriärer" är det man stoppade in lite här och var för att komma runt spectre/meltdown då de hindrar all form av spekulering (men det dödar också IPC).

2.
Sättet x86_64 instruktioner är kodade på binärnivå gör det väldigt komplicerat (dyrt i transistorer och effekt) att avkoda väldigt många instruktioner per cykel. AMD har sagt att man kunde ha gått till 5-wide i Zen3, men man skippade det då det i.o.f.s. skulle gett lite bättre IPC men det skulle också ha sänkt perf/W (mot hur man nu valde att designa Zen3).

Apples M1 är 8-wide, helt enkelt för att det är trivialt att avkoda ARM64 instruktioner. Så genom att översätta x86_64 instruktioner till motsvarande ARM64 instruktioner (det up-front vilket Rosetta 2 gör första gången man kör ett x86_64 program, man översätter alltså inte runtime) kan man då köra x86_64 programmet med högre effektiv IPC än vad Intel/AMD är kapabla till i deras CPUer.

Microsoft måste kopiera detta, x86_64 stöd är långt viktigare på Windows än vad det är på MacOS (är så när som två VPN klienter helt ARM64 native på mina M1 Mac:ar redan, det kommer inte gå så fort på Windows).

Gillar Microsoft Surface datorer skarpt, är en av väldigt få Windows baserade datorer jag kan tänka mig för tillfället.

Oavsett om Microsoft fortsätter samarbete med Qualcomm eller bygger en egen systemkrets för Surface måste de ta lärdom av Apple: man måste gå all-in om marknaden ska ta en seriöst.

Som M1 MBA och MacMini ägare hade jag förväntat mig en del strul, och det finns absolut fortfarande saker som inte är helt finputsat än. Men redan nu, mindre än två månader efter M1 lanseringen, fungerar majoriteten av de saker jag behöver i ARM64 native läge.

Vissa saker är ännu i beta, men huvudpoängen är ändå att det är inte speciellt komplicerat att kompilera om program skrivna för x86_64 till ARM64. Mycket tack vare att ARM64 är så utbred bland telefoner, Linux har väldigt bra ARM64 stöd tack vare alla Android-enheter samt då Linux är standardvalet för inbyggda-system idag där Arm dominerar (Arm dominerar i inbygga system som är avancerade nog att köra ett OS likt Linux).

Apple kanske har ännu lite lättre då MacOS och iOS egentligen är samma OS, enda som skiljer är vissa bibliotek som hanterar UI, men även för UI delar dessa OS mer än man tror. Tittar man t.ex. Metal finns egentligen ingen skillnad alls mellan MacOS och iOS. Använder Swift för Advent of Code, de flesta kanske tänker på Swift som språk man använder för iPhone men det fungerar även på MacOS (och faktiskt på Windows och Linux).

Sedan måste Microsoft kopiera Apples genidrag i M1. Det verkar helt omöjligt att man kan köra x86_64 kod på M1 med högre IPC än vad någon AMD/Intel CPU är kapabel till. Men är exakt vad M1 är kapabel till i förvånansvärt många fall.

Orsaken är två

1. (Rykte, men allt pekar på att det är sant)
M1 har HW-stöd för en av de saker som skiljer mest mellan ARM64 och x86_64, hur man hanterar minnesoperationer i program med fler än en aktiv tråd. Spekulationen är att Rosetta 2 (Apples verktyg som översätter x86_64 instruktioner till motsvarande ARM64) sätter CPUn i ett x86_64 kompatibelt läger m.a.p. minnesoperationer, x86_64 är mindre effekt på detta än ARM64 men det går inte att ersätta läsning/skrivning från RAM 1:1 om man går från x86_64 till ARM64 då den senare helt enkelt tillåter fler optimeringar och vissa program förutsätter att vissa av de optimeringarna inte görs i x86_64 program.

Detta är ett genidrag dels då det inte finns några patent runt x86_64 minneskonsistensmodell, kallad Total Store Ordering (TSO). Dels då det överhuvudtaget inte finns någon bra match i ARM64 för att emulera "vanliga" minnesoperationer, i praktiken får man gödsla med extra så kallade "minnesbarriärer", något som rejält minskar prestanda. Framförallt på en CPU som M1 där prestanda kommer från väldigt hög IPC, "minnesbarriärer" är det man stoppade in lite här och var för att komma runt spectre/meltdown då de hindrar all form av spekulering (men det dödar också IPC).

2.
Sättet x86_64 instruktioner är kodade på binärnivå gör det väldigt komplicerat (dyrt i transistorer och effekt) att avkoda väldigt många instruktioner per cykel. AMD har sagt att man kunde ha gått till 5-wide i Zen3, men man skippade det då det i.o.f.s. skulle gett lite bättre IPC men det skulle också ha sänkt perf/W (mot hur man nu valde att designa Zen3).

Apples M1 är 8-wide, helt enkelt för att det är trivialt att avkoda ARM64 instruktioner. Så genom att översätta x86_64 instruktioner till motsvarande ARM64 instruktioner (det up-front vilket Rosetta 2 gör första gången man kör ett x86_64 program, man översätter alltså inte runtime) kan man då köra x86_64 programmet med högre effektiv IPC än vad Intel/AMD är kapabla till i deras CPUer.

Microsoft måste kopiera detta, x86_64 stöd är långt viktigare på Windows än vad det är på MacOS (är så när som två VPN klienter helt ARM64 native på mina M1 Mac:ar redan, det kommer inte gå så fort på Windows).

Det alla missar är att vid all prestandamätning av M1s emulering av x86 jämförs denna alltid med tidigare Appledatorer med Intelprocessor. Och vad spelar det för roll då? Jo, Apple har som bekant alltid haft taskig prestanda i sina Inteldatorer pga undermåliga kyllösningar (De trottlar vid minsta belastning). Det

Det alla missar är att vid all prestandamätning av M1s emulering av x86 jämförs denna alltid med tidigare Appledatorer med Intelprocessor. Och vad spelar det för roll då? Jo, Apple har som bekant alltid haft taskig prestanda i sina Inteldatorer pga undermåliga kyllösningar (De trottlar vid minsta belastning). Det beror på att snygg design är viktigare än prestanda för Apple. När de designade M1 kunde de fokusera på låg TDP vilket passade deras dåligt kylda designer perfekt och detta gör såklart att M1 kan sträcka på benen medans gamla Intel-Macar går på knäna vid minsta verkliga belastning. Hade man jämfört med en Mac-dator med bra kylning hade det sett helt annorlunda ut. Nu finns tyvärr inga sådana MAC-datorer, så det är inte möjligt.

Visst, det är det en möjlig affärsmodell att Microsoft försöker ta hela kakan precis som Apple alltid gjort. Konsumenterna hade säkert gått att lura dit precis som Apple gjort med sina kunder. Microsoft hade säkert tjänat på det också men risken för Microsofts del är att Windows kanske hade fått ny konkurrens av något annat operativ. Hade Windows bara fungerat på dyr Microsofthårdvara hade jag sett mig om efter annat väldigt fort. Och andra hade säkert gjort det också. Linux utveckling hade nog tagit fart mot mer användarvänlighet, så att det är möjligt att installera ett valfritt program eller hårdvara utan att kunna en mängd kommandon och suffix. Konstigt att ingen gjort detta redan. Alltså köra linux i botten och ha ett helt användarvänligt skrivbord på detta.. Apple har iofs gjort detta med OpenBSD eller vad det var, så det borde vara möjligt. Och Android bygger väl på Linux? Eller kanske Android hade kommit i en ny dator anpassad variant. Vem vet vad som hade hänt? Jag tror inte Microsoft vågar chansa på att tappa sin helt dominerande ställning på datormjukvara.

Ingenting mer än att vi har en annan typ av CPU. Linux finns för massor av CPU arkitekturer redan idag.