Bulldozer reverzibilni multithreading!

[drfedja]

Bulldozer single thread execution!

Branch prediktor je kod Bulldozera deljen izmedju dva integer i floating point klastera.
Medjutim, on je podeljen na dva reda (queue-a). U BD arhitekturi on koristi RIP - relative instruction pointers. Ovo znaci da se u queue smesta razlika vrednosti PC - programm countera izmedju instrukcija uslovnog skoka, na osnovu cega procesor "ZNA" da li da izvrsavanje instrukcija nakon grananja uzme ili ne - (taken or not taken).
K10 koristi lokalni branch prediktor, kao i globalni i birac da li da koristi lokalni ili globalni. Kod BD jezgara se ne zna tacno da li se koristi 2-level BP, ali moze lako da se dogodi da postoji loop detektor, slicno kao sto postoji kod Intel Core arhitekture.
Branch Target Buffer - BTB je 5K za razliku od 2K kod K10. Veci kapacitet je razlog tome sto je deljen izmedju 2 integer klastera.
RIP queue navodno omogucuje da BD jezgra efektivno budu ispred front end hardvera. Dva jezgra na ovaj nacin rade bez zastoja i bolje tolerisu vece latencije front end hardvera.

x86, pa i x86-64 instrukcije su varijabilne duzine. Zbog ovog problema instrukcije nisu poravnate po linijama u L1 instrukcijskom keshu, pa se zato tesko dekodiraju paralelno, zbog cega je IPC smanjen. Neke od ovih instrukcija su Vector Path, a neke su Fast Path, a neke Fast Path double. Ove prve koriste mikrokod ROM za dekodiranje (mikrokodovane su), sto je daleko sporije (imaju vecu latenciju), od Fast Path (hardwired) instrukcija. Fast Path double se razbijaju na dve makrooperacije. Npr. 256-bitne AVX instrukcije se moraju razbiti u 2x128 bit load-a iz prostog razloga jer je sirina portova 128-bitna na L1 instrukcijskom keshu. K10 i BD imaju 32-byte fetch, sto omogucava 2x128-bit load po ciklusu. Razlika je u tome sto BD FPU poseduje 2x128-bit FMAC, pa FP klaster moze da izvrsi dva 128-bitna load-a po ciklusu, dok kod K10 moze samo 1. U slucaju 2 treda, FPU klaster moze da dobije po 1x128-bit load po tredu, kao i kod K10, sa razlikom sto na 4 jezgra x 2 treda imamo ukupno 8x128-bit loada za 8 tredova.

Tipicna x86 instrukcija se sastoji od 1-2 makrooperacije. Kod K7/K8/K10, pa i BD arhitekture, x86 instrukcije se dekodiraju u makrooperacije, koje su ortogonalne. Makrooperacije se razlikuju od mikrooperacija po tome sto su spojene (ili ne moraju da budu) sa adresnim operacijama. Kada prodju front end, adresne se izvrsavaju na AGU, a aritmeticke i logicke naravno, na ALU jedinicama. Ako je ALU operacija Register->Register tipa, onda nema adresnih operacija, kao npr. kod Register->Memory. Posto se obicno radi sa pokazivackim promenljivim, npr instrukcija LEA - Load Effective Adress racuna efektivnu adresu, offset i smesta ga u specifican registar. Npr. za ovakve operacije je zaduzena AGU - Adress Generation Unit. AGU moze da sabira i oduzima pokazivace, odnosno adrese. Mnozenje i deljenje adresa nema smisla. Operacije mnozenja,deljenja, kao i logicke operacije su stvar ALU jedinica. Dakle, poseban mikrokod je za AGU, a poseban za ALU i FPU.

BD ima cetvrti dekoder u odnosu na K10. Front End je zajednicki za sve klastere u jezgru.
Najverovatnije BD jezgro ima branch fusion, pa operacije CMP i JMP mogu biti dekodirane i izvrsene u jednom ciklusu, kao jedan makroop.
Kada se instrukcije dekodiraju u makrooperacije, one se smestaju u queue, pa se kao takve raspodeljuju u grupe od po cetiri makrooperacije odakle se salju na dva integer klastera.

Spojler

Kod OoO - Out Of Order izvrsavanja vrlo bitna stavka je "register renaming". Ovo je mehanizam koji sluzi da premosti problem malog broja registara i izbegne serijalizaciju izvrsavanja operacija. Cilj je da se instrukcije izvrsavaju paralelno, cime se naravno povecava IPC - broj instrukcija po ciklusu, odnosno smanjuje CPI.
Register renaming omogucava veci broj instrukcija u letu (instruction window), tako da se za operacije za koje nije uradjen "commit", odnosno koje nisu "retired" (vracene), njima se dodeljuju lokacije sa odgovarajucim indeksima u specijalnoj memoriji unutar procesora koja se zove "register file". Kod K7/K8 i K10 je koriscen princip kopiranja podataka iz preimenovanih registara u fizicke registre, zajedno sa instrukcijama, t.j. opkodovima, pre nego sto su izvrsene, odnosno pre nego sto su dobile commit signal. Ovo nije bas preterano efikasno, narocito sto zahteva dosta vise energetskih resursa. Umesto toga kod BD arhitekture PRF - phisycal register file se koristi samo za prenos pokazivaca ( pointera ) za odgovarajuce instrukcije i njihove operande. Bulldozer i Bobcat koriste Physical Register File da bi manje trosili umesto RRF - Retirement Register File. Slicna stvar je uradjena i kod Sandy Bridge-a.
Kod BD jezgra, svaki integer klaster ima svoj Register File, pa je i Register File clusterovan. Da bi jedan tred mogao da bude izvrsen na oba klastera pretpostavljam da bi trebao da postoji zajednicki register file za oba klastera. Medjutim i kod K7/K8/K10 postoji separatni integer i floating point klaster, ali treba imati na umu da su arhitekturalni registri za FP(x87, SSE ...) disjunktni od x86 za celobrojne i logicke operacije(kojih ima 8, odnosno 16 u x86-64 modu).

Prema tome, BD u jednom tredu nece moci da izvrsi vise od 2 ALU operacije, ali to ne bi trebalo da predstavlja neki problem jer ce moci da izvrsi instrukcijski miks od 2 ALU operacije, 1 SIMD i JMP/COMPARE u istom ciklusu zahvaljujuci 4-way front endu. To po tredu daje maksimalni IPC od cak 5 u ekstremnim slucajevima.

Na ovoj slici je prikazano nekoliko tipova klaster arhitektura. Pod A je obicna, neklasterovana, kao npr. Nehalem ili K10. Bulldozer je nesto sto lici na E ili C sa razlikom u tome sto je front end donekle deljen. Na zalost nemam dovoljno podataka da mogu da zakljucim previse, npr. da li je register renaming deljen, kakva je interkomunikacija izmedju klastera, itd... Ako bi izvrsavali 1 tred na oba klastera imali bi povecan broj registar konflikata. Registri su alocirani separatno iz svakog Register File-a, koji je sastavni deo svakog klastera (jer register file nije shareovan). Kada tred menja bira izmedju izvrsnih resursa, on eksplicitno mora da kopira celo stanje integer registara izmedju dva zasebna RF-a.
Ovo je kljucno - gde se nalazi register renaming kod BD jezgra? Ukoliko je on deljen, renaming bandwidth nije limitiran na samo 2 instrukcije po tredu - problem redukovane sirine znaci da imamo samo 2 ALU instrukcije na raspolaganju po tredu iz svakog klastera. Pri multithread izvrsavanju ova limitacija nije ključna. Ukoliko je renaming zaseban, nije moguce da oba jezgra mogu da rade na 1 tredu.

Na kraju krajeva imamo deljene:
FPU, L1-I cache, dekodere, Branch Prediktor, L2 keš

Separatni su:
Integer jedinice, register file, L1-D cache,

Ne znamo da li je separatno: register renaming.

Dodatni integer klaster uzima mali deo površine čipa. Ubrzanje koje donosi je daleko veće nego Hyperthreading kod "debelog" procesora.
Matematika je jasna. Površina 4/8 Bulldozer-a je slična površini 4-core Sandy Bridge-a. IPC jednog klastera u proseku je 0,85 IPC debelog Sandy-ja. Ubrzanje jednog BD jezgra uključivanjem drugog klastera i korišćenjem 2 treda je 1,8x.
Ubrzanje uz korišćenje Hyperthreadinga je 1,15x.

U multithread režimu Bulldozer (ako bude bio efikasan) sa 8 tredova bi mogao biti i 40% brzi od Sandy Bridgea sa 4 jezgra i 8 tredova.

 

[d0minat0r]

svaka cast na trudu

 

[noodi]

Jbt a ja mislio ja se nesto razumem u kompove..
Svaka cast za ovo!

 

[drfedja]

Nadam se da je razumljivo za vecinu citaoca. Ako ima nekih pitanja mogu da objasnim.

 

[animaN]

Bravo legendo! Prochitah ceo tekst sa uzivanjem!

 

[CooLa]

Po tvom tekstu znaci NehaJem ce i biti brzi od buldozera kod singlethread aplikacija? Ili sam pogresno skrenuo kod Albukerkija?

 

[Beagle]

Mislim da si omasio iskljucenje . Bulldozer ima mogucnost da singlethreaded aplikaciju izvrsava na vise clustera, pa bi valjda trebao i biti brzi. Sta kaze fedja?

 

[drfedja]

Mislim da si omasio iskljucenje . Bulldozer ima mogucnost da singlethreaded aplikaciju izvrsava na vise clustera, pa bi valjda trebao i biti brzi. Sta kaze fedja?

Mislim da nece bas biti tako, ali donekle hoce. Sto se tice Integer clustera, najverovatnije ce svako imati svoj renamer, jer inace svako ima svoj register file.
Time je BD ogranicen na 2 ALU i 2 AGU po tredu. Medjutim, pitanje je koliko mu to zaista predstavlja problem. Prakticno ni u jednoj Integer aplikaciji/tredu broj izvrsenih instrukcija po ciklusu ne prelazi 2. IPC 3 moze da se postigne za operacije u petlji koje imaju troughput 1/3 i koje se u petlji izvrsavaju iz L1 cache-a. Sve ostalo ima daleko manji IPC i u mnogome zavisi od rada sa memorijom, branch predictiona i mnogih drugih stvari.
S' druge strane, BD ima deljen FPU. Npr, moguce je da u jednom tredu iskoristi 2 ALU jedinice, i ceo FPU koji moze da izvrsi 2 operacije. To teoretski daje IPC 4 po tredu. Front End moze da dekodira najvise 4 instrukcije i pri tom moze da spoji JMP i CMP i jednu mikrooperaciju. U ekstremnom slucaju IPC bi mogao biti i 5, sto su inace i maksimalne mogucnosti Nehalema i Sandy Bridgea.
Druga stvar je veliki L2 kes po modulu. BD ima 4x2MB L2 i L3 verovatno 8MB.
Veliki L2 ce sigurno doneti jos 5-6% ubrzanja.
L1 ima vecu asocijativnost u odnosu na K10. Iako je manji, L1-I ima 32K, trebalo bi zahvaljujuci vecoj asocijativnosti da ima veci hit-rate.
L1 data je separatni po klasterima i iznosi 2x16K, sto je dosta malo, ali verovatno dovoljno, najverovatnije zbog izmenjenih protokola keš koherencije u odnosu na K10.
Npr. kod K10 L1 data je ekskluzivan, pa se sadržaj keš linija ne kopira u L2. Ovo je mač sa dve oštrice. Kada je K7 imao 256K L2 ovo je davalo ukupno veću količinu keš memorije na raspolaganju.
Npr. prebacivanje izbačene linije iz L1 u L2 usled keš miss-a u L2 košta vremena.

 

[Ace Rimmer]

Zanimljive su paralele koje D. Kanter povukao sa Intel P4 i sadašnjim IBM Powerom ... BD će navodno biti "speed demon".

 

[drfedja]

Ne bih se kladio u to da ce biti speed deamon. Navodno zbog 2-way ALU, malog data cache-a od 16K i jos ponekih sitnica. Pitanje je koliko je dubok pipeline. Koliko sam shvatio broj stanja ostaje isti kao i kod K8/K10. Medjutim, latencije velikog broja int. instrukcija su povecane, a ovo moze da bude posledica veceg broja stanja u pipelineu, a moze da bude i posledica neceg drugog. Da bi jedna x86 instrukcija prosla od front-end-a dok izvrsenja, potrebno je onoliko ciklusa koliko procesor ima stanja u pipelineu. Dakle, ako se instrukcija dekodira u jedan mikroop, bice potrebno 12 ciklusa u 12-stepenom pipelineu da bude izvrsena. Kako se instrukcije izvrsavaju jedna za drugom u letu, tako se ova latencija anulira. Medjutim, u slucaju branch mispredict-a pipeline ostaje prazan, a kod pocinje ponovo da se izvrsava od prethodne adrese skoka. Ovo uzrokuje zastoj od 12 ciklusa + operacija skoka.
P4 je bio speed deamon zbog dubokog pipelinea, male efikasnosti, specificne kes arhitekture itd... i kao takav je bio veliki potrosac, pa je odnos perf/watt bio nizak. Zbog toga je zamenjen efikasnijom Core arhitekturom.

Pumpanje megaherca kod BD nije dobra ideja bas iz tog razloga. Ipak, BD ce raditi na dosta visokim frekvencijama. Mislim da ce biti kompromis izmedju visokog IPC-a i visokog takta. U single thread rezimu bi mogao biti 15-20% brzi od Phenoma II, verovatno negde na nivou Nehalema. BD sa 4 modula u multithread rezimu bi mogao biti i do 60% brzi od Phenoma II X4, za otprilike jednaku povrsinu cipa. Jedan BD modul je po povrsini negde kao Core i7 jezgro, a daje 80-90% performansi Phenoma II X2 u multithread rezimu.

Single thread performanse ce biti dodatno poboljsane turbo modom. 2 ALU po klasteru eksplicitno ne znace manje integer, single thread performanse. Razlika u odnosu na K10 je u tome sto za obe ALU jedinice postoji zajednicki scheduler, dok kod K10 svaki ALU/AGU par ima po jedan odvojen scheduler. Ovo znaci da ako je "par" zauzet, da mora da ceka da se operacija zavrsi, iako su druga dva para slobodna. Kod BD jezgra to nije slucaj, pa je ovaj CPU daleko vise Out Of Order. Setimo se Pentiuma M koji je imao samo 2 ALU jedinice, pa u integer operacijama nije uopste zaostajao za K8. Zapravo, u mnogim situacijama je bio i brzi.
Izmenjena kes arhitektura, prefetcher, napredniji Branch Prediction, veci L2 i L3 kesh, JMP CMP fuzija, turbo mod itd... bi mogli da podignu single thread integer IPC bar za 20% u odnosu na K10. Kod floating pointa takodje imamo zajednicki scheduler za obe FMAC jedinice. Imamo zajednicki front end, pa je moguce na paralelno izvrsiti dve DP floating point operacije u ciklusu, paralelno, za jedan tred. Kako su BD-ove FMAC jedinice univerzalne, na njima mogu istovremeno zbog multithreadinga da se izvrsavaju iste operacije, ovo vazi i za single thread. FPU potpuno podrzava ILP - instruction level paralelelism, jednako kao i TLP - thread level paralelism. Ovo znaci da bi floating point operacije mogle da budu znacajno brze nego na K10.
K10 ima takodje zajednicki scheduler u svom floating point klasteru, medjutim moguce je paralelno izvrsiti samo FADD i FMUL operacije. Kod BD je moguce izvrsiti FADD + FADD, FADD+FMUL i obrnuto.