Jag är verkligen ingen expert, men är det inte lite fel att jämföra CISC (x86) instruktioner mot RISC (ARM) instruktioner? IPC, instruktioner per cykel, borde inte vara ett så bra mått om instruktionerna inte är likvärdiga liksom?
Annars har ju ARM för- och nackdelar precis som övriga alternativ. En nackdel är väl att Qualcomm i princip har monopol på det som är tillgängligt på marknaden, Apple bygger bra ARM-SoC men de säljer inte dem, nVidia verkar inte lägga så mycket krut på sina chip och AMD har väl mer eller mindre dragit sig ur den marknaden också. Kvar är ju Mediatek, som ju är helt ok på mobilsidan, men jag vet inte om de har kompetensen att konkurrera med QC. Å andra sidan kan ju vem som helst tillverka ARM-SoC om de bara betalar licensavgifterna, men det är förstås en stor investering oavsett.
"IPC" är inte bokstavligen "instruktioner per cykel" då det precis som du påpekar är svårt att jämföra rakt av mellan två olika instruktionsuppsättningar. IPC är här: hur står sig relativ prestanda om båda körs samma program, kompilerad för respektive CPU, på samma frekvens och lika många kärnor. I det läget är Cortex A76 väldigt jämn med Zen2/Skylake i heltal medan Cortex A77 är ~25 % snabbare i heltal och ~15 % i flyttal. Så ~20 % i genomsnitt i benchmarks som SPEC och GB, vilket egentligen är en underskattning då heltalsprestanda är långt mer relevant i praktiken (det gäller även spel).
Inte ens Ice Lake (Sunny Cove) når Cortex A77 i heltal, Sunny Cove har också ~20 % högre IPC mot Skylake i SPEC och GB, men där är det lite större fördel i flyttal och lite mindre i heltal.
Vidare, de gamla sanningarna om CISC och RISC stämmer inte längre, de om att RISC ger större program fast potentiellt högre frekvenser. "Ingen" skriver längre program i assembler, CISC hade en fördel när det var sant då de mer avancerade instruktionerna är lättare för människor att jobba med. I x86_64 har man nu så många specialfall att genomsnittslängden på instruktionerna är i nivå med de 4 bytes som alla Aarch64 instruktioner är (testade mätta genomsnittlig instruktionslängd på ett par program på min x86_64 laptop, genomsnittslängd blev 3,99 och så finns program där resultatet blev >4,0).
Idag skrivs programmen i språk som kompileras till maskinkod och Aarch64 (samt även RISC-V) har en instruktionsuppsättning som specifikt är optimerad för kompilatorutvecklare. Så här hittar men en del (men långt i från allt) av förklaringen till den höga "IPCn" hos 64-bitars ARM (notera att till skillnad mot x86 är 64-bitars ARM en helt separat ISA från 32-bitars ARM, 32-bitars ARM har inte alls samma fördelar över x86).
Kort och gott: x86_64 har i dag egentligen bara nackdelarna från CISC kvar. Den traditionella "RISC:en" finns egentligen inte längre. Moderna "RISC:ar" som Aarch64 och RISC-V har faktiskt en hel del "komplexa" instruktioner. "komplexa" är relativt här, majoriteten av de komplexa x86 instruktionerna kommer aldrig användas av en modern kompilator men "RISC" har idag mul/div och ARM har rätt "komplexa" instruktioner för minnesoperationer för att vara en "RISC", detta då kompilatorer har nytta av sådant.
Enda relevanta distinktionen idag är om instruktionerna har en fast längd (något som förenklar avkodning enormt) samt om aritmetiska operationer kan enbart utföras mot register (gäller i princip alla "RISC") eller mot RAM (typiskt för "CISC"). Så en bättre klassificering är om ISA är en "load/store design" eller ej. x86 är det inte, medan ARM är det (så även MIPS, PowerPC och RISC-V).
Bara för att förstå hur stor fördelen är i area är när man slipper x86-oket: en Zen2 kärna (inklusive lokal cache, d.v.s. L1$/L2$) är ~3,,67 mm². En Cortex A76 kärna med 512 kB L2$ och faktiskt mer L1I$, 64 kB mot Zen2 32 kB tar ~1,22 mm² på samma TSMC process, d.v.s. 1/3 yta för samma IPC!
Cortex A77 tar ~1,43 mm² på TSMC 7 nm, så 2/5 yta för ~20 % högre IPC.
Så det hade varit möjligt att få billigare tillverkning (mindre kretsyta), gett högre prestanda och dragit mindre ström om man valt en design från 2010 i stället för något med sina rötter i 1970-talet... Inser fördelarna med x86 på Windows, men i konsoler är det bara sorgligt att hålla fast vid stenåldersdesign
TL;DR på det hela då inlägget jag svarade på påstod att ingen förutom AMD har tekniken att bygga en konsol. Det stämmer inte, Nvidia har också tekniken, de har tekniken att bygga än bättre presterande krets till och med. Och det många nog missar är att det nog är på CPU-delen där Nvidia, p.g.a. att de inte kan välja x86, skulle ge störts fördel givet den teknik som finns på marknaden just nu.
Men nog sannolikt att Nvidia inte ens försökte utmana AMD om Sony/Micorsoft-konsolerna. Det är i.o.f.s. stora volymer, men bara titta på AMDs resultat när de primärt förlitade sig på intäkter från konsoler: det är brutalt långa marginaler. Att ta fram en konsolkrets är inte gratis ur FoU syfte, framförallt inte om det betyder att andra (potentiellt långt mer lönsamma saker) får stå tillbaka lite.
För AMDs del är det, ur icke-tekniska perspektiv, helt förståeligt att man väljer sin egen Zen2 design över ARM Cortex A77!
Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer