Bulldozer FlexFP isn't so flex!

[drfedja]

Sigurno ste se pitali zašto Buldi ima loše rezultate u FP intenzivnim aplikacijama i zašto npr. Linpack daje očajne rezultate.
Malo sam se bahtao sa time kakve penale ima deljen FPU i kakve su mogućnosti rada sa ovim deljenim resursom, koja su uska grla i došao sam do zaključka da su stručnjaci iz AMD-a napravili mali broj read/write portova.
Naime o čemu se radi, FPU za učitavanje podataka iz jezgara, odnosno L1D cache-a koristi load buffer koji je u stanju da učita ili piše najviše 2 operacije i to najviše 128-bitne. Nebitno je koliko podataka iz registara u L1D keš treba da transferuje, moguće su jedino i samo dve operacije, bilo da je jedan thread u pitanju ili dva. Evo dokaza:
1 thread, 2x128-bit SSE2 load:

Jasno se vidi da je transfer preko 100GB/s iz L1 keša. Namerno je postavljena vrednost dataseta na 8KB da bi stao u 16K L1-D cachea BD jezgra.
Računica je jednostavna, 2x16B(2x128-bit)x4.1GHz = 131 GB/s, što je teoretski maksimum, ali u praksi je iskorišćenje L1D cache bandwidtha oko 80% u ovakvim situacijama. Dakle, BD, kao i Phenom poseduje 2x128-bit load.

2 thread, 2x128-bit SSE load:

Šta se ovde dešava? Pa iako BD ima separatni L1D keš u svakom integer jezgru, bandwith je prepolovljen. Usko grlo nije integer blok, nego load buffer u FPU jedinici i broj 128-bitnih SSE2 portova. Jasno je da nije moguće izvršiti više operacija istovremeno od dve na FPU jedinici iz prostog razloga jer je ograničen broj izvršnih jedinica i portova. Svaki thread dobija po 1x128-bit load, što se jasno vidi iz transfera. Transfer za oba threada je vrlo sličan kao i transfer za jedan thread.

2 thread-a, 1x128-bit load, 1x128-bit store:

Ovde imamo upis, koji je zapravo daleko manji od 128-bit storea i polovinu ukupnog load bandwitha. Imamo samo dve operacije za dva threada iako imamo 2 jezgra sa dva L1D cache-a koji navodno imaju 2x128-bit loada i 1x128-bit store, 4-wide dizajn, tu bi moralo da bude moguće obaviti barem 4 keš operacije po ciklusu. Naravno, usko grlo je fpu load buffer, a nizak transfer upisa u L1D keš je uzrokovan write back keš arhitekturom, kod koje brzina upisa u L1D zavisi od transfera u L2 jer se za svake novu liniju koja se upisuje u L1, linija sa tog mesta se izbacuje u L2.
Elem, poenta je da su i dalje moguće samo 2 operacije. FPU load buffer koristi 2 porta širine 128-bita za upis i čitanje, ekskluzivno. Dakle, ne može 2 load-a i 2 store-a, može ili 2 loada ili 2 store-a ili 1 load i 1 store.

2 thread-a, 1x128-bit SSE2 load, 1x64-bit MMX load

Flex FPU ima 2 128-bitne FMA jedinice, koje izvršavaju SSE2 instrukcije i ima još dva pipelinea koja izvršavaju pakovane integer operacije, t.j. MMX, integer SSE ili XOP itd....
U ovom primeru se vidi da iako ne manjka izvršnih jedinica, i dalje se izvršavaju samo 2 operacije iz 2 različita threada. Dakle, razlog tome je mali broj FPU portova.
Dakle, FlexFP unutar Buldožer modula može da izvrši i više od 2 operacije, ali možda u nekim situacijama gde imamo rad sa registrima.
Iskreno voleo bih da vidim uskoro kako ova mikroarhitektura tretira rad sa novim ultra fancy FMA4 instrukcijama, s obzirom da je količina podataka koju jedna FMA instrukcija nosi praktično 2x veća od SSE2.
Trebaju nam operandi A*B+C i ciljni registar, ne destruktabilni, svaki po 128-bita. U principu za izvršavanje FMA4 potrebno je učitati u registar tri 128-bitna operanda. Čisto me interesuje da li Flex FP ovu operaciju čitanja tretira kao jednu operaciju, što bi bilo logično da je tako inače ne bi bilo nikakve koristi od famoznih instrukcija.

 

[deluxe]

Poucno. Bravo fedja!

 

[drfedja]

Evo upravo čeprkam sa Code Analystom i pokušavam da prokljuvim šta je razlog niskog IPC-a. Npr. kod zanimljivo je da FPU instrukcije, npr. ADDPS (SSE2 instrukcija za single precision vektor, koja radi sabiranje) dostižu IPC 2 u single threadu, kada npr. pustiš cinebench10. Ovo znači da jedno jezgro je u stanju da koristi oba FPU pipe-a u ciklusu, što nije bilo moguće na Phenomima, pa ni na Core arhitekturi. Problem je što mu to ne pomaže da bi performanse bile veće.
Opet, kod Linpacka se tačno vidi pattern instrukcija ADDPD, a zatim MULPD i tako čitava serija koja se izvršava. Idealno za FMA optimizaciju, koja bi ovde dve instrukcije zamenila jednom.
Jedan od razloga zašto većina procesora imaju jedan FADD FPU pipe i jedan FMUL pipe je i priroda algoritama koja primenjuje takav patern izvšavanja instrukcija. Npr. svako množenje matrica koristi ovaj pattern, a to je jedna od najčešćih operacija u Linpacku.
Da bi stvar bila jasnija, evo u matematici kako se množe matrice:

stvar je tu idealna za primenu FMA instrukcija. Ipak, ovo je brute force algoritam, Linpack koristi pametnije rešenje. Npr. Coppersmith Winograd algoritam
Složenost množenja matrica je inače

za naivni algoritam, dok je za ovaj

što je poprilična razlika. No da ne tupim sa implementacijom množenja matrica, evo kako izgledan asemblerski kod Linx-a, t.j. Intelovog Linpacka koji se pokreće na Bulldozer procesoru:

Spojler

IPC po jezgru iznosi 0,79, dok je kod Phenoma II oko 2.25, što tačno pravi onu razliku u GFLOPS-ima.

Evo i ASM koda linpacka:

Spojler

Sad barem znamo da Linpack koristi DP vektore.
Tamo gde je IPC za SSE instrukcije blizu 1 to je ok, u sustini jezgro u modulu moze da izvrsi do 1 SSE2 128-bitne instrukcije. Problem je tamo gde je IPC 0.3. Tako nizak IPC se javlja tamo gde je najveći postotak promašaja Data keša. Problem sa niskim Linx rezultatom može da leži u 16KB L1 Data keša. Postojeća verzija linpacka verovatno radi sa komadima podataka koji prevazilaze veličinu L1D keša buldožer modula. Zbog toga na K10 i na Intel procesorima ovo radi sa velikom efikasnošću.

 

[Shang Tsung]

Sta bi Fedja po tebi trebalo AMD da uradi da poboljsa IPC onda? U najavi je neko poboljsanje od jedva 15% za naslednika. Ne deluje mi da ce to biti iole dovoljno za dalje takmicanje sa Intelom, tj. AMD ce da kaska jos dugo godina.
Koliko sam ja video BD je odlican u tesko-optimizovanim multithread aplikacijama, ali intelova core arhitektura je dosta bolja u overall koriscenju.

 

[drfedja]

Treba da se reše uskih grla. Po meni je princip keš arhitekture koju koriste totalno outdated, još od vremena K7. Neke stvari su pogoršali, npr, keš polisu za upis Write Trough, umest Write Back kakva je kod Core i K10 procesora.
Ima tu dosta uskih grla koja trebaju da se reše. Prvo, mala asocijativnost instrukcijskog keša za dva jezgra koja ga koriste, zatim, ne bi bilo loše da postoji keš za predekodirane makrooperacije, FPU bi mogao da ima 4 porta, čime, što bi ga činilo efikasnijim. FPU može iz oba threada istovremeno da primi sadržaj najviše dva registra širine 128 bita. Ostale mikrooperacije se izvršavaju jedino ukoliko se podaci već nalaze u register file-u . Latencije keša bi bilo veoma pametno smanjiti.
Steamroller bi mogao da ima većinu ovih navedenih detalja.

 

[Shang Tsung]

Ne deluje mi kao da AMDovi inzinjeri ne znaju sta rade. Moguce je da prave neke teske kompromise iz nama nepoznatih razloga.

 

[drfedja]

Kompromisi se rade svakako iz više razloga. Npr. nemogućnost da se tehnološki isprati kompleksniji dizajn, kompleksniji dizajn utiče na frekvenciju, zatim keš arhitektura odgovara određenom tipu serverskih aplikacija. Postoji još jedan problem. AMD nema dovoljno resursa da uposli dovoljno kvalitetnih ljudi da neke stvari adekvatno reše, pa to ide u sitnijim koracima.
Da se razumemo, Buldožer je veoma interesantan koncept, ali je vrlo diskutabilno koliko se isplati proizvodnja i prodaja čipa relativno diskutabilnih performansi u odnosu na prethodnu generaciju. FX6200 npr. ne bi smeo da košta ni blizu prošlogodišnje cene Phenoma II X6 1090T, koja je bila oko 135 evra.
FX 8120 realno vredi toliko novca, dok FX 8150 vredi nešto malo više, tipa 150 €. Koliko AMD zaradi na tim čipovima ja zaista ne znam, ali sigurno je uloženo dosta u razvoj itd...
Mislim da će BD koncept izgledati sa svakom novijom generacijom sve bolje i bolje.