Netburst

[DeanXP]

Novi thread. Znam da je ovo prica bez kraja, ali eto...

@audiofreak: Pre svega, mene najvise zanima sta je po tebi replay? Vise puta si rekao "to nije replay", a nigde se nisi izjasnio sta je.

Osnovni koncept te arhitekture je efikasan streaming (podataka) i paralelna obrada preko SIMD-a.

Koji su ti argumenti za to?
Core je mnogo bolji u tom pogledu, zar ne?
Core: 128-bit MUL + 128-bit ADD + 128-bit move
Netburst: 64-bit MUL/ADD + 64-bit move
To je ozbiljna prednost Core-a u SIMD-u. Netburst to moze da nadoknadi samo visokim taktom.

Kakva je veza izmedju dugackog pipeline-a i streaming-a, SIMD-a? Po tebi ocigledno postoji. Meni zanima koja je?

Druga stvar koja je iskakala iz cele price je bio trace cache koji je bio prilicno inovativan koncept u 2000-toj godini i pokazao se vrlo sposobnim da odrzi visok instruction decoding throughput. Treca stvar je implementacija HTT preko uop tagging-a (jedan decoder i front end koji taguje instrukcije za core0/core1), a cetvrta replay, ali ne onakav kako ga ti zamisljas.

1) Trace cache je dobar koncept i sigurno ce se vratiti u buducim mikroarhitekturama.
2) Skoro svaka mikroarhitektura primenjuje microop tagging. U najosnovnijoj varijanti tag-ovi sluze samo za pracenje instrukcija za out-of-order izvrsavanje (u Re-Order Buffer-u). Dalje se sadraj tag-ova moze prosiriti za druge potrebe mikroarhitekture ili analize koda. Za implementaciju SMT-a se tag prosiri za jedan bit koji odredjuje pripadnost logickom procesoru.
3) Kao sto rekoh na pocetku posta: Sta je taj tvoj replay?

Ne, ideja je bila da pola takta kasnije mozes zapoceti drugu polovinu neke operacije (npr drugih 16 bita od 32-bitnog mnozenja ili drugih 32-bita od 64-bitnog ADD/SUB) pa je na taj nacin ALU izgledao 2x siri, a ne 2x brojniji.

Precizno: Pipeline-ovali su integer ALU. Pun ALU pipeline se sastoji od tri faze: obrada nizih 16 bita, obrada visih 16 bita, flags. Svaka faza traje kao polovina regularnog ciklusa. Tako, za vreme jednog regularnog ciklusa procesora, ALU dobije dve instrukcije na izvrsavanje. Dok se obradjuje visih 16 bita prve instrukcije, na drugoj se obradjuje nizih 16 bita.
To sto si ti naveo je implementacija (2x16-bit pipelined), a rezultat je da ALU pocinje dve obrade u samo jednom procesorskom ciklusu slicno kao da postoje dva ALU-a na regularnom taktu.
Medjutim, postoji jedna znacajna prednost DP ALU-a naspram dva obicna ALU-a: jedan DP ALU moze da obradi dve zavisne instrukcije u jednom ciklusu, sto dva ALU-a na regularnom taktu ne mogu. Sa te strane je prednost DP ALU-a ocigledna.

Ovde vec pocinjes da diskutujes o stvarima o kojima ja znam mnogo vise. Ne znam gde si to procitao, ali ja iz prakse mogu da tvrdim da to nije tako kod optimizovanog softvera.

Nesto vezano za replay... Optimizacija... Replay... Sta je replay?

Register Alias Table se zove to sto pominjes, a ne renamed register file

Ne.
RAT je mapa register file-a. Mapira dodelu fizickih registara pri renaming-u. RAT i renamed register file su dva pojma.

To nije replay kakav je imao Netburst.

Enlighten me.

Ceo tekst je senzacionalisticki i u fazonu "Sta X ne zeli da znate o Y".

To svakako da jeste. Senzacionalisticki je i u fazonu "Wow, vidi sta smo samo mi otkrili."

Prvo, nigde nisu navedeni nikakvi konkretni podaci o uticaju replay-a na performanse (na primer izmeren procenat CPU taktova potrosen na Replay uz pomoc performance countera), samo spekulacije.

Baci mail ovom coveku: http://www.agner.org/contact/
Dosao je do slicnih zakljucaka. http://www.agner.org/optimize/ Vrlo detaljno analizira mikroarhitekture pomocu svog koda i performance counter-a. Siguran sam da ti moze dati konkretne brojke.

a ti bi morao biti malo vise analitican i sumnjicav kad se vec upustas u sve to.

Ne brini 😉

Na osnovu mog iskustva, Netburst (pa cak i Prescott) je bio izuzetno efikasna arhitektura kad je u pitanju streaming i SIMD. Kod koji sam optimizovao za njih radio je u nekim slucajevima cak i do 20% brze, a nikad sporije nego na uporedivim AMD procesorima. Kad kazem uporedivim, mislim na recimo AMD64 2800+ i Prescott 2.8GHz oba na default taktu onako kako ih ozbiljni klijenti koriste.

A tvoja definica efikasnosti je... ? Ne ukupna brzina (IPC * frekvencija), nego efikasnost?
Koliko ja znam efikasnost se gleda: ucinak po ciklusu tj. IPC. Da li potpuno ozbiljno mozes da kazes da Core nije daleko efikasniji od Netbursta?

 

[drfedja]

Pa cinjenica je da Netburst ima smanjen IPC, ali i povecan radni takt koji je bio veci nego na bilo kojem tadasnjem procesoru, sto ga je naravno, cinilo relativno efikasnim, ali u odnosu na Athlon Thunderbird ili AthlonXP, ako ne posmatramo specificnu primenu vektorizovanog SSE2 koda.

I da K8 moze da se proizvodi na taktovima od 5 Ghz i da pri tom trosi 65W, bio bi verovatno kudikamo efikasniji od C2D.

Samo je problem sto takav koncept nosi sa sobom vise problema i losih stvari nego sto donosi dobrih.

Npr. visoka frekvencija i kompleksnost Netburst jezgra uticu na visoku potrosnju. Po broju tranzistora jedno Prescott jezgro je vece od jednog Core 2 jezgra, t.j. pola Core2 jezgra. Naravno ne racunajuci L2 kesh, a daleko od toga da je blizu toga efikasan. Daleko je i od toga da ima perf/watt odnos slican. Zapravo, tu je razlika jos veca, prvenstveno zbog velikog IPC broja koje ima Core 2 jezgro.

Netburst se ipak pokazao sasvim dobro u svojoj 130nm izvedbi, ali samo sa 512K L2 i vise kesa. Cak stavise, jedan Northwood, t.j. Gallatin EE na 3.46 Ghz je mogao sasvim solidno da parira Athlonu 64 FX51, a mozda cak i FX53. Willamette je s' druge strane imao malo kesha i relativno spor FSB za doticnu arhitekturu.

Misljenja sam da je Intel jednostavno mogao da uradi die shrink NW jezgra, da poveca L1 i L2 kesh i da eventualno doda SSE3 i x86-64, bez ikakvog produbljivanja pipeline-a i takav CPU bi imao mnogo manju disipaciju od Prescotta, a vrlo verovatno je da bi imao i veci IPC broj, a frekvencija bi sigurno isla do 3.8 Ghz.
Sve u svemu, Preshot je bio toliki promasaj, da je mnogo toga radilo sporije nego na njegovom prethodniku.

 

[audiofreak]

@audiofreak: Pre svega, mene najvise zanima sta je po tebi replay? Vise puta si rekao "to nije replay", a nigde se nisi izjasnio sta je.

Pa jedini pravi replay u Netburstu (i onaj koji su mogli da izmere performance counterima):

- Split Load Replays
- Split Store Replays
- MOB Loads Replays (Blocked Store Forwards Replays)

Ono o cemu si ti pricao i sto si rekao da ima svaki procesor (mogucnost da nastavi prekinutu instrukciju) na Netburst-u nije nista drugacije nego kod ostalih arhitektura i nema velikog uticaja na performanse.

Ako pogledas listu iznad, videces da su uzroci load replaya uvek klasicni penali koji nastaju usled izvrsavanja legacy instrukcijskog miksa generisanog od strane bajatih kompajlera.

Inace svi navedeni Events spadaju pod Advanced Events pre kojih imas jos Primary i Secondary Performance Tuning Events. Razlog zasto njihov uticaj na performanse uopste moze da se oseti je sto ih u starom softveru ima mnogo pa dolazi do onog cuvenog "death by a 1000 papercuts" sindroma ili po naski "malo po malo pa se nakupi".

Koji su ti argumenti za to?

Pa sam Intel je to rekao:

The design goals of Intel NetBurst microarchitecture are:
• To execute legacy IA-32 applications and applications based on single-instruction,
multiple-data (SIMD) technology at high throughput

Osnovni elementi koji potvrdjuju to su:
- Masivan L2 cache
- Hardware prefetcher koji moze da prati vise memorijskih stream-ova
- Efikasan SIMD, po mom misljenju cak efikasniji od SIMD implementacije u K8 arhitekturi (sto naravno ne znaci da je K8 arhitektura u celosti bila manje efikasna).

Core je mnogo bolji u tom pogledu, zar ne?

Nikad nisam ni rekao da nije bolji ali on je u tom smislu nadgradnja Netburst principa.

To je ozbiljna prednost Core-a u SIMD-u. Netburst to moze da nadoknadi samo visokim taktom.

Pa upravo u tome i jeste fazon. Core moze da izvrsi neku instrukciju recimo za 2 takta, a Netburst za 4, ali Netburst radi to na 3GHz, a Core na 1.5GHz. E sad, sto je novi proizvodni proces omogucio da Core stigne na 3GHz to je vec sasvim druga stvar.

Kakva je veza izmedju dugackog pipeline-a i streaming-a, SIMD-a? Po tebi ocigledno postoji. Meni zanima koja je?

Naravno da postoji, ako je pipeline dugacak onda mu linearan i paralelan pristup obrade podataka vise odgovara nego random. Netburst arhitektura je dakle bila optimizovana za streaming i paralelizam, sto je DivX enkoder sasvim lepo dokazivao u to vreme.

Navescu ti neke rezultate iz Sandre:

		Pentium 4-C HT 3GHz 512KB L2	AMD Athlon 64 3000+ (1.8GHz) 512KB L2
ALU		7514				6501
FPU (SSE2)	9183				5202

Imaj u vidu da namerno poredim rating 3000+ i 3GHz takt jer ih ozbiljni klijenti koriste na defaultu (npr, mozes li da zamislis overklokovan racunar u bolnici?). Takodje, namerno navodim sinteticki test jer on prikazuje maksimum koji se moze izvuci iz date arhitekture optimizacijom koda.

Ne.
RAT je mapa register file-a. Mapira dodelu fizickih registara pri renaming-u. RAT i renamed register file su dva pojma.

U pravu si, RRF sadrzi vrednosti renamed registara. Deljena je u postojecim SMT implementacijama ali su se pojavile neke interesantne ideje koje obecavaju prevazilazenje problema vezanih za SMT i deljeni RRF.

Baci mail ovom coveku: http://www.agner.org/contact/
Dosao je do slicnih zakljucaka. http://www.agner.org/optimize/ Vrlo detaljno analizira mikroarhitekture pomocu svog koda i performance counter-a. Siguran sam da ti moze dati konkretne brojke.

Znam ja Agnera odavno i razmenjivali smo emailove u nekoliko navrata. 🙂

Ono sto sam ti ja rekao ce ti reci i on, replay je sporedan izvor degradacije performansi. Najveci izvor pada performansi na Netburstu je L2 cache miss. Sve drugo je sitno u poredjenju sa tim.

A tvoja definica efikasnosti je... ? Ne ukupna brzina (IPC * frekvencija), nego efikasnost? Koliko ja znam efikasnost se gleda: ucinak po ciklusu tj. IPC.

Ako IPC znaci isto sto i CPI odnosno Clockticks per Instructions Retired onda on zavisi ne samo od efikasnosti arhitekture, vec pre svega od koda koji se na njoj izvrsava.

Proberi par long latency instrukcija, napravi dugacak data-dependence chain i ubaci neke instrukcije koje dovode do serijalizacije ili stall-a i imaces los CPI na svakoj arhitekturi.

Dalje, CPI se u tipicnoj aplikaciji krece izmedju 1 i 5.

A high value for this ratio indicates that over the current code region, instructions are taking a high number of processor clocks to execute. This could indicate a problem if most of the instructions are not predominately high latency instructions and/or coming from microcode ROM. Note: Using the latest compilers (Microsoft* Visual Studio* 7.0 or later, or the Intel(R) Compiler 6.0 or later) can significantly improve performance on the Intel(R) Pentium(R) 4 Processor.

Da li potpuno ozbiljno mozes da kazes da Core nije daleko efikasniji od Netbursta?

Naravno da ne!

Ono sto hocu da kazem je da se uz minimum ulozenog truda dobar CPI moze postici i na Netburstu.

To automatski znaci da CPI sam za sebe nije dobro merilo efikasnosti arhitekture. Ono sto krajnjeg korisnika zanima je broj operacija (koje su njemu bitne) u jedinici vremena. Na primer FPS u DivX enkodiranju, MB/s za kompresiju, obradu slike, etc.

Po meni najbolji primer ovoga o cemu pricam je Super PI. Bajatiji kod ces tesko naci:

- Legacy 386/387 kod -> SIMD zvrji prazan, cak ni FPU kod nije pipelined uz pomoc FXCH
- Koristi polovine 16-bitnih registara (AH/AL, itd) -> partial register stall
- Koristi LAHF/SAHF pa uslovni skok Jcc -> partial flags stall
- Koristi MOV AX, WORD PTR [mem] -> LCP (length changing prefix), penal za Core 2
- Koristi Rounding mode change -> penal na Netburstu, nesto manji na Core 2
- koristi zastareo algoritam, itd, itd.

Sa druge strane PiFast racuna istu stvar 14x brze, a cak ni on ne koristi maksimum.

Da li je onda Super PI zaista merilo efikasnosti moderne arhitekture?

 

[DeanXP]

Pa jedini pravi replay u Netburstu (i onaj koji su mogli da izmere performance counterima):

- Split Load Replays
- Split Store Replays
- MOB Loads Replays (Blocked Store Forwards Replays)

Koja je prednost replay-a nad mikroarhitekturama koje ga nemaju?
Split Load/Store je pristup podatku koji prelazi granice kes linije. To opet utice na sve mikroarhitekture. Koja je prednost sa replay-om?

Ako pogledas listu iznad, videces da su uzroci load replaya uvek klasicni penali koji nastaju usled izvrsavanja legacy instrukcijskog miksa generisanog od strane bajatih kompajlera.

Koliko mora da je bajat kompajler da uopste ne racuna na cache line alignement?
Mada je to vise pitanje organizacije podataka. Koliko mi je poznato u odredjenim media zadacima je neizbezno – zato Penryn ima mehanizam za ubrzavanje split load-a.

Efikasan SIMD, po mom misljenju cak efikasniji od SIMD implementacije u K8 arhitekturi (sto naravno ne znaci da je K8 arhitektura u celosti bila manje efikasna).

Da, za x87 su se potrudili, ali je SIMD slabiji. 128-bitni load-ovi prave problem zbog 2x64-bit portova, dok Netburst ima 128-bitni load port. Pored toga je K8 fp scheduler blago retardiran.

Naravno da postoji, ako je pipeline dugacak onda mu linearan i paralelan pristup obrade podataka vise odgovara nego random.

Kojoj mikroarhitekturi vise odgovara random nego linearan i paralelan pristup podacima?
Za paralelizam se radi na sirini, a za linearan pristup na prefetcher-u. To se moze lako postici i bez dugog pipeline-a. Core: kratak pipe, odlican SIMD. Ima sjajnih SIMD masina sa kratkim pipelinom I u ne-x86 svetu, ali da se ne udaljavam.
Znaci taj deo je nezavisan od duzine pipeline-a, dok random pravi manje penale na kracem pipeline-u nego na duzem. Pored toga je tesko naci nesto sto odgovara random pristupu.

Deljena je u postojecim SMT implementacijama ali su se pojavile neke interesantne ideje koje obecavaju prevazilazenje problema vezanih za SMT i deljeni RRF.

Do tell. Mislis na clustered microarhitekturu?

Ako IPC znaci isto sto i CPI odnosno Clockticks per Instructions Retired onda on zavisi ne samo od efikasnosti arhitekture, vec pre svega od koda koji se na njoj izvrsava.

Proberi par long latency instrukcija, napravi dugacak data-dependence chain i ubaci neke instrukcije koje dovode do serijalizacije ili stall-a i imaces los CPI na svakoj arhitekturi.

Dalje, CPI se u tipicnoj aplikaciji krece izmedju 1 i 5.

IPC – instructions per cycle (clocktick) – dakle, isti smisao kao CPI samo reciprocno.
CPI od 1 do 5 je IPC od 1 do 0.2, pri cemu je max IPC 3 (P4/K8) ili 4 (C2D).

To automatski znaci da CPI sam za sebe nije dobro merilo efikasnosti arhitekture. Ono sto krajnjeg korisnika zanima je broj operacija (koje su njemu bitne) u jedinici vremena. Na primer FPS u DivX enkodiranju, MB/s za kompresiju, obradu slike, etc.

Upravu si. Efikasnost je relatvna stvar.
Za desktop korisnika su najvaznije ciste performance.
Za mobile i u poslednje vreme za server je vazan performance/watt kao mera efikasnosti – tu je Netburst definitivno krenuo u pogresnom smeru.
A postoji i performance/die area koji je bitan samim proizvodjacima.

Da li je onda Super PI zaista merilo efikasnosti moderne arhitekture?

Nikako.
Ali je iz nekog neverovatnog razloga postao OC benchmark No. 1. Jos je ulozen i trud da preciznije prikazuje vreme i anti-cheating, a isti stari krs kod.
Nije bitno koliko je PiFast brzi kad se ne zove SuperPI. Hm… Pitam se da li je ime SuperPI zasticeno? Audiofreak, jesi mozda razmisljao da napises pi program i nazoves ga SuperPI v2.0? 😀

 

[audiofreak]

Koja je prednost sa replay-om?

Zaista ne znam, mozda je i nema. Samo sam pokusao da ti objasnim da postoje dve vrste replay-a.

Koliko mora da je bajat kompajler da uopste ne racuna na cache line alignement?

To uopste nije posao za kompajler.

Mada je to vise pitanje organizacije podataka. Koliko mi je poznato u odredjenim media zadacima je neizbezno – zato Penryn ima mehanizam za ubrzavanje split load-a.

To postoji jos od SSE3 u vidu LDDQU instrukcije. Penryn ima novu load instrukciju iz USWC memorije.

Kojoj mikroarhitekturi vise odgovara random nego linearan i paralelan pristup podacima?

Pa kraci pipeline svakako ima manji overhead kod random pristupa.

To se moze lako postici i bez dugog pipeline-a. Core: kratak pipe, odlican SIMD.

Slazem se, ali zasto onda stari Netburst Celeroni tuku nove Core based Celerone u recimo Photoshop testu (naravno poredjeni na default taktu)?

Do tell. Mislis na clustered microarhitekturu?

Pa ima raznih pristupa, Google for RRF SMT. Hint: pogledaj kineske radove na tu temu.

Audiofreak, jesi mozda razmisljao da napises pi program i nazoves ga SuperPI v2.0? 😀

Nisam pravo da ti kazem, mrzi me da pisem to od nule, a imam gomilu nekih korisnijih algoritama u glavi koji cekaju da im posvetim vreme.

 

[DeanXP]

To postoji jos od SSE3 u vidu LDDQU instrukcije. Penryn ima novu load instrukciju iz USWC memorije.

Uncacheable memorija je druga stvar. Info od Intela - ovo je za cache:
"The Penryn family's enhanced cache line split loads greatly improves performance by speculatively dispatching both halves of a split load potentially ahead of other loads or stores. This can speed up the performance of certain applications that perform data scans, such as video motion estimation."

Slazem se, ali zasto onda stari Netburst Celeroni tuku nove Core based Celerone u recimo Photoshop testu (naravno poredjeni na default taktu)?

Netburst Celeroni rade na 50-100% vecem taktu. Nije bas ni Core svemocan 🙂

 

[audiofreak]

"The Penryn family's enhanced cache line split loads greatly improves performance by speculatively dispatching both halves of a split load potentially ahead of other loads or stores. This can speed up the performance of certain applications that perform data scans, such as video motion estimation."

A pa to je onda poboljsanje memory disambiguation-a, a ne nova instrukcija zar ne?

 

[DeanXP]

Nisam ni rekao da je nova instrukcija.

 

[audiofreak]

I tako, posto je Core 2 Duo nasledio Netburst branch predictor...

Jesi li znao da Netburst branch predictor ima globalni i lokalni branch history, kao i staticki prediktor?

Staticki kaze:

-Unconditional jump is predicted as taken
-Backward conditional jump is predicted as taken
-Forward conditional jump is predicted as not taken

Postoje i jump hintovi u vidu dva jednobajtna prefiksa koji govore procesoru da ce skok koji sledi iza prefiksa biti taken ili not taken i koji imaju prednost nad statickim prediktorom.

Dinamicki prediktor (lokalni/globalni) moze imati cetiri stanja:

-Strongly taken
-Weakly taken
-Weakly not taken
-Strongly not taken

Najgora je varijanta ako imas 50/50 verovatnocu da ce jump biti taken, a lokalni prediktor krene iz pogresnog stanja. Zato postoji i nedokumentovani hint za ovu situaciju (prefix bajt) koji govori lokalnom prediktoru da krene iz weakly taken i da radi alternaciju (weakly taken, weakly not taken) pa je moguce i u takvim sumanutim slucajevima izvuci 100% predvidljivost skokova na osnovu history-ja.

Pretpostavljam da sve ovo radi i na Core 2 Duo, nisam imao prilike da probam.

 

[DeanXP]

Staticki kaze:

-Unconditional jump is predicted as taken
-Backward conditional jump is predicted as taken
-Forward conditional jump is predicted as not taken

Postoje i jump hintovi u vidu dva jednobajtna prefiksa koji govore procesoru da ce skok koji sledi iza prefiksa biti taken ili not taken i koji imaju prednost nad statickim prediktorom.

To je isti staticki predictor koji ima i P6, ali ne i Core. Staticki predictor se primenjuje samo kada o jump-u nema nikakvih podataka u history table tj. kada se jump prvi put sretne. Core u tom slucaju nasumicno pripise taken/not taken, bez obzira koji je smer grananja (ni hintovi ne rade).
Ovaj sistem je u sustini neprecizniji, ali jednostavniji i znacajno brzi, sto je na kraju dana vaznije jer staticki predictor ima vrlo mali doprinos.

Dinamicki prediktor (lokalni/globalni) moze imati cetiri stanja:

-Strongly taken
-Weakly taken
-Weakly not taken
-Strongly not taken

Da, to je saturating counter, ali on je samo pola price posto svi moderni procesori primenjuju two-level predictor. Prvi deo je registar sa n bita istorije grananja - taken/not taken stanje poslednjih n grananja (16 za Netburst, 8 za Core). Na osnovu tog registra se adresira 2^n saturating countera koji predstavljaju pattern history.
Jedina nezgodna stvar, koja utice na sve microarhitekture, je sto sa povecanjem dubine istorije 👎 potrebna memorija raste eksponencijalno. Jedna od zanimljivih resenja za buducnost je neural branch predictor, koji trosio znacajno manje memorije (linearan rast), ali se jos uvek radi na tome da se njegova brzina dovede na nivo klasicnih predictora.

 

[audiofreak]

To je isti staticki predictor koji ima i P6, ali ne i Core. Staticki predictor se primenjuje samo kada o jump-u nema nikakvih podataka u history table tj. kada se jump prvi put sretne. Core u tom slucaju nasumicno pripise taken/not taken, bez obzira koji je smer grananja (ni hintovi ne rade).

Jesi li siguran u vezi ovoga? Izvor?

 

[DeanXP]

Intel® 64 and IA-32 Architectures Optimization Reference Manual

3.4.1.3. Static Prediction:
"Pentium M, Intel Core Solo and Intel Core Duo processors do not statically predict
conditional branches according to the jump direction."

 

[audiofreak]

Intel® 64 and IA-32 Architectures Optimization Reference Manual

3.4.1.3. Static Prediction:
"Pentium M, Intel Core Solo and Intel Core Duo processors do not statically predict
conditional branches according to the jump direction."

Jes' vidi stvarno... sto li su to izbacili kad je radilo?

 

[DeanXP]

Napisao sam zasto u postu #10...