Apple uppges övergå till ARM-baserade processorer för bärbara datorer år 2020

Apple kan ju få göra såhär för att deras datorer bygger man liksom inte själv, samt att de har en exceptionellt lojal kundbas vars åsikter om teknikutvecklingen sammanfaller med företagets, så det är nog inget problem och det kommer bli en len och mjuk övergång utan krångel.

Om man däremot ser till ARM som ersättare för X86-arkitekturen på Windowsdatorer så tror jag det behövs perfekt emulering av X86 på ARM först, annars är det svårt att få med folk på tåget. X86 har idag miljarder program och det är ett för stort bibliotek att bara överge för kanske ~15% bättre prestanda klock för klock.

Debian har runt 54 000 program i grundutförande, men det är ju gratis och Linux.

Apple MacOS har väl typ lika många, men där IOS har fler idag. Apple tar också typ 70 % överpriser för medioker hårdvara.

Men... Deras kommande cpuer lär göra skillnad. Tänk om de kör en lösning lik Ryzen 3000-serien med särskild kisel som fördelar. Det kanske blir en bra framtid om de inte saboterar för sig själva genom att göra en "Windows 8"; jag läste någonstans att det är på g.

Skickades från m.sweclockers.com

Finns tre gigantiska orsaker till varför ARM på Windows varit en sådan total tågolycka så här långt

• enda riktiga försöket man gjort var med 32-bitars ARM. 32-bitars ARM och 64-bitars ARM har ungefär lika mycket gemensamt som MIPS och PowerPC, d.v.s. det är två separata ISA. 32-bitars ARM har en del fördelar mot x86, men finns ungefär lika mycket nackdelar. 64-bitars ARM är på alla sätt bättre än x86 sett till ISA

• försöket med 32-bitars ARM gjordes för sent, i det läget var ju övergången till x86_64 i princip 100 %-ig, varför skulle någon då vilja gå tillbaka till 32-bit?

• så länge man i praktiken är beroende av att köra viktiga program med någon form av emulering på ARM-system kommer x86 alltid vara ett bättre val, emuleringen dödar i princip alla fördelar med att 64-bitars ARM är en "perfekt ISA" då man vid emulering ändå blir bunden av begränsningarna med x86 (så här långt fungerar bara emuleringen av x86 i Windows på 32-bitars program)

Just det faktum att 32-bitars ARM och 64-bitars ARM är två separata ISA har gjort att man inte kunnat utnyttja fulla potentialen av 64-bitars ARM i de CPU-modeller som stödjer båda varianterna.

En orsak att Apples CPUer under en tid låg typ 3 år före toppmodellerna på Android-sidan var att Apple tidigt gjorde valet att droppa 32-bitars stödet och kunde därmed göra effektiva designer som är löjligt "breda" (även ställt mot AMD/Intels senaste modeller). "IPC" i senaste Apple CPUn är 40-50 % högre jämfört med Skylake i heltal (som i sin tur är 15-20 % högre jämfört med Zen+, kolla t.ex. spelprestanda vid samma frekvens här).

Man ser redan nu att de Android-modeller som precis lanserats baserat på Cortex A76 har tagit in rejält på Apples försprång. Samsungs egna "Mongoose M4" som sitter i Galaxy 10 serien är också 64-bit only och ser ut att komma ännu närmare Apples senaste jämfört med A76. Väntad utveckling nu när Android gänget äntligen släppt sargen (32-bitars ARM) och gett sig in i matchen på riktigt.

ARMs första modell som droppat 32-bitars stöd, Cortex A76, dök upp under hösten 2018. Nu förbereds en server-variant av denna, Neoverse N1. Svårt att se hur x86 ska på sikt ha någon chans att konkurrera med denna. Uppskattad prestanda placerar IPC för denna en bit förbi Skylake och man förväntar sig att 64 st N1 kärnor ska klara sig med 105 W TDP (plattformen stödjer även "klippa-och-klistra" med "chiplets" och går då till 128 kärnor per socket).

Visa innehåll

Enkeltrådprestanda, Intel kör på 4,5 GHz, AMD på 3,2 GHz och uppskattad ARM prestanda förutsätter 2,6 GHz

Uppskattad all-core prestanda

Förväntad prestanda jämfört med dagens x86 modeller

Att Apple skulle droppa x86 har sedan de gick 64-bit only och man såg prestanda på deras ARM CPUer bara varit en fråga om när, inte om.

Hoppas det kommer vettiga PC-laptops med 64-bitars ARM också, som inte är låst till Windows på något idiotiskt sätt. Kör man Linux fungerar det sedan någon år tillbaka lysande att köra 64-bitars ARM. Plattformen har mognat fantastiskt fort givet att ISA lanserades så sent som 2010.

Att Apple har nära nog obegränsat pengar har ju inte precis varit någon nackdel för 64-bitars ARM. Apple pushar LLVM extremt hårt vilket gjort att 64-bitars ARM har fått en öppen modern "tool-chain" som mognat med en aldrig tidigare skådad hastighet!

Exakt samma frågeställning hade man för drygt 10 sedan (Eller när det nu var) när man gick från PPC till x86.

Apple är väldigt effektiva på att driva genom förändringar både hos tredjepartleverantörer, sina kunder och sina egna produkter. Är målet att helt gå över till ARM så kommer det gå relativt smärtfritt, i alla fall om ser historiskt.

Sannolikheten att Intel väljer ARM framöver är nog rätt nära noll.

Men finns faktiskt en till ISA som är ”perfekt” för dagens krav: RISC-V.

RISC-V är, till skillnad från ARM, helt fritt att använda. Intel är en av flera stora organisationer som sponsrar projektet.

Nvidia använder redan RISC-V som kontrollprocessor i deras grafikkort. Kinesiska staten pushar också för RISC-V då man slipper hårt beroende på amerikanska företag (även om RISC-V kommer från Berkley kvittar det ju då man släppt allt fritt).

Skickades från m.sweclockers.com

Ex. Adobe förbereder redan genom att släppa fullständig version till iPad och har man redan börjat på ARM kan man fortsätta.

RISC-V må ha viss släktskap med MIPS (båda är skapade på samma universitet) men det är egentligen något helt nytt.

Då RISC-V inte har något likt 32-bitars ARM stöd att få en snabbstart från kommer det naturligtvis ta längre tid. Vidare saknar RISC-V någon som Apple, d.v.s någon men massiv ekonomi och enormt egenintresse i att en viss teknik (64-bitars ARM i Apples fall) lyckas.

Även om RISC-V och 64-bitars ARM i någon mening lanserades samtidigt (runt 2010) haltar jämförelsen något då 64-bitars ARM verkligen var en 100 % färdig specifikation medan RISC-V lanserade en grundspecifikation som är fullt användbar för vissa typer av inbyggda system men det som lanserades initialt var inte något som t.ex. kunde användas i datacenter.

HW-stödet har så här långt legat på helt olika nivåer. ARM gjorde allt helt rätt när man introducerade en helt ny ISA. Visst begränsades potentialen för 64-bitars CPUerna av att de fram till nu även behövt hantera 32-bitars ARM, men det såg även till att det fanns en enorm marknad för 64-bitars ARM CPUer redan dag 1.

Som referens, bara Samsung har sålt ~200 miljoner ARM CPUer per år de senaste 10 åren i deras galaxy telefoner. Ställ det mot att det totalt sålts <300 miljoner x86 CPUer per år räknat över alla kategorier under motsvarande period. Totalt säljs ca 10 ARM CPUer per x86.

För RISC-V har det egentligen bara funnits "mjuka" implementationer i form av FPGA:er fram till väldigt nyligen. Även om Intel stoppar in pengar i projektet lär de inte ha något intresse att pusha egna RISC-V CPUer innan det är uppenbart att x86 är överkörd av 64-bitars ARM. Men är övertygad om att Intel redan har RISC-V produkter i sina labb.

Även på kompilatorsidan har RISC-V haft en betydligt långsammare utveckling jämfört med 64-bitars ARM. Men idag finns bra stöd både i GCC och LLVM för RISC-V (förstahands info på det då min arbetsplats jobbar med RISC-V stöd, men vårt 64-bit ARM stöd är ju redan ute på marknaden).

RISC-V är ju helt ute ur applikationer som HPC och "machine-learning" innan de fått till sitt vektor stöd.

Men tror man är något på spåret med att inte gå på SIMD spåret som alla andra (inklusive x86 och ARM). Målet är med att välja vektor-spåret är ju väsentligt mycket enklare att utföra auto-vektorisering.

Andra stora fördelen nämner du ju, till skillnad från SSE/AVX/AVX512 som kräver omkompilering och där ett program designat för AVX512 överhuvudtaget inte kan köras på modeller som saknar det så är ju stora fördelen med vägen RISC-V går att man automatiskt kan dra nytta av bredare vektor-designer. Även den enklaste CPU kan köra programmet, även om "breda" vektorinstruktioner kommer ta väldigt många cykler att köra.