15 sep. 2025·8 min
David Patterson, RISC-tänkandet och samdesignens bestående påverkan
Utforska hur David Pattersons RISC-tänkande och hårdvaru–mjukvaru-samdesign förbättrade prestanda per watt, formade CPU:er och påverkar RISC-V idag.
Utforska hur David Pattersons RISC-tänkande och hårdvaru–mjukvaru-samdesign förbättrade prestanda per watt, formade CPU:er och påverkar RISC-V idag.
David Patterson introduceras ofta som “en pionjär inom RISC”, men hans bestående inflytande är bredare än någon enskild CPU-design. Han hjälpte till att popularisera ett praktiskt sätt att tänka på datorer: behandla prestanda som något du kan mäta, förenkla och förbättra end-to-end — från instruktionerna en krets förstår till de mjukvaruverktyg som genererar dessa instruktioner.
RISC (Reduced Instruction Set Computing) är idén att en processor kan köras snabbare och mer förutsägbart när den fokuserar på ett mindre antal enkla instruktioner. Istället för att bygga en stor meny av komplicerade operationer i hårdvara gör du de vanliga operationerna snabba, regelbundna och lätta att pipelina. Vinsten är inte "mindre kapacitet" — det är att enkla byggstenar, utförda effektivt, ofta vinner i verkliga arbetslaster.
Patterson förespråkade också hårdvaru–mjukvaru-samdesign: en återkopplingsloop där kretsarkitekter, kompilatorförfattare och systemdesigners itererar tillsammans.
Om en processor är utformad för att köra enkla mönster bra kan kompilatorer pålitligt producera dessa mönster. Om kompilatorer visar att verkliga program spenderar tid på vissa operationer (som minnesåtkomst) kan hårdvaran justeras för att hantera de fallen bättre. Därför kopplas diskussioner om en instruktionsuppsättning (ISA) naturligt ihop med kompilatoroptimeringar, cachning och pipelining.
Du kommer att förstå varför RISC-idéer kopplar till prestanda per watt (inte bara rå hastighet), hur "förutsägbarhet" gör moderna CPU:er och mobila kretsar mer effektiva, och hur dessa principer visar sig i dagens enheter — från laptops till molnservrar.
Om du vill ha en karta över nyckelkoncepten innan du dyker djupare, hoppa vidare till /blog/key-takeaways-and-next-steps.
Tidiga mikroprocessorer byggdes under knappa förhållanden: kretsarna hade begränsat utrymme för logik, minne var dyrt och lagring var långsam. Designerna försökte leverera datorer som var prisvärda och "tillräckligt snabba", ofta med små cacher (eller inga), modest klockfrekvens och mycket begränsat huvudminne jämfört med vad mjukvaran önskade.
En populär idé var att om CPU:n erbjöd kraftfullare, hög-nivå-instruktioner — sådana som kunde göra flera steg på en gång — skulle programmen köra snabbare och vara enklare att skriva. Om en instruktion kunde "göra arbetet av flera" skulle du behöva färre instruktioner totalt, löd resonemanget.
Det är intuitionen bakom många CISC-designs: ge programmerare och kompilatorer en stor verktygslåda med fiffiga operationer.
Problemet var att verkliga program (och de kompilatorer som översatte dem) inte konsekvent utnyttjade den komplexiteten. Många av de mest invecklade instruktionerna användes sällan, medan en liten mängd enkla operationer — ladda data, lagra data, addera, jämföra, hoppa — dök upp om och om igen.
Samtidigt gjorde stödet för en enorm meny av komplexa instruktioner CPU:erna svårare att bygga och långsammare att optimera. Komplexitet förbrukade kiselarea och designinsats som kunde ha lagts på att göra de vanliga vägarna snabba och förutsägbara.
RISC var ett svar på det gapet: fokusera CPU:n på vad mjukvaran faktiskt gör mest, och gör dessa vägar snabba — låt sedan kompilatorer ta mer av "orkestreringsarbetet" på ett systematiskt sätt.
Ett enkelt sätt att tänka på CISC vs RISC är att jämföra verktygslådor.
CISC (Complex Instruction Set Computing) är som en verkstad fylld med många specialiserade, avancerade verktyg — varje verktyg kan göra mycket i ett enda drag. En enda "instruktion" kan ladda data från minnet, göra en beräkning och lagra resultatet, allt ihop.
RISC (Reduced Instruction Set Computing) är som att bära en mindre uppsättning pålitliga verktyg du använder hela tiden — hammare, skruvmejsel, tumstock — och bygga allt från upprepade steg. Varje instruktion gör vanligtvis ett litet, tydligt jobb.
När instruktionerna är enklare och mer enhetliga kan CPU:n exekvera dem med ett renare löpband (en pipeline). Det löpbandet är lättare att designa, lättare att köra på högre klockfrekvenser och lättare att hålla igång.
Med CISC-stilens "gör-mycket"-instruktioner måste CPU:n ofta avkoda och bryta en komplex instruktion i mindre interna steg ändå. Det kan lägga till komplexitet och göra det svårare att hålla pipelinen flödande.
RISC strävar efter förutsägbar instruktionstid — många instruktioner tar ungefär samma tid. Förutsägbarhet hjälper CPU:n att schemalägga arbete effektivt och hjälper kompilatorer att generera kod som håller pipelinen matad istället för att stanna upp.
RISC behöver vanligtvis fler instruktioner för att utföra samma uppgift. Det kan innebära:
Men det kan ändå vara fördelaktigt om varje instruktion är snabb, pipelinen hålls jämn och designen är enklare.
I praktiken kan väloptimerade kompilatorer och bra caching väga upp nackdelen med "fler instruktioner" — och CPU:n kan spendera mer tid på att göra användbart arbete och mindre tid på att reda ut komplicerade instruktioner.
Berkeley RISC var inte bara en ny instruktionsuppsättning. Det var en forskningsattityd: börja inte med vad som verkar elegant på papper — börja med vad program faktiskt gör och forma CPU:n efter den verkligheten.
Konceptuellt siktade Berkeley-teamet på en CPU-kärna som var tillräckligt enkel för att köras mycket snabbt och förutsägbart. Istället för att packa hårdvaran med många komplicerade instruktionstrick förlitade man sig på kompilatorn för att göra mer av jobbet: välja raka instruktioner, schemalägga dem väl och hålla data i register så mycket som möjligt.
Denna arbetsdelning spelade roll. En mindre, renare kärna är lättare att pipelina effektivt, lättare att resonera kring och ofta snabbare per transistor. Kompilatorn, som ser hela programmet, kan planera på sätt som hårdvara inte lätt kan göra i farten.
David Patterson betonade mätning eftersom datordesign är full av frestande myter — funktioner som låter användbara men sällan syns i verklig kod. Berkeley RISC drev på att använda benchmarks och arbetsladespår för att hitta de heta vägarna: looparna, funktionsanropen och minnesaccesserna som dominerar körtiden.
Detta kopplar direkt till principen "gör det vanliga fallet snabbt". Om de flesta instruktioner är enkla operationer och load/store, då ger optimering av dessa frekventa fall större utdelning än att accelerera sällsynta, komplexa instruktioner.
Den bestående slutsatsen är att RISC var både en arkitektur och ett tankesätt: förenkla det som är frekvent, validera med data och behandla hårdvara och mjukvara som ett enda system som kan stämmas av tillsammans.
Hårdvaru–mjukvaru-samdesign är idén att du inte designar en CPU i isolering. Du designar kretsen och kompilatorn (och ibland operativsystemet) med varandra i åtanke, så att verkliga program körs snabbt och effektivt — inte bara syntetiska "bäst-fall"-instruktionssekvenser.
Samdesign fungerar som en ingenjörsloop:
ISA-val: instruktionsuppsättningen bestämmer vad CPU:n lätt kan uttrycka (till exempel "load/store"-minnesåtkomst, många register, enkla adresseringslägen).
Kompilatorstrategier: kompilatorn anpassar sig — håller heta variabler i register, omordnar instruktioner för att undvika stalls och väljer calling conventions som minskar overhead.
Arbetslaster: du mäter verkliga program (kompilatorer, databaser, grafik, OS-kod) och ser var tid och energi går åt.
Nästa design: du finjusterar ISA och mikroarkitektur (pipelinedjup, antal register, cachestorlekar) baserat på dessa mätningar.
Här är en liten loop (C) som lyfter fram relationen:
for (int i = 0; i < n; i++)
sum += a[i];
På en RISC-stil ISA håller kompilatorn typiskt sum och i i register, använder enkla load-instruktioner för a[i] och utför instruction scheduling så att CPU:n hålls upptagen medan en load är i färd.
Om en krets lägger till komplexa instruktioner eller specialhårdvara som kompilatorer sällan använder, förbrukar det ändå effekt och designinsats. Samtidigt kan de "tråkiga" saker som kompilatorer faktiskt förlitar sig på — tillräckligt många register, förutsägbara pipelines, effektiva calling conventions — vara underfinansierade.
Pattersons RISC-tänkande betonade att lägga kisel där verklig mjukvara faktiskt kan dra nytta.
En viktig RISC-idé var att göra CPU:ns "monteringslinje" enklare att hålla igång. Denna monteringslinje är pipelinen: istället för att avsluta en instruktion helt innan nästa startas bryter processorn arbetet i steg (hämta, avkoda, exekvera, skriva tillbaka) och överlappar dem. När allt flyter slutför du nära en instruktion per cykel — som bilar genom en fabrik med flera stationer.
Pipelines fungerar bäst när varje enhet på linjen är lik. RISC-instruktioner designades för att vara relativt enhetliga och förutsägbara (ofta fast längd, med enkla adresseringsformat). Det minskar "specialfall" där en instruktion behöver extra tid eller ovanliga resurser.
Verkliga program är inte perfekt jämna. Ibland beror en instruktion på resultatet av en föregående (du kan inte använda ett värde innan det beräknats). Ibland måste CPU:n vänta på data från minnet, eller så vet den inte ännu vilken gren som ska följas.
Dessa situationer orsakar stalls — korta pauser där delar av pipelinen står stilla. Intuitionen är enkel: stalls uppstår när nästa steg inte kan göra användbart arbete eftersom något det behöver inte har kommit fram.
Här visar sig hårdvaru–mjukvaru-samdesign tydligt. Om hårdvaran är förutsägbar kan kompilatorn hjälpa genom att omordna instruktioner (utan att ändra programmets betydelse) för att fylla "luckor." Till exempel, medan man väntar på ett värde, kan kompilatorn schemalägga en oberoende instruktion som inte beror på det värdet.
Resultatet är delat ansvar: CPU:n hålls enklare och snabb på det vanliga fallet, medan kompilatorn gör mer planering. Tillsammans minskar de stalls och ökar genomströmningen — ofta förbättrar detta verklig prestanda utan att behöva en mer komplex instruktionsuppsättning.
En CPU kan utföra enkla operationer på några cykler, men att hämta data från huvudminnet (DRAM) kan ta hundratals cykler. Detta gap finns eftersom DRAM är fysiskt längre bort, optimerat för kapacitet och kostnad, och begränsat av både latens (hur lång tid en förfrågan tar) och bandbredd (hur många bytes per sekund som kan flyttas).
När CPU:er blev snabbare höll inte minnet jämna steg i samma takt — detta växande missförhållande kallas ofta memory wall.
Cacher är små, snabba minnen placerade nära CPU:n för att undvika DRAM-straffet vid varje åtkomst. De fungerar eftersom verkliga program har lokalitet:
Moderna kretsar staplar cacher (L1, L2, L3) för att hålla "working set" av kod och data nära kärnan.
Här visar hårdvaru–mjukvaru-samdesign sin nytta. ISA och kompilatorn tillsammans formar hur mycket cache-tryck ett program skapar.
I vardagliga termer är memory wall anledningen till att en CPU med hög klockfrekvens ändå kan kännas seg: att öppna en stor app, köra en databasfråga, scrolla ett flöde eller bearbeta en stor dataset buntas ofta upp av cache-missar och minnesbandbredd — inte rå aritmetisk hastighet.
Länge lät CPU-diskussioner som ett lopp: vilken krets som avslutade en uppgift snabbast "vann." Men verkliga datorer lever inom fysiska gränser — batterikapacitet, värme, fläktljud och elkostnader.
Därför blev prestanda per watt en central mätpunkt: hur mycket användbart arbete får du för energin du spenderar.
Tänk på det som effektivitet, inte toppstyrka. Två processorer kan kännas lika snabba i vardagligt bruk, men den ena kan göra det samtidigt som den drar mindre ström, håller sig svalare och kör längre på samma batteri.
I laptops och telefoner påverkar detta direkt batteritid och komfort. I datacenter påverkar det kostnaden för att driva och kyla tusentals maskiner, plus hur tätt du kan packa servrar utan överhettning.
RISC-tänkandet lutade CPU-design mot att göra färre saker i hårdvara, mer förutsägbart. En enklare kärna kan minska effekt på flera sätt:
Poängen är inte att "enkelt alltid är bättre." Poängen är att komplexitet har en energikostnad, och en väl vald instruktionsuppsättning och mikroarkitektur kan byta lite listighet mot mycket effektivitet.
Telefoner bryr sig om batteri och värme; servrar bryr sig om strömförsörjning och kylning. Olika miljöer, samma lärdom: den snabbaste kretsen är inte alltid den bästa datorn. Vinnarna är ofta designer som levererar stadig genomströmning samtidigt som energianvändningen hålls under kontroll.
RISC sammanfattas ofta som "enklare instruktioner vinner", men den mer bestående lärdomen är mer nyanserad: instruktionsuppsättningen spelar roll, men många verkliga vinster kom från hur kretsar byggdes, inte bara hur ISA såg ut på papper.
Tidiga RISC-argument antydde att en renare, mindre ISA automatiskt skulle göra datorer snabbare. I praktiken kom de största hastighetsvinsterna ofta från implementeringsval som RISC gjorde lättare: enklare avkodning, djupare pipelining, högre klockar och kompilatorer som kunde schemalägga arbete mer förutsägbart.
Därför kan två CPU:er med olika ISA hamna förvånansvärt nära i prestanda om deras mikroarkitektur, cachestorlekar, grenprediktion och tillverkningsprocess skiljer — ISA:n sätter reglerna; mikroarkitekturen spelar spelet.
En viktig förändring under Pattersons era var att designa från data, inte antaganden. Istället för att lägga till instruktioner eftersom de verkade användbara mätte team vad program faktiskt gjorde och optimerade för det vanliga fallet.
Detta tankesätt överträffade ofta "funktionsdriven" design, där komplexiteten växer snabbare än vinsterna. Det gör också avvägningar tydligare: en instruktion som sparar några kodrader kan kosta extra cykler, energi eller kiselarea — och de kostnaderna syns överallt.
RISC-tänkande formade inte bara "RISC-chip." Med tiden antog många CISC-CPU:er RISC-liknande interna tekniker (till exempel att bryta komplexa instruktioner i enklare interna operationer) samtidigt som de behöll sina kompatibla ISA:er.
Så utgången var inte "RISC besegrade CISC." Det var en evolution mot designer som värdesätter mätning, förutsägbarhet och tajt hårdvaru–mjukvarukoordination — oavsett vilken logotyp som sitter på ISA:n.
RISC stannade inte i labbet. En av de tydligaste trådarna från tidig forskning till modern praxis går från MIPS till RISC-V — två ISA:er som gjorde enkelhet och klarhet till en egenskap, inte en begränsning.
MIPS är ofta ihågkommen som en undervisnings-ISA, och av goda skäl: reglerna är lätta att förklara, instruktionsformaten är konsistenta och den grundläggande load/store-modellen står ut ur kompilatorns väg.
Denna renhet var inte bara akademisk. MIPS-processorer levererades i verkliga produkter i åratal (från arbetsstationer till inbyggda system), delvis eftersom en okomplicerad ISA gör det lättare att bygga snabba pipelines, förutsägbara kompilatorer och effektiva verktygskedjor. När hårdvarubeteendet är regelbundet kan mjukvaran planera kring det.
RISC-V återupplivade intresset för RISC-tänkande genom att ta ett steg MIPS aldrig gjorde: den är en öppen ISA. Det förändrar incitamenten. Universitet, startups och stora företag kan experimentera, leverera silikon och dela verktyg utan att förhandla om åtkomst till instruktionsuppsättningen.
För samdesign spelar den öppenheten roll eftersom "mjukvarusidan" (kompilatorer, OS, runtime) kan utvecklas offentligt parallellt med "hårdvarusidan" med färre konstlade hinder.
En annan anledning till att RISC-V passar bra för samdesign är dess modulära angreppssätt. Du börjar med en liten bas-ISA och lägger till tillägg för specifika behov — som vektormatris, inbyggda begränsningar eller säkerhetsfunktioner.
Detta uppmuntrar en hälsosammare avvägning: istället för att proppa in varje möjlig funktion i en monolitisk design kan team anpassa hårdvarufunktioner efter den mjukvara de faktiskt kör.
Vill du ha en djupare introduktion, se /blog/what-is-risc-v.
Samdesign är inte en historisk parentes från RISC-eran — det är hur modern databehandling fortsätter bli snabbare och mer effektiv. Nyckelidén är fortfarande Patterson-stilen: du "vinner" inte med bara hårdvara eller bara mjukvara. Du vinner när de två passar varandras styrkor och begränsningar.
Smartphones och många inbyggda enheter lutar tungt mot RISC-principer (ofta ARM-baserade): enklare instruktioner, förutsägbar exekvering och stark betoning på energianvändning.
Denna förutsägbarhet hjälper kompilatorer att generera effektiv kod och hjälper designers att bygga kärnor som dricker lite ström när du scrollar, men som kan ge en prestandaökning för kamerapipeline eller spel.
Bärbara datorer och servrar strävar i allt högre grad efter samma mål — särskilt prestanda per watt. Även om instruktionsuppsättningen inte traditionellt är "RISC" försöker många interna designval uppnå RISC-liknande effektivitet: djup pipelining, bred exekvering och aggressiv energihantering anpassad till verkligt mjukvarubeteende.
GPU:er, AI-acceleratorer (TPU/ NPU) och mediaenheter är en praktisk form av samdesign: istället för att pressa allt arbete genom en general-purpose CPU erbjuder plattformen hårdvara som matchar vanliga beräkningsmönster.
Det som gör detta till samdesign (inte bara "extra hårdvara") är den omgivande mjukvarustacken:
Om mjukvaran inte riktar sig mot acceleratorn förblir teoretisk hastighet just teoretisk.
Två plattformar med liknande specifikationer kan kännas väldigt olika eftersom "verkliga produkten" inkluderar kompilatorer, bibliotek och ramverk. Ett väloptimerat mattbibliotek (BLAS), en bra JIT eller en smartare kompilator kan ge stora vinster utan att byta krets.
Detta är varför modern CPU-design ofta är benchmark-driven: hårdvaruteam ser vad kompilatorer och arbetslaster faktiskt gör och justerar funktioner (cacher, grenprediktion, vektorinstruktioner, prefetching) för att göra det vanliga fallet snabbare.
När du utvärderar en plattform (telefon, laptop, server eller inbyggt kort) leta efter signaler på samdesign:
Modern datorteknisk framgång handlar mindre om en enskild "snabbare CPU" och mer om ett helt hårdvara-plus-mjukvara-system som formats — mätt och sedan designat — kring verkliga arbetslaster.
RISC-tänkandet och Pattersons bredare budskap kan kokas ner till några bestående lärdomar: förenkla det som måste vara snabbt, mät vad som faktiskt händer, och behandla hårdvara och mjukvara som ett sammanhang — för användarna upplever helheten, inte komponenterna.
För det första är enkelhet en strategi, inte en estetik. En ren instruktionsuppsättning (ISA) och förutsägbar exekvering gör det enklare för kompilatorer att generera bra kod och för CPU:er att köra den effektivt.
För det andra slår mätning intuition. Benchmarka med representativa arbetslaster, samla profileringsdata och låt verkliga flaskhalsar styra beslut — oavsett om du finjusterar kompilatoroptimeringar, väljer en CPU-SKU eller redesignar en kritisk het väg.
För det tredje staplas vinster i samdesign. Pipeline-vänlig kod, cache-medvetna datastrukturer och realistiska mål för prestanda-per-watt levererar ofta mer praktisk hastighet än att jaga teoretisk toppgenomströmning.
Om du väljer plattform (x86, ARM eller RISC-V-baserade system), utvärdera den som dina användare kommer göra:
Om en del av ditt arbete är att förvandla dessa mätningar till levererad mjukvara kan det hjälpa att förkorta build–measure-loopen. Till exempel använder team Koder.ai för att prototypa och utveckla riktiga applikationer via en chattdriven arbetsflöde (webb, backend och mobil), och kör sedan om samma end-to-end-benchmarks efter varje ändring. Funktioner som planning mode, snapshots och rollback stöttar samma "mät, sedan designa"-disciplin Patterson drev — applicerat på modern produktutveckling.
För en djupare introduktion till effektivitet, se /blog/performance-per-watt-basics. Om du jämför miljöer och behöver ett enkelt sätt att uppskatta kostnads-/prestandaavvägningar kan /pricing vara till hjälp.
Den bestående slutsatsen: idéerna — enkelhet, mätning och samdesign — fortsätter ge utdelning, även när implementationerna utvecklas från MIPS-erans pipelines till moderna heterogena kärnor och nya ISA:er som RISC-V.
RISC (Reduced Instruction Set Computing) betonar ett mindre antal enkla, regelbundna instruktioner som är lätta att pipelina och optimera. Målet är inte "mindre kapacitet", utan mer förutsägbar och effektiv körning för de operationer som verkliga program använder mest (laddningar/lagringar, aritmetik, hopp).
CISC erbjuder många komplexa, specialiserade instruktioner som ibland slår ihop flera steg i ett. RISC använder enklare byggstenar (vanligtvis load/store + ALU-operationer) och förlitar sig mer på kompilatorer för att kombinera dessa effektivt. I moderna CPU:er är gränsen suddig eftersom många CISC-chips översätter komplexa instruktioner till enklare interna operationer.
Enklare, mer enhetliga instruktioner gör det lättare att bygga en jämn pipeline (en "monteringslinje" för instruktionsexekvering). Det kan förbättra genomströmningen (nära en instruktion per cykel) och minska tiden som går åt till att hantera specialfall, vilket ofta hjälper både prestanda och energieffektivitet.
En förutsägbar ISA och exekveringsmodell låter kompilatorer konsekvent:
Det minskar pipeline-bubblor och onödigt arbete, och förbättrar verklig prestanda utan att lägga till komplicerade hårdvarufunktioner som mjukvaran inte kommer använda.
Hårdvaru–mjukvaru-samdesign är en iterativ loop där ISA-val, kompilatorstrategier och mätta arbetslaster informerar varandra. Istället för att designa en CPU isolerat finjusterar team hårdvara, verktygskedja och ibland OS/runtime tillsammans så att verkliga program körs snabbare och mer effektivt.
Stalls uppstår när pipelinen inte kan fortsätta eftersom den väntar på något:
RISC-stilens förutsägbarhet hjälper både hårdvara och kompilatorer att minska frekvensen och kostnaden för dessa pauser.
"Memory wall" är gapet som växer mellan snabb CPU-exekvering och långsam huvudminnesåtkomst (DRAM). Cacher (L1/L2/L3) dämpar problemet genom att utnyttja lokalitet:
Men cache-missar kan fortfarande dominera körtiden och göra programminnesbundna även på mycket snabba kärnor.
Det är en mått på effektivitet: hur mycket användbart arbete du får per energienhet. I praktiken påverkar det batteritid, värme, fläktljud och datacentrums kostnader för kraft och kylning. Designbeslut influerade av RISC-tänkande strävar ofta efter förutsägbar exekvering och mindre onödig toggling, vilket kan förbättra prestanda per watt.
Många CISC-designs tog till sig RISC-liknande interna tekniker (pipelining, enklare interna mikrooperationer, fokus på cacher och prediktion) samtidigt som de behöll bakåtkompatibla ISA:er. Den långsiktiga vinsten var därför mer ett tankesätt: mät verkliga arbetslaster, optimera det vanliga fallet och anpassa hårdvara till kompilator-/mjukvarubeteende—inte en enkel "RISC slog CISC"-berättelse.
RISC-V är en öppen ISA med en liten bas och modulära tillägg, vilket gör den väl lämpad för samdesign: team kan anpassa hårdvarufunktioner till specifika mjukvarubehov och utveckla verktygskedjor öppet. Det är en modern fortsättning på "ren kärna + starka verktyg + mätning"-metoden som artikeln beskriver. Se gärna /blog/what-is-risc-v för mer.