Komandu posmu

paralēla izpilde

1
Konveijerizācija aparatūras
līmenī
Secīga izpilde

laiks

Konveijerizēta izpilde

komandas

2
Komandas dzīves cikls
Komandas nolasīšana
Fetch Instruction ( FI)

Komandas dekodēšana
Decode I nstru cti on( DI)

Operandu nolasīšana Operandu adr ešu aprēķins

Fetch Oper ands (F O) Cal culate Operands ( CO)
Operandu nolasīšana
Fetch Oper ands (F O)
Komandas izpilde Komandas izpilde
Execute Instruction (EI) Execute Instruction (EI)
Rezultāta pieraksts
Write Operand (WO)

3
Uzlabojumi no
konveijerizācijas

Komanda Nr. 1 Fi Di Co Fo Ei Wo

Fi Di Co Fo Ei Wo

Fi Di Co Fo Ei Wo

Fi Di Co Fo Ei Wo

Fi Di Co Fo Ei Wo

Komanda Nr. n Fi Di Co Fo Ei Wo

t0 t1 t2 t3 t4 t5 t6 tn tn+1

4
Uzlabojumi
Pēc zināma laika (n-1 taktīm) visi n posmi strādā un konveijers ir “pilns”.
Teorētiski, konveijers var turpmāk darboties, nodrošinot maksimālu
paralēlismu (n komandas izpildās vienlaicīgi).
Jo vairāk posmu katrai komandai jo labāka būs veiktspēja?
Diemžēl jāņem vērā tas ka:
Lielāks posmu skaits nozīmē arī lielākus virstēriņus uz datu pārvietošanu un
sinhronizāciju starp posmiem (aiztures laiks, takts nobīdes (skew), takts trīces (jitter))
Diemžēl palielinoties konveijera posmu skaitam pieaug arī CPU sarežģītība
Nav iespējams turēt konveijeru pilnu dēļ konveijeru konfliktiem (hazards)
CPI vairs nav konstants, bet gan sastāv no divām daļām (ideālais un aizkaves
gadījums)
Piemēri:
Pentium: 5. posmu konveijers veseliem skaitļiem un 8. posmu FP komandām
PowerPC: 4. posmu konveijers veselo skaitļu komandām un 6. posmu FP komandām

5
Skew un jitter

6
Pamati
Datori izpilda miljoniem darbību sekundē tāpēc mums ir svarīga to
caurlaides spēja nevis darbības ātrums
Sadalām komandas izpildi vairākās daļās IF DI CO FO EI WR
Katrā laika momentā dažādas komandas būs dažādos izpildes
posmos
Ilgākais posma izpildes laiks noteiks takts frekvenci
CPI=1 (ideālā gadījumā)
Uzlabojums = posmu skaits (ideālā gadījumā)
Diemžēl vairāki faktori neļauj sasniegt ideālus rezultātus:
Nevar komandas izpildi sadalīt vienādi ilgos laika posmos
Ir jāpatērē laiks lai aizpildītu un iztukšotu konveijeru
Ir nepieciešami virstēriņi darbību sinhronizācijai, datu pārraidei….
Konflikti (structural, data, control hazards)

7
Konflikti
Konveijera riski (konflikti) ir situācijas kad kādas problēmas neļauj
izpildīt komandu tai atvēlētajā taktī.
Šādu komandu sauc par aizkavētu (stalled)
Kad kāda komanda tiek aizkavēta tad visas pārējās komandas (kas
atrodas konveijerā aiz aizkavētās komandas) arī tiek aizkavētas.
Komandas kas atrodas pirms aizkavētās komandas var tikt izpildītas.
Aizkaves gadījumā jaunas komandas konveijerā netiek ielādētas.

Konfliktu veidi:
Strukturālie (Structural hazards) - Aparatūra nespēj izpildīt komandu secību
ja piemēram divas komandas vēlas izmantot vienu aparatūras resursu.
Datu (Data hazards) - Komanda ir atkarīga no iepriekš esošas komandas
rezultāta.
Vadības (Control hazards) – Vadības komandas kuras maina komandu
skaitītāja (PC) saturu.

8
Struktūras konflikti
Struktūras konflikti rodas tad kad divas vai vairāk komandas pieprasa
vienu un to pašu resursu
Parasti lai izvairītos:
Dublē resursus
Konveijerizē resursus
Pārkārto komandas
Ir gadījumi kad šos konfliktus nevar novērst (tad ir jāaizkavē konveijers)

9
Datu konflikti

10
Trīs veidu datu konflikti
Read After Write (RAW)
KomandaJ cenšas nolasīt operandu pirms KomandaI pieraksta to

I: add r2,r3,r1
J: sub r4,r1,r3

To izraisa atkarība (”dependance”) ko izveido programmētājs (vai

kompilators) un kura pieprasa šo datu nodošanu no vienas komandas
otrai

11
Trīs veidu datu konflikti
Write After Read (WAR)
KomandaJ pieraksta operandu pirms KomandaI to nolasa

I: sub r4,r1,r3
J: add r2,r3,r1
K: mul r6,r1,r7
Sauc arī par “anti-dependence” un to izraisa vārda “r1” atkārtota
izmantošana
Vienkāršā konveijerā neiespējams gadījums jo:
Visas komandas izpildās vienādā taktu skaitā
Nolasa vienmēr 3. taktī bet pieraksta vienmēr 6. taktī
WAR konflikti rodas ja komandas tiek izpildītas ārpus secības vai tās
piekļūst datiem vēlāk nekā parasti

12
Trīs veidu datu konflikti
Write After Write (WAW)
KomandaJ pieraksta operandu pirms KomandaI pieraksta to pašu operandu

I: sub r4,r3,r1
J: add r2,r3,r1
K: mul r6,r1,r7

Tiek saukta arī par “output dependence” un to arī izraisa vārda “r1” atkārtota
izmantošana
Vienkāršā konveijerā neiespējami jo:
Visas komandas izpildās vienādā taktu skaitā
Pieraksta vienmēr 6. taktī
WAR un WAW ir iespējami tālāk apskatītos sarežģīti organizētos konveijeros.

13
Datu konfliktu novēršana
Dažus datu konfliktus var novērst ar datu pārsūtīšanu (forwarding,
bypassing)

14
Datu konfliktu novēršana
Dažus datu konfliktus nevar novērst ar aparatūras palīdzību (piemēram
tos kurus izraisa load komandas)
Tos var censties novērst ar programmatūras palīdzību....

15
Datu konfliktu novēršana
Piemēram izveidojiet pēc iespējas ātrāku dotā koda
izpildi : a=b+c
d=e–f
Pieņemot to ka a, b, c, d ,e, un f atrodas atmiņā
Lēni: Ātrāk:
Load Rb,b Load Rb,b
Load Rc,c Load Rc,c
ADD Rb,Rc,Ra Load Re,e
Store Ra,a ADD Rb,Rc,Ra
Load Re,e Load Rf,f
Load Rf,f Store Ra,a
SUB Re,Rf,Rd SUB Re,Rf,Rd
Store Rd,d Store Rd,d
16
Mājas darbi
http://www.cs.iastate.edu/~prabhu/Tutorial/PI
PELINE/pipe_title.html
Vai var vēl uzlabot iepriekšējā slaida
piemēru?
6. nodaļa no Computer_Organization_and_Design.pdf

17
BUJ

18