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

Transkript

1 INF2440 Uke 11, v2016 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: 13. april (i dag), 20.april, 27.april, 4 mai og 11 mai (oppsummering/eksamenstips ) Oblig 4: Den konvekse inn hyllinga av en punktmegde med innleveringsfrist 13 mai Mulig Prøveeksamen: 25. mai med gjennomgang og tips (mer info evt senere)?? Eksamen: 7. juni 2

3 Hva så vi på i Uke10 Hvor lang tid tar de ulike mekanismene (les/skriv, new, metodekall, arrayer,..) i Java 6 og 8. 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 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 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 (i eksempelet primtallene på 25 bit i bittabellen hver) 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æing 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); 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 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); } 20

21 II) Christian Goldbachs påstand i 1742: Alle partall m =n+n > 4 kan skrives som en sum av to primtall som 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. 21

22 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 22

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

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

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

26 Hvordan vise Goldbach med et program En riking i USA har utlovet $1mill for løsning på 10 matematiske problemer som lenge var uløst. Goldbach er en av disse problemene, og premien er ikke hentet. 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) 26

27 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. 27

28 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 bevist for n < 4*10**18:" + m + " kan ikke skrives som summen av to primtall "); } // end m 28

29 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 29

30 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) 30

31 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?? 31

32 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. 32

33 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 småprimtall fra e 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? 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 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] ) ); 35

36 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? 36

37 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? 37

38 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

39 III)Oblig 3 skal leveres på fredag 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[]) 39

40 Oblig 3 Parallelliser Radix-sortering med 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 har ett parallelt steg a) 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 b) er løst i ukeoppgave (hvor bla. hver tråd har sin kopi av count[]) 40

41 Litt 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 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) 42

43 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) 43

44 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 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 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) 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 AtomicIntegerArray eller Felles int []count eies av tråd k-1 Fra løsning b2, b3 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: 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 IV) Hvorfor lage en egen IntList istedenfor ArrayList <Integer> Ukeoppgave, til Oblig4 Fordi det er raskere og tar mindre plass Hva er forskjellen på en Integer og en int. Hvordan lage IntList 56

57 Forskjeller på Integer og int - størrelse Integer er et objekt som brukes å holde et heltall. Hvert heltall tar da 12 byte (object header) + 4 byte (int) int er en basaltype som tar 4 byte En int [] array har ett array objekt for hver rad dvs. ekstra 12 byte per rad + ett array-objekt for hver dimensjon (2,3,..) se: og a normal object requires 8 bytes of "housekeeping" space; arrays require 12 bytes (the same as a normal object, plus 4 bytes for the array length). If the number of bytes required by an object for its header and fields is not a multiple 8, then you round up to the next multiple of mark word klass pointer array size (opt) padding Har vi 1000 Integer i en array er det: 1000x 16 (Integer objekter) + 16 (array overhead) + 8x1000 (pekere) = byte Har vi int [] a = new int[1000} er det *1000 = byte 57

58 class IntList{ // en litt for kort IntList, noen metoder mangler kanskje int [] data; int len =0; IntList( int len) { data = new int [Math.max(1,len)]; } IntList() { data = new int [32]; } void add( int elem) { if (len == data.length-1) { int [] b = new int [data.length*2]; for (int i = 0; i < data.length; i++) b[i] = data[i]; data =b; } data[len++] = elem; } // end add void clear(){ len =0; } // end clear int get ( int pos){ // error antar at svaret brukes til array-indeks if (pos > len-1 ) return -1; else return data [pos]; } //end get int size() { return len; } //end size } // end class IntList 58

59 Fra testprogrammet long ILSek (int n) { IntList itlist = new IntList(n); long j = 1; for (int i =0; i<n; i++) itlist.add(i); for (int i =0; i<n; i++) j +=itlist.get(i); return j; }// end ILSek long ALSek (int n) { ArrayList <Integer> alist = new ArrayList<Integer>(n); long j = 1; for (int i =0; i<n; i++) alist.add(i); for (int i =0; i<n; i++) j +=alist.get(i); return j; }// ens ALSek.. long t = System.nanoTime(); // start tidtaking IntList sum += ILSek(n); t = (System.nanoTime()-t);.. t = System.nanoTime(); // start tidtaking ArrayList sum += ALSek(n); t = (System.nanoTime()-t); 59

60 Tidsforbruk int og Integer Integer Når vi skal lagre et heltall i en Integer, må den først pakkesinn (boxing) i et objekt vi lager + en peker til den i arrayen av Integer-pekere Når vi skal lese en heltallsverdi fra en Integer, må vi først følge en peker for å lokalisere Integer-objektet, og så lese ut int-verdien (unboxing) int-array Lesing og skriving i en int [] er mye raskere tilsvarende som å finne og skrive en peker i Integer-arrayen. 60

61 Test på lage (add) n stk Integer i ArrayList og i IntList og lese dem (get) Test av IntList mot ArrayList for å oppbevare heltall med 4 kjerner, og 4 traader, Median av:3 iterasjoner (lager array 128 lang først og så kopierer) n IntList.tid(ms) ArrayList.tid(ms) Speedup (tallene kan variere mye men IntList er alltid en god del raskere enn ArrayList <Integer>- eks. lager stor nok array initierer med n: ) Hvorfor ikke en større speedup? 61

62 Ser på performance i Task manger Før kjøring 62

63 Kjøring av IntList test ser på performance i Task manger Kjøring av IntList test 15% 100/8 63

64 Ser ut til at optimaliseringen parallelliserer ArrayList operasjonene ser på performance i Task manger Kjøring av ArrayList test 73 % må komme av parallellisering Derfor er ikke ArrayList så mye langsommere enn IntList 64

65 V) Debugging feilfjerning parallelt Antar at vi har et program som lar seg starte opp Felles problem i sekvensiell og parallell kode? Råd0 : Hvis ikke sekvensiell kode virker, fix den 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 65

66 Du har en feil som kan reproduseres på et relativt lite eksempel EKS fra debugging av min parallelle Oblig2-løsning (parallell ErSil + parallell faktorisering.): para: = 65*2*307 NEI!! (65 = 13*5) Symptomer: Kom ikke hver gang (bare ca. hver 4. gang)) Kom ikke i den sekvensielle faktoriseringa. Spørsmål:: Er det en tidsavhengig feil? Svar1? Sannsynligvis det Eller det bare en sekvensiell feil i den parallelle koden? Svar2: Mindre sannsynlig. Nesten alle parallelle faktoriseringer er riktige (og ingen andre brukte 65 som primtall) 66

67 para: = 65*2*307 - nei Er det feil i Eratosthenes bit-tabell eller i selve faktoriseringa Jeg prøvde ut flere optimaliseringer. Sjekket først synkronisering Viktig: At bare en tråd (tråd-0) initierer konstanter o.l., og genererer alle primtall < 200 =14,, og at alle andre tråder venter på at det er ferdig. 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? Debug:2 Debug:3 Debug:5 Debug:7 Debug:11 Debug:13 Debug:17 Debug:23 Debug:29 Debug:33 Debug:39 Debug:41 Debug:47 Debug:51 Debug:53 Debug:57 Debug:59 Debug:69 67

68 Noen av Primtallene var altså gale (for mange) Første feil : 33! Feilen var altså i Erotasthenes Sil i parallell: Algoritmen, skisse (for n=200, n =14): Finn først alle primtall < n sekvensielt Dette er de vi trenger for å lage alle under 200 Del tallinja i antallkjerner (8) deler, jeg fikk: left:1, right:27 left:1, right:13 left:71, right:83 left:99, right:200 left:85, right:97 left:57, right:69 left:43, right:55 left:15, right:27 left:29, right:41 Ikke opplagt riktig Debug:2 Debug:3 Debug:5 Debug:7 Debug:11 Debug:13 Debug:17 Debug:23 Debug:29 Debug:33 Debug:39 Debug:41 Debug:47 Debug:51 Debug:53 Debug:57 Debug:59 Debug:69 68

69 Råd4: Litt analyse (papir og blyant): Denne metoden ble brukt av både sekvensiell innledende fase av parallell alle < n (rød) og parallell (sort): Den er også tilpasset grensene for hva innholdet av en byte er: byte[0] 1-13, byte[1] 15-27, Siden 200 =14 > 13, så OK? De andre grensene så ut til å være veldig skjevt fordelt? Men siden da jeg regnet ut antall primtall per kjerne: (200 /8) /14)*14 = (25/14)*14 = 14 og siste tråd tar resten, er dette OK. Konklusjon: Tråd-2 (29-41) feiler med 3-er avkryssingene left:1, right:27 left:1, right:13 left:71, right:83 left:99, right:200 left:85, right:97 left:57, right:69 left:43, right:55 left:15, right:27 left:29, right:41 69

70 Hvis den alltid tror at 65 er et primtall, hvorfor går dette ofte OK? Råd5: Forstå feilen Som oftest får vi følgende svar : = 2*5*13*307 som er helt riktig! Og hvorfor vil den sekvensielt alltid ha det riktig selv om den tror at 65 er et primtall? Se på koden: 70

71 Hvis 65 = 5*13 er to faktorer i et tall num og vi allerede har delt ned num med de mindre primtallene 5 og 13, så finner vi ikke 65 en faktor (den er dividert bort) Dividerer vi først ned med 5 og 13 (alltid ved sekvensiell), så vil vi aldri oppdage 65. Hvis tråd2 deler num ned før tråd0, vil vi oppdage 65 ellers ikke. // Sekvensiell faktorisering av primtall 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 71

72 Feilen - konklusjon: Diagnose enten ble 3-ere, 5ere..avkrysset galt i byte[1], byte[2],.., eller så har vi et timing-problem FASIT: Hvor starter vi neste kryss fra primtall p i en byte (bit-nummeret) som har sitt venstre, minste bit i left. p 2 ikke er i inneværende byte. Hva er verdien til start 2p 2p 2p 2p 2p start p 2 left I denne byten skal vår tråd krysse av start = ((left - p p)/(p + p)) (p + p) + p p; while(start < left) start += p + p; 72

73 Avsluttende bemerkninger om debuging av parallelle programmer: Råd6: Legg System.out.println(s) innn 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 : print(«a»); print(«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. Start å lete etter siste bokstav i koden som kom ut. 73

74 Hva så vi på i Uke11 I) En del sluttkommentarer og optimalisering av Oblig2 II) Debugging av parallelle programmer III) 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 (ukeoppgave neste uke) IV) Oblig 3 74