Piledriver modul je znatno efikasniji od Bulldozer modula u dekodiranju instrukcija

[drfedja]

Da se podsetimo malo... Bulldozer i Piledriver modul se sastoji od deljenog front-enda, koji sadrži zajednički keš za instrukcije, branch prediction, kao i x86 dekodere, koji su zaduženi da "nahrane" dva jezgra i jedan deljen FPU.
Svako jezgro u modulu poseduje zasebni L1 data keš, keš prvog stepena za podatke, odakle procesor dobija podatke sa kojima operiše. Keš za podatke je zadužen da operandima, odnosno podacima "nahrani" i FPU jedinicu, zbog čega je širina njegovih portova 2x128-bita za load. Dakle, svako jezgro poseduje 16KB L1 data keša sa 2x128-bita za čitanje i 1x128-bita za pisanje. Teoretski, trebalo bi da je moguće na modulu dekodirati maksimum 4 instrukcije, odnosno dve 128-bitne SIMD za jedan thread i dve 128-bitne SIMD za drugi thread. Opkod sadrži nekoliko bajtova i te četiri instrukcije bi trebale da stanu u fetch fazu čiji buffer sadrži maksimum 32 bajtova.

Letos sam malo proučavao kako se ponaša FPU na FX8120 kada se optereti modul sa 2 threada, koja bi trebalo da daju 2 128-bitna load-a i došao sam do zaključka da nije bilo moguće izvršiti više od dva 128-bitna load-a u celom modulu iako je teoretski moguće izvršiti i četiri. Dokaz za to je ovo:
Singlethread - 2x128-bit load, ukupno 2x16Bx4.1 GHz = 131.2 GB/s teoretski transfer L1D keša, po threadu, praktično 107 GB/s, što je ok.

Dual thread u modulu - trebalo bi da bude 4x128-bit, ukupno 4x16Bx4.1 GHz = 262.4 GB/s teoretski, praktično 109GB/s, što odgovara protoku od dve, a ne cetiri instrukcije...

Jedan thread load, drugi store:
Opet imamo ograničenje na samo jednu operacju po threadu...

Kako stvari stoje kod Piledriver jezgara/modula:
Imamo procesor koji radi na 4.5 GHz, što daje teoretski protok keša od 144 GB/s, dakle, efikasnost je 85% u singlethreadu, dok je kod BD-a 81,5%.

Sa dva threada efikasnost ne pada drastično, Piledriver modul može da procesira do četiri 128-bitna load-a:
Efikasnost je i dalje oko 85%, dok je kod BD-a oko 42%.

Piledriver bez problema procesira u isto vreme jedan 2x128-bit čitanja, kao i 1x128-bit upisa u drugom threadu:

Između ostalog, pojavila se hakovana verzija Linpack-a koja koristi AVX instrukcije kod FX procesora. Bulldozer i Piledriver modul poseduje FlexFP, FPU koja sadrži ukupno 4 izvšne jedinice za rad sa vektorima. Širina svake ove jedinice iznosi 128-bita. Moduli podržavaju izvršavanje Intelovih 256-bitnih AVX instrukcija, ali uz neka ograničenja. FlexFP sadrži dve 128-bitne izvršne jedinice za rad sa vektorima u pokretnom zarezu, dok ostale dve su za rad sa celobrojnim vektorima, ali i za bitovske operacije, permutacije itd... FP vektorima.
128-bitne FMA jedinice mogu da izvršavaju 128-bitne FP operacije i to dve istovremeno ili jednu 256-bitnu, koja je obično izvedena preko mikrokoda kao dve 128-bitne, što je u suštini iznuđeno rešenje.
FMA jedinice su dosta fleksibilne, jer mogu da izvrše bilo koju operaciju, sabiranje FADD ili množenje FMUL. Dakle, u teoriji osmojezgarni FX poseduje 4x256-bit FP za AVX, odnosno 8x256-bit za FMA3/4. Praktično FP throughput je dvostruko veći sa FMA instrukcijama.
Ipak, Linpack koristi AVX instrukcije, a teoretski gledano, FX8xxx može da izvrši najviše 16 DP FLOPS operacija po ciklusu koristeći ove instrukcije, dok Sandy Bridge može da izvrši 32 DP FLOPS operacije, zahvaljujući tome što svako SB/IB jezgro poseduje 1x256-bit FADD i 1x256-bit FMUL. Glavna razlika je u tome što PD/BD FPU/modul izvršava 1x256-bit FADD ILI 1x256-bit FMUL, tako da je teoretski throughput ovih instrukcija isti kao na SB/IB, ali je mogućnost paralelnog izvršavanja FADD i FMUL dvostruko manja.

Piledriver uspeva da izvuče neverovatnih 91 GFLOPS koristeći AVX sa 8 threadova:

Da bi testirao efikasnost, iz biosa sam uključio opciju 1 core per module, tako da sam isključio CMT:

Sa istim brojem FPU jedinica i dvostruko manjim brojem threadova, broj GFLOPS-a je bio tek neznatno manji, što potvrđuje činjenicu da jedno jezgro može da iskoristi skoro ceo FPU.

Ako uzmemo u obzir da FX8350 može da izvrši najviše 16DP AVX FLOPS-a po ciklusu, to na 4.5 GHz daje maksimalni throughput od tek 72 GFLOPS-a, zanimljivo je to kako je postignuto čak 91 GFLOPS, ako PD FPU ne može da izvrši više od jedne 256-bitne operacije po ciklusu.

Objašnjenje upravo leži u testovima 128-bitnih load-a. Moguće je u modulu 2x128-bit LOAD, za svaki thread posebno.
PD FPU može da izvrši dve 256-bitne operacije u modulu, ali sa nešto manjom efikasnošću nego Sandy Bridge, zbog mikrokodovanih instrukcija.

 

[vujasoft]

Posle onog jucerasnjeg post-a o linx-u sam i ja skinuo avx verziju i potvrdio isti rezulat.
A10-5800K sa standardnim linx-om izbacuje oko 18GFlopsa na def. vrednostima, dok sa avx verzijom gura 37-40.

 

[drfedja]

U readme fajlu piše šta su frajeri uradili da bi to radilo kako valja...
Originalni kod koji određuje da li će linpack koristiti Linpack math library je sledeći:

linpack_xeon64.exe (Intel CPU only)
CRC-32: ee84f31b
   MD5: ea2c1ed5d9ea12a3df2e47ee7666ab12
 SHA-1: a4f9effd7b23afc85b8b3858ff44c9764c580f8c

00046C	85 C0	Test	EAX, EAX		  ; Not Zero = Intel, Zero = AMD
00046E	75 2B	JNE	Some Memory Address	  ; Intel, so go to Math Routine

Kod koji je patch-ovan izgleda ovako:

linpack_xeon64.exe (Patched, Both Intel and AMD)
CRC-32: 3f167792
   MD5: 4032d811603594a0785c7bb1dd67bf7b
 SHA-1: 8a7f62581846bd33be45161f09738f348e07882c

00046C	85 C0	Test	EAX, EAX		  ; Not Zero = Intel, Zero = AMD
00046E	EB 2B	JMP	Some Memory Address	  ; Don't care just go to Math Routine

JNE je instrukcija uslovnog skoka, dok je JMP instrukcija bezuslovnog skoka. JNE - Jump if not zero.

 

[Shang Tsung]

Jea, linx vuce na 90 GFLOPS. Sad, da li je ovo pravo merilo za poredjenje sa intelovim AVXom, tj da li se moze uporediti odnos snaga preko gflopsova izmedju FXa i intela i5, i7?

 

[drfedja]

Ne, zato što je drugačija koncepcija. U suštini 256-bitne AVX instrukcije kod FXa su mikrokodovane kao dvostruke 128-bitne. U principu FlexFP bolje radi sa 128-bitnim FMA i AVX instrukcijama nego sa 256-bitnim, jer je brzina dekodiranja veća. 256-bitne operacije su uvek duplo dekodirane, što znači da jedna instrukcija se razbija u dva makroopa i kao takva se šalje na izvršavanje. Eventualno da bi se postigla veća efikasnost u dekodiranju i izvršavanju, par instrukcija sabiranja i množenja mogao bi da se dekodira interno kao FMA, čime bi se postigao veći throughput, mada tu postoji problem oko načina zaokrugljivanja FP brojeva, što bi moglo da dovede do netačnog računanja.

The floating-point logic in AMD Family 15h processors uses four separate execution positions
referred to as pipes 0, 1, 2 and 3. The mapping of these pipes to floating-point units is illustrated in
Table 8 on page 238. Two 128-bit fused multiply-accumulate units and two 128-bit integer units are
provided. This improves the FPU bandwidth up to four times over the previous AMD64 processors.
For details on the floating-point unit see “Floating-Point Unit” on page 37.

FlexFP koristi dve 128-bitne FMA jedinice, i dve 128-bitne integer jedinice i u principu u isto vreme je moguće izvršiti operacije na sve četiri.
Kod Intela za 256-bitne AVX instrukcije koriste se datapath-ovi od integer SIMD (MMX) ALU-ova, a na istom portu se nalaze i ALU jedinice. Sandy Bridge ukoliko radi sa 128-bitnim AVX ima dvostruko manji throughput nego sa 256-bitnim, tako da ono što bi se isplatilo na AMD-u ne bi se isplatilo na Intelu i obrnuto.

 

[drfedja]

Jea, linx vuce na 90 GFLOPS. Sad, da li je ovo pravo merilo za poredjenje sa intelovim AVXom, tj da li se moze uporediti odnos snaga preko gflopsova izmedju FXa i intela i5, i7?

Da, zaboravih... Linpack je kompajliran Intelovim kompajlerom koji je optimizovan za Intelove procesore, tako da ovih 90 GFLOPS-a je veoma dobar rezultat.
Najbolje poređenje bi bilo sa Thubanima.