Krönika: Mäktig början på den stora stagnationen

Börjar kanske bli dags att söka effektivare tekniker. X86 kommer nog bli överkörd av risc, kanske en ny liknande sak inom grafikkorts världen behövs?

Varför skulle risc bli bättre än x86?
Båda arkitekturerna och filosofierna är uråldriga och i båda fallen är vi troligen i slutet av utvecklingskurvan.
Jag tror snarare att vi kommer behöva något helt nytt som inte följer von Neumann-arkitekturen för integration mellan minne och beräkningar för att kunna fortsätta att ta stora kliv frammåt.

Vi får väl se. 5090 ryktas få dubbla prestandan mot 4090.
Utan materialbyte är det kanske tveksamt att fortsätta med monoliter framöver dock.

Kisel är inne på sista versen helt klart, men om de får igång optiska kretsar kanske det finns några generationer till

Kvantdatorer är ju av en helt annan karaktär och kommer inte kunna driva spel i realtid eller köra vanliga algoritmer

Skulle gärna se en övergång till ARM eller andra arkitekturer som använder transistorerna mer effektivt. Där finns det fortfarande utrymme att skala en del, både i frekvens och IPC

Alla moderna x86 kör RISC internt, översätter alla externa instruktioner från övriga datorn till interna instruktioner som egentligen är ganska skilda från faktiska binärkoden. Zen hade ju syskonet K12 som körde samma exekveringsdelar men med en ARM64 frontend istället

Om man ser till vad Apple gör med sina processorer så ser man ju att nytänk kan nå långt både sett till prestanda och effektivitet

Nja.

För det första är RISC en term för många arkitekturer, och dessutom en ganska luddigt definierad sådan. För det andra så kan man komma väldigt nära ”metallen” med x86 assembler om man vill.

Förr när minne var svindyrt ville man optimera minnesanvändningen väldigt hårt, och gjorde därför instruktioner av typen ”ladda minne från adress 1234 och lägg till det till innehållet i register B” istället för att göra det till två instruktioner. Nånstans på 80-talet började priserna på minne gå ner kraftigt, och detta var inte längre lika viktigt. Där nånstans föddes RISC som idé. Bakgrunden är att en operation som skall hämta något i huvudminnet och sedan lägga ihop två tal tar ganska lång tid, och detta blev begränsande på klockfrekvensen. Genom att dela upp sådana instruktioner i två kunde man mer eller mindre dubblera klockfrekvensen. Detta gjorde att de enklare instruktionerna - de som inte behövde delas i två - kunde exekveras snabbare.

Med Pentium Pro (och allt efter den) började Intel att bryta ner sina gamla x86-instruktioner till något som är väldigt RISC-likt - något som kallas mikro-operationer, eller uops (u skall vara ett grekiskt my, för mikro). Enkla x86-instruktioner blir en uop, något mer komplexa blir två, tre eller fyra. De riktigt vidriga blir hundratals uop långa. Detta gjorde att Intel fick den första nyttan med RISC gratis utan att behöva byta ISA mot programmen. Pentium Pro blev en väldigt bra processor delvis på grund av detta, men också för att den var OoOE - det vill säga, den kunde flytta runt instruktioner och göra vissa tidigare än var tänkt. Den största vinsten var att man kunde hitta de där operationerna som skulle läsa från minnet och skicka iväg dem i förväg, så att den datan fanns klar i ett register när man skulle ha den.

Svagheten hos x86 idag har inte med detta att göra. Det handlar mest om att instruktioner inte går att köra parallellt med varandra i samma utsträckning som på Arm64.

"RISC" och "CISC" har egentligen aldrig haft någon relevant distinktion utöver att "RISC"-designer haft hård separation mellan instruktioner som läser/skriver från minne och instruktioner som utför någon form av beräkning, s.k. load-store architecture. Det medan CISC typiskt tillåter att en av argumenten till beräkningar direkt refererar minne.

En "sanning" som egentligen aldrig varit en sanning är att RISC skulle ha enklare instruktioner. 32-bit ARM (som är en helt annan instruktionsuppsättning jämfört med 64-bit ARM) är allt annat en enkel och till skillnad från t.ex. MIPS och SPARC är 32-bit ARM kod väldigt kompakt (typiskt mer kompakt än x86 kod) medan MIPS/SPARC-kod är mer som man förväntar sig mindre kompakt.

32-bit ARM fick p.g.a. sin design ännu större problem än x86_64 när man inte längre kunde höja frekvensen utan vill skapa allt "bredare" mikroarkitekturer. Samma underliggande problem, men 32-bit ARM använder detta långt mer än x86 gör.

Exakt. ARM64 och även RISC-V ISA är explicit designade på ett sätt som maximerar potentiell "ILP" (instruktion level parallellism). Det har inget med fysik att göra, utan handlar bara om att optimera utifrån de förutsättningar som finns.

Ska bli spännande att se hur bra/dåligt RISC-V fungerar när man börjar skala upp det. För ARM64 verkar fördelen mot x86_64 motsvara ungefär 1-1,5 helnoders försprång (dagens helnoder, som denna artikel pekar på kommer vinsten bli allt mindre framåt för varje ny helnod, vilket då betyder att den fördel ARM64/RISC-V har mot x86_64 kommer öka relativt sett).

Ska jag vara lite elak så har det inte hänt extremt mycket de senaste 10 åren. Senaste stora steget där två generationer skiljde sig rejält åt var när Sandy Bridge kom 2011.

Likadant är det med grafiksidan, man slog i taket för ett bra tag sedan och nu plågar man sig genom det genom att tillåta grafikkorten att dra ännu mer galna mängder ström.

Kan inte riktigt hålla med om CPU-delen. Tycker Apple M1 är det största som hänt den här sidan millenskiftet, betydligt större än lyften från Nehelem (eller Core2 för den delen) till Sandy Bridge. Den totalt omdefinierade prestandanivån hos "thin-and-light" bärbara.

När den lanserades gav de oss en krets som satt i fläktlösa MBA och hade vid release högre prestanda per kärna än det AMD/Intel då hade på marknaden i sina stationära. Utöver det gav det oss en krets med iGPU-prestanda på en ny nivå, det redan med M1 men framförallt hos M1Pro/M1Max.

Även om AMD/Intel sedan gått om igen sett till prestanda per CPU-kärna, har de gjort det med helt löjlig effekt per kärna och de är trots allt inte speciellt långt före M2 (stämmer ryktena kring M3 och den lanseras i sommar tar Apple tillbaka single-core prestanda kronan).

I.o.f.s. kan man säg att M1 inte var mer än en uppskalad Iphone/Ipad CPU. Men gick inte riktigt att fatta hur CPU-starka dessa iOS-enheter egentligen var innan samma CPU-design blev tillgäng på ett "dator OS".

Tack för era utförliga förklaringar om hur det hela fungerar. Ska bli intressant att se vad som händer när x86 får lite riktigt konkurrens.

Håller i helt med dig, jag var inne på x86-spåret lite för hårt. För där händer inte några jättekliv längre.

Det finns redan en M1-baserad dator i hushållet och det lär bli fler framöver när det är dags att byta laptop för mig.

Stagnation eller ej så tycker jag personligen det viktigaste är att om prestanda per krona inre ökar så ska produkten inte säljas. Det måste till en mentalitet där "mer prestanda för samma pengar" ses som en självklarhet. Då som det var runt tiden för pascal och bakåt.

Tack för en väldigt bra och intressant krönika. Gillar när ni zoomar ut och tittar på de större skeendena också.

Fast vänta nu, vadå ”inte säljas”? Ska man förbjuda nya produkter att säljas om de inte leverade högre prestanda/arbiträr valuta? Hur har du då tänkt att någon som helst utveckling ska ske? Top tier produkter kostar ju alltid okristligt mycket, men sen så droppar den utveckligen ner på ”lägre” produkter.

Man kan argumentera om att utvecklingen kan fortsätta genom att använda effektivare cpu/gpu design och bättre skriven kod. Jag ser detta dock bara som att man fördröjer stagnationen.

Vi har haft en supersnabb datorutveckling sedan runt 1940 talet. Denna extrema utvecklingen har vi inte haft för så mycket annat, självklart kan denna utvecklingen stagnera.
Problemet är att inom vissa områden så är behovet så otroligt mycket större än vad det finns för att det ska bli bra.
Jag påstår att både film och spelbranchen inte kommer gå under om datorutvecklingen idag helt skulle stanna upp. De skulle kunna producera sitt arbete och folk skulle köpa det för samma pris ändå. Samma gäller mycket annat, det överlever ändå.

Det jag däremot ser stora problem med är teknikutveckling av vissa produkter som Ai, VR och AR.
Jag ser dessa områden idag i samma stadie som en person som innan satt med sin 386 16MHz, 2MB ram, 40MB hdd, 14" skärm och säger att min dator klarar av allt vanligt kontorsarbete som man skulle kunna behöva göra. Utan att inse vilken hårdvara som hade varit optimal för dennas uppgifter.

Det jag påstår är alltså att för Ai, VR och AR ska bli riktigt bra så behövs det brutalt mycket snabbare datakraft, denna brutalt kraftigare kan kännas lika främmande för personen som satt där med sin 386a 16Mhz och ser folks behov idag för att jobba med större excelfiler som enbart trollande påstående. -Btw testa att maxa excel med nästan 1 miljon rader och 10 000 kolumner lägg på lite formler och se hur seg er dator är, detta utan att ni har gjort något avancerat i Excel.

Stora problemet är ju att likt 4090 så blir dessa bjässar som ökar prestanda över förra generationen dyra, långt dyrare än tidigare kort. Så kommer det bli även nästa varv. Det säljs färre sådana kort än gamla toppkort vilket vrider upp priset ännu mer. Det blir en ond spiral som driver på stagnationen ännu mer

Var den gränden går är såklart individuellt. Men de flesta kan nog hålla med om att det är trevligare när 8 495Kr är okristligt mycket (1080 TI) än när okristligt mycket är 21 990 Kr (4090).

Sen får man såklart ta hänsyn till reallöner, inflation etc etc men även när man gör det så blir det ju ingen förmildrande omständighet i fallet 4090.

Sen om nu tillverkarna verkligen talar sanning och skyhöga kostnader för nya noder som kostar fan i helvete verkligen är hela problemet så... OK... Låt bli att utveckla på nya noder tills de blivit billigare och gör som intel och gör en ny arkitektur på samma nod då istället. Hela PC-DIY-intresset håller ju på att eroderas just på grund av att allt blivit smärtsamt dyrt. Och jag tror inte att intresset för de flesta går ut på ren förundran över vad som är möjligt rent tekniskt om "möjligt" innebär att ingen har råd.

Nya tillverkningsnoder blir inte billigare om de inte används.
Den teknik och utrustning som behövs för nya tillverkningsnoder kostar väldigt att ta fram och konstruera i sig. De pengarna behöver företagen (i alla led) få tillbaka på något sätt. Om köper in utrustning för nya noder så finns det inte pengar att utveckla kommande generationer. Om utrustningen köps in men inte används så är massa pengar kastade i sjön.

Tyvärr har vi nog nått en punkt i datorutvecklingen (liksom i många andra teknikområden) där om det skall bli signifikant bättre så blir det dyrare.
För att komma runt det så krävs det någon slags ganska fundamentalt tekniskt/vetenskapligt genombrott. Något i stil med uppfinnandet av integrerade kretsar på sin tid.

Älskar personligen lågnivåprogrammering och prestandaoptimeringar. Något som ändå ofta glöms bort i "det var bättre optimerat förr" diskussionen är att vi idag designar system som hanterar långt större och mer komplexa dataset jämfört med tidigare.

Det var fullt realistiskt att skriva spel i assembler på C64/Spectrum tiden (i praktiken ett krav) och till viss del på Amiga/Atari ST (här hade ändå C blivit ett realistiskt alternativ). Men de spelen kan inte jämföras med dagens sett till komplexitet. Jag skulle då inte vilja skriva moderna spel i Assembler (men det är däremot helt vettigt att idag skriva IO-drivers i Assembler till RPi Pico )...

Microservices har som allt annat för- och nackdelar. Förutsatt att man har ett "tillräckligt komplext system" som hanterar "tillräckligt många samtida transaktioner" väger fördelar med microservices klart upp nackdelarna.

Sen finns alltid friktion när någon större förändring sker. Rent praktiskt/logiskt fungerar ju de tekniker vi blivit vana att använda, som Java, Dotnet, NodeJS etc hur bra som helst även till microservices.

Men dessa tekniker är ändå rätt mycket designade under "monolit-eran" så huvudfokus har inte varit att minimera "one-time overhead" kostnader för den typen av applikationer. Är framförallt mängden RAM som drar iväg hos dessa, ett icke-problem när man körde en virtuell maskin per system, inte som nu när man i praktiken blir tvingad till en per microservices...

Det är ett fullt lösbart problem. Jämför en minimal service skriven med JVM/Dotnet/Node kontra en skriven i t.ex. Go (en miljö som designades efter microservice trenden tagit fart). Alla dessa kör med GC, de har ungefär samma abstraktionsnivå, men Go är trots det väldigt nära C/C++/Rust i "one time overhead" som i sin tur är (med lite snabb testning här lokalt) verkar vara ungefär en tiopotens längre jämfört med JVM/Dotnet/Node.

TL;DR på det är att det är ett övergående problem och microservices är inte i sig ett fundamentalt problem.

Helt sant att Unity (som jag förstår är den näst mest använda spelmotorn idag, det efter Roblox) har en rad begränsningar. En stor sådan givet både denna artikel och trenden mot allt fler CPU-kärnor i desktop-maskiner är att den motorn gör det väldigt svårt att effektivt utnyttja många CPU-kärnor. Väldigt mycket i Unity kan i praktiken bara köras på en enda tråd!!

Det är dock en avvägning. Genom att göra så har en rad saker blivit enklare och länge var det inte något jättestort problem. Rätt nyligen lanseras 1.0 av det Unity kallar ESC (Entity Component System). Det kommer vara lite mer utmanande att jobba i ESC, men det ger nya möjligheter!

Även om man forsätter skriva i C# kommer det i praktiken bli en "specialvariant" av C#, något som kan bli lite förvirrande framförallt för de som är bekväm med Dotnet och "vanlig" C#.

T.ex. får man rätt mycket skrota alla tankar på "objektorienterad design" i ESC då OOP lämpar sig rätt dåligt för parallell-programmering. Med ESC kommer vissa typer av spelmoment effektivt kunna använda ordentligt med CPU-kärnor. Skulle allt detta gjorts från scratch vore nog C# fel val av programspråk, men är rätt att behålla det för att kunna göra en gradvis övergång.

Väldigt lätt att med ECS ha tiotusentals "spelobjekt" som alla animeras, kollar kollisioner etc på en dator med 16C/32T och där effektivt använda alla CPU-kärnor. Tekniken gör det också möjligt att effektivt dela upp arbeten som bäst körs på "många svaga CPU-kärnor" och det som behöver en stark CPU-kärna (så framtida spel som lämpar sig för denna teknik kommer bättre kunna utnyttja asymmetriska CPU-designer).

Finns andra saker som inte alls går att skala på samma sätt (d.v.s. detta är inte en silverkula som gör att alla spel framåt kan använda massor med CPU-kärnor), men det är ändå möjligt att börja designa en ny typ av spelmekanik som effektivt kan använda många CPU-kärnor. Så kanske 3-5 år från nu kan vi börja se de titlar som drar bra nytt av detta

ESC/DOTS är ett exempel där man med mer programvara kan göra något som i grunden rätt mycket är för komplext att hantera för varje enskild individ till (genom att begränsa scope + göra massa hjälpmedel runt det hela) till något som blir relativt tillgängligt. Tyvärr kommer det med egna kostnader... Kompileringstiderna går från "nästan ingenting", till "minst lika illa som Unreal Engine"...