Készítette: Trosztel Mátyás Konzulens: Hajós Gergely

Átírás

1 Készítette: Trosztel Mátyás Konzulens: Hajós Gergely

2 Monte Carlo Markov Chain MCMC során egy megfelelően konstruált Markov-lánc segítségével mintákat generálunk. Ezek eloszlása követi a céleloszlást. A mintavételezett értékekből becsüljük a keresett mennyiséget.

3 A sorrendezések tere felett lépked. Ez a tér sokkal kisebb és kevésbé tüskés, így gyorsabb konvergenciát biztosít a stacionárius eloszláshoz. X 2 X 2 X 2 X 4 X 3 X 4 X 4 X 3 X 3 X 1 X 1 X 1 G 1, G 2,

4 Mennyire jó a sorrendezésünk? Ahol a score() azt a valószínűséget adja meg hogy D adat mellett X i változónak Pa G (X i ) a szülői halmaza. A szülői halmazok megválasztása független egymástól, ezért: Ahol U a sorrendezéssel kompatibilis szülői halmazok halmaza

5 A sorrendezések tere n! méretű, ezért zárt formában csak kevés változóra tudnánk kiszámolni. Itt jön segítségünkre az MCMC algoritmus. A Markov-láncot úgy hozzuk létre, hogy a stacionárius eloszlása P(D ) legyen. Ezek után bármilyen f( ) függvény várható értékét meg tudjuk határozni: Ahol T az iterációk száma

6 Globális cache építés MPI segítségével -> ~ score számítás párhuzamosítása 139 változó, futási idő lépés találat valószínűség lokális s 99,01% eloszott (6 klienssel) 5 938s 99,61% elosztott (12 klienssel) 5 349s 99,80%

7 Adat- és feladat párhuzamos modell Az ISO C99 szabvány részhalmaza párhuzamos kiegészítésekkel Heterogén platform támogatás Többmagos CPU-k Grafikus hardver (GPU) Jelfeldolgozó processzorok (DSP) Cell/B.E. processzor Az OpenCL elemei Platform modell Végrehajtási séma Memória modell Program modell

8 Cache miss minimalizálása Folytonos adatszerkezetek (felejtsük el az OOP-t) Az adat tömb belefér az L3 cache-be -> egyszerre több score-t számoljunk, ne csak szükség esetén. Vektoros (SIMD) utasításkészlet kihasználása (SSE) Gyors load/store biztosítása.

9 Egy feladatra több speciális kernel. Futásidejű fordítás. Jobb optimalizáció. Ciklus kifejtés (unroll) Elágazás megszüntetése (GPU-n különösen drága) Szükséges regiszterek csökkentése -> Külön kernel 1,2,,k szülő számú score kiszámításához. Optimális globális memória elérés biztosítása 64B-os igazítás, folytonos olvasás. (random memória elérés ~16x lassabb mint az ideális)

10 Adat tömb: CPU: 1load MMX regiszterbe (SSE) GPU: 1 32B tranzakció ushort16-ba d 1,1 d 1,2 d 1,3 d 1,4 d 1,L Padding 64B X 1 d 2,1 d 2,2 d 2,3 d 2,4 d 1,L Padding 64B X 2 d 3,1 d 3,2 d 3,3 d 3,4 d 1,L Padding 64B X 3 d n,1 d n,2 d n,3 d n,4 d n,l Padding 64B X n D 1 D 2 D 3 D 4 D L

11 Eredeti c++: 3ms/score OpenCL CPU: 0.025ms/score (AMD Phenom II 1 magra vetítve: 0.1ms -> 30x gyorsulás OpenCL GPU: 0.11ms/score (AMD Radeon 4850) 27x gyorsulás Nagy feltételes eloszlás táblák -> register spilling Kevés és egyszerű műveletek -> memória késleltetés nem fedhető el hatékonyan

12 Párhuzamosítás: Markov-láncok CPU: Ha több mag van mint lánc akkor kihasználatlan. GPU: nagyon kevés szál, optimálisan >1000 szál kell Párhuzamosítás: Ordering változó score Függetlenül számolható CPU: ok GPU: random memória olvasás kevés szál -> a szülői halmazok mentén is tudunk párhuzamosítani.

13 X 2 Cache-elt értékek X 2 X 4 X 4 Cache-elt értékek X 3 Szál 1 X 3 X 1 Szál 2 X 1 Szál 5 X 6 Szál 3 X 6 Szál 6 X 5 Szál 4 X 5 Szál 7 X 7 Cache-elt értékek X 7 Szál 8 X 8 1. Lánc X 8 2. Lánc Szál 9

14 Az MPI verzió futási idejének fele score számítással telt. Ezt jelentősen sikerült gyorsítani -> 2x gyorsulás. Ordering párhuzamos számítása ->?x gyorsulás. (~CPU mag/markov-lánc)

15

16 Szülő halmaz -> (0,C(N,k)+C(N,k-1)+ C(N,0)) l-binomiális ábrázolás pl. (l=k=4) m = 26 = C(6,4) + C(5,3) + C(2,2) Ez a {6,5,1,0} m = 126 = C(9,4) -> {8,7,6,5} Visszafelé: pl. {1,7,6,2} = {7,6,2,1} -> C(7,4) + C(6,3) + C(3,2)

17 X 2 X 4 X 3 X 2 X 4 X 5 Két tetszőleges változót felcserél a sorrendezésben. X 1 X 1 X 6 X 6 X 5 X 3 X 7 X 7 X 8 X 8

18 X 2 Nem változnak a szülői halmazok. X 4 Nem változik a score. X 3 X 1 Csak itt változnak a szülői halmazok. X 6 Ezekre kell újraszámolni a score-t! X 5 X 7 Nem változnak a szülői halmazok. X 8 Nem változik a score.

19 X 2 X 4 X 3 Két részre vágja a sorrendezést és a két halmaz sorrendjét felcseréli. X 5 X 7 X 8 Mindenhol változás történt a szülői halmazokban X 1 X 2 X 6 X 4 X 5 X 3 Mindenhol újra kell számolni a score-t! X 7 X 1 X 8 X 6

20 Csak 32B, 64B, 128B, (256B) tranzakciók. 64B igazított 128B igazított szálak

21 Optimális elérés: maximális sávszélesség 64B igazított 128B igazított szálak 1db 64B tranzakció

22 Nem igazított elérés 64B igazított 128B igazított szálak 1db 128B tranzakció 1db 64B + 1db 32B ha átlóg a 128B határon Nagy sávszél pazarlás!

23 Stride x=3. 64B igazított 128B igazított szálak 1db 128B + 1db 64B tranzakció Nagyon rossz kihasználtság nagy x esetén!

24 NDRange Gy Feladat egység Feladat egység Feladat egység Feladat egység Munkacsoport méret Sy NDRange Gx Munkacsoport méret Sx

25 OpenCL eszköz Számító egység Privát mem Privát mem Számító egység Privát mem Privát mem PE 1 PE M PE 1 PE M Lokális mem Lokális mem Globális/Konstans memória cache Globális memória Konstans memória

26 Hoszt <-> VRAM adatmozgatás Amit lehet tároljuk a GPU-n és dolgozzuk is fel ott. Async elérés. Kevés privát memória Rövid, egyszerű kernelek Divergens szálakat kerülni kell Probléma felbontása. De megéri? Indítási overhead Lassú double számítás Cél GPU, de még ez sem az igazi. Ahol csak lehet használjunk float típust. Mixed precision Optimális memória elérés Sokszor nehéz. Sok szál A globális ram elérése lassú, hogy ezt elfedjük sok szál szükséges (több ezer).