pipelining: basisprincipes

Structuur en Organisatie van Computersystemen: deel 2 Yolande Berbers

Pipelining: basisprincipes


pipelining: overzicht wat is pipelining voorbeeld: DLX pipeline hazards

structurele hazards data hazards control hazards

moeilijkheden bij het implementeren van pipelines uitbreiding van een pipeline voor multicyclus-

operaties instructie set en pipelining de MIPS R4000 pipeline fouten en valstrikken


° Ann, Brian, Cathy, Dave hebben elk één wasmand vuile was die moet gewassen, gedroogd, opgevouwen en weggeborgen worden

° Het wassen duurt 30 minuten

° Het drogen duurt 30 minuten

° Het vouwen duurt 30 minuten

° Het wegbergen duurt 30 minuten

A B C D

wat is pipelining: wasserette voorbeeld


sequentieel werken duurt 8 uur voor 4 wasmanden

30Task

Order

B

C

D

ATijd

3030 3030 30 3030 3030 3030 3030 3030

6 PM 7 8 9 10 11 12 1 2 AM



met een pipeline duurt het maar 3.5 uur voor 4 wasmanden !

Task

Order

12 2 AM6 PM 7 8 9 10 11 1

Tijd

B

C

D

A

303030 3030 3030

Begin met taak zodra het kan



wat is pipelining implementatietechniek

meerdere instructies voeren overlappend uit in de tijd te vergelijken met een assemblagelijn in een autofabriek

terminologie pipe stage of pipe segment: 1 stap machine cyclus:

tijd voor 1 stap wordt bepaald door de traagste pipe stage meestal gelijk aan klokcyclus

ideaal:

Speedup: ideaal n

tijd per instr. met pipeline = tijd per instr. zonder pipeline

aantal stages in de pipeline


wat is pipelining (vervolg) ideaal is niet haalbaar

pipeline is niet perfect gebalanceerd overhead

effect van pipelining of reductie van CPI of verkorting van klokcyclus

pipeline is vorm van parallellisme er wordt aan meerdere instructies tegelijk gewerkt volledig transparant voor programmeur


wat is pipelining (vervolg) vb: DLX

eenvoudige implementatie zonder pipeline in 5 klokcycli

1. instruction fetch (IF) een instructie wordt uit het geheugen gehaald de programmateller wordt met 4 verhoogd

2. instruction decode / register fetch (ID) ophalen van registers kan direct want nummer staat

op vaste plaats inhoud van registers gekopieerd naar 2 interne

registers ook de mogelijke immediate wordt uit de instructie

gehaald decoderen gebeurt in parallel


wat is pipelining (vervolg) implementatie zonder pipeline in 5 klokcycli

(vervolg)

3. execution / effective address cycle (EX)afhankelijk van opcode zijn er 4 categorieën:

geheugentoegang (berekening van effectief adres) register-register ALU instructie register-immediate ALU instructie sprong

4. memory access / branch completion cycle (MEM) alleen loads, stores en sprongen voeren uit tijdens

deze cyclus5. write-back (WB)

voor register-register ALU instructie, register-immediate ALU instructie en voor een load instructie


voorbeeld: DLX figuur 3.1:

datapad zonder pipeline multi-cyclus ontwerp: 1 instructie duurt 5 cycli

(behalve sprong en eventueel de ALU-instructies) gebruikt tussenregisters (NPC, IR, A, B, Imm, ...) voor

bijhouden van informatie nodig in de volgende klokcyclus

zou kunnen geoptimiseerd worden bv zelfde ALU voor verhogen programmateller en

operaties maar uitstekende basis voor pipeline:

elke klokcyclus wordt een pipe stage


voorbeeld: DLX figuur 3.2 en 3.3: schematisch zicht op de pipeline

nooit twee verschillende operaties met hetzelfde datapad

merk op: verschillend geheugen voor instructies en data: op te

lossen door een instructie-cache en een data-cache register file gebruikt in 2 stages, maar elk maar

tijdens de helft duidelijke problemen bij sprongen; oplossing volgt

later


figuur 3.4: datapad met pipeline pipeline registers (pipeline latches) genoemd naar de stages waarden uit tussenregisters die nodig zijn voor een latere

stage moeten “meegaan” met de instructie (vb: register voor resultaat van een operatie)

vaste positie voor encodering van registers maakt dat decoderen en ophalen van registerinhoud samen kan gebeuren

limiterende elementen bij een pipeline niet-gebalanceerd zijn van de stages vertraging door de interne registers minimale klok-tijd (clock-skew) een individuele instructie zal trager uitvoeren met de

pipeline de doorvoer van instructies zal echter groter zijn

voorbeeld: DLX (vervolg)


pipeline hazards definitie: situaties waardoor een instructie-stroom

niet gewoon verder kan uitvoeren in de pipeline structurele hazards (conflicten met hulpmiddelen) data hazards control hazards

gevolg: stalls alle instructies na de gestopte instructie blokkeren mee geen nieuwe instructies beginnen in de pipeline door stalls zal de speedup en de performantie verlagen

andere naam voor stall: bubble


A hangt af van D; stall (bubble) nodig omdat vouwen vast zit

Task

Order

12 2 AM6 PM 7 8 9 10 11 1

Tijd

B

C

D

A

E

F

bubble

303030 3030 3030

pipeline hazards


structurele hazards def: wanneer een bepaalde combinatie van

instructies in de pipeline niet kan uitvoeren door conflicten over hulpmiddelen als een bepaalde functionele eenheid niet volledig

gepipelined is (vb FP vermenigvuldiging) als een bepaald hulpmiddel is niet voldoende

gerepliceerd voorbeeld

wanneer geen twee gescheiden geheugens voor instructies en data (zie figuur 3.6, 3.7 en 3.8)

oplossing: gesplitste cache of instructiebuffers waarom laat men structurele hazards toe ?

kosten laag houden latency klein houden (geen tussenregisters nodig)


data hazards komen voor wanneer de volgorde van lees- en

schrijftoegangen tot operanden gewijzigd wordt vb (algemene vorm: OP resultaat, operand1,

operand2): ADD R1, R2, R3SUB R4, R5, R1AND R6, R1, R7OR R8, R1, R9XOR R10, R1, R11

figuur 3.9 toont de hazards mooi aan oplossing: forwarding

resultaat wordt direct naar de plaats gebracht waar die nodig is (bv uitgang ALU direct terug naar ingang ALU voor de volgende instructie, zie figuur 3.10)

tweede voorbeeld: figuur 3.11


data hazards (vervolg) classificatie van data hazards

RAW: read after write hazard uit vorige voorbeelden komt het meeste voor

WAW: write after write twee instructies na elkaar schrijven in zelfde register de eerste write gebeurt na de tweede kan enkel voorkomen indien er meerdere write stages

zijn (zie voorbeelden later)

WAR: write after read een tweede instructie schrijft iets weg voordat een

eerste instructie de vorige waarde heeft gelezen kan niet voorkomen in ons voorbeeld

RAR: read after read: is geen hazard !


data hazards (vervolg) forwarding is niet altijd voldoende:

LW R1, (0)R2SUB R4, R1, R5AND R6, R1, R7OR R8, R1, R9

LW heeft zijn gegeven pas na de 4de cyclus, te laat voor SUB (zie figuur 3.12)

alleen een stall kan hier helpen (zie figuur 3.13 en 3.14)


data hazards (vervolg) rol van compiler ter voorkoming van data hazards

vb van vertaling van A = B + C

LW R1, B LW R2, CADD R3, R1, R2SW A, R3

dit geeft een stall (zie figuur 3.15) compiler kan proberen code goed te schedulen (machine-

afhankelijke optimisatie die rekening houdt met de pipeline)

spelend met de volgorde van de instructies waarbij natuurlijk de correctheid bewaard moet blijven schedulen = volgorde (van instructies) kiezen


data hazards (vervolg) rol van compiler ter voorkoming van data hazards

(vervolg) vb van vertaling van a = b + c;

d = e - f;LW Rb, b LW Rc, c

LW Re, e (herschikking)ADD Ra, Rb, RcLW Rf, f (herschikking)SW a, RaSUB Rd, Re, RfSW d, Rd

herschikking kost meestal meer registers


control hazards probleem: als instructie i een ‘genomen sprong’ is

PC wordt normaal pas veranderd aan einde van MEM (fig. 3.4)

behandeling van sprongen stall de pipeline zodra een sprong gedetecteerd wordt (fig.

3.21) 3 klokcycli verloren tot 30% sprongen -> helft van de ideale versnelling oplossing bestaat uit 2 delen

– sneller ontdekken of de sprong genomen wordt– de nieuwe PC sneller berekenen

vb: figuur 3.22, te vergelijken met figuur 3.4– werkt voor instructies die op 0 testen– maakt gebruik van extra opteller– slechts 1 klokcyclus gaat verloren


behandeling van sprongen (vervolg) oude machines met complexe instructies hebben vaak

een sprong-vertraging van 4 klokcycli of meer hoe dieper de pipeline, hoe zwaarder de sprong-

vertraging doorweegt sprong-gedrag in programma’s

meer voorwaartse sprongen dan achterwaartse (3 op 1): fig. 3.24

meeste lussen gebruiken achterwaartse sprongen 60% van voorwaartse sprongen worden genomen 85% van achterwaartse sprongen worden genomen

control hazards (vervolg)


verkleinen van gemiddelde vertraging: sprongvoorspelling statisch: zie volgende slides dynamisch: zie volgend hoofdstuk

control hazards (vervolg)


statisch voorspellen van sprongen vier methoden voor het omgaan met sprongen

bevries de pipeline tot nieuwe PC is gekend (zie eerder) eenvoudig, maar niet efficiënt; wordt niet gedaan

voorspel altijd dat de sprong niet genomen wordt men moet terug kunnen indien de voorspelling fout was vb voor DLX: fig. 3.26

omgekeerd: voorspel de sprong als wel genomen men moet terug kunnen indien de voorspelling fout was is interessanter: meer dan 50% van de sprongen

worden genomen geen voordeel in de DLX pipeline wel voordeel indien sprongtest ingewikkelder dan

berekening van nieuwe PC


vertraagde branch: gebruik van een branch delay slot de compiler voegt een nuttige instructie toe na de

sprong-instructie; deze instructie wordt altijd uitgevoerd (zie fig. 3.28 en 3.29: drie gevallen

– er is een eerdere instructie waar de sprong niet van afhangt: altijd voordelig

– verplaatsing van instructie uit code waarnaar eventueel gesprongen gaat worden (meestal gekopieerd): mag geen probleem zijn bij niet-sprong, voordeel bij sprong

– een instructie uit de code die volgt op sprong vult de branch delay slot: mag geen probleem zijn bij sprong, voordeel bij niet-sprong)

statisch voorspellen van sprongen (vervolg)


statisch voorspellen van sprongen (vervolg)

vertraagde branch: (vervolg) cancelling of nullifying branch

– speciale instructie die richting van de voorspelling bevat

– indien mis-voorspeld: de instructie in de branch delay slot wordt veranderd in no-op (zie fig. 3.30)

branch delay slot wordt minder gebruikt in geavanceerde RISC-architecturen:

– diepere pipelines, langere branch delays– men gebruikt meer dynamische voorspelling van

sprongen (zie volgend hoofdstuk) wat gebeurt er bij interrupt ?!

– het is nodig om 2 PC’s te saven


verder gebruik van compilertechnologie

vb op pagina 175: met statische sprongvoorspelling om data hazard op te lossen

LW R1, 0(R2)SUB R1, R1, R3BEQZ R1, LOR R4, R5, R6......

L: ADD R7, R8, R9

SUB is data-afhankelijk van LW veronderstel sprong bijna altijd genomen en R7 is een

vrij register: verplaats de ADD na de LW veronderstel sprong bijna nooit genomen en R4 is een

vrij register: verplaats de OR na de LW


verder gebruik van compilertechnologie (vervolg)

basismethoden voor het voorspellen van sprongen studie van programma

voorspel de sprong altijd als genomen– misvoorspelling van 34%, maar dit varieert sterk

voorspelling gebaseerd op richting– voorwaartse sprong: voorspel niet genomen– achterwaartse sprong: voorspel genomen– meestal ook misvoorspelling tussen 30 en 40%

profile informatie (is beter maar moeilijker uit te voeren)


moeilijkheden bij implementatie van pipelines

correcte behandeling van exceptions moeilijkheden als gevolg van keuze in de

instructieset


exceptions veel soorten mogelijke exceptions: zie pagina 179 of

eerste kolom van fig 3.39 er is geen echte standaard-terminologie (interrupts,

fouten, ...) 5 belangrijke karakteristieken (zie fig. 3.40):

synchroon of asynchroon asynchroon heeft niets te maken met het programma dat

uitvoert asynchrone exceptions kunnen meestal behandeld

worden na de uitvoering van de instructie, is eenvoudiger al dan niet door de gebruiker gevraagd (vb trap, breakpoint) al dan niet maskeerbaar in een instructie of tussen instructies programma moet stoppen of moet verder gaan


exceptions (vervolg)

moeilijkst: exception midden in een instructie, waarbij het programma moet verder gaan deze exceptions zijn altijd synchroon en nooit door de

gebruiker aangevraagd pipeline moet herstart worden na behandeling van

exception

vb. van moeilijke exception: een page fault wordt slechts gedetecteerd na de MEM stage meerdere andere instructies zitten reeds in de pipeline


precise exception: de pipeline kan gestopt worden zodat al de instructies vóór de exception uitgevoerd zijn, en die na de exception kunnen herstart worden (bijna) alle integer pipelines, met inbegrip van load en

store, ondersteunen precieze exceptions soms problemen met FP instructies die lang duren (zie

later) veel machines hebben 2 modes de niet-precieze mode gaat veel sneller (soms 10 x

sneller) onmogelijk om in niet-precieze mode te weten welke

instructie de exception (bv overflow) veroorzaakte



meerdere exceptions door verschillende instructies kunnen tegelijk gebeuren vb: LW veroorzaakt een (data) page fault en wordt gevolgd

door een ADD die een rekenkundige exception veroorzaakt

LW IF ID EX MEM WBADD IF ID EX MEM WB

exceptions kunnen uit hun logische volgorde gebeuren (zie ook fig. 3.41) vb: LW veroorzaakt een (data) page fault en wordt gevolgd

door een ADD die een (instruction) page fault veroorzaakt

LW IF ID EX MEM WBADD IF ID EX MEM WB



processoren proberen de logische volgorde te respecteren een status vector per instructie houdt de exceptions bij aan het einde van MEM of begin van WB wordt deze

vector bekeken, en wordt beslist of de instructie moet gestopt worden



keuzen in instructieset kunnen de pipeline bemoeilijken autoincrement-adresseringsmode: een register wordt

opgehoogd midden in een instructie, waarbij aan het einde een exception optreedt

meeste machines hebben hardware zodat ze de toestand van voor de instructie kunnen herstellen

string copy operaties: vaak heel omvangrijke instructies tussenresultaat staat in registers, en bij herstart van

instructie wordt verder gewerkt vanuit het tussenresultaat

instructies die conditie codes zetten nadeel: zulke instructies zijn niet meer te gebruiken in

branch delay slot branch moet zeker zijn dat CC reeds gezet is

andere moeilijkheden


multicyclus-operaties bij floating point, integer vermenigvuldiging en

deling de EX cyclus kan meerdere keren achter elkaar herhaald

worden (fig. 3.42) of duurt meerdere klokcycli (fig. 3.44) er kunnen meerdere functionele eenheden zijn elke functionele eenheid heeft (fig. 3.43)

een ‘latency’ = aantal cycli dat men moet wachten op het resultaat

een ‘herhalingsinterval’ = aantal cycli tussen het opstarten van twee instructies die dezelfde functionele eenheid nodig hebben

doordat de latency groter is voor sommige instructies krijgen we veel meer (en langere) RAW hazards (fig. 3.45 en volgende slide)


multicyclus-operaties (vervolg) voorbeelden van problemen ivm het detecteren

van hazards en forwarding technieken structurele hazards (bv er is maar 1 FP div.) die tot stalls

leiden er kunnen meerdere writes naar registers gebeuren in 1

cyclus (zie fig. 3.47) (structurele hazard indien er maar 1 poort is)

WAW kan gebeuren omdat WB niet altijd in juiste volgorde gebeurt

vb: fig 3.47 met LD één instructie eerder en met F2 als bestemming

gebeurt eigenlijk alleen indien de eerste write nooit gebruikt wordt (dus onnodige instructie), anders kwam er een RAW stall die het geheel vertraagde


multicyclus-operaties (vervolg) voorbeelden van problemen ivm het detecteren

van hazards en forwarding technieken (vervolg) instructies eindigen niet in volgorde: problemen met

exceptions vb: DIVF F0, F2, F4

ADDF F10, F10, F8SUBF F12, F12, F14

ADDF en SUBF zijn uitgevoerd voordat DIVF eindigt als DIVF een exception veroorzaakt en ADDF is al

gebeurd, dan is de oorspronkelijke inhoud van F10 verloren en kan die instructie niet herstart worden

instructies duren langer (langere latency): meer stalls bij RAW (zie fig. 3.46)


MIPS R4000 superpipelining

om hogere klokcyclus te halen: minder doen per stage, dus diepere pipeline (in dit geval 8 stages) (zie fig. 3.50)

meer forwarding vergroot de load en branch delays (fig. 3.51 en 3.53)

FP pipeline: 3 functionele eenheden adder, multiplier, divider eigenlijk kun je 8 onderdelen onderscheiden (fig. 3.55) elke functionele eenheid gebruikt deze onderdelen in een

bepaalde volgorde (fig. 3.56) van elk onderdeel is maar 1 exemplaar: hier krijg je dus

structurele hazards in sommige combinaties van instructies (voorbeelden in fig. 3.57-3.60)


fouten en valstrikken

valstrik: vreemde sequenties van instructies geven onverwachte hazards vb WAW: dit heeft logisch gezien geen zin, maar kan

het gevolg zijn bv van een verplaatste instructie bij een branch delay

fout: meer pipeline stages geeft altijd betere performantie (zie fig. 3.63) er komen meer stalls pipeline overhead vergroot


fouten en valstrikken

valstrik: het herschikken van instructies door een compiler evalueren aan de hand van niet-geoptimiseerde code niet geoptimizeerde code bevat veel onnodige

instructies die gemakkelijk verplaatst worden

pipelining: basisprincipes

Documents