INF2440 Uke 4, v2018 Om å samle parallelle svar, matrisemultiplikasjon og The Java Memory Model. Eric Jul PSE, Inst.

Transkript

1 INF2440 Uke 4, v2018 Om å samle parallelle svar, matrisemultiplikasjo og The Java Memory Model Eric Jul PSE, Ist. for iformatikk 1

2 Hva så vi på i uke 3 1. Presiserig av hva som er pesum 2. Samtidig skrivig av flere tråder i e array? 1. Går det lagsommere år aksesse er til aboelemeter? 3. Sylighetsproblemet (hvilke verdier ser ulike tråder) 4. Java har as-if sequetial sematikk for et sekvesielt program viktigste regler om lesig og skrivig på felles data. 6. To ekle regler for sykroiserig og felles variable 7. Jit-kompilerig ka gi meget store hastighetsforbedriger 8. Effekte på eksekverigstid av cache 1. Del 1 Radix-sorterig sekvesiell 9. Kommetarer til Oblig 1 2

3 Pla for uke 4 I. Om å avlutte k tråder med å samle svaree fra disse. 1 gal + 5 riktige måter. II. III. IV. Ukeoppgave om matrise-multiplikasjo Vi bruker ikke PRAM modelle for parallelle beregiger I. Hva er PRAM og hvorfor er de ubrukelig for oss Hva skjer egetlig i lageret (mai memory) år vi kjører parallelle tråder - the Java Memory Model V. Hvorfor sykroiserer vi, og hva skjer da? VI. Oblig 2: Parallell Matrice-multiplikasjo. 3

4 I) Hvorda samle data fra trådee til ett, felles svar Kursets mål: Riktig og Raskt - begge deler Skal se på ulike måter å løse flg. problem: Vi har delt opp problemet vår i k deler på k kjerer/tråder og parallellisert det. Hvorda kombierer vi disse delresultatee til ett, felles og riktig svar? Ser på problemet FiMax og 6 «løsiger» på dee avslutige: 1. GAL ige sykroiserig 2. Sychroized metode for hvert elemet i a[] 3. ReetratLock beskyttet metode for hvert elemet i a[] 4. Bare kall på samme ReetratLock beskyttet metode hvis y verdi > hittil største verdi. 5. Alle trådee kaller samme ReetratLock beskyttet metode med hver si lokalemaks år de er ferdige 6. Tråd 0 fier max de adre trådee veter 4

5 1) GAL ige sykroiserig, kode i trådee: // Riktig oppdelig at= a.legth/attråder; // atall elemeter per tråd start = at*id; um = at; if (id == attråder-1) um = at + (a.legth % attråder) ; // GAL IKKE sykroisert: for (it i = 0; i< um; i++) { if (a[start+i] > globalmax) globalmax = a[start+i]; } Mulig feilsituasjo, ata tråd 0 leser a[i] der GlobalMax ligger: Tråd 0 Les a[i] =10 og GM = 8 Skriv GM = 10 Tråd 1 Les a[j] =9 og GM = 8 Skriv GM = 9 mai Les GM = 9 Hvor sasylig er dette? Skal vi ta sjase?? 5

6 1) Nei det er like raske og ALLTID riktige løsiger, og slike feil er farlige! Det er vaskelig å få dee gale måte til å feile, me med mye prøvig og feilig (lure data) ka vi få de til å feile ca. ca. hver gag. I Nets (tidl. Bakees Betaligssetral) behadler de opp til 2 mill. trasaksjoer hver dag. Vil vi lage programmer som kaskje feiler 20 gager per dag? Hvor lette tror du slike programmer er å debugge (teste og rette)? 6

7 2) Bruk av sychroized metode for alle elemetee i a[] sychroized void updateglobalmax1 (it val){ if (val > globalmax ) globalmax=val; } // ed updateglobalmax1.. // i ru-metode i hver tråd: for (it i = 0; i< um; i++) { updateglobalmax1(a[start+i]); } 100 % riktig svar alltid Det gjøres kall på de sykroiserte metode (/k kall fra hver av de k trådee) sychroized tar mye tid! Eledig løsig: Regel 1: bruk ikke sychroized Regel 2: Hvis sychroized alikevel, så max 100 gage! 7

8 3) Bruk av ReetratLock metode for alle elemetee i a[] void updateglobalmax2 (it val){ lock.lock(); try{ if (val > globalmax ) globalmax=val; } fially { lock.ulock(); } } // ed updateglobalmax2. // i ru-metode i hver tråd for (it i = 0; i< um; i++) { updateglobalmax2(a[start+i]); } 100 % riktig svar alltid Det gjøres kall på lock metode (/k kall fra hver av de k trådee) Lock er raskere e sychroized, me tar fortsatt mye tid! Eledig løsig 8

9 4) Bruk av ReetratLock metode hver gag ytt elemet er større void updateglobalmax2 (it val){ lock.lock(); try{ if (val > globalmax ) globalmax=val; } fially { lock.ulock(); } } // ed updateglobalmax2. // i ru-metode i hver tråd for (it i = 0; i< um; i++) { if (a[start+i] > globalmax ){ updateglobalmax2(a[start+i]); }} 100 % riktig svar alltid Det gjøres log kall på lock metode (log/k kall fra hver av de k trådee) Lock er raskere e sychroized, og log kall er mye midre e (eks. = 1mill, log =20)! Ikke helt bra løsig 9

10 5) lokal max (threadmax) i hver tråd, så oppdaterig med lock - metode // i ru-metode i hver tråd for (it i = 0; i< um; i++) { if (a[start+i] > threadmax ) threadmax = a[start+i]; } updateglobalmax2(threadmax); } 100 % riktig svar alltid Det gjøres k kall på lock-metode (ett kall fra hver av de k trådee) Utmerket løsig 10

11 6) lokal max (threadmax) i hver tråd, så vetig i y CyclicBarrier (vetm5), og tråd 0 order opp // i hver tråd i ru-metode for (it i = 0; i < um; i++) { if (a[start+i] > threadmax ) threadmax = a[start+i]; } lokalmax[id] = threadmax; try { // wait o all other threads vetm5.await(); } catch (Exceptio e) {retur;} 100 % riktig svar alltid Det gjøres k kall på lock metode (ett kall fra hver av de k trådee) for (it j = 0; j < attråder; j++){ if (id == 0) { } } if (lokalmax[j] > globalmax) globalmax = lokalmax[j]; Utmerket løsig Riktig og det gjøres k kall på e CylicBarrier(ett kall fra hver av de k trådee) Utmerket løsig 11

12 Speedup for =100,1000,,1 mrd med 8 tråder/kjerer 12

13 Hva lærer vi av dette? E gal, to eledige, e dårlig og to gode løsiger Aldri bruk e gal metode (går alltid galt med i++ - programmet, sjelde galt her, me..) Det er alltid e eller flere like raske og riktige løsiger Atall sykroiseriger er helt avgjørede, log eller k (k er et fast, lite tall) Geerelt: Det er lagt flere alterativer i det parallelle programmet e i det sekvesielle. Her har vi e løsig hvor vi bare lager trådee bare é gag. Vi kue (lagsommere) ha laget ye tråder hver gag og at mai sa joi() på dem 5 ye alterativer. 13

14 Tillegg, hva om sekvesiell max lages som metode? it RegutMaxSeq(it [] a) { it seq =0; for (it i=0;i < a.legth;i++){ if (a[i] > seq) seq = a[i]; } retur seq; }//ed RegutMaxSeq.. globalmaxseq = RegutMaxSeq(a); // for (it i=0;i < a.legth;i++){ // if(a[i] > globalmaxseq) globalmaxseq = a[i]; // } Hvorfor skulle det gå fortere?? JIT-kompilerig?? 14

15 Mye bedre JIT-kompilerig av sekvesiell beregig (= raskere sekvesiell bergig); samme parallelle og samme form på kurvee, me da lavere speedup. Her ca. 3x raskere - bedre JIT kompilerig av små metoder e kode ilie i e større metode. 15

16 Ny I DAG: Hvis vi ser på kjøretidee, så burde de kue gjøres oe bedre! // i ru-metode i hver tråd oe lagsom for (it i = 0; i< um; i++) { if (a[start+i] > threadmax ) threadmax = a[start+i]; } updateglobalmax2(threadmax); } // bedre: i ru-metode i hver tråd - raskere for (it i = fra; i< til; i++) { if (a[i] > threadmax ) threadmax = a[i]; } updateglobalmax2(threadmax); } 16

17 Ny I DAG: Hvis vi ser på kjøretidee, så burde de kue gjøres oe bedre med y for-løkke + små metoder Speedup går opp fra 1.6 til7,6 Kjøretider for N= 100 mil - y forløkke og lite metode for hver løkke: Met:0, Para: ms; Sekv: ms., SUp: Met:1, Para: ms; Sekv: ms., SUp: Met:2, Para: ms; Sekv: ms., SUp: Met:3, Para: ms; Sekv: ms., SUp: Met:4, Para: ms; Sekv: ms., SUp: Met:5, Para: ms; Sekv: ms., SUp: Speedup går opp fra 1.6 til7,6 Kjøretider for N= 100 mil - gammel forløkke og lite metode for hver løkke : Met:0, Para: ms; Sekv: ms., SUp: Met:1, Para: ms; Sekv: ms., SUp: Met:2, Para: ms; Sekv: ms., SUp: Met:3, Para: ms; Sekv: ms., SUp: Met:4, Para: ms; Sekv: ms., SUp: Met:5, Para: ms; Sekv: ms., SUp:

18 II) Ukeoppgave forrige og dee uka, matrisemultipliserig Matriser er todimesjoale arrayer Skal berege C=AxB (A,B,C er matriser) +,- c i [j] = ' a i k b k [j] ()* C i,j = A i cc X B cc j

19 Idé traspoer B (=bytte om rader og koloer) Bytt om elemetee i B (B i,j byttes om med B j,i ) Da blir koloee lagret radvis. B cc j B T cc j -1-1 Begruelse: Det blir for mage cache-lijer (hver 64 byte) fra B i cachee 19

20 Vi har da at litt y formel for C +,- c i [j] = ' a i k b T j [k] ()* C i,j = A i cc X B T c c j -1-1 Vi får multiplisert to rader med hveradre går det fortere? 20

21 Kjøretider i millisek. (y-akse logaritmisk) 21

22 Kjøretidsresultater Speedup, y-akse logaritmisk 22

23 Speedup med lieær y-akse 23

24 Koklusjo Matrisemultiplikasjo E rett frem implemetasjo gikk ikke særlig fort (år = 1000 ), tok det : 11,24 sek med valig sekvesiell løsig 3,24 sek. med rett fram parallelliserig 0,91 sek med sekvesiell + traspoerig av B 0,26 sek med først traspoerig av B, så parallellisert Det viktigste år vi skal parallelliser er: Ha de beste sekvesielle algoritme Så ka du parallellisere de Hvis du er veer med cache, vil parallelliserig av e slik algoritme i tillegg este alltid løe seg Dette er ett eksempel på at det å aksessere data fortløpede, ikke på tvers av data, ka gi e speedup på gager. (bare multiplikasjoe ikke traspoerige, ble parallellisert) 24

25 Speedup Hvorda fremstille det? Disse to kurvee er like! Hvorda? 25

26 Hvorda framstille ytelse I Disse fire kurvee fremviser samme tall! Hvorda? 26

27 Både logaritmisk x- og y-akse Fordel med log-akse er at de viser fram øyaktigere små verdier, me vaskelig å lese øyaktig mellom to merker på aksee. 27

28 III) PRAM modelle for parallelle beregiger PRAM (Parallel Radom Access Memory) atar to tig: Du har uedelig mage kjerer til beregigee Ehver aksess i lageret tar like lag tid, - igorerer f.eks fordele med cache-hukommelse Da blir mage algoritmer lette å berege og programmere Problemet er at begge forutsetigee er helt gale. Det PRAM gjør er å telle atall istruksjoer utført Det har vi sett er helt feilaktig (Radix og Matrise-mult) Svært mage kurs og lærebøker er basert på PRAM PRAM vil si at de to sekvesielle algoritmee (med og ute traspoerig) gikk de utraspoerte fortest! Dette kurset bruker ikke PRAM-modelle! 28

29 Noe kommetarer til modell for parallelle programmer import java.util.cocurret.*; class Problem { it x,y,r1,r2,..; // felles data public static void mai(strig [] args) { Problem p = ew Problem(); p.utfoer(12); } void utfoer (it att) { Thread [] t = ew Thread [att]; } for (it i =0; i< att; i++) ( t[i] = ew Thread(ew Arbeider(i))).start(); for (it i =0; i< att; i++) t[i].joi(); :Problem it x,y,r1,r2,..; Thread t[] class Arbeider implemets Ruable { it id, lokaledata; // lokale data Arbeider (it i) {id = i;) public void ru() { // kalles år tråde er startet } // ed ru } // ed idre klasse Arbeider } // ed class Problem :Arbeider it id,lokaldata; :Arbeider it id,lokaldata; 29

30 Noe kommetarer til modell for parallelle programmer import java.util.cocurret.*; class Problem { it [] a; it attr=12;// felles data public static void mai(strig [] args) { Problem p = ew Problem(); p.utfoer(attr); } void utfoer (it att) { Thread [] t = ew Thread [att]; a = ew it [ ]; // + fyll a[] med tilfeldige tall } for (it i =0; i< att; i++) ( t[i] = ew Thread(ew Arbeider(i))).start(); for (it i =0; i< att; i++) t[i].joi(); class Arbeider implemets Ruable { it id, fra,til,um; // lokale data Arbeider (it i) {id = i; um= a.legth/attr; fra =id*um; til = (id+1)*um; if ( id == attr -1) til = a.legth; } public void ru() { // kalles år tråde er startet } // ed ru } // ed idre klasse Arbeider } // ed class Problem 30

31 IV) Utsatte operasjoer i JIT-kompilerig JIT-kompilatore ka godt teke seg å utsette å gjøre oe setiger eks: y = 17; x = 4; z = x + 6; Vi ser at x treges i este setig, så de blir utført, me ige treger y så de ka vete (til vi får tid, eller droppes hvis ige adre setiger bruker y) Vi ka ikke vite at y == 17 selv om x == 4; Vi treger da e måte å orde opp i bl.a: Utsatte operasjoer blir gjort Alle trådee ser de samme verdiee på felles data. 31

32 Repetisjo: 3 viktigste regler om lesig og skrivig på felles data. Før (og etter) sykroiserig på felles sykroiserigsvariabel gjelder : A. Hvis ige tråder skriver på e felles variabel, ka alle tråder lese dee. B. To tråder må aldri skrive samtidig på e felles variabel (eks. i++) C. Hvis derimot é tråd skriver på e variabel må bare de tråde lese dee variabele før sykroiserig ige adre tråder må lese de før sykroiserig. Muliges ikke helt tidsoptimalt, me ekel å følge gjør det mulig/mye eklere å skrive parallelle programmer. Regel C er i hovedsak problemet i Java Memory Model 32

33 IV) Hva er e memory-modell og hvorfor treger vi e! Vi har hittil sett at med flere tråder så: Istruksjoer ka bli utsatt og byttet om av CPU, kompilator, cache-systemet Ulike tråder ka samtidig se ulike verdier på felles variabel Programmet du skrev er optimalisert og har lite direkte likhet med det som eksekverer Vi må likevel ha e viss orde på (visse steder i eksekverige): På rekkefølge av istruksjoee Sylighet - år ser é tråd det e ae har skrevet? Maskivare og hukommelse hvor alle-ser-det samme-alltid tar for lag tid Atomære operasjoer Når e operasjo først utføres, skal hele utføres ute at adre operasjoer blader seg i og ødelegger (som i++) Ulike maskivare-fabrikater ka ulike memory-modeller, me Itel/AMD modelle er rask og uderstøttes av Java. 33

34 The Java memory model (JMM) hva skjer i lageret år vi utfører ulike setiger i et Java-program med tråder? JMM defierer hva som er lovlige tilstader på variable år vi har flere tråder, og særlig år flere tråder leser hva e tråd har skrevet; data-kappløp (data-race) om e variabel lest før eller etter de ble skrevet til gammel eller y verdi?. JMM prøver å tillate så mye som mulig av kompilatoroptimaliseriger (særlig ombyttig av setiger) ute at vi får ulogiske/gale resultater. Et setralt begrep er hedt før (happes before) som betyr at av og til må vi vite at oe setiger har blitt utført, før de setige vi å ser på ka utføres. Det gode budskapet er: Hvis alle trådee oppfyller regel c : Hvis bare é tråd skriver på e variabel må også bare dee tråde lese dee variabele før sykroiserig ige adre tråder må lese de før (este) sykroiserig. så sier JMM at programmet er fritt for data-kappløp og vi ka resoere om programmet vårt som om det utføres sekvesielt! 34

35 Et kort iblikk i JMM 1 tillatte og ikke tillatte effekter (ikke pesum) Iitially, x == y == 0 Thread 1 Thread 2 1: r2 = x; 3: r1 = y 2: y = 1; 4: x = 2 r2 == 2, r1 == 1 violates sequetial cosistecy. Kommetar : r2 ka lett bli 2, me da er T2 utført først og r1 blir da 0; alterativt T1 først og da er r1==1, me r2==0 Iitially, x == 0, ready == false. ready is a volatile variable. Thread 1 Thread 2 x = 1; if (ready) ready = true; r1 = x; If r1 = x; executes, it will read 1. Figure 3: Use of Happes-Before Memory Model with Volatiles 35

36 Et kort iblikk i JMM 2 tillatte og ikke tillatte effekter (ikke pesum) Iitially, x == y == 0 Thread 1 Thread 2 1: r1 = x 6: r3 = y 2: if (r1 == 0) 7: x = r3 3: x = 1 ; 4: r2 = x ; 5: y = r2 ; Compiler trasformatios ca result i r1 == r2 == r3 == 1 Figure 12: Behavior that must be allowed Det rare er her hvorda r1 ka bli 1; bare hvis 1: blir utført etter 2: og 3: Koklusjo: Å sette seg i i og programmere etter JMM er meget vaskelig (ær umulig å gjøre det riktig) hvis vi tillater data-kappløp om variable. Slik programmerig overlater vi til de som programmerer våre sykroiserigs-mekaismer (CyclickBarrier, Semaphore,..) og de som skriver JIT-kompilatore. 36

37 V) Effekte av sykroiserig på samme sykroiserigsvariabel og The Java memory model (JMM) - pesum fortsetter Hva gjør vi hvis vi vil (i e tråd) lese hva e ae tråd har skrevet? Har de adre skrevet eda og har det kommet ed i lageret? Svar: Vi lar begge (alle) trådee sykroisere på samme sykroiserigsvariabel (e CyclicBarrier eller e Semaphore, ): Da skjer følgede før oe fortsetter: 1. Alle felles variable blir skrevet ed fra cachee og ed i lageret. 2. Alle operasjoer som er utsatt, blir utført før oe av trådee slipper gjeom sykroiserige. 3. Følgelig ser alle trådee de samme verdiee på alle felles variable år de fortsetter etter sykroiseriga! 37

38 JMM og volatile variable del 1 Ehver variabel i Java ka deklareres som volatile eks: volatile it i =0; volatile boolea stop = false; E volatile variabel skal ikke caches, me skrives så fort som mulig ed i lageret. Er tekt å dekke behovet for delte felles variable som ka oppdateres og straks leses av adre tråder. Å oppdatere (skrive til) e volatile garaterer også at alle utsatte operasjoer i kode utføres før dee skrivige. Imidlertid er det lett å gjøre feil med volatile variable: Hvis vi deklarerer volatile it i; i vårt program som testet i++, vil det likevel gå galt ved at vi mister oppdateriger. Grue til det er at i++ fortsatt er tre operasjoer (les i, i = i+1; skriv i), og de samme problemer ved at to tråder gjør dette samtidig. 38

39 JMM og volatile variable del 2 volatile variable har likevel e yttig fuksjo, ved at de ka yttes til at e tråd (også mai) ka sigalisere til de adre trådee at å er oppgave løst ferdig. Atar da at alle trådee har e evig løkke i si ru-metode: public void ru() {{ while do (!{ stop); try try {{ // // waito oall all other threads + mai vet.await(); }} catch (Exceptioe) e) {retur;} if if (moresort) (! stop) { { sort (a,threadidex ); sort (a,threadidex); // parallell-algoritme try { // wait o all other threads + mai } else ferdig.await(); { } try catch { //(Exceptio wait all e) other {retur;} threads + mai ferdig.await(); } //} ed catch if (Exceptio e) {retur;} } while (moresort); } // ed ru} // ed else } // ed while } // ed ru I ytre felles klasse: CyclicBarrier vet, ferdig; volatile boolea stop = false;. /** Termiate ifiite loop */ sychroized void exit(){ stop= true; try{ // start all treads to // termiate themselves vet.await(); } catch (Exceptio e) {retur ;} } // ed exit 39

40 V) Sykroiserig på samme sykroiserigsobjekt løser alle problemer - løser sylighet og utsatte operasjoer. Hvis alle arbeider-trådee gjør e sykroiserig på samme sykroiserigsvariabel (e Semaphore, e CyclicBarrier,..) Før de slipper løs, er : Alle felles variable som er skrevet på, skrevet med i hoved-lageret Alle utsatte operasjoer er utført Alle trådee ka da etter å ha gjeomgått de samme sykroiseriga lese samme verdier på alle felles variable! Ige problemer med e vaskelig JMM hvis vi følger regel C om lesig/skrivig på felles variable: «år é tråd skriver på e variabel, må ige adre tråder lese eller skrive på de» Vi må altså først sykroisere på e felles sykroiserigsvariabel for at e tråds skriviger skal bli foruftig lesbart for alle adre trådee og evt. kue skrives på av e ae tråd. 40

41 Oblig 2: Parallell Matrise-multiplikasjo 53

42 Hva her vi sett på i Uke4 I. Om å avlutte k tråder med å samle svaree fra disse. 1 gal + 5 riktige måter + bedre for-løkke betyr mye! II. III. IV. Kommetarer på ukeoppgave om matrise-multiplikasjo Vi bruker ikke PRAM modelle for parallelle beregiger I. Hva er PRAM og hvorfor er de ubrukelig for oss Å lage små metoder gir bedre, raskere JIT kompilerig V. Hva skjer egetlig i lageret (mai memory) år vi kjører parallelle tråder - the Java Memory Model VI. Hvorfor sykroiserer vi, og hva skjer da? VII. Oblig 2: Parallell Matrise-multiplikasjo 54