Enhver prosessorinstruksjon har flere trinn i driften. Hvert av disse stadiene tar en enkelt CPU-syklus å fullføre. Disse stadiene er Instruksjonshenting, Instruksjonsdekoding, Utfør, Minnetilgang og Tilbakeskrivning. Henholdsvis disse får instruksjonen som skal fullføres, skiller operasjonen fra verdiene som opereres på, utfør prosessen, åpne registeret som resultatet skal skrives på, og skriv resultatet til det åpnede registrere.
Historiske prosessorer i rekkefølge
På tidlige datamaskiner brukte ikke CPU en instruksjonsrørledning. I disse CPUene måtte hver enkeltsyklusoperasjon skje for hver instruksjon. Dette betydde at det tok fem klokkesykluser før den gjennomsnittlige instruksjonen ble behandlet helt før den neste kunne startes. Noen operasjoner trenger kanskje ikke å skrive noe resultat ut til et register, noe som betyr at minnetilgangs- og tilbakeskrivningsstadiene kan hoppes over.
Det er imidlertid et problem som lurer når du kjører en fullstendig instruksjon i rekkefølge før du kan gå videre til neste instruksjon. Problemet er cache-missen. CPU-en lagrer data den aktivt behandler i registeret. Dette kan nås med en en-syklus latency. Problemet er at registeret er lite fordi det er innebygd i prosessorkjernen. CPU-en må gå til den større, men tregere L1-cachen hvis dataene ikke allerede er lastet inn. Hvis den ikke er der, må den gå til den større og tregere L2-cachen igjen. Det neste trinnet er L3-cachen; det siste alternativet er system-RAM. Hvert av disse alternativene tar flere og flere CPU-sykluser å sjekke.
Nå kan denne ekstra ekstra ventetiden være et stort problem i et system som må fullføre hver instruksjon i sin helhet før du starter neste instruksjon. Det som hadde vært en 5-syklus per instruksjonsprosessor, kan plutselig bli hengt opp i én instruksjon for dusinvis eller hundrevis av klokkesykluser. Hele tiden kan ingenting annet skje på datamaskinen. Teknisk sett kan dette lindres noe ved å ha to uavhengige kjerner. Ingenting hindrer dem begge i å gjøre det samme, potensielt samtidig. Så å gå nedover flerkjerneruten løser ikke dette.
Den klassiske RISC-rørledningen
RISC står for Reduced Instruction Set Computer. Det er en prosessordesignstil som optimerer ytelsen ved å gjøre dekodingen av hver instruksjon enklere. Dette er i forhold til CISC eller Complex Instruction Set Computer, som designer mer komplekse instruksjonssett som gjør at færre instruksjoner er nødvendige for å utføre de samme oppgavene.
Den klassiske RISC-designen inkluderer en instruksjonsrørledning. I stedet for å kjøre noen av de fem instruksjonstrinnene i en gitt syklus, lar rørledningen alle fem trinnene utføres. Selvfølgelig kan du ikke kjøre alle fem trinnene i en instruksjon i en syklus. Men du kan stille fem påfølgende instruksjoner i kø med en forskyvning på ett trinn hver. På denne måten kan en ny instruksjon fullføres hver klokkesyklus. Tilbyr en potensiell 5x ytelsesøkning for en relativt lav økning i kjernekompleksitet.
Prosessorer som ikke har en pipeline kan bare være sub-skalære, siden de ikke kan utføre én komplett instruksjon per syklus. Med denne primære fem-trinns pipeline kan du lage en skalar CPU som kan fullføre en instruksjon for hver prosess. Ved å lage enda mer vidtrekkende rørledninger kan du lage superskalære CPUer som kan utføre mer enn én instruksjon per klokkesyklus. Selvfølgelig er det fortsatt potensielle problemer.
Fortsatt sekvensiell
Ingenting av dette løser problemet med å vente i mange sykluser på svar når det er behov for å spørre etter de forskjellige nivåene av cache og RAM. Det introduserer også et nytt problem. Hva om en instruksjon er avhengig av utdata fra den forrige instruksjonen? Disse problemene løses uavhengig med en avansert dispatcher. Den planlegger utførelsesrekkefølgen nøye slik at ingen instruksjoner som er avhengige av utdata fra en annen er for nær hverandre. Den håndterer også cache-misser ved å parkere en instruksjon og erstatte den i rørledningen med en annen instruksjoner som er klare til å kjøre og som ikke krever resultatet, fortsetter instruksjonen når den er det klar.
Disse løsningene kan fungere på prosessorer uten pipeline, men de kreves for en superskalarprosessor som kjører mer enn én instruksjon per klokke. En grenprediktor er også svært nyttig siden den kan prøve å forutsi utfallet av en instruksjon med mer enn ett potensielt utfall og fortsette å anta at det er riktig med mindre annet er bevist.
Konklusjon
En pipeline gjør at alle prosessorens distinkte muligheter kan brukes i hver syklus. Den gjør dette ved å kjøre forskjellige stadier av forskjellige instruksjoner samtidig. Dette legger ikke engang mye kompleksitet til CPU-designet. Det baner også vei for å tillate mer enn én instruksjon å utføre et enkelt trinn per syklus.