INF2440 Uke 11, v2017 om Goldbachs problem og Oblig 2,3. Arne Maus PSE, Inst. for informatikk

Transkript

1 INF2440 Uke 11, v2017 om Goldbachs problem og Oblig 2,3 Arne Maus PSE, Inst. for informatikk 1

2 Fra hjemmesida til INF2440: Plan for resten av semesteret: Forelesninger: 29. Mars (i dag), 5.april, 19.april, 26. april, 3. mai og 10 mai (oppsummering/eksamenstips ) Oblig 4: Den konvekse inn hyllinga av en punktmengde, ut 7.april med innleveringsfrist 12. mai Eksamen: 14. juni (manuell IKKE digital) 2

3 Hva så vi på i Uke10 Automatisk parallellisering av rekursjon PRP- Parallel Recursive Procedures Nåværende løsning (Java, multicore CPU, felles hukommelse) implementasjon: Peter L. Eidsvik Demo av to eksempler med kjøring Ikke gå i fella: Et Rekursivt kall = En Tråd Halvautomatisk oversettelse (hint/kommandoer fra kommentarer) Hvordan virker en kompilator (preprosessor) for automatisk parallellisering Prinsipper ( bredde-først og dybde-først traversering av r-treet) Datastruktur Eksekvering Krav til et program som skal bruke PRP Noen tips til Oblig 3 3

4 Hva skal vi se på i Uke 11 I) Optimalisering av Oblig 2 flere, også nye resultater II) Et større problem uløst problem siden 1742 Vil du tjene $1 mill.? Løs Goldbach s påstand (alternativt: motbevis den) Formulering og skisse av løsning av tre av Goldbachs problemer Parallellisering av disse (ukeoppgave neste uke) III) Om Oblig 3 siste tips 4

5 II) Om å løse og parallellisere faktorisering Oblig 2 Parallellisering består i å dele opp problemet (data) mellom trådene. Hva deler vi opp i faktoriseringen? Tallet vi skal faktorisere Primtallene vi skal dele med Forbausende svar: Først og fremst primtallene Alle algoritmene, men litt spesielt i alg 3 Men også tallet - se Alg 1-3 Parallellisering består ofte også i å kopiere data til å bli lokal i hver tråd hvis det skrives mye i trådene Ved faktorisering skrives lite (de 1 15 faktorene vi har i et 18- sifret tall) Det ordnes med en felles Locked (synchronized) metode. Ingen lokal kopi i trådene, men felles variabel kan leses av alle. 5

6 Fire algoritmer for parallell faktorisering av M, N= M Alg0: Vi deler opp primtallene 2..N og lar hver tråd dele tallet med sine primtall og finne faktorene. Alg1: Rett fram med k tråder, hver av trådene får N/k-del av primtallene, men: Deler det store tallet som skal faktoriseres med disse primtallene og tar lokalt i hver tråd å deler ned tallet som skal faktoriseres med de faktorene tråden finner(reduserer da øvre grense for hvilke primtall vi deler med) Alg2: Som Alg1 + innser at hvis vi har en felles variabel for alle trådene som deles ned for faktorene som finnes av alle trådene, så går det kanskje bedre fordi alle trådene kanskje får redusert sine beregninger hver gang når en annen tråd finner en ny faktor. Alg3: Som Alg2, men med tillegg at vi innser at Alg2 gir dårlig lastbalansering fordi Alg2 medfører at mange av trådene slutter, men hvis vi ikke har avlastet jobben til tråd 0, tar faktoriseringa jo like lang tid som Alg1; forbedrer dette. Algoritmen skisseres muntlig på forelesningen 6

7 = 107* = 2*2*3*5*5*89*1447*1553* = 19*2897* = 2* * = 3*101*241* = 2*2*2*2*2*1061* = 5*7*13* = 2*3*3*17*31* = * = 2*2*11*168409* = 3*2713* = 2*5* = 167*659*3581*86629* = 2*2*2*3*7*7*4127*669869* = 239* = = 2*2*3*5*5*7*952381* = 181*229*229*47237* = 2*16103* = 3*191* = 2*2*2*2*2*47*7867*19843* = 5*151*230341* = 2*3*3*3*3*3*3*2089* = 7*7*7*29* Om faktoriseringer Observasjoner : - Hvor mange faktorer er det i de fleste? - Hvor store er tallene? - Deler vi talllinja av primtall (2 milliarder) på 8 kjerner får vi 250 mill. til hver tråd - Hvilken tråd finner de fleste faktorene? 7

8 Langt fra optimal, men riktig kode alg 0 // Sekvensiell faktorisering av primtall alg.0 ArrayList<Long> factorize (long num) { ArrayList <Long> fakt = new ArrayList <Long>(); int pcand =2; long pcand2=4l, rest= num; while (rest > 1 && pcand2 <= num) { while ( rest % pcand == 0){ fakt.add((long) pcand); rest /= pcand; } pcand = nextprime(pcand); pcand2 =(long) pcand*pcand; } if (rest >1) fakt.add(rest); return fakt; } // end factorize Tips: Hva er grensene når vi har funnet første faktor 8

9 Algoritme 0 enkel SEKVENSIELL KODE ArrayList<Long> factorize (long num) { ArrayList <Long> fakt = new ArrayList <Long>(); int pcand =2; long pcand2=4l, rest =num; while (rest > 1 && pcand2 <= num) { while ( rest % pcand == 0){ fakt.add((long) pcand); rest /= pcand; } pcand = nextprime(pcand); pcand2 =(long) pcand*pcand; } if (rest>1) fakt.add(rest); return fakt; } // end factorize PARALLELL KODE void parafactorize (long num, int left, int right) { int pcand =2, tell =0; long pcand2, rest=num; if (left > 2) pcand = nextprime(math.max(left-1,1)); while (rest > 1 && pcand <= right) { while ( rest % pcand == 0 && rest >1){ put((long) pcand); rest /= pcand; } pcand = nextprime(pcand) } } // end parafactorize 9

10 Alg 0: Antall tråder: 64, antall kjerner:8 n sekv(ms) para(ms) Speedup PerElemSek PerElemP EratosthesSil Faktorisering Total tid EratosthesSil Faktorisering Total tid EratosthesSil Faktorisering Total tid EratosthesSil Faktorisering Total tid EratosthesSil Faktorisering Total tid Bra speedup, men meget langsom algoritme for både sekvensiell og parallell faktorisering. 10

11 Alg 1:Optimalisering1 av parallell faktorisering: Ved parallellisering av faktorisering, får hver kjerne (8) sin del av primtallene Hvor stor sannsynlighet er det for at et vilkårlig tall k er delbart på 3 - uten rest? Hvor stor sannsynlighet er det for at et vilkårlig tall k er delbart på uten rest? Mens vi i det sekvensielle tilfellet hadde kontroll over resten av tallet har vi det ikke på samme måte parallell faktorisering. Vi må først finne det gode optimaliseringa sekvensielt, og gjøre noe av det samme med en felles variabel mellom trådene. Bruke lokal variabel rest som øvre grense istedenfor num. 11

12 Algoritme 1 enkel og bedre avskjæing SEKVENSIELL KODE ArrayList<Long> factorize (long num) { ArrayList <Long> fakt = new ArrayList <Long>(); int pcand =2; long pcand2=4l, rest =num; while (rest > 1 && pcand2 <= rest) { while ( rest % pcand == 0){ fakt.add((long) pcand); rest /= pcand; } pcand = nextprime(pcand); pcand2 =(long) pcand*pcand; } if (rest>1) fakt.add(rest); return fakt; } // end factorize PARALLELL KODE void parafactorize (long num, int left, int right) { int pcand =2, tell =0; long pcand =4L, rest=num; if (left > 2) pcand = nextprime(math.max(left-1,1)); while (rest > 1 && pcand <= right && pcand2<= rest) { while ( rest % pcand == 0 && rest >1){ put((long) pcand); rest /= pcand; } pcand = nextprime(pcand); pcand2=(long)pcand*pcand; } } // end parafactorize 12

13 Algoritme 1 oppdeling av primtallene og divisjon med disse, reduksjon av øvre grense i hver tråd 64 tråder? Antall tråder: 64, antall kjerner:8 n sekv(ms) para(ms) Speedup PerElemSek PerElemPar EratosthesSil Faktorisering Total tid EratosthesSil Faktorisering Total tid EratosthesSil Faktorisering Total tid EratosthesSil Faktorisering Total tid EratosthesSil Faktorisering Total tid Bra sekvensiell tid, elendig speedup og elendig parallell tid 13

14 Algoritme 2 bedre parallell avskjæring med felles nedfaktorisert variabel : paranum SEKVENSIELL KODE PARALLELL KODE ArrayList<Long> factorize (long num) { ArrayList <Long> fakt = new ArrayList <Long>(); int pcand =2; long pcand2=4l, rest =num; while (rest > 1 && pcand2 <= rest) { while ( rest % pcand == 0){ fakt.add((long) pcand); rest /= pcand; } pcand = nextprime(pcand); pcand2 =(long) pcand*pcand; } if (rest>1) fakt.add(rest); return fakt; } // end factorize void parafactorize (long num, int left, int right) { int pcand =2, tell =0; long pcand2, rest=num; long pcand =4L, rest=num; if (left > 2) pcand = nextprime(math.max(left-1,1)); while (num> 1 && pcand <= right && pcand2<= num) { while ( num% pcand == 0 && num>1){ put((long) pcand); // endrer paranum num/= pcand; } num =paranum; pcand = nextprime(pcand); pcand2=(long)pcand*pcand; } } // end parafactorize 14

15 Algoritme 2 som Alg1, men reduksjon av øvre grense i faktoriseringa felles for trådene også med faktorer funnet av andre tråder. n sekv(ms) para(ms) Speedup PerElemSek PerElemPar EratosthesSil Faktorisering Total tid EratosthesSil Faktorisering Total tid EratosthesSil Faktorisering Total tid EratosthesSil Faktorisering Total tid EratosthesSil Faktorisering Total tid Bra sekvensiell tid, akseptabel speedup og akseptabel parallell tid. Men hvorfor ikke bedre speedup med 4(8) kjerner? 15

16 Algoritme 3 faktorisering som som alg2, men mye bedre lastbalansering SEKVENSIELL KODE PARALLELL KODE ArrayList<Long> factorize (long num) { ArrayList <Long> fakt = new ArrayList <Long>(); int pcand =2; long pcand2=4l, rest =num; while (rest > 1 && pcand2 <= rest) { while ( rest % pcand == 0){ fakt.add((long) pcand); rest /= pcand; } pcand = nextprime(pcand); pcand2 =(long) pcand*pcand; } if (rest>1) fakt.add(rest); return fakt; } // end factorize void parafactorize (long num, int left, int right) { int pcand =2, tell =0; long pcand2, rest=num; long pcand =4L, rest=num; if (left > 2) pcand = nextprime(math.max(left-1,1)); while (num> 1 && pcand <= right && pcand2<= num) { while ( num% pcand == 0 && num>1){ put((long) pcand); num/= pcand; } num =paranum; pcand = nextprime(pcand); pcand2=(long)pcand*pcand; } } // end parafactorize 16

17 Det som gjøres ekstra i Alg3 Vi har observert at mange faktorer er < f.eks.1000 Da gjør vi først en parallell faktorisering hvor vi først deler opp alle primtall < 1000 mellom trådene Og faktoriserer for disse Deretter regner vi ut ny øvre grense av hvilke gjenstående primtall vi må faktorisere for. Disse ble så jevnt fordelt mellom trådene, og alle trådene har da i utgangspunkt like mye å gjøre Vi faktoriserer i runde nr. 2 da med alle trådene aktive for disse resterende primtallene Feilen med Alg2 var at straks vi fant noen faktorer, ble mange tråder fort ferdige, og grovt sett fortsatte bare tråd0. 17

18 Algoritme 3 mye bedre lastbalansering mellom trådene + mange (56) tråder med 8 kjerner. Klar speedup (>3) AntTraader:56, AntKjerner:8 n sekv(ms) para(ms) Speedup Sek/elm Par/elm EratosthesSil Faktorisering Total tid EratosthesSil Faktorisering Total tid EratosthesSil Faktorisering Total tid EratosthesSil Faktorisering Total tid EratosthesSil Faktorisering Total tid EratosthesSil Faktorisering Total tid

19 Speedup for de fire algoritmene for parallell faktorisering Alg1: Rett fram med k tråder, hver av trådene får n/k-del av primtallene. Deler det store tallet som skal faktoriseres med disse primtallene og tar lokalt i hver tråd og deler ned tallet som skal faktoriseres med disse faktorene (reduserer da øvre grense for hvilke primtall vi deler med) Gir speedup på ca. 0.5 < 1 (speeddown) Alg2: Som alg1 + innser at hvis vi har en felles variabel for alle trådene som deles ned for faktorene som finnes av alle trådene, så går det kanskje bedre. Gir speedup opp til 2 Alg3: Som Alg2, men med tillegg at vi innser at Alg2 gir dårlig lastbalansering fordi Alg2 medfører at mange av trådene slutter, men hvis vi ikke har avlastet jobben til tråd0, tar det jo like lang tid og forbedrer dette. Gir speedup opp til ca: 3,2 Algoritmen skisseres muntlig på forelesningen ca 6x så rask som Alg1 og nesten 2x så rask som Alg2 19

20 En enda bedre optimalisering Alg 4 1. Lag først Eratosthenes sil 2. Les sila en gang med nextprime() og putt alle primtallene i en int [] prim( prim[0]=2, prim[1]= 3,...) 3. Bruk heller prim[] for å finne neste primtall under faktoriseringa i alle algoritmene. 20

21 Tips til utskrift mm Saml inn tidene først i en fler-dimensjonal double[][][] array, og skriv det så ut oversiktlig (funksjon, n, iterasjon) Faktoriseringa kan skrives ut mens du finner den. (kan ikke lage array av ArrayList-er.) Lag utskriftsmetoder som skriver ut både på fil og skjerm /** for også utskrift på fil */ synchronized void println(string s) { ut.outln(s); System.out.println(s); } /** for også utskrift på fil */ synchronized void print(string s) { ut.out(s); System.out.print(s); } 21

22 II) Christian Goldbachs påstand i 1742: Alle partall m =n+n > 4 kan skrives som en sum av to primtall (som begge er oddetall). m = p1+p2 ( p1 p2) Eks: 6 = 3+3, 14 = 7+7 og 14 = 11+3,. Antall slike ulike summer av to primtall for en gitt m kaller vi G(m). Bevis at G(m) > 0 m. 22

23 vel egentlig..: Goldbach foreslo at alle tall kan skrives som sum av tre primtall. Den store matematiker Euler ryddet opp i det og utledet lett: Alle oddetall kan skrives som sum av tre primtall Alle partall kan skrives som summen av to primtall Goldbach mente selv at 1 var et primtall (naturlig nok) Goldbachs påstand er ikke bevist matematisk for partall. Praktisk på datamaskiner (Wikipedia): T. Oliveira e Silva is running a distributed computer search that has verified the conjecture for n (and doublechecked up to ). One record from this search: needs minimal prime 9781 (=p1 : n =p1+p2)) Dvs for de fleste tall som kan representeres i en long 23

24 Goldbachs brev til Euler hvor han foreslår at alle tall kan skrives som sum av tre primtall 24

25 G(m) for alle tall < 1000 varierer mye, men har en litt uklar nedre grense som vi ikke greier å vise er >0 25

26 G(n) for alle tall < 1 mill varierer mye, men har en skarp nedre grense som vi ikke greier å vise er > 0! 26

27 Hvordan vise Goldbach med et program, premie $1 mill. for løsning Upon publication of Apostolos Doxiadis new novel, Uncle Petros & Goldbach's Conjecture, the publishers Faber and Faber in Britain and Bloomsbury Publishing USA, have offered $1,000,000 to individual(s) who solve Goldbach's Conjecture. To måter å vise Goldbach: Komme med et matematisk bevis for at den er sann. Komme med et mot-eksempel: Partallet M som ikke lar seg skrive som summen av to primtall. Å bevise noe om sum (+) er mye vanskeligere enn faktorisering (*) bla. fordi ethvert N tall har en entydig faktorisering mens N har mange summer (faktisk N summer med to addender, og svært mange flere med mer enn 2 addender) 27

28 Hvordan løser vi dette? Første sekvensielt Hvilket program skal vi lage? a) Prog1: Som for alle tall m=6,8,.,n finner minst én slik sum m= p1+p2 b) Prog2: Som regner ut G(m) for m=6,8,.,n c) Prog3: Som tester noen tall > om Goldbach gjelder også for disse tallene (sette ny rekord ikke testet tidligere, kanskje finne ett tall som ikke lar seg skrive som summen av to primtall.) Forskjellen på Prog1 og Prog3 er at i Prog1 antar vi at vi vet alle primtall < m, det trenger vi ikke i Prog3 (som da blir en god del langsommere). Prog1 og Prog2 bruker bare Eratosthenes Sil fra Oblig2. Prog3 bruker både Eratosthenes Sil og faktoriseringa fra Oblig2. 28

29 Skisse av Prog1 : Finn minst én slik sum m=p1+p2, m <n, m partall, p1 p2; sekvensielt program <Les inn: n> <Lag e= Eratosthens Sil(n)> for (int m = 6 ; m < n; m+=2) { // for neste tall m, prøv alle primtall p1 m/2 for (int p1 = 3, p1 <= m/2; e.nextprime(p1){ if ( e.isprime(m-p1)) { // System.out.println( m+" = "+ p1 + " + "+ (m-p1) ); break; } } // end p1 if (p1 > m/2) System.out.println( " REGNEFEIL: (Goldbach er bevist for n < 4*10**18:)" + m + " kan ikke skrives som summen av to primtall "); } // end m 29

30 Skisse av Prog2 : Finn G(m) antall slike summmer: m = p1+p2, m <n, m partall, p1 p2; sekvensielt program <Les inn: n> <Lag e= Eratosthens Sil(n)> int Gm; for (int m = 6 ; m < n; m+=2) { Gm = 0; // for neste tall m, prøv alle primtall p1 m/2 for (int p1 = 3, p1 <= m/2; e.nextprime(p1){ if ( e.isprime(m-p1)) { Gm++; } } // end p1 if (Gm == 0) println(" REGNEFEIL: (Goldbach bevist for n < 4*10**18):" + m + " kan ikke skrives som summen av to primtall "); else println(" Antall Goldbachsummer i "+m+" er:"+gm); } // end m 30

31 Skissen av Prog3 : Er svært lite effektiv fordi en av operasjonene er tar mye lenger tid enn alle andre og gjentas veldig mange ganger med samme argument <Les inn: antall> <Lag e= Eratosthens Sil ( )> // nær øvre grense for int for (long m = 4*10 18 ; m < 4* antall; m+=2) { // for neste tall m, prøv alle primtall p1 m/2 for (int p1 = 3, p1 <= m/2; e.nextprime(p1){ if ( e.faktorisering (m-p1).size() == 1 )) { println(«ok:»+ m + «= «+(m-p1) + «+» +p1); } } // end p1 if (p1 > m/2)system.out.println(" BINGO: "+ m +", ikke sum av to primtall"); } // end m e.faktorisering (m-p1).size() tar hver ca 1/6 sek i parallell, men vi må teste ca 40 tall før vi finner et primtall (og da tar det 1. sek), og bare hvert 10 primtall passer (men i verste tilfellet er det hvert 1000 primtall). Dvs. Å finne en GSum på denne måten tar ca. 100 sek. hver gang vi får OK, eller ca. 115 døgn på å lage slike nye summer. Det må finnes en bedre algoritme som bla. ikke beregner de samme store primtallene svært mange ganger. 31

32 Original skisse av Prog3 : Finn minst én slik sum m=p1+p2, sekvensielt program m, 4*10 18 < m < 4* antall, m partall, p1 p2; <Les inn: antall> <Lag e= Eratosthens Sil( )> // nær øvre grense for int for (long m = 4*10 18 ; m < 4* antall; m+=2) { // for neste tall m, prøv alle primtall p1 m/2 for (long p1 = 3, p1 <= m/2; e.nextprime(p1){ if ( e.faktorisering (m-p1).size() == 1 )) { // Funnet Goldbach sum break; } } // end p1 if (p1 > m/2) System.out.println( " BINGO: Funnet $1. mill:" + m + " kan ikke skrives som summen av to primtall "); } // end m Hvorfor er denne en riktig, men dårlig algoritme?? 32

33 Betraktninger før skissen til Prog3 Det største antall bit vi kan ha i en bit-array = maksimalstørrelsen av en int ( litt for overflyt) max int = Prøver å lage en Erotosthanes Sil med n= Da kan vi faktoriser tall < Dette gir oss plass for å prøve ut tall > 4*10 18 Egentlig skal vi jo prøve ut alle p1 < m/2, men forskningen viser: (One record from this search: needs minimal prime 9781 (= den største p1 : n =p1+p2)) Dvs, satser på at: Er det en Goldbach sum for 19-sifrete tall, så er p1 < (som er en del større enn 9 781) 33

34 Skisse1 av ny algoritme for prog3 <Les inn: antall> a) Lag e= Eratosthens Sil( )> // nær øvre grense for int b) Lag en int[] p1funnet som er ca lang> c) Lag alle store primtall vi trenger og lagre dem i en ArrayList storeprimtall> d) for hvert element p2 i storeprimtall, adder de små primtallene p1 fra e slik at summen er < 4* og lagre disse p1-ene i p1funnet> e) gå så gjennom p1funet og skriv ut de summene du forhåpentligvis kan finne der> hvis p1funnet[i]!= 0 så representerer det summen: m = p1 + p2 i+ 4*10 18 = p1funnet[i] + (i+ 4* p1funnet[i] ) < legg til evt optimalisering av pkt. d) > 34

35 Ide: Hvis det er en sum m = p1+p2, så er p1 < Lag en int [] p1funnet, si lang, og en ArrayList storeprimtall med de første store primtall > 4* storeprimtall 4* * småprimtall fra e p1funnet Legg sammen alle små primtall p1 fra e (3,5,..) med først den minste fra storeprimtall, og lagr p1 i p1funnet for alle slike summer som er > 4*10 18 Gå neste store primtall p2 og gjenta summeringene med de samme små primtallene p1 fra e. osv Når alle slike summer er utført, håper vi at det i p1funnet står en p1 i hver plass som representerer tallene 4*10 18, 4* , 4* ,, 4* Står det ikke en p1 i en av disse plassene, er det kanskje et tall som ikke har en GoldbachSum ($1mill.?) Hvorfor begynne adderingen på 4* , hvorfor ikke på 4*10 18? 35

36 Programskisse av ny Prog3 : Den gamle skissen var svært lite effektiv fordi å finne store primtall tar mye lenger tid enn alle andre og gjentas veldig mange ganger med samme argument <Les inn: antall> <Lag e= Eratosthens Sil( )> // nær øvre grense for int long start = 4* , m; ArrayList storeprimtall = new ArrayList(); // plass til store primtall > start int [] p1found = new int [ ] ; // p1 i summen: m = p1+p2 // lag først alle store primtall for ( m = start ; m < 4* antall; m+=2) { if (e.faktorisering(m).size==1) storeprimtall[(m-start)/2] = m; } int i =0; for (m = storeprimtall.get(i); i < storeprimtall.size(); i++) { // for neste tall m, legg til alle primtall p1 for (int p1 = 3, p1 <= ; e.nextprime(p1) p1found[(m-start+p1)/2] = p1; } m = 4*10 18 ; i =0; while ( p1found[i]!= 0 && i++ < ) println(m + i *2) + «=«p1found[i] «+» + (m+i*2 - p1funnet[i] ) ); 36

37 Prog1: Hvordan parallellisere å finne én sum? Vi har en dobbelt løkke (m og p1) Parallelliser den innerste løkka: Deler opp primtallene og lar ulike tråder summere med ulike p1 Sannsynligvis uklokt? Parallelliserer den ytterste løkka: Hvis vi lar hver tråd få 1/k-del av tallene å finne p1 for. Med n= 2mrd. får hver tråd 250 mill. tall å sjekke. <Les inn: n> <Lag e= Eratosthens Sil(n)> for (int m = 6 ; m < n; m+=2) { // for neste tall m, prøv alle primtall p1 m/2 for (int p1 = 3, p1 <= m/2; e.nextprime(p1){ if ( e.isprime(m-p1)) { break; // funnet sum } } // end p1 if (p1 > m/2) System.out.println(" REGNEFEIL for "+ m); } // end m Litt ulik belastning på trådene, da større tall må lete lenger etter den første p1 hvor m-p1 er primtall. Parallelliserer ved å lage en rekursjon på ytterste løkke. Kan bruke PRP Mye kortere kode Konklusjon: Forsøker først å parallellisere den ytterste løkka? 37

38 Viktig poeng: Hvilke rutiner bruker vi? Vi har sekvensielle og parallelle versjoner av Eratosthenes Sil og Faktorisering. Hvilken versjon bruker vi i Prog1,2,3? <Les inn: antall> /* Prog3 skisse */ <Lag e= Eratosthens Sil( )> // nær øvre grense for int for (long m = 4*10 18 ; m < 4* antall; m+=2) { // for neste tall m, prøv alle primtall p1 m/2 for (int p1 = 3, p1 <= m/2; e.nextprime(p1){ if ( e.faktorisering (m-p1).size() == 1 )) { // Funnet Goldbach sum break; } } // end p1 if (p1 > m/2) System.out.println( " BINGO: Funnet $1. mill:" + m + " kan ikke skrives som summen av to primtall "); } // end m Kan vi parallellisere inne i en parallellisering? Bør vi evt. gjøre det og hvorfor / hvorfor ikke? 38

39 Prog 1, finn én sum: n sekv(ms) para(ms) Speedup SekElem(us) ParaElem(us) EratosthesSil Goldbach Sum Total tid EratosthesSil Goldbach Sum Total tid EratosthesSil Goldbach Sum Total tid EratosthesSil Goldbach Sum Total tid EratosthesSil Goldbach Sum Total tid EratosthesSil Goldbach Sum Total tid EratosthesSil Goldbach Sum Total tid

40 III) Oblig 3 skal leveres på neste fredag 7.april Parallelliser Radix-sortering med fra 1 5 sifre Skriv rapport om speedup for n= 1000, , , 1 mill., 10 mill og 100 mill. Radix består av to metoder, begge skal parallelliseres. Den første, finn max(a[]) løst tidligere Den andre har tre steg løses i parallell effektivt: b) tell hvor mange det er av hvert sifferverdi i a[] i count[] c) legg sammen verdiene i count[] til pekere til b[] d) flytt tallene fra a[] til b[] Steg a) er løst i ukeoppgave (hvor bla. hver tråd har sin kopi av count[]) 40

41 Flere tips til Oblig3 - MultiRadix Problemet med data-konkurranse: To eller flere tråder skriver samtidig på samme variabel (i++-problemet), i samme plass i en array: Løsning: Hver tråd har en kopi av disse felles variable Etter at alle trådene er ferdig (f.eks. etter en barrier-synk) kan resultatene fra hver tråd samstilles (også dette helst i parallell) til et felles svar Muligens må man kopiere data mer enn en gang? Oppdeling av data i arrayer man skal behandle med k tråder: Dele opp arrayen i like store deler (det er indeksene man deler opp) Dele opp etter verdiene i elementene (tråd 0 eier de minste verdiene, tråd 1 de nest-minste,..,) 41

42 Datastrukturer og grep i Oblig3 (hvordan parallellisere) Radix består av 4 steg (løkker) flere valg for datastruktur og oppdeling ved parallellisering a) finn max verdi i a[] b) count= oppttelling av ulike sifferverdier i a[] c) Summér opp i count[] akkumulerte verdier (pekere) d) Flytt elementer fra a[] til b[] etter innholdet i count[] Generelt skal vi se følgende teknikker med k tråder: Dele opp data i a [] i k like deler Dele opp verdiene i a[] i k like deler => dele opp count[] i k like deler Kopiere delte data til hver tråd her lokal count[] kopi en eller to ganger Innføre ekstra datastrukturer som ikke er i den sekvensielle løsningen 42

43 a) finn max verdi i a[] a[] eies av tråd0 eies av tråd1 allmax[] int globalmax 0 1 k-1 eies av tråd k-1 Tråd-i finner max i sin del av a[] og legger svaret i allmax[i] <sync på en CyclicBarrier cb> Nå har alle trådene sin max i allmax[] valg nå: Skal en av trådene (f.eks. tråd-0) finne svaret og legge det i en felles globalmax (mens de andre trådene venter i så fall nok en <sync på en CyclicBarrier cb>)? Skal alle trådene hver regne ut en lokal globalmax (de får vel samme svar?) og fortsette direkte til steg b) 43

44 b) count= oppttelling av ulike sifferverdier i a[] Anta at det er 10 bit i et siffer dvs mulige sifferverdier a[] eies av tråd0 eies av tråd1 count[] 0 1 allcount[] [] 0. k eies av tråd k Skal: 1. Hver tråd ha en kopi av count[] 2. Eller skal count være en AtomicIntegerArray 3. Eller skal de ulike trådene gå gjennom hele a[] og tråd-0 bare ta de små verdiene, tråd-1 de nest minste verdien,..(dvs: dele verdiene mellom trådene) 44

45 Roadmap oversikt over drøftelsen av Oblig3 flere alternativer på steg b og senere endringer i c og d Steg b1)? Steg c1) Steg d1)?? Steg b1+) Steg a)? Steg b2) Steg c2) Steg d2)? Steg b3) Steg c3) Steg d3) FinnMax Tell sifferverdier lag pekere flytt a[] til b[] 45

46 a) finn max verdi i a[] a[] eies av tråd0 eies av tråd1 allmax[] int globalmax 0 1 k-1 eies av tråd k-1 Tråd-i finner max i sin del av a[] og legger svaret i allmax[i] <sync på en CyclicBarrier cb> Nå har alle trådene sin max i allmax[] valg nå: Skal en av trådene (f.eks. tråd-0) finne svaret og legge det i en felles globalmax (mens de andre trådene venter i så fall nok en <sync på en CyclicBarrier cb>)? Skal alle trådene hver regne ut en lokal globalmax (de får vel samme svar?) og fortsette direkte til steg b) 46

47 b) count= oppttelling av ulike sifferverdier i a[] Anta at det er 10 bit i et siffer dvs mulige sifferverdier a[] eies av tråd0 eies av tråd1 count[] 0 1 allcount[] [] 0. k eies av tråd k Skal: 1. Hver tråd har en kopi av count[] 2. Eller skal count være en AtomicIntegerArray 3. Eller skal de ulike trådene gå gjennom hele a[] og tråd-0 bare ta de små verdiene, tråd-1 de nest minste verdien,..(dvs: dele verdiene mellom trådene) 47

48 Om delvis deklarasjoner av arrayer int allcount[] []; - da lages? int allcount[] [] = new int [k][]; - da lages? int [] count = new int[10] ; allcount[k] [0] = x; 48

49 Løsning b1) lokale count[] i hver tråd som etter opptelling settes inn i allcount[] [] a[] eies av tråd0 eies av tråd1 Lokal count[] 0 1 allcount[] [] eies av tråd k Hver tråd-i teller opp de ulike sifferverdien i sin del av a[] opp i sin lokale count[] som så hektes inn i allcount[] [] <sync på en CyclicBarrier cb> Nå er hele opptellingen av a[] i de k count[]-ene som henger i allcount[] [] Denne løsningen trenger (kanskje) et tillegg b1-b: Summering av verdiene i allcount[][] til en felles globalcount[] 49

50 b1+) : Summering av verdiene i allcount[][] til en felles: globalcount[] allcount[] [] globalcount[] Deler opp de mulige sifferverdiene (1024) på de k trådene slik at tråd-0 for de 1024/k minste, tråd-1 de 1024/k nest minste, Tråd-i summerer sine verdier (sine kolonner) på tvers i de k count[] arrayene som henger i allcount[] [], inn i globalcount[] Bør allcount[][] transponeres før summering (mer cache-vennlig)?? <sync på en CyclicBarrier cb> Da er globalcount[] fullt oppdatert Spørsmål: Trenger vi globalcount[], eller holder det med allcount[][]? Svar : Avhenger av neste steg c) 50

51 Løsning b2) Eller skal count[] være en AtomicIntegerArray? a[] eies av tråd0 eies av tråd1 Felles AtomicIntegerArray count[] eies av tråd k-1 Alle tråder oppdaterer AtomicIntegerArray count[] samtidig uten fare for synkroniserings-problemer med sifferverdiene fra sin del av a[] pga synkroniseringa av AtomicIntegerArray-elementene <sync på en CyclicBarrier cb> Spørsmål: Hvor mange synkroniseringer trenger vi med denne løsningen 51

52 Løsning b3) Eller skal de ulike trådene gå gjennom hele a[] og tråd-0 bare ta de n/k minste verdiene, tråd-1 de n/k nest minste verdiene,.. (dvs. dele verdiene mellom trådene) a[] Felles int []count Tråd-i oppdaterer count[] bare med de verdiene som tråd-i eier uten fare for synkroniserings-problemer med sifferverdiene fra hele a[] ingen andre skriver slike sifferverdier. <sync på en CyclicBarrier cb> Spørsmål: Hvor mange synkroniseringer trenger vi med denne løsningen Hvor mye av a[] leser hver tråd 52

53 c1) Gitt b1: Summér opp i count[] akkumulerte verdier (pekere) a[] eies av tråd0 eies av tråd1 allcount[][] o 1. k-1 int []localcount eies av tråd k-1 Fra løsning b1 Vi trenger et prinsipp for at hver tråd finner akkurat hvor den skal plassere sin del av a[]. Hver tråd får nok en kopi av count[]: localcount[] initielt tom (=0) Tråd-i sin localcount[t] er lik summen av alle tråder sin opptelling i allcount[r][s] for alle r og s<t + sum av allcount[r][t] r < i når s == t Vitsen er at før tråd-i plasserer sine sifferverdier s, må det først gjøres plass til alle lavere sifferverdier + de sifferverdiene i tråder med indeks mindre enn i. <sync på en CyclicBarrier cb> 53

54 a[] c2 og c3) Summér opp i count[] akkumulerte verdier (pekere) eies av tråd0 eies av tråd1 Sentralt int [] delsum 0. k AtomicIntegerArray eller Felles int []count eies av tråd k-1 I løsning b2 og b3 har vi samme situasjon som sekvensiell løsning. Kan parallelliseres som følger :Deler verdiene i count[] mellom de k trådene som før. Alle summerer sine verdier og legger de i en separat array delsum[k]. <sync på en CyclicBarrier cb> Deretter justerer du dine plasser i count[] med summen av delsummene i delsum[k] fra tråder med mindre indeks enn deg. Spørsmål: Fra løsning b2, b3 Hvor lang tid tar dette kontra at tråd-0 gjør hele jobben og de andre venter. 54

55 d1,2 og 3) Flytt elementer fra a[] til b[] etter innholdet i count[] a[] eies av tråd0 eies av tråd1 b1: localcount[] k stk. b2, b3: int []count b[] eies av tråd k-1 Løsning b1: Nå kan alle trådene i full parallell kopiere fordi hver localcount[] peker inn i ulike plasser i b[]. Løsning b2: Alle trådene kan i full parallell kopiere over fra a[] til b[] fordi hver gang blir synkronisering foretatt av AtomicIntegerArray. Løsning b3: Nå kan alle trådene i full parallell flytte elementer fra a[] til b[] fordi hver tråd bare flytter sine sifferverdier. Hver tråd går gjennom hele a[]. Alle b1,b2,b3: <sync på en CyclicBarrier cb> Spørsmål: Hvilken av løsningene tar lengst tid? 55

56 Hva så vi på i Uke11 I) En del kommentarer og optimalisering av Oblig2 II) Et større problem uløst problem siden 1742 Vil du tjene 1 millioner $? Løs Goldbach s påstand (alternativt: motbevis den) Formulering og skisse av løsning av tre av Goldbachs problemer (Prog1, Prog2, Prog3) Parallellisering av disse III) Siste tips Oblig 3 56