PROCESSPROGRAMMERING Föreläsning 6 - 29.10.2010‏ Innehåll: Att designa parallella program - manuell vs. automatisk parallellisering - Java och ”multi-core”

En presentation över ämnet: "PROCESSPROGRAMMERING Föreläsning 6 - 29.10.2010‏ Innehåll: Att designa parallella program - manuell vs. automatisk parallellisering - Java och ”multi-core”"— Presentationens avskrift:

1 PROCESSPROGRAMMERING Föreläsning 6 - 29.10.2010‏ Innehåll: Att designa parallella program - manuell vs. automatisk parallellisering - Java och ”multi-core” processorer Hur skall koden parallelliseras?

2 Manuell vs. automatisk parallellisering Att designa parallella program har länge varit en manuell process Att designa parallell kod är komplext och ger ofta upphov till oväntade fel (trådsäkerhet) Det finns en mängd olika verktyg för automatisk parallellisering av program (främst för Fortran och varianter av C) Parallelliseringsverktyg tillåter ofta två olika typer av automatisering: Fullt automatisk Programmeraren ger direktiv för parallellisering för kompilatorn

3 Manuell vs. automatisk parallellisering Ett exempel på en parallelliserings-API är OpenMP, se http://openmp.org/wp/ http://openmp.org/wp/ Det har också utvecklats liknande verktyg för Java, t.ex. JOMP: http://www2.epcc.ed.ac.uk/computing/research_activities/jomp/index_1.html http://www2.epcc.ed.ac.uk/computing/research_activities/jomp/index_1.html Groovy Parallel: http://gpars.codehaus.org/ http://gpars.codehaus.org/ Ateji: http://www.ateji.com/ http://www.ateji.com/ http://www.ateji.com/ Automatisk parallellisering är ofta en bra lösning men det finns också problem: Felaktiga resultat kan produceras Mindre flexibelt än manuell parallellisering Begränsar sej till en viss del av parallelliserbarkod, främst loopar

4 Manuell vs. automatisk parallellisering ”Ordentliga” automatiska parallelliseringsverktyg för Java saknas? Vi kommer tillsvidare att koncentrera oss på manuell parallellisering eftersom detta ger en bättre förståelse för hur Java program kan parallelliseras och optimeras för Multi- processor arkitekturer

5 Java och ”multi-core” processorer Dagens Java virtualmaskiner klarar av att använda multi-core processorer Multipla Java trådar klarar av att exekveras parallellt på multipla processorer om sådana finns. Concurrent API:n som funnits med sedan JDK5 har (där bl.a. Thread Pools definieras) bästa stödet för multi-core processorer

6 Hur parallellisera? Hur skall vi då parallellisera ett java program på rätt sätt för att få bästa möjliga prestanda? T.ex. Om vi har en seriell kod (ickeparallelliserad) måste vi söka fram sådana algoritmer som är ”tunga” (detta kan göras manuellt men det finns även ”performance analysis” verktyg som man kan använda för detta ändamål) Den enklaste typen av parallelliserbar kod är loopar En lång loop som t.ex. utför en beräkning för varje iterationsvarv och där varje iterationsvarv är oberoende av varandra kan enkelt splittas upp i två eller flera delar (Denna typ av parallellisering brukar kallas för ”embarrassingly parallell” eftersom det är så enkelt, bl.a. ingen kommunikation behövs mellan de olika delarna)

7 Hur parallellisera? Det mest optimala är att splitta upp loopen i så många delar som det finns tillgängliga processorer/processorkärnor Att splitta upp en loop i flera delar än antalet processorer/processorkärnor gör inte koden längre effektivare (eftersom processorerna i stället börjar alternera mellan de olika ”överlopps” trådarna) Antalet lediga processorkärnor kan i ett Java-programm fås fram på följande sätt: Runtime.getRuntime().availableProcessors();

8 Hur parallellisera? När man splittar upp en loop i t.ex. två delar gör man det i praktiken så att vi har en s.k. ”master thread” och två s.k. ”worker threads” Master thread sköter om att skapa en trådgrupp på två trådar och delegerar sedan uppgifter åt ”worker” trådarna Så länge ”worker” trådarna ”arbetar” väntar master tråden (med get())

9 Hur mycket effektivare program får vi? I teorin borde en loop försnabbas med 50% om vi har två processorkärnor och fördelar ”arbetet” jämnt mellan båda kärnorna. Detta stämmer dock ej i praktiken eftersom: Att skapa trådar/överföra kod till trådgrupper tar processortid Båda processorkärnorna är sällan (nästan aldrig) helt och hållet lediga

10 Amdahl’s lag Den potentiella effektiveringen av ett program definieras i följande formel: 1----------------------------- Speed up= P+S ---N P = Hur stor del av koden som kan parallelliseras (0 = ingen alls, 1 = all kod) N = Antelet processorer/processoerkärnor S = Hur stor del av koden som är seriell (0 = ingen alls, 1 = all kod) I praktiken uppnår vi aldrig speedup=2 (dubbelt snabbare) eftersom 100% av koden (P=1) kan aldrig i praktiken parallellisera, vi måstju ju bl.a. skapa en trådgrupp, föra över uppgifter til trådarna osv.

11 Förstå problemet och programmet Innan du börjar slösa tid på att parallellisera, kontrollera om ett visst problem kan parallelliseras eller inte Exempel på problem som kan parallelliseras: Avläs 1 miljon mätvärden på temperaturer ur en väderstations loggAvläs 1 miljon mätvärden på temperaturer ur en väderstations logg Beräkna medeltemperaturen på basen av alla mätvärdenBeräkna medeltemperaturen på basen av alla mätvärden Exempel på problem som INTE kan parallelliseras: Beräkning av en Fibonacci-serie (en tabell där ett element är summan av de två föregående elementen)Beräkning av en Fibonacci-serie (en tabell där ett element är summan av de två föregående elementen)

12 Förstå problemet och programmet Hitta ”hotspots” i programmet Var i koden spenderar programmet mest tid?Var i koden spenderar programmet mest tid? Detta kan göras i Netbeans genom att t.ex. Använda ”Profiler” verktygetDetta kan göras i Netbeans genom att t.ex. Använda ”Profiler” verktyget Fokusera dej på att parallelisera ”hoptspottarna” och undvik att parallellisera den delen av koden som inte förbrukar mycket processortidFokusera dej på att parallelisera ”hoptspottarna” och undvik att parallellisera den delen av koden som inte förbrukar mycket processortid Identifiera ”flaskhalsar” i programmet Finns det delar av koden som är extremt långsamma eller som förorsakar att parallelliserbara delar av programmet stannar upp, t.ex. p.g.a I/OFinns det delar av koden som är extremt långsamma eller som förorsakar att parallelliserbara delar av programmet stannar upp, t.ex. p.g.a I/O Konstruera programmet så att långsamma delar av koden inte förhindrar parallelliseringenKonstruera programmet så att långsamma delar av koden inte förhindrar parallelliseringen

13 Partitionering av koden En av de första stegen vid parallellisering är att bryta upp ett problem i diskreta ”bitar” som kan exekveras parallellt Finns två grundläggande sätt att partitionera: Domain decompositionDomain decomposition Functional decompositionFunctional decomposition

14 ”Domain decomposition” Man delar upp en mängd data i flera delar och utför sedan samma operation på de olika datadelarna parallellt Ett exempel på där denna metod kan tillämpas är inläsning av mätdata från väderdatabasen (se slide nr 12)

15 ”Functional Decomposition” I detta fall spjälker man upp själva själva operationen som skall utföras på någon typ av data i flera delar Problemet delas upp enligt det arbete som ska utföras Sedan uttförs varje ”deluppgift” parallellt på samma data

16 ”Functional Decomposition” Exempel på problem där ”Functional Decomposition” kan tillämpas: Signalprocessering:

17 Kommunikation mellan ”uppgifter” Behovet av kommunikation mellan trådarna som utför de olika parallella uppgifterna beror helt på problemet:  Kommunikation behövs INTE:  Vissa typer av problem kan bli partitionerade och exekverade parallellt utan att det finns behov för utybe av data mellan trådarna  T.ex. Analysering av mätdata

18 Kommunikation mellan ”uppgifter”  Kommunikation BEHÖVS:  De flesta typer av problem är inte så lätta att parallellisera som ovannämnda exempel  Ofta behöver en uppgift uttyba någon typ av data med en annan process  T.ex. vid parallellisering av en funktion som beräknar värmespridning

19 Kommunikation mellan ”uppgifter” Det är viktigt att ta i beaktande vissa saker om kommunikation mellan ”upptifter” behövs till följd av parallellisering:  Vad är kostnaden?  Behövs synkronisering? => leder till blockering och förlångsammar parallelliseringen.  Lönar det sej ändå att parallellisera trots att parallellisering förorsakar ”extra” kostnader och problem?