INF2440 Uke 15, v2017 litt om parallellisering av Oblig4 + oppsummering av kurset. Arne Maus PSE, Inst. for informatikk

Transkript

1 INF2440 Uke 15, v2017 litt om parallellisering av Oblig4 + oppsummering av kurset Arne Maus PSE, Inst. for informatikk 1

2 Oblig4 parallelliseringen av konveks innhylling Antar at du har to riktige metoder: a. IntList Sekv(int low, int high, IntList alle) sekvensiell løsning b. IntList RekPara(...) - rekursiv parallellisering av Sekv(..) 5 mulige andre parallelliseringer enn RekvPara: 1) Del punktene i mange deler (#tråder k = f.eks 5* antall kjerner) 1) Kjør Sekv på hver av disse delene du har da k små konvekse innhyllinger over samme område. 1) Du kan lett vise at alle punktene på den store innhyllinga også er et punkt på en av de små innhyllingene. 2) Problem hvordan slå disse k små -innhyllingene sammen til den ene store vi ønsker (de små har i sum ca % flere punkter enn den store): 2

3 Eks en slik liten kohyll, n= 95 3

4 Parallellisering av Oblig4-forts Husk at sammenstillingen av n slike små -innhyllinger til den ene, store innhyllinga har kjøretid nlogn, nesten alle punktene i de små er på den store innhylinga (når n er stor) Dvs. Du har ca pkt, men logn(16 000) 14, dvs. Problemet har tar tilsvarende problem med *14 uniformt fordelte punkter = punkter eller ca. 10 ms. 1. Slå sammen de små og kjør Sekv på denne mengden - * 2. Slå sammen de små og kjør RekPara på denne mengden * 3. Flett sammen to små til en litt større hvor du også har fjernet overflødige punkter (vanskelig) gjentatt til alle er slått sammen. * 4. Slå alle puktene sammen og sortér mengden (med Radix) på y og så på x- verdier for hvert av de 4 kvadrantene. Fjern så ekstra indre punkter. 5. Flette-sorter sammen to og to slike innhyllinger til alle er flettet sammen. Fjern så ekstra punkter. (Du kan flette-sortere fordi hver av de små er jo perfekt sortert)...? Fjern indre punkter = se på tre fortløpende punkter (sortert), og hvis p2 ligger til venstre (på innsida) for linje p1-p3, fjern p2. * - er implementert og testet 4

5 Hva skal vi se på i Uke15 I) Presisering og utvidelse av en uttalelse om en eller flere tråder i en GUI (+ TegnUt til Oblig3). II) Repetisjon og oversikt Hvorfor lage parallelle programmer Hvordan får vi til parallellitet lokale og delte data Synkroniseringsmekanismer Ekstra problemer med parallellitet : Data-kappløp, synlighet og vraglås. JIT-kompilering, cachene og parallellitet Tidtaking og synkronisering Regler for delte data, og når kan vi bryte en av dem Hvordan parallellisere en sekvensiell algoritme Oppdeling av data eller verdiene Kopier av delte data lokal oppdatering Rekursjon, oppdeling i faser Ett problem som vel ikke lar seg meningsfylt parallellisere (enda) 5

6 I) Vi kan trenge to tråder i en GUI-applikasjon En for å spille innholdet En for at brukeren skal kunne betjene knappene styre f.eks en avspilling. 6

7 1. Hvorfor lage parallelle programmer? Det lages ikke raskere maskiner nå, bare flere på hver brikke og effektivt får vi 4-8 ekte kjerner per. CPU. Vi må lære oss å utnytte hele maskinen (aller kjernene i en multikjerne maskin). Dette kurset: Praktisk kurs i hvordan lage parallelle programmer (algoritmer) som er: Riktige Parallelle programmer er klart vanskeligere å lage enn sekvensielle løsninger på et problem. Effektive dvs. raskere enn en sekvensiell løsning på samme problem dvs speedup >1 (for stor nok n) Speedup = Sekvensiell/parallell tid «Ingen grunn til å lage lengere, mer kompliserte parallelle programmer hvis de ikke går fortere» 7

8 Utgangspunktet for et parallelt program I Nesten alltid :Den beste sekvensielle algoritmen! Eks MultiRadix i Oblig3 er nær optimal Radix. UNNTAK: Full Parallell QuickSort (bare en parallell algoritme) + en bestemt løsning på Oblig4? Vurdere oppdeling av problemet: Har vi k kjerner, starter vi vanligvis k tråder, men av og til lønner det seg å Overbooke flere tråder enn kjerner hvorfor? Deler nesten alltid opp data i problemet Deler data direkte i k deler (de n/k første data til tråd 0, ) men på en klynge kanskje i langt flere, i f.eks 20*k deler. Kan være fornuftig (i Oblig2) for å få jevnere lastballansering å la : tråd0 ta første primtall (3), så primtall k+1, 2k+1, tråd1 ta neste primtall (5), så primtall k+2, 2k+2 osv.. Rekursiv oppdeling (som vanlig QuickSort) 8

9 Utgangspunktet for et parallelt program II Vi legger ofte til ekstra data når vi parallelliserer. Kopier av felles data oppdateres først i hver tråd, så synkronisering og så samstilling av disse kopiene. Mange problemer med parallelle programmer, men problemene har enkle løsninger! Husk: Cachene oppdelingen må gå (lese/skrive) langs cache-linjene om vi kan (eks. transponering av matrise før multiplisering) JIT-kompilering (kan gi opp til 200x) hastighetsforbedring Overhead med å starte tråder i Java; tråder er ikke for små problemer med kjøretider < 5 ms. Synkronisering tar tid må ha et lite tellbart antall synkronisering f.eks en per tråd + en per løkke vi parallelliserer Aldri over si synkroniseringer (uansett størrelse) Vi kan alltids ha speedup >1 når kjøretiden > 100ms. 9

10 Mange mulige synsvinkler Mange nivåer i parallellprogrammering: 1. Maskinvare 2. Operativsystemet 3. Programmeringsspråk 4. Programmeringsabstraksjon. 5. Hvilke typer problem egner seg for parallelle løsninger? 6. Empiriske eller formelle metoder for parallelle beregninger INF2240: Raskest mulig parallellprogrammering av ulike algoritmer med tråder på en multikjerne CPU i Java. Raskest = tidsmålinger (i praksis; ikke antall intruksjoner utført = PRAM) 10

11 Maskinvare og språk for parallelle beregninger og Ifi-kurs 1. Klynger av datamaskiner - INF3380 jfr. Abelklyngen på USIT med ca kjerner. 640 maskiner (noder), hver med 16 kjerner C, C++, Fortran, MPI, men også Java med MPI de ulike programbitene i kjernene sender meldinger til hverandre (synkront og asynkront) Med delte hukommelser går det ca. 100x langsommere enn med felles, delt hukommelse som i maskine vi bruker. 2. Grafikkkort GPU med små-kjerner, INF5063 Eks Nvidia med flere tusen småkjerner (SIMD maskin) Cell prosessoren (produseres ikke lenger) 3. Multikjerne CPU (2-100 kjerner per CPU) INF2440 AMD, Intel, ARM, Mobiltelefoner,.. De fleste programmeringsspråk: Java, C, C++,.. 4. Mange maskiner løst koblet over internett. INF5510 Planet Lab Emerald 5. Teoretiske modeller for beregningene INF4140 PRAM modellen og formelle modeller (f.eks FSM) 11

12 Maskin ca med to dobbeltkjerne CPU-er 12

13 Testing av forsinkelse i data-cachene Programmet : latency.exe (fra CPUZ) 13

14 Operativsystemet og tråder De ulike operativsystemene (Linux, Windows) har ulike begreper for det som kjøres; mange nivåer (egentlig flere enn det som vises her) Linux Task 1 1..* Process 1 1..* Tråd 1..* 1 Windows Application 1 1..* Process 1 1..* Tråd 1 1..* fiber Heldigvis forenkler Java dette 14

15 Java forenkler dette ved å velge to nivåer Windows Linux Et Java program (kjører på en Java VM) 1 1..* Tråd 1..* 1 starter Alle trådene i et Java-program deler samme adresserom (= samme plasser i hovedhukommelsen), og alle trådene kan lese og skrive i de variable (objektene) programmet har og ha adgang til samme kode (metodene i klassene). 15

16 Problem 1: Operasjoner blandes ved samtidige oppdateringer (data-kappløp) Samtidig oppdatering - flere tråder sier gjentatte ganger: i++ ; tråd1 i++ er 3 operasjoner: a) les i, b) legg til 1, c) skriv i tilbake Anta i =2, og to tråder gjør i++ Vi kan få svaret 3 eller 4 (skulle fått 4!) Dette skjer i praksis! Les i Legg til 1 Skriv i tilbake Les i Legg til 1 Skriv i tilbake tråd Antall tråder n Svar 1.x 2. x Tap 1.x 2. x 0 % 0% 0% tiden 20,4% 35,5% 14,6% 15,3% 17,7% 14,9% 17,5%

17 CyclicBarrier. Hva gjør den? Man lager først et objekt b av klassen CyclicBarrier med et tall ant til konstruktoren = det antall tråder den skal køe opp før alle trådene slippes fri samtidig. Tråder (også main-tråden) som vil køe opp på en CyclicBarrier sier await() på den. De ant-1 første trådene som sier await(), blir lagt i en kø. Når tråd nummer ant sier await() på b, blir alle trådene sluppet ut av køen samtidig og fortsetter i sin kode. Da er alle data spylt ned (flushed) til hovedhukommelsen. Det sykliske barriere objektet b er da med en gang klar til å være kø for nye ant tråder. 17

18 Tråder i Java (lett revidert og kompilerbar ) En tråd er én programflyt, dvs. en serie med instruksjoner som oppfører seg som ett sekvensielt program og kjører på en kjerne Det kan godt være (langt) flere tråder enn det er kjerner. En tråd er ofte implementert i form av en indre klasse i den klassen som løser en del av problemet vårt (da får alle trådene greit utsyn til felles data): import java.util.concurrent.*; class Problem { int [] fellesdata ; // dette er felles, delte data for alle trådene public static void main(string [] args) { Problem p = new Problem(); p.utfoer(); } void utfoer () { Thread t = new Thread(new Arbeider()); t.start(); } class Arbeider implements Runnable { int i, lokaldata; // dette er lokale data for hver tråd public void run() { // denne kalles når tråden er startet } } // end indre klasse Arbeider } // end class Problem 18

19 Avslutning med join() - enklest Logikken er her at i den rutinen hvor alle trådene lages, legges de også inn i en array. Main-tråden legger seg til å vente på den tråden som den har peker ti skal terminere selv. Venter på alle trådene etter tur at de terminerer dvs. går ut av sin run()-metode: // main tråden i konstruktøren Thread [] t = new Thread[n]; for (int i = 0; i < n; i++) { t[i] = new Thread (new Arbeider(..)); t[i].start(); } // main vil vente her til trådene er ferdige for(int i = 0; i < n; i++) { try{ t[i].join(); }catch (Exception e){return;}; }.. 19

20 Sammenligning av Amdahl og Gustafson + egne betraktninger Amdahl antar at oppgaven er fast av en gitt lengde(n) Gustafson antar at du med parallelle maskiner løser større problemer (større n) og da blir den sekvensielle delen mindre. Min betraktning: 1. En algoritme består av noen sekvensielle deler og noen parallelliserbare deler. 2. Hvis de sekvensielle delene har lavere orden f.eks O(log n), men de parallelle har en større orden eks O(n) så vil de parallelle delene bli en stadig større del av kjøretida hvis n øker (Gustafson) 3. Hvis de parallelle og sekvensielle delene har samme orden, vil et større problem ha samme sekvensielle andel som et mindre problem (Amdahl). 4. I tillegg kommer alltid et fast overhead på å starte k tråder (1-4 millisek.) Algoritmer vi skal jobbe med er mer av type 2 (Gustafson) enn type 3 (Amdahl) men vi har alltid overhead, så små problemer løses lettest sekvensielt. Konklusjon: For store problemer bør vi ha håpet om å skalere nær lineært med antall kjerner hvis ikke vi f.eks får kø og forsinkelser når alle kjernene skal lese/skrive i lageret. 20

21 En Java-modell for parallelle programmer import java.util.concurrent.*; class Problem { int x,y,r1,r2,..; // felles data public static void main(string [] args) { Problem p = new Problem(); p.utfoer(12); } void utfoer (int antt) { Thread [] t = new Thread [antt]; } for (int i =0; i< antt; i++) ( t[i] = new Thread(new Arbeider(i))).start(); for (int i =0; i< antt; i++) t[i].join(); :Problem int x,y,r1,r2,..; Thread t[] class Arbeider implements Runnable { int ind, lokaledata; // lokale data Arbeider (int in) {ind = in;) public void run() { // kalles når tråden er startet } // end run } // end indre klasse Arbeider } // end class Problem :Arbeider int ind,lokaldata; :Arbeider int ind,lokaldata; 21

22 Viktigste tre regler om lesing og skriving på felles data. Før (og etter) synkronisering på felles synkroniseringsvariabel gjelder : A. Hvis ingen tråder skriver på en felles variabel, kan alle tråder lese denne samtidig. B. To tråder må aldri skrive samtidig på en felles variabel (eks. i++) C. Hvis derimot en tråd skriver på en felles variabel må bare den tråden lese denne variabelen før synkronisering ingen andre tråder må lese den før synkronisering. Muligens ikke helt tidsoptimalt, men enkel å følge gjør det mulig/mye enklere å skrive parallelle programmer. Regel C er i hovedsak problemet i Java Memory Model Vi har sett 2 tilfeller hvor vi bevisst bryter regel C Når? 22

23 To typer av felles variable De felles variable som er en sum eller annen beregning og hvor det bare er ett riktig, summert tall som vi skal ha på denne plassen til sist. En slik variabel kalle en akkumulator. Da må vi følge regel C bare én skriver og ingen andre leser. Av og til er det mange tall som er riktige verdier for denne felles variabelen. Vi har sett to slike eksempler: Avskjærings-verdien i faktoriseringa (der hvor vi delte ned øvre grense med nye faktorer som hver tråd fant i et tall). I Goldbach-summen m = p1+p2 kan flere tråder samtidig skrive ned hver sin p1 i samme plass i p1save[i]. Og siden p2 og m utledes fra p1 og i, er det likegyldig hvilken p1 vi velger. Da kan vi bryte regel C og la flere tråder usynkronisert skrive på denne feles variabelen. 23

24 Når en tråd (main eller en av de andre) aksesserer (lesere/skriver) data, hvilke data er det? Svar: Det vanlige skopet (utsynet): først lokale variable og i metoden og parametre så variable og metoder i klassen man er inne i Evt. så i en eller flere ytre klasser Dette gjelder alltid uansett hvilken tråd som kaller metoden Kallstedet har sitt skop Utførelsesstedet har sitt skop. import java.util.concurrent.*; class Problem { int [] a = new int[100]; // fyll med verdier long s; public static void main(string [] args) { Problem p = new Problem(); p.utfoer(12); } void utfoer (int antt) { Thread [] t = new Thread [antt]; for (int i =0; i< antt; i++) ( t[i] = new Thread(new Arbeider(i))).start(); long s = sum(a); long t = t[0].sum2( t[1].b); for (int i =0; i< antt; i++) t[i].join(); } long sum (int a[]) { s=0 ; for (int i = 0; i<a.length;i++) s += a[i]; return s; } class Arbeider implements Runnable { int ind; int [] b= new int[200]; // fyll b[] long sum2 (int a[]) {long s=0 ; for (int i = 0; i<a.length;i++) s += a[i]; return s; } long sum3(int [] c) { return sum(c);} Arbeider (int in) {ind = in;) public void run(int ind) { long p = sum(a); long q = sum2(b); long r = sum3(a); } // end run } // end indre klasse Arbeider } // end class Problem 24

25 Kan vi stoppe en annen tråd? Hvis ikke vi, hvem da? Helst ingen, forbudt I Java 1.0 var det riktignok metoder som: stop() Deprecated. This method is inherently unsafe. Stopping a thread with Thread.stop causes it to unlock all of the monitors that it has locked. suspend() Deprecated. This method has been deprecated, as it is inherently deadlock-prone. Disse vil bli fjernet og skaper bare problemer ikke bruk dem. Bare trådene kan stoppe seg selv midlertidig ved synkronisering ved å gå ut av siste setning i sin main() eller run() metode En tråd kan starte andre tråder, men den må stoppe/terminere seg selv 25

26 Why is Thread.stop deprecated? Because it is inherently unsafe. Stopping a thread causes it to unlock all the monitors that it has locked. (The monitors are unlocked as the ThreadDeath exception propagates up the stack.) If any of the objects previously protected by these monitors were in an inconsistent state, other threads may now view these objects in an inconsistent state. Such objects are said to be damaged. When threads operate on damaged objects, arbitrary behavior can result. This behavior may be subtle and difficult to detect, or it may be pronounced. Unlike other unchecked exceptions, ThreadDeath kills threads silently; thus, the user has no warning that his program may be corrupted. The corruption can manifest itself at any time after the actual damage occurs, even hours or days in the future. 26

27 Hva er en stack (stabel)? Hvor mange har vi og hvilke er det? En stabel er et dataområde som holder de metodene (med deres lokale variable og parametre) som er kallt. En metode kan kalle en annen metode, Da legger det nye metodeobjektet seg oppå det som kalte,..osv Det hele er som en tallerken-stabel Det er bare den metoden som er på toppen av en stabel som utføres nå. De lenger nede venter bare på at den som ligger rett over den skal returnere, osv Hvert trådobjekt (også objektet med main) har hver sin stabel. nederst i hver av disse stablene ligger hhv. main() og run() Java er et multi-stabel språk (ikke alle språk er det) Stablene ender seg hele tiden etter som metoder kalles og returnerer println() sum() main() Tråd 0: println() sum() sum3() run() Tråd 1: sum3() run() Tråd 3: Tråd 2: println() println() sum() sum() sum3() sum3() run() run() 27

28 Kan flere tråder kalle samme metode samtidig. Hva skjer da? Anta at både main-tråden og tråd 2 kalle metoden sum3() som igjen kaller sum(). Da legger det på hver av stablene en metode-objekt av hhv. sum3() og oppå det hvert sitt sum()-objekt Svaret er JA. - ingen problemer. Metodene bare ligger der og kan kalles av alle andre metoder som har utsyn til dem, enten: Gjennom sitt utsyn (skop) på kallstedet Eller via pekere main-tråden sum() sum3() main() Tråd 2: sum() sum3() run() 28

29 Hva er en memory-modell og hvorfor trenger vi en! Vi har hittil sett at med flere tråder så: Instruksjoner kan bli utsatt og byttet om av CPU, JIT-kompilator, cache-systemet Ulike tråder kan samtidig se ulike verdier på felles variabel Programmet du skrev er JIT-optimalisert og har liten direkte likhet med det som eksekverer Vi må likevel ha en viss orden på (visse steder i eksekveringen): Rekkefølgen av instruksjonene Synlighet - når ser én tråd det en annen har skrevet? Maskinvare og hukommelse hvor alle-ser-det samme-alltid tar for lang tid Atomære operasjoner Når en operasjon først utføres, skal hele utføres uten at andre operasjoner blander seg inn og ødelegger (som i++) Ulike maskinvare-fabrikanter kan ulike memory-modeller, men Intel/AMD/ARM modellen er rask og understøttes av Java. 29

30 Effekten av synkronisering på samme synkroniseringsvariabel og The Java memory model (JMM) Hva gjør vi i en tråd hvis vi vil lese hva en annen tråd har skrevet? Har den andre skrevet enda og har det kommet ned i lageret? Svar: Vi lar begge (alle) trådene synkronisere på samme synkroniseringsvariabel (en CyclicBarrier eller en Semaphore, ): Da skjer følgende før noen av trådene fortsetter: 1. Alle felles variable blir skrevet ned fra cachene og ned i lageret. 2. Alle operasjoner som er utsatt, blir utført før noen av trådene slipper gjennom synkroniseringen. 3. Følgelig ser alle trådene de samme verdiene på alle felles variable når de fortsetter etter synkroniseringa! 30

31 Effekten av cache ved matrisemultiplisering Matriser er todimensjonale arrayer Skal beregne C=AxB (A,B,C er matriser) n 1 c i [j] = a i k b k [j] k=0 C i,j = A i cc X B cc j n-1 n-1 31

32 Idé transponer B (=bytte om rader og kolonner) Bytt om elementene i B (B i,j byttes om med B j,i ) Da blir kolonnene lagret radvis. B cc j B T cc j n-1 n-1 Begrunnelse: Det blir for mange cache-linjer (hver 64 byte) fra B i cachene når vi multipliserer etter lærebok-definisjonen 32

33 Vi har da at litt ny formel for C n 1 c i [j] = a i k b T j [k] k=0 C i,j = A i cc X B T c c j n-1 n-1 Vi får multiplisert to rader med hverandre går det fortere? 33

34 Kjøretider speedup av ulik parallellisering: Radvis eller kolonnevis av transponering og multiplikasjon. 34

35 Litt konklusjon om Matrisemultiplikasjon Parallelliserte C kolonnevis Speedup: 3,5 Så transponerte vi B Speedup: ca 40 Så beregnet vi C radvis i parallell Speedup: opp til 64 Så parallelliserte transponering av B Speedup: opp til 66 (Ganske liten effekt av å parallellisere transponeringen hvorfor?) 35

36 3) Finnes det alternativer til synchronized metoder? a) Bruk av ReentrantLock (import java.util.concurrent.locks.*;) // i felledata-omraadet i omsluttende klasse ReentrantLock laas = new ReentrantLock(); /*** HER skriver du eventuelle parallelle metoder som ER synchronized */ void addi() { laas.lock(); try{ i++; // dette en metodens innhold laas.unlock(); } catch(exception e) {return;} } // end addi Kjøring: M:\INF2440Para\ModelKode>java ModellAlt test.txt Test av TEST AV i++ med ReentrantLock oppdatering med 8 kjerner, og 8 traader Median of 5: Sekv. tid: 0.70 ms, Para tid: ms, Speedup: 0.003, n = x fortere enn synchronized! 36

37 b) Alternativ b til synchronized: Bruk av AtomicInteger Bruk av AtomicInteger (import java.util.concurrent.atomic.*;) // i felledata-omraadet i omsluttende klasse AtomicInteger i = new AtomicInteger(); /*** HER skriver du eventuelle parallelle metoder som ER synchronized */ void addi() { i.incrementandget(); } // end addi Kjøring: M:\INF2440Para\ModelKode>java ModellAlt test.txt Test av TEST AV i++ med AtomicInteger oppdatering med 8 kjerner, og 8 traader Median of 5: Sekv. tid: 0.66 ms, Para tid: ms, Speedup: 0.003, n = Konklusjon: Både ReentrantLock og AtomicInteger er 3-5x fortere enn synchronized metoder + at all parallell kode kan da ligge i den parallelle klassen, men speeddown likevel. 37

38 Oppummering, finn max Løsning kjøretid Speedup Sekvensiell 0,70 ms 1 Bare synchronized 1015,72 ms 0,001 ReentrantLock ms 0,003 AtomicInteger 235,91 ms 0,003 Lokal kopi, så synchronized oppdatering 0,47 ms 1,504 Oppsummering: Synkronisering av skriving på felles variable tar lang tid, og må minimeres (og synchronized er spesielt treg) Selv den raskeste er 500x langsommere enn å ha lokal kopi av fellesvariabel int i, og så addere svarene til sist. 38

39 4) Vranglås: Rekkefølgen av flere synkroniseringer fra flere, ulike tråder går det alltid bra? Anta at du har to ulike parallelle klasser A og B og at som begge bruker to felles synkroniseringsvariable: Semphorene vent og fortsett (begge initiert til 1). A og B synkroniserer seg ikke i samme rekkefølge: A sier: try{ vent. acquire(); ferdig. acquire(); } catch(exception e) {return;} gjør noe. ferdig.release(); vent.release(); B sier: try{ ferdig. acquire(); vent. acquire(); } catch(exception e) {return;} gjør noe. vent.release(); ferdig.release(); 39

40 Vranglås del 2 Dette kan gi såkalt vranglås (deadlock) ved at begge trådene venter på at den andre skal bli gå videre. Hvis operasjonene blandes slik går det galt (og det skjer også i praksis!) A vent. acquire(); ferdig. acquire(); B ferdig. acquire(); vent. acquire(); tid Begge fortsetter A må vente på at B slipper ferdig B må vente på at A slipper vent 40

41 Vranglås - løsning A og B venter på hverandre til evig tid programmet ditt henger til evig tid! Løsning: Følg disse enkle regler i hele systemet (fjerner all vranglås): 1. Hvis du skal ha flere synkroniserings-primitiver i programmet, så må de sorteres i en eller annen rekkefølge. 2. Alle tråder som bruker to eller flere av disse, må be om å få vente på dem (s.acquire(),..) i samme rekkefølge som de er sortert! 3. I hvilken rekkefølge disse synkroniserings-primitiver slippes opp (s. release(),..) har mer med hvem av de som venter man vil slippe løs først, og er ikke så nøye; gir ikke vranglås. 41

42 1) Om å parallelliser et problem Utgangspunkt: Vi har en sekvensiell effektiv og riktig sekvensiell algoritme som løser problemet. Vi kan dele opp både koden og data (hver for seg?) Vanligst å dele opp data Som oftest deler vi opp data med en del til hver tråd, og lar hele koden virke på hver av disse data-delene. Eks: Matriser radvis eller kolonnevis oppdeling av C til hver tråd Omforme data slik at de passer bedre i cachene (transponere B) Rekursiv oppdeling av data ( lett ) Eks: Quicksort Primtalls-faktorisering av store tall N for kodebrekking: N= p 1 * p 2 vi lar hver tråd finne faktorer i sin del av tallinja. Også mulig å dele opp koden: Gammelt alternativ Oblig3 i INF1000: Beregning av Pi (3,1415..) med sifre med tre ArcTan-rekker 42

43 Å parallellisere algoritmen Koden består en eller flere steg; som oftest i form av en eller flere samlinger av løkker (som er enkle, doble, triple..) Vi vil parallellisere med k tråder, og hver slikt steg vil få hver sin parallellisering med en CyclicBarrier-synkronisering mellom hver av disse delene + en synkronisert avslutning av hele algoritmen(f.eks.join(),..). Eks: finnmax hadde ett slikt steg: for (int i = 0 n-1) -løkke MatriseMult hadde ett slikt steg med trippel-løkke Radix hadde 4 slike steg: en enkelt løkke i radix tre steg i radixsort : b),c) og d) - alle enkeltløkker (gjenntatt 2 ganger) Hver av disse må få hver sin parallellisering. 43

44 Å dele opp data del 2 For å planlegge parallellisering av ett slikt steg må vi finne: Hvilke data i problemet er lokale i hver tråd? Hvilke data i problemet er felles/delt mellom trådene? Viktig for effektiv parallell kode. Hvordan deler vi opp felles data (om mulig) Kan hver tråd beregne hver sin egen, disjunkte del av data ved at hver tråd tar kopi av felles data det regnes på av trådene, og da kan regne på kopien uten synkronisering. Færrest mulig synkroniseringer (de tar alt for mye tid) 44

45 Viktig: Kopiere deler av felles data til lokale data Kan vi kopiere aktuelle deler av felles data til hver tråd (ha en lokal en kopi av disse i lokale data i hver tråd)? Hver tråd oppdaterer så sin kopi og etter en synkronisering kan disse lokale kopiene summeres/sys sammen slik at vi får riktig felles resultat i de felles data? Da vil en for-løkke bli til to steg: Steg 1: Lag kopi de felles data og kjør løkka på sin lokale del av data. Synkroniser på en CyclicBarrier Steg 2: De lokale data samles/adderes til slik data blir som i den sekvensielle algoritmen (hvis neste steg kan bruke disse lokale kopiene, beholdes de) Disse sammen-satte data er nå igjen felles, delte data. Eks: FinnMaks haddde en int max; som felles data. Den kunne lett kopieres til hver tråd som int mx, og felles resultat ble beregnet som de største av disse mx ene fra alle trådene. 45

46 Husk at vi skal lage effektive algoritmer! Vi må ikke synkronisere for mange ganger! Fordi hver synkronisering tar lang tid (skriving av cachene til lageret, utføre utsatte operasjoner,..) Vi kan ikke synkronisere hver gang vi i den sekvensielle algoritmen bruker (leser/skriver) felles data. Regel for synkronisering: Antall synkroniseringer på felles data må være av en lavere orden enn selve algoritmen. Eks: O(n log n), O(n) eller O(log n) synkroniseringer (under tvil: O(n 2 ) ) hvis algoritmen er O(n 3 ) O(log n) hvis algoritmen er O(n) eller høyere. Aller helst bare et fast antall synkroniseringer uavhengig av n f.eks antalltråder + antall løkker vi parallelliserer. 46

47 Synkronisering av algoritme i flere steg. Med venting på en felles CyclicBarrier mellom hvert steg: int x,y,r1,r2,..; :Problem CyclicBarrier vent; Thread t[] :Arbeider int ind,lokaldata; :Arbeider int ind,lokaldata; void run(int ind) { Steg1; try{ vent.await(); } catch {.} Steg2; try{ vent.await(); } catch {.} Steg3;.. } void run(int ind) { Steg1; try{ vent.await(); } catch {.} Steg2; try{ vent.await(); } catch {.} Steg3;.. } 47

48 Hvordan faktorisere et stort tall (long) en effektiv sekvensiell algoritme Anta at vi har en long M: Vi kan faktorisere den hvis vi vet alle primtall < N= M For å finne alle primtall < N, må vi krysse av for alle primtall Q < N = M For å faktorisere så store tall som M M N = M for å krysse av for all primtall < N Q = N Vi må finne disse primtallene 48

49 Flere (synkroniserings-) metoder i klassen Thread. getname() Gir navnet på tråden (default: Thread-0, Thread-1,..) join(): Du venter på at en tråd terminerer hvis du kaller på dens join() metode. sleep(t): Den nå kjørende tråden sover i minst t millisek. yield(): Den nå kjørende tråden pauser midlertidig og overlater til en annen tråde å kjøre på den kjernen som den første tråden ble kjørt på.. notify(): (arvet fra klassen Object, som alle er subklasse av). Den vekker opp en av trådene som venter på låsen i inneværende objekt. Denne prøver da en gang til å få det den ventet på. notifyall(): (arvet fra klassen Object). Den vekker opp alle de trådene som venter på låsen i inneværende objekt. De prøver da alle en gang til å få det de ventet på. wait(): (arvet fra klassen Object). Får nåværende tråd til å vente til den enten blir vekket med notify() eller notifyall() for dette objektet. 49

50 notify() 50

51 En effektiv Threadpool? Vi har med modell2-koden selv startet en samling av k tråder som- venter til vi vil kjøre problemet (evt. flere ganger): enten med samme n for å få bedre tider (median) eller for en ny n. Ideen om å lage en samling av tråder som er klar for å løse neste oppgave har vi også i Java-biblioteket. Vi skal her se på: Executors.newFixedThreadPool i java.util.concurrent. 51

52 Grunnidéene i Executors.newFixedThreadPool Du starter opp et fast antall tråder Hvis du under kjøring trenger flere tråder enn de startet må du vente til en av dem er ferdig og da er ledig For hver tråd som gjør noe er det tilknyttet et objekt av klassen Future: Den sier deg om tråden din er ferdig Du kan legge deg og vente på et eller alle Future-objekter som join() med vanlige tråder Future-objektet bringer også med seg svaret fra tråd når den er ferdig, hvis den har noen returverdi En tråd som har terminert kan straks brukes på nytt fordi main-tråden venter ikke på tråden, men på tilhørende Future 52

53 For å administrere en slik mengde (pool) av tråder Må man først lage en pool (med tilhørende Vektor av Futures): class MinTraadpool{ MinTraadpool pt = new MinTraadpool (); int anttraader = Runtime.getRuntime().availableProcessors(); ExecutorService pool = Executors.newFixedThreadPool(pt.antTraader); List <Future> futures = new Vector <Future>(); Hvordan lage trådene og slippe dem ned i poolen (svømmebasenget): for (int j =0; j < anttraader; j++) { Thread QParExec = new Thread(new FindExec(j)); futures.add(pool.submit(qparexec)); // submit starts the Thread } 53

54 1 &2)Test på effektivitet tre implementasjoner av parallell FindMax i int [] a ; speedup: a) Med ExecutorService og FixedThreadPool a1)med like mange tråder som kjerner: a2) Med 2x tråder som kjerner b) Med modell2 kode med 2 CyclicBarrier for start&vent n a1)pool 1x a2) Pool 2x b) Barrier , ,235 0, ,302 0, ,399 0, ,344 1, ,6662 1,972 Konklusjon: Om lag like raske!? 54

55 Programmerings-mekanismer i Java: Oppsummering om kjøretider: 2013: Metodekall tar svært liten tid: 2-5 s og kan også optimaliseres bort (og gis speedup >1) Å lage et objekt av en klasse new (og kalle en metode i det) tar liten tid: ca.785 s Å lage en tråd og starte den opp tar en del tid: ca.1500 s, men lite ca. 180 s for de neste trådene (med start() ) Å lage en tråd-samling og legge tråder (og Futures) opp i den tar ca s for første tråd og ca. 210 s for neste tråd. Å bruke trådsikre heltall (AtomicInteger og AtomicIntegerArray) mot vanlige int og int[] tar vanligvis x så lang tid, men for mye bruk (> 10 6 ) tar det bare ca. 2x tid (det siste er sannsynligvis en cache-effekt) 2016: Metodekall 2.10 us. forste Metodekall 0.016us. snitt x Array new len =100 Array new len = us. forste 0.136us. snitt 100 x new Thread() start & join 3086us. forste new Thread() start & join 63.0us. snitt x new Class C+ metodekall 3025us. forste new Class C+ metodekall 0.04us.snitt x Array write Array write Array les Array les us. forste us. snitt 100 x 0.30us. forste 0.013us. snitt x En parallell løsning må alltid sammenlignes med hvor mye vi kunne ha gjort sekvensielt på denne tida! 55

56 Konklusjon om å parallellisere rekursjon Antall tråder må begrenses til toppen av treet! I toppen av treet brukes tråder (til vi ikke har flere og kanskje litt mer) I resten av treet bruker vi sekvensiell løsning i hver tråd! Viktig også å kutte av nedre del av treet (her med insertsort) som å redusere treets størrelse drastisk (i antall noder) Vi har for n = med Quicksort gått fra: n sekv.tid(ms) para.tid(ms) Speedup Ren trådbasert Med insertsort Avkutting i toppen Speedup > 1 og ca gang fortere enn ren oversettelse at et rekursivt kall = new Thread(.) er bare å ha noen tråder i toppen av treet og så igjen vanlig rekursjon. 56

57 I Uke 9 så vi på å overføre Rekursjon til tråder - fra Peter Eidsviks masteroppgave Vi skal nå automatisere det Vi lager en preprosessor: javaprp dvs. et Java-program som leser et annet Java-program og omformer det til et annet, gyldig Java-program (som er det parallelliserte programmet med tråder) For at JavaPRP skal kunne gjøre dette, må vi legge inn visse kommentarer i koden: Hvor er den rekursive metoden Hvor er de rekursive kallene Bare rekursive metoder med to eller flere kall, kan parallelliseres. 57

58 Hvordan gjøres dette? Administrator arbeider modell Oppgaver legges ut i et fellesområde Arbeiderne tar oppgaver og legger svar tilbake i fellesområdet 58

59 II) Debugging feilfjerning parallelt Antar at vi har et program som lar seg starte opp Felles problem i sekvensiell og parallell kode: Er det en feil her? Terminerer programmet Gale resultater Samme feil hver gang? Et sekvensielt program kan gjøres deterministisk (eks. Random r = new Random(123) vil produsere samme tall-rekke ved neste kjøring) Parallelle programmer kan ikke gjøres deterministiske Never same result twice Er feil avhengig av størrelsen på problemet som løses av programmet, av n? Råd1: Finn først det minste eksempelet som feiler 59

60 Råd2: Ikke debug ved å gå linje for linje gjennom koden! Råd3: Bruk binær feilsøking: Plasser en System.out.println(..) midt i koden og sjekk de data som der skrives ut virker de riktige? Hvis ja: feilen nedenfor, nei: feilen er ovenfor Her: Siden problemet feilet med n=200, så: Skrev ut alle primtallene < n (200) Vi hadde to algoritmer (Eratosthenes eller faktoriseringen) var det den første eller den andre? Råd4: Litt analyse (papir og blyant): Råd5: Forstå feilen, se på koden Råd6: Legg System.out.println(s) inn i en: synchronized void println(string s) i den ytre klassen Da vil utskrifter ikke blandes. Råd7: Hvis ingen ting skjer når vi starter programmet: Lag en 5-6 setninger av typen : println(«a»); println(«b»);..og plasser de jevnt over rundt i programmet (i toppen av løkker) Da ser vi hvor langt programmet kom før det hang seg. 60

61 D:\INF2440Para\Static-ABC>java ClassC ) s= paa: nanosek 2) s= paa: nanosek 3) s= paa: nanosek 4) s= paa: nanosek 5) s= paa: nanosek 6) s= paa: 6159 nanosek 7) s= paa: 6544 nanosek 8) s= paa: 7699 nanosek 9) s= paa: 7699 nanosek 10) s= paa: 6544 nanosek 11) s= paa: 3465 nanosek 12) s= paa: 3464 nanosek 13) s= paa: 5005 nanosek 14) s= paa: 4620 nanosek 15) s= paa: 5004 nanosek 16) s= paa: 3849 nanosek 17) s= paa: 5390 nanosek 18) s= paa: 4620 nanosek 19) s= paa: 5004 nanosek 20) s= paa: 5005 nanosek 21) s= paa: 3464 nanosek 22) s= paa: 5004 nanosek 23) s= paa: 5004 nanosek 24) s= paa: 5004 nanosek 25) s= paa: 4235 nanosek 26) s= paa: 3464 nanosek 27) s= paa: 3079 nanosek 8000 tall summert 27 ganger stadig kortere kjøretid pga. JIT kompilering til maskinkode og hyper-optimalisering i flere steg. Speedup : 211,5 61

62 Ett problem som vel ikke lar seg parallellisere. Innstikksortering kan den parallelliseres?? Neppe: Praktisk fordi den brukes bare til å sortere arrayer < 100 lang men også teoretisk fordi det er vanskelig å se logikken i å delsortere a[] i k deler og så,? /** sort double-array a[left..right] */ void insertsort( double a[], int left, int right) { int i,k; double t; for (k = left+1 ; k <= right; k++) { t = a[k] ; i = k; while ( a[i-1] > t ) { a[i] = a[i-1]; if (--i == left) break; } a[i] = t; } // end k } // end insertsort 62

63 Oppsummering: Parallellisering av en algoritme med k tråder: Finn hvilke steg/faser den sekvensielle algoritmen består av (løkkene og/eller rekursjon) For hvert steg: Finn de delte data de som flere tråder skal skrive på samtidig. Kopiér heller de delte data til hver tråd. Det er mye raskere enn å synkronisere hver aksess til delte data. Synkroniser (CyclicBarrier) slik at alle blir samtidig ferdig med sin oppdatering av sin kopi av delte data. Samkjør så hver tråds kopi av til et felles svar (slik det blir i det sekvensielle tilfellet) dette er muligens en sekvensiell operasjon Overhold reglene for samtidig lesing/skriving Husk å synkronisering til sist slik at main-tråden vet at alle trådene har blitt ferdige eller bruk join(). 63

64 Teaching B.S. students to parallelize algorithms with speedup > 1 on a shared memory multicore machine using Java threads. No reason to write complicated parallel algorithms if they are not any faster in measured execution time 1. JIT-compilation speedup 170. ex: Calling a method that does sum of 8000 integers, 35 times measured execution time from interpreted byte code to hyper optimized machine code (from to nanosec.). 2. Three level cache speedup 20. ex : Matrix-multiplication Since Java stores Matrixes by row, text-book definition C=AxB (= row*column) is very slow versus: first transpose B and then do: C = Ax B T. (= row*row) 3. Parallelization speedup 3-4 (on 4(8) cores). ex: Any algorithm on top on JIT and cache speedup. Speedup example 1&2 sum : Speedup up to 3.3. Matrix mult: speedup 66 (=20*3.3) compared with text-book def. Delaunay Triangulation: see graph. Compulsary assignments: (sequential and parallel version + speedup): a) Find the 50 largest elements among 100, 1000,..,100 mill. integers. b) Factorize any integer m < 4.2*10 18 in less than 1 sec. c) Radix sorting parallelized (sequential version given). A) Number of Goldbach sums in m: 4 < m < 1 mill. Other major algorithms presented to the students through exercisis: A) Goldbachs conjecture (any even number m is the sum of two primes) B) Delaunay triangulation (convex hull + triangulation two algorithms) B) Delaunay triangulation of 100 random points Arne Maus (arnem@ifi.uio.no) and Stein Gjessing (steing@ifi.uio.no)