AMD: ARM inte effektivare än x86

"AMD: Snapdragon X inte effektivare än x86"

Fixade till rubriken!

Ser än så länge inget skäl till att använda ARM (läs Snapdragon X) för att köra Windows-applikationer gjorda för x86_64. Snapdragon X var en besvikelse redan när den släpptes!

Däremot kommer jag inte att överge Apple Silicon, då macOS och "alla" program numera är optimerade för just ARM64 samt Metal (Apples motsvarighet till DirectX).

Edit:
Snapdragon X2 Elite är på väg:
https://www.tomshardware.com/pc-components/cpus/qualcomm-snap...

Känns dock fortfarande rätt klen för att kunna få fart på utvecklingen av ARM64-applikationer till Windows.

Fortfarande saknar vad jag vet exempelvis nära nog samtliga Adobe-programvaror stöd för ARM64, såsom Premiere Pro, After Effects, InDesign, Illustrator etc. (även Lightroom Classic?)

https://www.windowscentral.com/software-apps/adobe-native-sup...

Suck, effektivitet beror väl på vad man optimerar koden för och/eller vilken kod som ska köras på arkitekturen?

Beroende på sammanhang kan x86 vara effektivt, ARM kan vara effektivt, PPC och VLIW kan vara effektivt (nåja), etc. Samtliga arkitekturer som används idag är i praktiken uråldriga skapelser som det plåstrats på en oändlig mängd tillägg. För alla som prompt ska försvara den ena eller den andra - det gäller både x86 och ARM.

Nå, äpplen och päron blir det någonstans, men antar att kommentarerna kommer att fyllas av RISC-riddare och CISC-diton oavsett, som tycker det minsann är enkelt och självklart vad som är "bra" och "dåligt". Som vanligt.

Men äsch, låt oss gå över helt till FPGA-baserade lösningar så vi kan köra så gott som vilken arkitektur vi vill i stället, då kan vi prata effektivitet... eller hur det nu var. 😅

Väldigt synd att Apple inte kunde vara med i Vulkan, utan istället behövde hitta på ett eget språk. Inte som att spel på Mac är någon stor grej heller.

Fast inte ens det är ju sant och vet AMD.

En produkt som blev väldigt dåliga nyheter för Qualcomms intåg på Windows-marknaden var Lunar Lake. Frågan är hur mycket Intel gjorde denna just för att ha ett bra svar, Qualcomm var lite korkade i att de började prata om sin Windows-plattform flera år innan introduktion så ett bra svar kunde förberedas.

Problemet med Lunar Lake är att Intel själva sagt att den kretsen är så dyr och avancerad att det kommer vara en "one-off". Snapdragon X är fortfarande mer effektiv än AMD/Intels "vanliga" laptop-kretsar.

Det AMD "glömmer" här är att de bara jämför batteritid samt prestanda som de vet till nära 100 % mäts när man kör på nätström. "Tricket" både AMD och Intel tar till som gör att de numera faktiskt har riktigt bra batteritid är att deras mobilkretsar inte presterar i närheten lika bra på batteri som på nätström

Även här är Apple dock i särklass. Förutom att deras CPU är världens snabbaste sett till single-thread så har de i praktiken identisk prestanda på batteri som på nätström, Qualcomms Snapdragon X ser en liten försämring (kanske en Windows grej?).

Fast nu är just ARM64 ihop med RISC-V unika i att de inte är uråldriga skapelser, utan de är just nå de enda ISA som bl.a. designats efter man började för lite konsensus i bra regler för lämplig hantering av minneskonsistens i programspråk när man jobbar med flera OS-trådar.

Första versionen av specifikationen för RISC-V och ARM64 kom båda 2011. D.v.s ARM64 är, till skillnad från x86, en modern ISA designad from scratch med flera viktiga sker vi lärt oss om multicore, en värld där RAM hamnar allt längre efter i latens jämfört med hur mycket CPUn kan processa per cykel etc.

ARM64 är inte en utökning av tidigare 32-bit ARM som skapades på 80-talet. Arm hade insikten och modet att inser just hur mycket "gammal junk" som de dragit på sig under åren, så man skapade en ny ISA från scratch. De tidiga ARM64 CPU-modellerna hade stöd för att avkoda två olika ISA, de hanterade både ARM64 och traditionella 32-bit Arm.

Alla högpresterande ARM64 designer är idag ARM64 only. Och här bör nog AMD fundera lite på vad de påstår givet att vi nu är i ett läge där Apple, Qualcomm och även Arm nu alla har en toppmodell som klår AMD/Intels toppmodeller med 30-40 % i perf/Hz.

Något gör att ARM64 baserade CPU-designer skalar långt bättre till väldigt breda mikroarkitekturer. Endera har Apple, Qualcomm och Arm långt smartare ingenjörer, eller så kanske problemet ligger i något som är gemensamt för (Apple, Qualcomm, Arm) resp. (AMD, Intel)...

Din dator kan vara snabb effektiv tyst och med bra batteritid även om andra datorer också är det?

Men är det inte dags att se verkligheten?

Windows ARM satsning nu för något år sedan var ju en katastrof (som det talas väldigt tyst om), dina inlägg börjar bli lite i stil med "i år är året då Linux slår igenom på skrivbordet..." (oftast med hänvisning till att det är "tekniskt" överlägset).

Det är möjligt att ARM är överlägsen, (Windows) marknaden har, för stunden i alla fall, sagt att dom inte vill ha den.

Och den dagen människor köper datorer baserat på bäst perf/Hz, så kanske du får rätt.

Jag känner exakt 0 människor som fattar köpbeslut på perf/Hz, men alla är olika, och saker förändras.

Jag bemödar mig knappt att svara, då jag visste att försvarstalet skulle komma från dig.

AArch64 har sin grund i ARMv8, som kom 2011 och började utvecklas 2007, som i sin tur är baserad på tidigare iterationer, ARMv7 etc. (Förvisso med flera radikala förändringar, men sådana har funnits i x86 utvecklingshistoria också. Eller för den delen PPC.)
Så jodå, ARM64 är precis som nuvarande x86-64 ett torn med basen byggd för flera decennier sedan.

RISC-V är förhållandevis "ny" ("bara" 15 år gammal), och vart den ISAn tar vägen får vi se. Intressant, visst, men glhf att bygga ett ekosystem för den, älskar alla goa prognoser som säger att den ska ta allt mellan 25% och 50% av marknaden inom de närmaste ~5 åren. Källa: RISC-V bl.a. Heh, lika opartiskt som AMD här. Omdia ligger på mer "blygsamma" 25% beräknat, utan att hänvisa till egentligen något annat än en beräknad exponentiell tillväxtprognos. Visst får man tro på sånt om man vill.

Men återigen, precis som jag skrev, jag orkar inte ta diskussionen med sådana som ska stå på barrikaderna konstant. Men för all del, fortsätt du om du vill. Dina spekulationer, teorier och antaganden tänker jag inte ens svara på.

Har varit med i IT-branschen sen -94 och har sett samma sak flera gånger. När man hamnar på efterkälken så börjar marknadsfolket gasa och då kommer uttalanden som de från Amd nu: "Jooho, vi är visst bra!". Skulle säga att det är en rätt bra indikator om var man befinner sig.

Helt rätt, AMD kunde aldrig komma tillbaka från katastrofen Bulldozer... med samma ISA dessutom. Och Intels Prescott var ju också ett otroligt steg framåt i utvecklingen. /s

Komiskt att tro att utveckling är en spikrak väg uppåt hela tiden, och att allt "nytt" (som egentligen kanske inte är helt nytt, se ovan) per automatik är bra. Kul när det finns konkurrens och olika utvecklingsvägar, men det är bisarrt hur många som ser det så svart och vitt, och stirrar sig blinda på just det de anser vara det bästa.

Najs om individer eller organisationer hittar det som funkar för dem och/eller för stunden iaf, kör på, för all del. Betyder inte att det är det bästa sedan skivat bröd på ett bräde.

Det är vansinne att köra Windows på ARM-datorer. Det leder nästan alltid till kompatibilitetsproblem, eftersom de flesta program är byggda för x86 och måste köras via emulering. Dessutom saknar ARM en standardiserad BIOS/UEFI-modell, vilket gör att varje tillverkare måste leverera en anpassad firmware och Windows-image för just sin hårdvara.

Eller som Apple med deras AI, jag väntar forfarande på funktionerna som de pratade om vid releasen av min iPad.

Problemet idag när det gäller x86 vs Arm, Windows vs något annat etc. Är att vi går emot en utveckling åt hållet software as service. Vi på användarsidan kan i princip ha vad som helst, de program som vi använder exekveras ändå inte på våra datorer.

Jag tycker mig tydligt se detta på systemutvecklare idag, frågar man vad de har för laptop så säger vissa att laptopen är svart eller grå, knappt mer än detta vet vissa ej idag.

På serversidan? Vanligt sedan ett antal år och växande, framförallt drivet av de stora molnleverantörerna. Mycket mindre populärt för on-premise-prylar men där är det väl också oftare legacygrejer som kanske bara finns till x86 som körs.

I telefoner? Totalt dominerande, men det är förmodligen inte den typ av enhet du tänkte dig.

I IoT/appliance-prylar? Vanligt, men även andra arkitekturer är ju populära inom det området. x86 är väl däremot i princip obefintligt.

På skrivbordet? Ovanligt * ovanligt = nästan obefintligt, typ. Mycket till följd av begränsat utbud av relevant hårdvara som inte är nedlåst till att endast köra något specifikt system samt i viss mån avsaknad av drivrutiner.

Vad menar du med "apple inte kan vara med i vulkan"?
Alla får använda Vulkan mig veterligen. Finns till en hel uppsjö olika plattformar. Jag vill påstå att det inte finns något hinder här.

Tänker du på att apple inte får vara med i Khronos group som äger och driver Vulkan APIet?
Vad jag kan se har de varit med sedan start där och är fortsatt involverade. Så apple är med!
https://www.khronos.org/members/member_list

Jag skulle snarare beskriva det såhär:
"Väldigt synd att Apple inte kunde ville använda Vulkan, utan istället behövde ville hitta på ett eget API för grafiken.

Önskar AMD kunde förklara varför en iPad M4 på batteri med i princip obefintlig kylning är 10% snabbare(geekbench 6) än en desktop med 9950x3d med AIO kylning och nätström.

Det är lagt på hyllan, kallades X86S https://www.tomshardware.com/pc-components/cpus/intel-termina...

Problemet är följande:
Varför har så många x86 processorer och Windows x86/x64. Är det för att dessa produkter bäst passade för deras behov eller beror det på bakåtkompilatet med de mjuk och hårdvaror som de har?
Så att ta bort den viktigaste orsaken till varför folk väljer en produkt är inte det bästa.

X86 kommer dock dö ut och det är av orsaker som att allt fler använder mobil/surfplatta och det folk använder är främst plattformoberende webbtjänster som går att köra på allt med en modern webbläsare.

Jag tycker det är lite tråkigt utvecklingen är sådan att x86 desktop minskar men det är inget som direkt går att stoppa. Jag fascineras ofta över att så många som jobbar inom IT inte ens kan montera ihop en egen dator etc. När jag för länge sedan var ung, varenda elev i min klass monterade ihop sin egen dator, vissa hade dyrare eller billigare begagnad hårdvara. Men alla monterade ihop dem själva och bytte hårdvara.
Och utvecklingen går emot att folk inte ens vet vad de har för datorenheter som de jobbar med.

Skulle AMD/Intel kunna göra en tekniskt bättre lösning om de bröt bakåtkompatibiliteten? Ja, säkerligen.
Men nu har de ju hamnat i en konkurrenssituation där just bakåtkompatibiliteten är den huvudsakliga anledningen att de är relevanta.

Visst har de dragit erfarenheter från tidigare generationer, men AArch64 bryter mot ARMv7 på ett helt annat sätt än vad de olika X86-generationerna gör.

X86 har kommit med nya prefix för att introducera nya features.

• REX - extra RXB-bitar så man kunde ha 16(!) register och 64-bits-operationer.

• VEX - AVX

• EVEX - AVX512 och bredare AVX-operationer, 32 register och k-masken

• ??EX - nya encodings för APX

men all tidigare kod går fortfarande att köra.

Du säger "radikala förändringar" men med AArch64 klipps banden med ARMv7 helt. Man går från 16 till 32 register, skippar conditional execution, droppar Thumb helt. AArch64 är en ny ISA med annan instruktionskodning. Man tog de arkitekturmässiga sakerna som var bra från ARMv7, skar bort det som var mindre lyckat och byggde nytt på de grunderna. Det går inte riktigt att jämföra med X86 där 8086-DNAt fortfarande syns i instruktionskodningen och de senaste CPUerna fortfarande kan köra koden som skrevs 1978 (ja, ja, man kommer inte kunna köra kod från 1978 men det beror OS-versioner och andra problem, CPUn kan fortfarande exekvera koden).

Här är det helt objektivt sett ute i spenaten. Arms namngivning är rätt förvirrande.

ARMv7-A, ARMv8-A och ARMv9-A är alla namn på vad Arm kallar "architecture specification", det är INTE samma sak som en ISA-specifikation.

ARMv7-A innehåller enbart en ISA för 32-bit

ARMv8-A innehåller två ISA, en som är 64-bit och en som är 32-bit. Dessa är två distinkta ISA med helt inkompatibel binärkodning, d.v.s. Aarch64 (ofta benämnt ARM64) bygger inte alls på 32-bit Arm och skiljer sig på en rad fundamentala punkter.

ARMv9-A innehåller åter igen bara en ISA, här har man släppt 32-bit stödet.

2011 må vara ett tag sedan, men i detta kontext jämför vi ändå mot alternativ från 80-talet (32-bit Arm ISA) och 70-talet (x86). Ur den aspekten är det en extremt ny och modern ISA med långt mindre junk som hänger med.

Och här lyfter du en annan viktig sak som AMD "glömde" nämna: finns fortfarande en del områden där Snapdragon X kommer få lite sämre effektivitet/prestanda då den inte kan köra "native ARM64" kod utan istället kör binäröversatt x86_64.

Det är ett problem som kommer minska/försvinna med tiden om ARM64 på Windows ska ha någon relevant chans att bli populärt. Hur stort/litet det problemet är idag beror på vad man gör. Specifikt för programutveckling fick ARM64 rätt snabbt native stöd även på Windows. Visual Studio, Visual Studio Code, Rider, C, C++, C#, Java, Go, m.fl. kompilatorer, git, webbläsare, MS Office finns alla redan idag med native ARM64 stöd.

För andra områden har det gått betydligt trögare, spel existerar knappt i ARM64 native version på Windows (ett viktigt hinder idag är att Steamworks saknar stöd för ARM64 Windows...).

Jag skulle gissa på att en del av problematiken heter RFLAGS. Implicit flagsättning var säkert en bra ide på den tiden då köra instruktioner var det som var dyrt. I dagsläget känns det som en mindre bra idé. Man kan dölja mycket med register renaming, men det måste leda till en rejäl skopa extra komplexitet. Det kommer bli spännande att se vilka effekter APX ger. Intel skröt ju med 10% färre loads och 20% färre stores, men man kan misstänka att många av dessa skulle tas omhand på mikroarkitekturnivå och sedan kommer man byta kortare två-addressinstruktioner mot längre tre-addressinstruktioner. Vi får se vad det blir i slutändan.