1 / 41

Pipelining: basisprincipes

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

paco
Download Presentation

Pipelining: basisprincipes

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 2 AM 12 6 PM 1 8 7 11 10 9 sequentieel werken duurt 8 uur voor 4 wasmanden 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 T a s k O r d e r Tijd A B C D

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

  6. 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

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

  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, R11figuur 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, R9LW 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 • 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

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

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

  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 veroorzaaktLW IF ID EX MEM WBADD IF ID EXMEM 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 veroorzaaktLW IF ID EX MEM WBADD 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. 3.45 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 • 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)

  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

More Related