Krönika: ARM-revolutionen är äntligen här! Eller?

Fast just det fallet har rätt lite bäring på om man kör ARM64 eller x86_64, enda som spelar roll är att man kör Windows.

Historiskt har det ofta betytt mer jobb än "kompilera om" för att stödja en extra ISA. Även idag betyder det en hel del jobb om man behöver byta OS.

Att däremot få igång en existerande Windows-applikation på Windows/ARM64 i stället för Windows/x86_64 är enkelt, i alla fall så länge man har tillgång till källkoden till allt som används (eller i alla fall har access till ARM64 baserad bibliotek man beror på).

Vad de gäller bibliotek var även det ett betydligt större problem historiskt, få satt på andra system än x86 baserade utanför embedded, så inte helt ovanligt att stöta på problemen jag nämnde ovan om man satt på MIPS, PowerPC, SPARC eller liknande. Specifikt för ARM64 är ju det idag typiskt väldigt väl testat då mobil är så stort, Linux har lysande ARM64 stöd samt MacOS är nu ARM64 och majoriteten av de populära biblioteken finns på flera eller alla av dessa plattformar.

I en övergångsfas går det ju att köra binäröversättning. Men tycker vi egentligen aldrig fick en bra bild av hur bra/dåligt det fungerar i större skala då övergång från MacOS/x86_64 till MacOS/ARM64 skedde så väldigt snabbt för alla populära program och verktyg (vilket i sig är en rätt stark indikator på hur enkelt det är numera).

Är egentligen bara spel på Steam och App-Store (exklusive Arcade där allt verkar vara ARM64-native) Rosetta2 används i någon form av skala. Men MacOS är inte precis en stor gaming-plattform...

Nämen fy då, kompilatorn borde göra en bedömning här tycker jag och se att programmeraren trots allt inte bör göra alltför arkitekturspecifika saker, och helt enkelt tvinga fram objekt som följer goda CPU-agnostiska principer.

Men ja, jag traskade runt i C-träsket för en herrans massa år sen och med en mer naiv approach går det bra att krypa lite för nära en specifik arkitektur även i fall där man kanske inte avsåg det... det fanns så att säga inte mycket hängslen och livrem där.

Någon får gärna tala om varför ARM är bättre? Om det nu är det?!!

WinRT och diverse inkompatibla ramverk och körverk är varför Microsoft har misslyckats på ARM.

Nu missar jag inte sarkasmen, men man ska ju även ha i åtanke att topmodeller inte direkt är representativa. T ex så testade techpowerup 14900k vid olika effektnivåer; med CPU begränsad till 125W mot 250W så tappa man 9% prestanda i produktivtettesterna, och 3% i 1080p speltesterna.

Fast problemet är väl att hela marknaden av datorer (utanför datacentret) är i princip bärbart.
Och då är det inte 125w man vill ha utan vi pratar snarare om 10-15w och där har inte x86-marknaden hängt med utvecklingen.

Men även inom datacentrer har ju x86-världens höga värmeutveckling skapat problem då man inte kan bli av med värmen och kan inte packa lika hög densitet som man vill.

Det uppstår väl problem när vi har så många olika hårdvaror som då ska fungera mot windows ARM?
Kommer kräva mycket finslipande av drivrutiner. Dvs mycket arbete.
Eller har jag fel?

Arm härstammar också från 70-talet med Acorn som grundare. Det går inte att jämföra X86 med Arm64. Amd64 är mer jämförbart och det är inte 40 år gammalt direkt. Det är olika filosofier helt enkelt.

Apple tvingar sina användare att byta till Arm eftersom det är ett inlåst system. De skiter i om användarna kan köra sina gamla program effektivt. Du blir tvingad att köpa nytt eftersom Apple tjänar mest på att byta till Arm. Med Apple som enda härskare kan de göra precis som de vill och deras kunder skriker av glädje och försvarar dem med näbbar och klor. Lustigt..

Grundproblemet är att typ 100% som jobbar med detta har jobbat främst med windows de senaste 30åren.
Det finns dock väldigt många som inte alls jobbar inom området, som tycker det borde vara superlätt att bara gå över till ett annat operativsystem som typ ingen av de som jobbar inom området har.

På frågan när sker det förändring. Ja vi pratar om ett trög marknad som inte hoppar på nymodigheter. Sakta men säker går det emot lösningar som inte kräver installation på någon dator, detta för att det är problematisk att ha 100tals olika vm ett för varje program på ens laptop. Detta får sedan följdeffekten att det går att använda en Linux och macdator att programmera det ena och andra.

Så slutsats för var år som det går så blir bara Macbook, Linux m.m mer användbar att programmera det ena och andra. Men orsaken är att det är förlegat att ha mjukvara lokalt på ens egen dator, man jobbar ifrån detta.

Eller så skriver man mjukvara som fungerar att kompilera på alla plattformar på en gång.
Det är faktiskt bara Windows applikationsutbud av de stora systemen som är låst till en enda hw-plattform.

Linux och alla tusentals applikation är klart mer utbrett och har fler installationer än Windows och hanterar flera arkitekturer samtidigt. Samma gäller *BSD etc. Hela poängen med "högnivå"-språk som C och dess släktingar var ju att det var portabelt och att kompilatorn ska lösa ut dina problem.

Så bra skrivna programvaror som nyttjar operativsystemets funktioner/bibliotek behöver inte skrivas om när man byter ISA. Det är sådant som är beroende av specifika drivrutiner för specifik hårdvara som får det jobbigare, men generellt använder ju slutanvändare ganska få sådana lösningar. I linux används dbus för att prata med hw på en högre abstruktionsnivå till exempel så programvaror inte behöver byggas om när du byter ut t.ex ditt 4g-modem.

Det är därför inte ett problem för utvecklare av Mac-applikationer. De behöver ju oftast bara kompilera om programvaran så fungerar det automatiskt, precis som på Linux.

Fast den jag citerade pratade just om desktop, och just därför jag pratade om desktop-modeller. Och jag förstår inte riktigt din invändning, ju lägre man går ner i effektklasserna ju "bättre" (mindre dålig) ser ju x86 ut i jämförelsen mot arm. Alltså om man jämför effektiviteten mellan kretsar så är det ju inte bara arm-kretsar som får 200-300W x86 desktopkretsar att se dåliga ut; x86 kretsar i 15-35W klassen har 5 gånger så hög prestanda/w i jämförelse.

x86 från Intel/AMD har ju knappast 5x högre prestanda/w i jämförelse än Apples Mx-cpuer.
Är ju snarare det omvända, och jag pratade klart lägre effekt än 35w.

Ge oss Zen Arm från AMD.Det är väl på G.Men kommer till xbox ps6 först ARM.Sedan lär det ta fart som fan.
Men först ska det ju hända.Jag tror Sony är bra sugen på ARM och då kommer PC hänga på med tanke på alla
spel som börjats göra på konsollerna med ARM.Så tänker jag då.

I jämförelse mot dekstop-modellerna, inte mot Apple.

Alltså, ställer man 10-35W Zen4 kretsar mot M2:orna, så pratar vi väl mer om 25-50% högre effektivetet hos apple (kollade fort på 7840U mot M2 Pro i geekbench), sämre visst, men mil bättre än man jämför ARM mot dom sönderklockade desktop-modellerna.

Det finns ju knappast några desktop-modeller av ARM-proppar egentligen.
Det finns server-hw och det finns mobila/integrerade plattformar, där i mellan är det ett vakum för att det finns ingen marknad där längre.

Edit:
"Desktop"-marknaden är legacy likt klassiska unix-workstations som blev uppätna av stationära x86-datorer en gång i tiden.

Du får nog läsa om mina inlägg... För jag förstår inte vad det är du svara på. Det enda jag säger är att effektiviteten hos sönderklockade x86-modeller för skrivbordet inte representativt för effektiviteten för x86 i stort, när man får ut 90% av prestandan när man halverar effekten, eller när mobila x86 kretsar har fem gånger så hög effektivitet.

Jag köper det du säger att det inte är representativt.
Samtidigt så är det ju så att även Intels laptop-cpuer har en tendens att överklocka sig själv enormt, för att de ska kunna få den utlovade prestandan. Men har man last som varar i över några minuter så börjar dessa CPUer oftast throttla.
Det finns ju därför en viss relation till samma energiineffektivitet på överklockade desktop-cpuer för x86 och för dess mer representativa vanliga bärbara CPUer.

I allt för många benchmarks ser t.ex laptop-cpuer som i7or ut att se bra ut. Men i real work usecases så börjar de throttla så snabbt att prestandan blir gräslig och att det mesta som genereras är värme.

ARM64 är en ny instruktionsuppsättning och fundamentalt annorlunda jämfört med deras tidigare, medan x86-64 bara är en utökning av x86 som inte förändrar de grundläggande problemen med t.ex. minnesmodellen.

Som nämnts i tråden är 32-bit Arm (som härstammar från 80-talet, inte 70-talet) och ARM64 två helt separata instruktionsuppsättning. Det är inte en utökning av existerande teknik på ett binärt kompatibelt sätt.

Orsaker var att Arm gjorde insikten att flera av de saker som var en bra idé på 70, 80 och 90-talet (egentligen så länge Dennard scaling fungerade) i många fall vändes till ett sänke när det inte längre gick att skriva upp frekvenserna, utan man fick i stället bygga "breda" designer (hög IPC) för att öka enkeltrådprestanda + flera kärnor för att öka total kapacitet.

Alla ISA som designades innan millenieskiftet har en rad designbeslut som var vettiga då, men som man inte skulle göra idag.

Nog för att x86_64 fixade några av de värsta grodorna i x86, men är helt uppenbart att poletten trillat ned för Intel att x86_64 har ett problem när det ställs mot ARM64 (och eventuellt RISC-V längre fram).

Under sensommaren presenterade Intel "Advanced Performance Extensions" (APX), den största förändring av x86 ISA någonsin. Tittar man på detaljerna ser man i praktiken en total rip-off av ARM64 så långt det överhuvudtaget är möjligt utan att bryta bakåtkompatibilitet med dagens x86_64.

Problemet med APX är flera

1. det kommer bli en klar förbättring mot x86_64, men lär med väldigt nära 100 % sannolikhet inte bli lika bra som ARM64. Vissa fördelar ARM64 har kring användandet av många CPU-kärnor går inte att stoppa in i x86_64 med mindre än att bryta kompatibilitet. Går inte heller att fixa variabel storlek på instruktioner (försvårar riktigt "breda" designer).

2. "risken" jag ser det är att likt x86_64 det blir något som är "tillräckligt bra" så man haltar vidare med x86 till Windows. Men även om det blir bra kvarstår problemet att APX inte ger något alls för existerande program, det krävs att man kompilerar om allt (och om man ska göra det, varför inte gå till ARM64 som är bättre?).

Just tidsaspekten i 2:an tror jag leder till att APX är kan ha lanserats för sent. Fler spelar är på väg in i ARM64 lägret, Nvidia har gett sig in i servermarknaden i år (med standard Arm Neoverse V2 design) och de, likt Qualcomm med deras egen "Oryon", kommer lansera sin "egen" design framåt (2025 säjer ryktena om Nvidias CPU).

Spel är specifikt det som fungerar klart bäst, d.v.s. får minst prestandapåverkan, av att köra binäröversaftt x86_64 kod till ARM64.

De DX12 spel som körs via Apples GameKit har de primära flaskhalsarna i ineffektivitet i att översätta DX12 till motsvarande Metal.

Tittar man bara på x86_64->ARM64 effekten är den rätt liten i de spel som finns "native" till MacOS om man jämför att köra x86_64 versionen via Rosetta 2 mot ARM64 "native" versionen.

Orsaken till det är flera, men primärt handlar det om att sättet binäröversättningen fungerar blir som mest effektiv i applikationer som körs relativt länge. Ovanpå det blir det ändå en viktig delmängd som körs i "native" i spel, allt som har med grafik och annat som hanteras av OS körs alltid "native".

"Worst-case" för binäröversättning är applikationer som är CPU-tunga och relativt kortlivande, kompilering via Rosetta 2 är en direkt katastrof prestandamässigt!

Och angående kompilering: AMD/Intel har lite att jobba på om de ska ta sig förbi M3...

M3 är ~25 % snabbare jämfört med 14900K

och ~35 % snabbare jämfört med 7950X

Inte viktigt för alla (men jag bryr mig då det är det som den största prestandaflaskhalsen för mig)