Pipelining: basisprincipes

Presentatie over: "Pipelining: basisprincipes"— Transcript van de presentatie:

1 Pipelining: basisprincipes

2 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

3 wat is pipelining: wasserette voorbeeld
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

4 wat is pipelining: wasserette voorbeeld
6 PM 7 8 9 10 11 12 1 2 AM T a s k O r d e 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 Tijd A B C D sequentieel werken duurt 8 uur voor 4 wasmanden

5 wat is pipelining: wasserette voorbeeld
6 PM 7 8 9 10 11 12 1 2 AM Tijd 30 30 30 30 30 30 30 T a s k O r d e A B C Begin met taak zodra het kan D met een pipeline duurt het maar 3.5 uur voor 4 wasmanden !

6 wat is pipelining implementatietechniek terminologie ideaal:
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

7 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

8 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

9 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 cyclus 5. write-back (WB) voor register-register ALU instructie, register-immediate ALU instructie en voor een load instructie

10 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

11 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

12 voorbeeld: DLX (vervolg)
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

13 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

14 pipeline hazards 6 PM 7 8 9 10 11 12 1 2 AM 30 Tijd T a s k O r d e bubble A B C D E F A hangt af van D; stall (bubble) nodig omdat vouwen vast zit

15 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)

16 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, R3 SUB R4, R5, R1 AND R6, R1, R7 OR R8, R1, R9 XOR 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

17 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 !

18 data hazards (vervolg)
forwarding is niet altijd voldoende: LW R1, (0)R2 SUB R4, R1, R5 AND R6, R1, R7 OR 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)

19 data hazards (vervolg)
rol van compiler ter voorkoming van data hazards vb van vertaling van A = B + C LW R1, B LW R2, C ADD R3, R1, R2 SW 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

20 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, Rc LW Rf, f (herschikking) SW a, Ra SUB Rd, Re, Rf SW d, Rd herschikking kost meestal meer registers

21 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

22 control hazards (vervolg)
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

23 control hazards (vervolg)
verkleinen van gemiddelde vertraging: sprongvoorspelling statisch: zie volgende slides dynamisch: zie volgend hoofdstuk

24 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 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

25 statisch voorspellen van sprongen (vervolg)
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 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)

26 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

27 verder gebruik van compilertechnologie
vb op pagina 175: met statische sprongvoorspelling om data hazard op te lossen LW R1, 0(R2) SUB R1, R1, R3 BEQZ R1, L OR R4, R5, R 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

28 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)

29 moeilijkheden bij implementatie van pipelines
correcte behandeling van exceptions moeilijkheden als gevolg van keuze in de instructieset

30 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

31 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

32 exceptions (vervolg) 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

33 exceptions (vervolg) 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 WB ADD 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 WB ADD IF ID EX MEM WB

34 exceptions (vervolg) 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

35 andere moeilijkheden 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

36 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 en volgende slide)

37 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

38 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, F8 SUBF 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)

39 MIPS R4000 superpipelining FP pipeline: 3 functionele eenheden
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 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 )

40 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

41 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