Permalänk
Skrivet av Mindfighter:

Absolut, en peak 2013 i iPad försäljningen, men jag skulle knappast påstå att sen mattats av som du vill ge sken av:
https://www.businessofapps.com/data/apple-statistics/

Year Sales
2011 32.3 million
2012 58.1 million
2013 97 million
2014 67.9 million
2015 53.8 million
2016 45.5 million
2017 43.7 million
2018 43.5 million
2019 45.2 million
2020 71.1 million
2021 57.8 million

Jag pratade generellt för alla surfplattor. Sedan har jag ingen källa på det och det kanske inte har dalat som jag har trott.
Däremot om man går till Elgiganten och säger, jag vill byta ut min Android surfplatta från 2017, vad har ni för nyare bättre android. Så har de i princip ingen som är märkbar bättre, kanske lite snabbare, men övrigt har det stannat.

Det har dock hänt saker i världen att väldigt många skolelever får surfplattor (ofta iPad) och det driver säkert upp försäljningen lite.

Permalänk
Datavetare
Skrivet av lillaankan_i_dammen:

Jag pratade generellt för alla surfplattor. Sedan har jag ingen källa på det och det kanske inte har dalat som jag har trott.
Däremot om man går till Elgiganten och säger, jag vill byta ut min Android surfplatta från 2017, vad har ni för nyare bättre android. Så har de i princip ingen som är märkbar bättre, kanske lite snabbare, men övrigt har det stannat.

Det har dock hänt saker i världen att väldigt många skolelever får surfplattor (ofta iPad) och det driver säkert upp försäljningen lite.

Surfplattor med Android tog aldrig riktigt fart, eller mer specifikt: "ingen" har orkat lagt resurser på att specifikt designa Android-applikationer för pekplattor.

Så trots att det är ungefär 50 / 50 i marknadsandel (om man ska tro detta i alla fall) så är Android plattor inte mycket mer än en "telefon med större skärm" sett till stödet hos applikationer.

På iOS är normalfallet att applikationer är mer lik en "datorversion" på iPad jämfört med Iphone versionen. Tittar man specifikt på Apple arcade skulle jag säga att man där primärt designar för Ipad (följt av Iphone och sist MacOS just där). Ios har flera specialfunktioner för Ipad just för att göra plattformen mer lik en PC och en Ipad med tangentbord+musplatta kan nog för rätt många helt ersätta en PC.

Givet trådens ämne: lägger man till pekplattor till kategorin "PC datorer" hoppar ARM64 andelen upp till ~40 % av marknaden.

Permalänk
Medlem

Det viktiga är att Windows går bakåt....

Men intressant statistik, oavsett.

Permalänk
Medlem

Det som skett är att Apple ersätter sina x86 med ARM, vilket vi vetat om sen ett bra tag. I övrigt verkar det statiskt. Många ARM-hypetrådar vore mer logiska att ersätta ARM med Apple. Väck mig när det sker något på Windows PC-sidan.

Permalänk
Medlem

Vi får också se om RISCV kommer att ersätta ARM i framtiden.
Det är mycket mer drag runt RISCV än ARM i dessa tider och antalet företag som utvecklar RISCV processorer istället för ARM är bra många fler.
Skulle inte heller förvånar mig att även Apple hoppar på RISCV tåget
Det finns idag ett antal startup som utvecklar serverclass RISCV processorer.
Dock så kommer mjukvaru-stödet vara eftersläppande under en längre tid.

Permalänk
Medlem
Skrivet av Yoshman:

Som redan nämnts, det är antal sålda PC-datorer som avses och procentsiffran refererar till antalet sålda enheter.

Var någon som gjort ett försök att räkna på omsättning, i det läget har Apple runt 20 % (ca 40 miljarder USD i omsättning för Mac senaste 12 månaderna och marknaden som helhet omsätter strax under 200 miljarder USD per år) då de inte har någon bärbar dator under $1000 medan Lenovo, HP och Dell alla säljer en hel del "billigt junk".

Värt att nämna är att Apple står för ca 90 % av alla sålda ARM64 datorer just nu. Sen är det också noterbart att resterande 10 % är relativt jämt fördelat mellan ChromeOS och Windows. Intel och AMD har (än så länge) lyckas väldigt bra med att hålla Arm ute från ChromeOS, detta genom att pusha specifika CPU-modeller mot ChromeOS som man nästan ger bort.

Då bör titeln & ingress uppdateras som nu riskerar att misstolkas, då det gäller försäljningen under Q1'22. Citatet nedan sätter slutsatsen i rätt kontext. Det är en milstolpe att fira minst sagt, men låt oss göra det med rätt premisser 😁🎉

Citat:

The industry shipped around 348.8 million PCs in 2021 and 80.5 million systems in Q1 2022, according to IDC. Sales of Chromebooks totaled 37 million units in 2021 as well as 5.1 million systems in Q1 2022. In the first quarter, Apple shipped 7.2 million Macs and had a market share of 8.9%.

Since the vast majority of Apple's PCs solid in Q1 this year were powered by its own Arm-enabled SoC, it is clear that Arm commands a sizeable share of the PC market due to Apple's M-series SoCs alone. Meanwhile, there are also several popular Chromebooks based on Qualcomm's Snapdragon as well as MediaTek SoCs. While those systems are not as popular as Apple's MacBook Air or MacBook Pro laptops, it is safe to say that Arm's share in PCs is at least 10%, a significant achievement for the British CPU designer.

Permalänk
Medlem
Permalänk
Medlem
Skrivet av SwedenVirre:

Det man så klart inte ska glömma är att det inte är enthusister som anammat ARM utan vanliga svenssons, det brukar ofta vara tvärt om med nya tekniker vilket är positivt

Svensson skiter i vad som sitter för CPU. Bara datorn är billig, så köper dom. Även om dom står där med ett lobotomerat härke till Chromebook, så köper dom eftersom säljare på felgiganten sa att den var så bra, eftersom den gav säljare bäst kickback den dagen.

Permalänk
Medlem
Skrivet av MBlaze:

Vi får också se om RISCV kommer att ersätta ARM i framtiden.
Det är mycket mer drag runt RISCV än ARM i dessa tider och antalet företag som utvecklar RISCV processorer istället för ARM är bra många fler.
Skulle inte heller förvånar mig att även Apple hoppar på RISCV tåget
Det finns idag ett antal startup som utvecklar serverclass RISCV processorer.
Dock så kommer mjukvaru-stödet vara eftersläppande under en längre tid.

Intressanta är väl att intel inne och jobba med Risc V. Jag har faktiskt sett ur ARM på ett copy party på 80 talet. Det var en Acorn Archimedes A3000
( A!= Amiga ) , som på den tiden var en extrem udda fågel i Sverige.

Permalänk
Medlem

Då jag gjorde service på Acorn datorer i Sverige under 80-talet så ägde jag under en kort tid en Archimedes.
Den hade mus och fönster hantering men problemet var saknan av programvara.
Om jag minns rätt så hade den dock en 6502 (BBC Acorn) och 80186 emulator (MS-DOS).

Permalänk
Datavetare
Skrivet av Greyguy1948:

Den länken innehåller en av huvudargumenten varför fler borde önska att ARM64 tar över även på Windows plattformen.

Länge var konsensus att instruktionsuppsättningen, ISA, inte spelade speciellt stor roll kring vilken prestanda en krets får. I praktiken var det så, primärt av två orsaker

  • ISA har visat sig långt viktigare nu när normen är CPUer med flera kärnor än vad som var fallet när CPU hade en eller max två kärnor

  • Tidigare försök, Intels IA64 är nog det mest välkända, till en ny ISA fungerade väl inom vissa specifika områden men var ingen vinst över x86/x86_64 sett till det genomsnittliga fallet. ARM64 och RISC-V är de första fallen som uppvisar i praktiken konsekvent bättre egenskaper än x86_64, båda dessa designades och lanseras (2010) efter att vi gått in i multi-core eran"

"The process of eliminating 32-bit and optimizing for the 64-bit ISA exclusively has been a 2-step process. With the Cortex-X2, the underlying circuitry used for handling 32-bit architectural-related elements was removed, saving on transistors and simplifying some structures. With the new Cortex-X3, the design team took the time to start optimizing specifically for AArch64. In particular, many optimizations to fetch and decode took place taking advantage of the more predictable and regular nature of the AArch64 ISA."

Helt övertygad om att en viktig orsak (finns flera) till att Apples M1 kan ha så brutalt mycket högre "IPC" jämfört med vad Intel/AMD kan få till (M1 utför åtminstone 50-60 % mer jobb per cykel jämfört med Golden Cove och Zen3, även Cortex X2 ligger ~20 % högre) kommer av möjligheter med ARM64.

Apple droppade 32-bit stödet för Arm rätt tidigt. Här är det viktigt att inse att ARM64 inte är en utökning utav 32-bit Arm likt hur x86_64 är en utökning av x86 (IA32). ARM64 är en helt egen ISA som inte har samma kodning av instruktion som 32-bitars Arm, det är lika stor skillnad mellan ARM64 som mellan t.ex. MIPS och PowerPC.

ARM64 har dels fördel att alla instruktioner är samma längd, x86_64 instruktioner kan vara allt från 1 till 15 bytes. Trots att ARM64 är en "RISC" (vilket idag är en rätt meningslös term) med fast instruktionsstorlek blir program nästan alltid mer kompakta med ARM64 än med x86_64.

Detta beror mycket på att ARM64 (likt RISC-V) designats för att vara enkla att optimera kompilerad kod för. x86_64 må ha långt fler instruktioner än ARM64, men ARM64 är "rätt" instruktioner för en kompilator.

ARM64/RISC-V implementerar rätt exakt den minneskonsistenmodell som alla de stora programmeringsspråken efter mycket bollande fram och tillbaka kommit fram till är "optimalt" för multitrådade program. I princip alla andra tidigare RISC:ar valde en lite för tillåtande modell, d.v.s. för lite garantier ges mot hur Java, C#, C++, Rust, Go etc förväntar sig att saker ska fungera. x86_64 har valt en långt striktare modell än nödvändigt.

RISC:arna får därför stoppa in extra synkronisering, så de tappar de fördelar de hade på pappret. x86_64 lämnar en hel del prestanda på bordet, att fixa detta skulle byta att alla existerande multitrådade program skulle sluta fungera -> går inte att fixa för då försvinner huvudpunkten med att dras med x86_64: dessa bakåtkompatibilitet.

Arm har historiskt varit rätt spot-on kring de IPC förbättringar man lovat, så Cortex X3 borde inte vara något avsteg från det. 11 % IPC (geometriskt medel över ett gäng applikationer) är betydligt bättre än vad Intel verkar få i Raptor Cove och vad AMD kommer få i Zen4 (och tänk då på att det är 11 % mot X2 som lanserades 2021, Intel verkar få några enstaka procent sen Alder Lake och AMDs förbättringar med Zen4 är vid lansering mot en 2 år gammal Zen3).

11 % är ändå inte tillräckligt för att man ska komma riktigt nära Apple, och för att ARM64 på Windows ska ta fart behövs något likt M1/M2 (d.v.s. i praktiken lika bra eller bättre på varje punkt jämfört med Intel/AMD, och väsentligt bättre på ett par).

Artikeln nämner att Qualcomm ska använda Cortex X3 i nästa generation Snapdragon. Tror man kan tolka det positivt givet vad denna tråd handlar om: det betyder kanske att Qualcomm/Nuvia CPUn verkligen är till 100 % designad för laptop/PC, det skulle ge dem möjligheter att trumfa Apples M1/M2 serie då Apple bara har en "big-core" design som de använder från Iphone och uppåt.

Permalänk
Medlem

Är det tänkbart att det på Windows finns en marknad (utanför serverhallen) där entrådat inte är det viktigaste, utan många kärnor? Tänker att en Windowsburk med exv 64-128 ARM64 - kärnor är möjlig att kyla och att den då levererar mer prestanda än en Mac med M2. (sedan får vi se hur Mac Pro kan tänkas se ut).

Jag ser för mig att Apple har snabbare chip men att datorer med Windows kommer att ha fler kärnor till ett lägre pris.

Permalänk
Datavetare
Skrivet av Pirum:

Är det tänkbart att det på Windows finns en marknad (utanför serverhallen) där entrådat inte är det viktigaste, utan många kärnor? Tänker att en Windowsburk med exv 64-128 ARM64 - kärnor är möjlig att kyla och att den då levererar mer prestanda än en Mac med M2. (sedan får vi se hur Mac Pro kan tänkas se ut).

Jag ser för mig att Apple har snabbare chip men att datorer med Windows kommer att ha fler kärnor till ett lägre pris.

100 % säker att svaret är NEJ!!!

Anledning: det har testas flera gånger, pitchen har varje gång varit hur mycket effektivare och hur mycket snabbare dessa CPUer varit än Intel/AMD sett över alla kärnor.

Ett av de mer extrema fallen var TILE64 som på pappret gjorde mos av Intels bästa CPU tack vare att TILE64 hade hela 64 kärnor, det redan 2007. Prestanda per kärna var öken, men summan av alla 64-kärnor var långt mer än vad Intel/AMD hade på den tiden. I praktiken var kretsen hopplös att använda utanför extremt smala nischer.

Problemet är att på desktop, och långt oftare även på servers än vad man kanske tror, är prestanda per kärna brutalt mycket viktigare än totala prestanda över alla kärnor.

M1 är framgångsrik till väldigt stor del då den vid lansering var den CPU med högst prestanda per kärna, punkt! D.v.s. den CPU Apple kunde köra i en fläktlös M1 var snabbare per kärna än något Intel och AMD då hade (faktum är att M1 fortfarande är snabbare per kärna än alla AMDs modeller, är bara Intels absolut högst klockade Golden Cove modeller som är snabbare idag).

Qualcomm kommer lyckas etablera ARM64 på Windows om de kan göra en M1. Och det betyder inte att de kan matcha M1, det betyder att de vid lansering måste ha en krets vars prestanda per kärna måste slå alla Raptors Cove och Zen4 modeller.

Höga krav, men givet vilka som grundande Nuvia (företaget Qualcomm köpte förra året och som jobbar på deras nya CPU-design) så tror jag det faktiskt är fullt realistiskt. Intel och AMD har ett allt tyngre ankare att baxa med sig i form av x86_64. Så även om det är Qualcomms första försökt på en "desktop class high-end CPU" rent praktiskt har de som jobbar med CPUn tidigare både jobbat med M1 (flera av grundarna till Nuvia har gjort det) och Intels/AMDs CPUer (Nuvia har lockat över flera personer från Intel/AMD).

Permalänk
Medlem

Menar du att M1 är snabbast i total prestanda man kan få ut av en krets oavsett effektförbrukning?
Trodde att M1 var bäst när det gällde mätvärden som IPC eller prestanda/Watt.

Permalänk
Datavetare
Skrivet av MBlaze:

Menar du att M1 är snabbast i total prestanda man kan få ut av en krets oavsett effektförbrukning?
Trodde att M1 var bäst när det gällde mätvärden som IPC eller prestanda/Watt.

Vid lansering hade M1 högsta prestanda per kärna av alla då existerande CPU-modeller. AMD/Intel hade självklart modeller som tack vare fler kärnor presterade bättre totalt sett.

Vad det gäller perf/W var (är) det total kross. AnandTech har kikat på det ett par gånger, lite beroende på användarfall är fördelen för M1 ~2-3 gånger i enkeltrådade fall och 3-6 gånger i multitrådade fall. Så just på bärbara är det Intel/AMD levererar just nu direkt pinsamt.

Det är möjligt för Intel/AMD att väsentligt minska detta gap, AMD gör det också till viss del när man kör på batteridrift. Problemet är att det kräver väsentligt lägre CPU-frekvens, man minskar gapet i perf/W men man hamnar då rejält efter i prestanda.

Permalänk
Medlem

Personligen så tror jag att M1 presterar så bra är mer beroende på Apple än att dom använder ARM AArch64.
Det var ganska länge sedan som x86 CPUerna exekverade x86 instruktioner direkt.

Efter strulet med ARM/NVidia så tror jag att ARM har tappat luften, dom avskedar folk i Cambridge (flera bolag har av en anledning precis startat kontor där, undrar varför) samt att draget runt RISCV hotar en stor del av deras marknad i framtiden.

Om/när Apple börjar göra RISCV processorer så kommer dom också vara marknadsledande.

Typo
Permalänk
Skrivet av MBlaze:

Om/när Apple börjar göra RISCV processorer så kommer dom också vara marknadsledande.

Jag själv tror mycket på att pengar är en stor del förklaring till mycket. Hur kan Apple ligga så mycket före Qualcomm och Samsung när det gäller deras mobilcpuer? Olika hypoteser kan man ha som att Apples utvecklingscenter ligger där currylinjerna är extra starka. Men jag tror mycket på att de har väldigt mycket pengar och kan anlita på att ta in bra folk och lägga mycket pengar på forskning är en stor del av förklaringen.

När det gäller MacOS vs Windows. Så har har generellt MacOS användare mer varit folk som kör populära konsumentapplikationer, den utveckling som har skett har främst varit web som utvecklas snabbt.
Där man på Windows sidan har haft extrem krav på bakåtkompilatet som härmar utvecklingen av operativsystemet. Om man tar bort dem som jobbar med IT och gamers, så skulle jag påstår att detta extrema bakåtkompilatetkravet inte längre finns på Windows.
Dessutom är Windows enligt mig inte en klientoperativsystem och så totaltsönderbloatad med serverfunktioner, där dessa bara ställer till problem. Som behörighet på filer, vilket blir mycket mer komplicerat när man har windows service och liknande som är inne och rör i filer. Att bara ha en vanlig installationshanterare och kopiera filer till programdata så kommer vanliga användare ej ha rättigheter att ändra dessa.

Så jag tror i framtiden att folk kommer ha operativsystem på sina klienten som just är utvecklade som ett rent enkelt simpelt avskalat klientoperativsystem. Klientoperativsystemet behöver inte klara av att hantera saker som vi har 50st användare inne på datorn samtidigt och kör megastora program med grafiska gränssnitt, hur ska vi se till så att det inte krockar?

Det som gör att jag inte tror på Apple är deras priser, vanligt folk som vill ha en enkel 15,6" laptop har inga extrema krav på hårdvaran. Kan Apple i framtiden göra billigare laptops? Självklart, men det finns en risk att de främst tar kunder som hade köpt en dyrare Macbook.
På samma sätt som att om Apple skulle lansera en 6,7" iPhone som har lite sämre av allt men otroligt mycket billigare, hade nog blivit en säljsuccé.

Permalänk
Datavetare
Skrivet av MBlaze:

Personligen så tror jag att M1 presterar så bra är mer beroende på Apple än att dom använder ARM AArch64.
Det var ganska länge sedan som x86 CPUerna exekverade x86 instruktioner direkt.

Efter strulet med ARM/NVidia så tror jag att ARM har tappat luften, dom avskedar folk i Cambridge (flera bolag har av en anledning precis startat kontor där, undrar varför) samt att draget runt RISCV hotar en stor del av deras marknad i framtiden.

Om/när Apple börjar göra RISCV processorer så kommer dom också vara marknadsledande.

"ISA spelar inte roll, endast mikroarkitektur som bestämmer prestanda och effektivitet" var länge konsensus. Alla ISA som designats innan ARM64 och RISC-V hade sina för- och nackdelar mot x86.

ARM64 och RISC-V är unika på flera tekniskt viktiga sätt!!!

De är de enda mer välkända/välanvända ISA som designats efter att multicore blev normen samt man lyckades komma på en både mänskligt hanterbar och HW-mässigt implementerbar specifikation för hur synkronisering mellan OS-trådar som potentiellt körs på olika CPU-kärnor ska se ut.

Arm själva säger ju att en stor del av prestandaförbättringarna de kunde realisera i Cortex X2 och Cortex X3 är en konsekvens av att man där släppte stödet för 32-bit Arm (som är en separat ISA från ARM64, 32-bit Arm är ett bra exempel på en ISA som har vissa fördelar mot x86, men också vissa klara nackdelar).

Slutligen är ARM64 och RISC-V första generationen ISA som helt designats under förutsättningen: "ingen" skriver längre saker i assembler, ISA ska därför helt optimeras för att underlätta för kompilator-konstruktörer.

Går att ta t.ex. en RPi4, installera en 32-bit versionen av Linux samt 32-bit version av alla program, göra samma sak med en ARM64 variant av OS och applikationer. Trots att Cortex A72 inte egentligen har någon ARM64 specifik optimering (det är i praktiken en energioptimerad Cortex A57 som var första generationen med ARM64 stöd) får man ändå mellan 0-30 % (beror mycket på applikation, de som hamnar närmare 0 % är typiskt NEON optimerade applikation och NEON är väldigt snarlikt mellan 32-bit Arm och ARM64).

Jag har flera applikationer som ser >20 % förbättring, det enbart från att kompilera om programmen som ARM64 i stället för 32-bit Arm. 20 % är 1,5-2 generationer av ISA förbättringar för AMD/Intel!

Men anta att allt ovan är gallematias: vad säger det om AMDs/Intels konstruktörer? Är det bara schimpanser som jobbar med CPU-design hos dem numera? Eller har Apple ett dream-team på en nivå vi aldrig tidigare skådat (och om så är fallet, längtar då än mer att se vad Qualcomm/Nuvia kan få till då de nu har dröm-kedjan där)?

Edit: angående Arm, tyvärr var det den absolut mest väntande effekten av att neka Nvidia att köpa Arm. Apple lär inte bry sig, Qualcomm gnuggar händer för nu slipper de konkurrens från Arms Cortex serie mot deras kommande egendesignade ARM64 design.

Är också helt övertygad att Intel hade kraftigt accelererat sina investeringar i RISC-V om Nvidia fått köpa Arm. Det fanns så mycket bra som kunde ha kommit ur den affären. Ja, Nvidia är assholes på många sätt, men jag såg det bara ur ett teknikutvecklingsperspektiv. Då var det en drömaffär!

Permalänk
Medlem
Skrivet av MBlaze:

Det var ganska länge sedan som x86 CPUerna exekverade x86 instruktioner direkt.

Nackdelarna med x86 försvinner dock inte för det, x86 ger fortfarande minnesgarantier som måste följas och programmen måste fortfarande använda x86-instruktioner.

Permalänk
Medlem

En av anledningarna till Apple kretsar framgång är att dom äger hela mjukvaru-stacken samt att deras kretsar bara finns för deras system. Ingen annan kan använda dom.
Har själv jobbat på Apple och vet att dom ändrar friskt mellan vad som skall implementeras i hårdvara eller mjukvara.
Om det sent i utvecklingen kommer fram att en funktion inte funkar i hårdvara så kollar man hur viktig den är samt om man kan fixa det i mjukvaran. Dom kan strunta i att gammal programvara inte skulle fungera på dom nya kretsarna.
Detta påverkar sjukt mycket då den mesta utvecklingstiden och resurser av att ta fram nya kretsar är verifikationen och inte att innovera. Man kan då spendera mycket mer tid på att få in fler optimeringar och nya funktioner.
Om AMD/Intel släpper en ny x86 så har dom mycket gammalt som också måste verifieras.

AArch64 är en mycket modernare ISA än den gamla 32-bitars som är från 80-talet.
Den har dubbelt så många CPU register vilket har en stor inverkan på prestanda. Det har nog mycket mer påverkan än synchronizering mellan trådar. Synchronizering är viktig men det sker inte vid varje instruktion.

Permalänk
Datavetare
Skrivet av MBlaze:

En av anledningarna till Apple kretsar framgång är att dom äger hela mjukvaru-stacken samt att deras kretsar bara finns för deras system. Ingen annan kan använda dom.
Har själv jobbat på Apple och vet att dom ändrar friskt mellan vad som skall implementeras i hårdvara eller mjukvara.
Om det sent i utvecklingen kommer fram att en funktion inte funkar i hårdvara så kollar man hur viktig den är samt om man kan fixa det i mjukvaran. Dom kan strunta i att gammal programvara inte skulle fungera på dom nya kretsarna.
Detta påverkar sjukt mycket då den mesta utvecklingstiden och resurser av att ta fram nya kretsar är verifikationen och inte att innovera. Man kan då spendera mycket mer tid på att få in fler optimeringar och nya funktioner.
Om AMD/Intel släpper en ny x86 så har dom mycket gammalt som också måste verifieras.

AArch64 är en mycket modernare ISA än den gamla 32-bitars som är från 80-talet.
Den har dubbelt så många CPU register vilket har en stor inverkan på prestanda. Det har nog mycket mer påverkan än synchronizering mellan trådar. Synchronizering är viktig men det sker inte vid varje instruktion.

De >20 % som jag sett i flera applikationer är ju på Linux + även om Apple har fantastisk vertikal integration så är de benchmark jag baserar mina jämförelse på sådana som bara beror på CPUn.

Det Apples vertikala integration ger är ju utöver vad man får från CPUn. Jobbar t.ex. inte med videoredigering, men det är ett exempel där fler delar av M1-systemkretsen samarbetar med OS och programvara och då ger helt fantastiskt resultat.

M1 presterar CPU-mässigt lika väl under Docker/Linux som under OSX. Under Linux finns inga Apple/MacOS specifika tricks, utan det man har är HW i M1 samt arbetet som Arm, Apple, m.fl. stoppat in i projekt som GCC (Arm har jobbat mycket med denna) och LLVM (Apple lägger väldigt mycket krut här då Clang/LLVM är officiell C/C++ kompilator för alla deras system).

Att många register är förklaringen kommer ofta upp, det kan bara förklara en väldigt liten del av prestandaförbättringen då t.ex. x86 såg väldigt liten vinst från att gå från 8 heltalsregister till 16 heltalsregister. 8 var absolut för lite, 32-bit Arm hade 15 heltalsregister (16 men en var ju programräknare) till 32 heltalsregister (exklusive programräknare, men inklusive ett zero-register).

Sant att synkronisering inte sker vid varje instruktion, men det sker vid varje minnesoperation (även om CPUn kan göra en hel del tricks så länge bara en CPU-kärna petar på minnet). Har för mig att ett program typiskt har en minnesoperation per varje 3 till 5 instruktioner (lite beroende på vad det gör). Men är primärt multitrådade program där denna fördel visar sig, och då allt mer ju fler kärnor systemet har och aktivt använder.

De >20 % jag pratar om är primärt i program där varje tråd jobbar väldigt oberoende av andra trådar.

Den absolut största designmissen i 32-bit Arm är att i princip alla instruktioner är villkorade, uppfylls inte villkoret blir instruktionen i praktiken en NOP. Det är förödande om man försöker designa en CPU som ska spekulera långt framåt, en sak Apples M1 ligger i topp på är just hur många instruktioner den kan ha parallellt "in-flight". ARM64 har i praktiken helt eliminerat detta.

Samtidigt är detta en av 32-bitars Arm största styrkor. Den må kallas "RISC", men denna egenskap känns väldigt "icke-RISC" och den medför att 32-bit Arm program tenderar vara riktigt kompakta, kompaktare än motsvarande x86 (medan motsvarande program på t.ex. PowerPC, MIPS, SPARC i princip alltid blir större än på x86).

Vidare har 32-bit Arm och framförallt x86/x86_64 egenheten att nästan alla instruktioner påverkar CPU-flaggorna, d.v.s. de modifierar ett globalt tillstånd. Vad har vi lärt oss om att skriva till globalt delad data i program där saker potentiellt sker parallellt (vilket det gör även i enkeltrådade fall i dagens high-end CPUer)? Det är en skitdålig idé då det begränsar mängden parallellism.

I ARM64 (och RISC-V) har majoriteten av alla instruktioner ingen påverkan på något globalt tillstånd, de tar indata via register och producerar endast utdata i ett register. HÄR tror jag en av de riktigt stora fördelarna med ARM64 ligger, om så är fallet borde även RISC-V kunna skalas upp på liknande sätt!

Intel/AMD kan inte fixa något av ovan, alla existerande program skulle gå sönder om man gjorde det.

Permalänk
Medlem

Tror att load/store är runt 20-30% av koden men minnessynkroniseringen behöver bara ske med data som skall delas med andra.
Den egna datastrukturen har inget behov av synkronisering och det mesta av all minneshantering sker mot den lokala cachen.

Att gå från 8 register till 16 hjälper inte så mycket då generella behovet är mer än 16 register.
ARM32 hade 14 register tillgängligt (r15, r14 är dedikerade) och det är alldeles för lite.
Mycket av det gömdes då ARM32 had a multiple register stack load/store instruktion men det tar inte bort behovet att det blir mycket skriv/läs mot stacken.
Man skulle kunna använda fler register än 32 men vinsten blir då mindre eftersom man behöver fler bitar i opkoden och fler register att spara vid byte av tråd.

Statusbitar gör det krångligt för hög-prestanda CPUer med out-of-order och multi-issue hanteringen.
Detta har både AArch64 och RISCV fixat.
Tror dock att framtiden är RISCV.

Permalänk
Datavetare
Skrivet av MBlaze:

Tror att load/store är runt 20-30% av koden men minnessynkroniseringen behöver bara ske med data som skall delas med andra.
Den egna datastrukturen har inget behov av synkronisering och det mesta av all minneshantering sker mot den lokala cachen.

Att gå från 8 register till 16 hjälper inte så mycket då generella behovet är mer än 16 register.
ARM32 hade 14 register tillgängligt (r15, r14 är dedikerade) och det är alldeles för lite.
Mycket av det gömdes då ARM32 had a multiple register stack load/store instruktion men det tar inte bort behovet att det blir mycket skriv/läs mot stacken.
Man skulle kunna använda fler register än 32 men vinsten blir då mindre eftersom man behöver fler bitar i opkoden och fler register att spara vid byte av tråd.

Statusbitar gör det krångligt för hög-prestanda CPUer med out-of-order och multi-issue hanteringen.
Detta har både AArch64 och RISCV fixat.
Tror dock att framtiden är RISCV.

jag tror svaret varför inget hände på x86 är mycket enklare än så: "architectural versus physical registers"! Redan när övergången till x86_64 i praktiken hände var x86 CPUerna så pass avancerade att de hade så pass avancerad OoO att antalet fysiska register vida översteg register synliga i ISA. Det kombinerat med att x86 sedan PIII-tiden hade dedicerad HW för att hantera push/pop (bl.a. register spills).

Cortex A serien var ju betydligt mer avancerad än en PIII klass CPU när ARM64 introducerades, framförallt hade man även på Arm sidan gått över till OoO på de mer avancerade modellerna -> även där fanns långt fler fysiska register än ISA register. Möjligen kan CPUer som Cortex A53, A55 och A510, som alla är in-order designer, se lite mer utväxling.

Just då jag sett denna diskussion förut + jag läst att "optimala antalet register" är någonstans 16-20 st gjorde jag för en tid sedan analys av ett gäng program och kollade lite hur mycket olika register användes (har dock inte superbra modell för att specifikt mäta registerspill).

På x86_64 använda rätt konsekvent 3 register (r9, r10 och r11) i mindre än 1 % av fallen (de användes dock i alla program jag kikade på). På x86 användas ah/al/ax/eax/rax (teknisk sett samma register, bara olika delar) långt mer än andra register, vilket inte är förvånande givet x86 historik där vissa instruktioner måste använda det registret. bx, cx och dx har även de vissa specifika användningar som delvis kvarstår, vilket gör att även dessa är lite mer välanvända än de ny r9-r15.

På 32-bit Arm finns det teknisk sett 5 "specialregister", r10 (sl = stack limit, är på Linux ett "vanligt" register), r11 (fp = frame pointer, likt "bp" på x86 används detta register i debug-byggen, men typiskt är det ett "vanligt" register i optimerade binärer), r12 (ip = Intra-procedure scratch register, i praktiken ett vanligt register), r13 (sp = stack pointer, är stack pointer), r14 (lr = link register, sätts till återhoppsadress vid anrop av subrutiner), r15 (pc = program counter).

Även här finns register som i praktiken används väldigt lite, här kan man också scanna efter push/pop för att kolla om det finns fall som sparar/laddar alla register (hittade noll sådana fall, men finns fall som sparar/laddar nästan alla register). Klart högst tryck på r3 och r0 då dessa används som första argument samt returvärde. Inget register användes typiskt mindre än 1 % av tiden, 4-6 register användes dock rätt sporadiskt (låga enstaka procent).

Så 32-bit Arm har absolut inget överflöd av register, men verkar inte heller som det är en skriande brist alt. så skulle GCC kunna vara halvkass på att optimera för Arm (vilket jag inte tror).

På ARM64 är xN och wN samma register, bara 64- resp 32-bit variant. Så behandlade t.ex. w0 och x0 som samma register i mätningar. Alla register används, men 10-12 register användes < 1% av fallen. Endast 8 st register används i mer än 5 % av fallen. Här verkar man kommit till en punkt där det nästan allt finns fler register än vad en kompilator kan använda till något vettigt. Det stämmer också med de uttalande jag sett kring "optimalt antal register".

Det finns fall där väldigt många register är fördelaktigt, men det handlar nästan alltid om flyttalstunga applikationer. Är nog inte för intet som Intel slängt in 32 flyttals/SIMD register med AVX-512, upp från tidigare 16st!

Vore det så bra med fler register skulle man absolut kunna öka antalet på x86 och ändå vara bakåtkompatibel. Bara lösa på det sätt man alltid löser det på x86: ännu ett prefix!

Permalänk
Medlem

Om man skall kolla upp hur mycket register man behöver så måste man kompilera för bägge fallen.
Vilket är kanska struligt eftersom man måste göra en ARM32 kompilator för 32 CPU register.
Man kanske kunde kolla upp det relativa antalet stack load/store mellan AArach32 och AArach64 för samma kompilator.
Eftersom man mäter prestanda i exekverade instruktioner och inte antalet instruktioner i koden så bör man göra denna jämförelse på den exekverande koden vilket är lite jobbigare.
När jag kollar på benchmark för processorerna jag utvecklar så är det ganska mycket skriv/läs mot stacken.
Det är mest läs/skriv, hopp instruktioner för loopar samt lite arithmetik.
Även för en ISA med 32 CPU register så är antalet register som en funktion kan använda utan att spara på stacken inte så många.

Permalänk
Medlem

Intressant test av M2 mot 6800U/i7-1260P
https://www.youtube.com/watch?v=FWfJq0Y4Oos

Permalänk
Medlem

Qualcomm Snapdragon just nu:
https://www.notebookcheck.net/Qualcomm-Snapdragon-8-Gen-1-Pro...

Intressant om pris och batteritid är rimliga...
Prestanda är inte dåliga för de flesta.
Se tex Kraken 1.1 och WebXPRT3!
Däremot är Gen2 betydligt sämre än Gen 1 och Gen 1+ på dessa benchmark......

Permalänk
Datavetare
Skrivet av MBlaze:

Om man skall kolla upp hur mycket register man behöver så måste man kompilera för bägge fallen.
Vilket är kanska struligt eftersom man måste göra en ARM32 kompilator för 32 CPU register.
Man kanske kunde kolla upp det relativa antalet stack load/store mellan AArach32 och AArach64 för samma kompilator.
Eftersom man mäter prestanda i exekverade instruktioner och inte antalet instruktioner i koden så bör man göra denna jämförelse på den exekverande koden vilket är lite jobbigare.
När jag kollar på benchmark för processorerna jag utvecklar så är det ganska mycket skriv/läs mot stacken.
Det är mest läs/skriv, hopp instruktioner för loopar samt lite arithmetik.
Även för en ISA med 32 CPU register så är antalet register som en funktion kan använda utan att spara på stacken inte så många.

Visade sig att det faktiskt går att styra hur många register som ska användas i ett program som byggs för ARM64

Upp till 16 register kan "reserveras" via flaggan "-ffixed-<REGNAME>". Får det inte att fungera med den gcc/c++ kompilator jag installerat på Mac:en, men fungerar med LLVM/Clang.

Det man får tänka på är att vissa register har dedicerade uppgifter, så när man reserverar 16 register har man effektivt klart färre än 16 register att använda fritt. Följande reserverad register finns (och dessa kan därför inte reserveras med -ffixed-<REGNAME>)

x0-x7 används för argument och returvärden

x8 används för systemanrop, vilket systemanrop man gör ligger där
x16-x18 används för att lagra information som ibland används över funktionsanrop
x29 är "frame-pointer" (används sällan i optimerade binärer, men blir svårt att debugga utan frame-stöd)
x30 är länkregister
x31 är stackpekare (och i andra lägen zero-register)

Av dessa verkar ändå kompilatorn använda x16 (men inte x17 och x18). Också lite förvånad att den inte använder x0-x7 som "fria" register, utan de används just som argument och returvärden även när man stryper tillgången på register.

Så uppenbarligen är användningen av register i LLVM/clang designad runt det antal register som faktiskt finns, "normal/tänkt" användning av -ffixed-<REGNAME> är att kunna reservera något enstaka register i t.ex. inbyggda-system eller liknande.

Tog ett par av programmen från "benchmark-game" och jämförde fallet "alla register tillgängliga" mot "16 st reserverade".

Som mest blev det en prestandaförlust om 10 % (fannkuch-redux, heltalstungt i praktiken helt utan minnesreferenser) medan mer minnesintesiva och flyttalsintensiva applikationer gjorde någon enstaka procent. Binary-trees, som rätt mycket är ett "pointer-chasing test", såg <0,5 % skillnad.

Så fler än 16 register ger absolut en boost, men svårt att se hur den kan förklara mer än en mindre del av vinsten man får att kompilera om kod från 32-bit Arm till ARM64 för t.ex. RPi3/4. Körde mina tester på en M1Pro.

Edit: På Linux fungerar switchen med GCC/G++ (det gjorde den inte på MacOS), testade på en RPi4 med ARM64 versionen av Ubuntu 20.04

Tog mina 2017 års advent of code lösningar gjorda i C++ och byggde dem så alla register får används resp. med 16 st register reserverade. Skiljer ~1,5 % mellan de två versionerna, så ännu mindre än vad jag såg på M1. Är just på RPi4 jag såg 0-30 % vinst att köra ARM64 över 32-bit Arm, orsaken är rimligen primärt andra saker än fler register!

Permalänk
Datavetare
Skrivet av Greyguy1948:

Qualcomm Snapdragon just nu:
https://www.notebookcheck.net/Qualcomm-Snapdragon-8-Gen-1-Pro...

Intressant om pris och batteritid är rimliga...
Prestanda är inte dåliga för de flesta.
Se tex Kraken 1.1 och WebXPRT3!
Däremot är Gen2 betydligt sämre än Gen 1 och Gen 1+ på dessa benchmark......

Även Arm börjar få till hyfsad ST prestanda med deras Cortex X serie! Nu har senaste Snapdragon och Exynos "bara" en Cortex X2 kärna, men ändå noterbart att den drar hyfsat jämt med CPU-modeller som i7-9700 och Ryzen 3950X i ST!