Instruction pipelining

Fordele og ulemper ved pipelining

Fordele ved pipelining:

1. Processorens cyklustid reduceres, hvilket øger instruktionsgennemstrømningen. Pipelining reducerer ikke den tid, det tager at gennemføre en instruktion; i stedet forøges antallet af instruktioner, der kan behandles samtidigt ("på én gang"), og forsinkelsen mellem de gennemførte instruktioner reduceres (kaldet "gennemløb").
   Jo flere pipeline-trin en processor har, jo flere instruktioner kan den behandle "på én gang", og jo mindre forsinkelse er der mellem de færdige instruktioner. Alle de mest udbredte mikroprocessorer til
   generelle formål, der fremstilles i dag, anvender mindst 2 trin af pipeline op til 30 eller 40 trin.
2. Hvis der anvendes pipelining, kan den aritmetiske logikenhed i CPU'en designes hurtigere, men den vil være mere kompleks.
3. Pipelining øger i teorien ydeevnen i forhold til en kerne uden pipelining med en faktor svarende til antallet af trin (forudsat at clockfrekvensen også øges med samme faktor), og koden er ideel til pipelineudførelse.
4. Pipelined CPU'er arbejder generelt med en højere clockfrekvens end RAM- clockfrekvensen (siden 2008-teknologier arbejder RAM'er med lave frekvenser sammenlignet med CPU-frekvenser), hvilket øger computernes samlede ydeevne.

Ulemper ved pipelining:

Pipelining har mange ulemper, selv om der er mange teknikker, som CPU'er og compileringsdesignere bruger til at overvinde de fleste af dem; nedenfor er en liste over almindelige ulemper:

1. Designet af en non-pipelined-processor er enklere og billigere at fremstille, og non-pipelined-processoren udfører kun en enkelt instruktion ad gangen. Dette forhindrer forsinkelser i forbindelse med forgreninger (i pipelining forsinkes alle forgreninger) og problemer, når serielle instruktioner udføres samtidig.
2. I en pipelined-processor øger indsættelse af flipflops mellem modulerne instruktionslatenstiden sammenlignet med en ikke-pipelined-processor.
3. En ikke-pipelined-processor vil have en defineret instruktionsgennemstrømning. En pipelined-processors ydeevne er meget sværere at forudsige, og den kan variere meget for forskellige programmer.
4. Mange design omfatter pipelines med en længde på 7, 10, 20, 31 og endnu flere trin; en ulempe ved en lang pipeline er, at når et program forgrener sig, skal hele pipelinen skylles (ryddes). Den højere gennemløbskapacitet ved pipelines falder til kort, når den udførte kode indeholder mange forgreninger: processoren kan ikke på forhånd vide, hvor den skal læse den næste instruktion, og må vente på, at forgreningsinstruktionen er færdig, hvorved pipelinen bag den bliver tom. Denne ulempe kan reduceres ved at forudsige, om en betinget greninstruktion vil forgrene sig på grundlag af tidligere aktivitet. Efter at forgreningen er løst, skal den næste instruktion hele vejen gennem pipelinen, før dens resultat bliver tilgængeligt, og processoren genoptager "arbejdet" igen. I sådanne ekstreme tilfælde kan en pipelined-processor have en dårligere ydeevne end en processor uden pipelined-processor.
5. Desværre er ikke alle instruktioner uafhængige. I en simpel pipeline kan det kræve 5 trin at fuldføre en instruktion. Hvis denne pipeline skal fungere med fuld ydeevne, skal den køre 4 efterfølgende uafhængige instruktioner, mens den første færdiggøres. Enhver af disse 4 instruktioner kan være afhængig af output fra den første instruktion, hvilket får pipeline-kontrollogikken til at vente og indsætte en stall eller en spildt clockcyklus i pipelinen, indtil afhængigheden er løst. Heldigvis kan teknikker som forwarding reducere antallet af tilfælde, hvor der er behov for at trække tiden i langdrag, betydeligt.
6. Selvmodificerende programmer kan ikke udføres korrekt på en pipelined-arkitektur, når de instruktioner, der ændres, er tæt på de instruktioner, der udføres. Dette kan skyldes, at instruktionerne måske allerede befinder sig i prefetch-inputkøen, så ændringen måske ikke får virkning for den kommende udførelse af instruktioner. Instruktionscaches gør problemet endnu værre.
7. Farer: Når en programmør (eller en compiler) skriver assemblerkode, antager de generelt, at hver instruktion udføres, før den næste instruktion udføres. Når denne antagelse ikke valideres ved hjælp af pipelining, medfører det, at et program opfører sig forkert, og situationen kaldes en fare. Der findes
   forskellige teknikker til at løse farer eller til at omgå dem, f.eks. forwarding og delaying (ved at indsætte en stall eller en spildt clockcyklus).

Eksempler

Generisk rørledning

Til højre ses en generisk rørledning med fire trin:

1. Hent
2. Afkodning
3. Udfør
4. Tilbagebeskrivelse

Den øverste grå boks er listen over instruktioner, der venter på at blive udført; den nederste grå boks er listen over instruktioner, der er blevet udført; og den midterste hvide boks er pipelinen.

Udførelsen er som følger:

Tid	Udførelse
0	Fire instruktioner venter på at blive udført
1	den grønne instruktion hentes fra hukommelsen
2	den grønne instruktion afkodes den lilla instruktion hentes fra hukommelsen
3	den grønne instruktion udføres (den faktiske operation udføres) den lilla instruktion afkodes den blå instruktion er hentet
4	resultaterne af den grønne instruks skrives tilbage til registerfilen eller hukommelsen den lilla instruktion udføres den blå instruktion afkodes den røde instruktion er hentet
5	den grønne instruktion er afsluttet den lilla instruktion skrives tilbage den blå instruktion udføres den røde instruktion afkodes
6	Den lilla instruktion er afsluttet den blå instruktion skrives tilbage den røde instruktion udføres
7	den blå instruktion er afsluttet den røde instruktion skrives tilbage
8	den røde instruktion er afsluttet
9	Alle instruktioner udføres

Boble

Når der opstår en "hikke" (afbrydelse) i udførelsen, skabes der en "boble" i pipelinen, hvor der ikke sker noget nyttigt. I cyklus 2 er hentningen af den lilla instruktion forsinket, og afkodningsfasen i cyklus 3 indeholder nu en boble. Alt bag den lilla instruktion er også forsinket, men alt foran den lilla instruktion fortsætter med at blive udført.

Det er klart, at når man sammenligner med udførelsen ovenfor, giver boblen en samlet udførelsestid på 8 clock ticks i stedet for 7.

Bubbles er som stalls (forsinkelser), hvor der ikke sker noget nyttigt i forbindelse med hentning, afkodning, udførelse og tilbageskrivning. Det er som en NOP-kode (forkortelse for No OPeration).

Eksempel 1

En typisk instruktion til at addere to tal kan være ADD A, B, C, som adderer værdierne i hukommelsesplaceringerne A og B og derefter placerer resultatet i hukommelsesplacering C. I en pipeline-processor vil pipelinecontrolleren opdele dette i en række opgaver svarende til:

LOAD A, R1 LOAD B, R2 ADD R1, R2, R3 STORE R3, C LOAD næste instruktion

Placeringerne "R1" og "R2" er registre i CPU'en. De værdier, der er gemt i hukommelsesplaceringer mærket "A" og "B", indlæses (kopieres) i disse registre og lægges derefter sammen, hvorefter resultatet gemmes i en hukommelsesplacering mærket "C".

I dette eksempel består pipelinen af tre trin - indlæsning, udførelse og lagring. Hvert af disse trin kaldes pipeline-trin.

På en ikke-pipelined-processor kan kun ét trin arbejde ad gangen, så hele instruktionen skal være afsluttet, før den næste instruktion kan begynde. På en pipelined-processor kan alle trin arbejde på forskellige instruktioner på samme tid. Så når denne instruktion er på eksekveringsstadiet, vil en anden instruktion være på afkodningsstadiet og en tredje instruktion vil være på hentningsstadiet.

Eksempel 2

For bedre at forstå konceptet kan vi se på en teoretisk 3-trins pipeline:

Scene	Beskrivelse
Belastning	Læs instruktion fra hukommelsen
Udfør	Udfør instruktion
Butik	Lagre resultatet i hukommelse og/eller registre

og en pseudokode, der skal udføres:

Sådan vil det blive gennemført:

Ur 1
Belastning	Udfør	Butik
LAD

LOAD-instruktionen hentes fra hukommelsen.

Ur 2
Belastning	Udfør	Butik
MOVE	LAD

LOAD-instruktionen udføres, mens MOVE-instruktionen hentes fra hukommelsen.

Ur 3
Belastning	Udfør	Butik
TILFØJ	MOVE	LAD

LOAD-instruktionen er i Store-stadiet, hvor resultatet (tallet 40) gemmes i register A. I mellemtiden udføres MOVE-instruktionen. Da den skal flytte indholdet af A til B, skal den vente på, at LOAD-instruktionen er afsluttet.

Ur 4
Belastning	Udfør	Butik
STORE	TILFØJ	MOVE

STORE-instruktionen er indlæst, mens MOVE-instruktionen er ved at blive afsluttet, og ADD-instruktionen er ved at blive beregnet.

Og så videre. Bemærk, at en instruktion nogle gange afhænger af resultatet af en anden instruktion (som i vores MOVE-eksempel). Når mere end én instruktion refererer til en bestemt placering for en operand, enten ved at læse den (som input) eller skrive den (som output), kan det føre til den ovenfor beskrevne situation, hvis disse instruktioner udføres i en anden rækkefølge end den oprindelige programrækkefølge.

Generisk 4-trins pipeline; de farvede bokse repræsenterer instruktioner, der er uafhængige af hinanden


En boble i cyklus 3 forsinker udførelsen

Relaterede sider

• Pipeline (databehandling)
• Parallel databehandling
• Parallelitet på instruktionsniveau