Parallelliseringsstrategier med Web workers för partikelsystem med realtidsgrafik

Parallelliseringsstrategier med Web workers för partikelsystem med realtidsgrafik

Examensarbete inom huvudområdet Datalogi Grundnivå 30 Högskolepoäng

Vårtermin 2012 Johan Gustafsson

Handledare: Henrik Gustavsson

Examinator: Björn Lundell

Sammanfattning

Webbapplikationer blir allt mer lika desktopapplikationer vilket innebär att högre prestandakrav ställs på dessa. Ett sätt att möta dessa krav är att bättre utnyttja tillgänglig hårdvara med hjälp av parallellisering. Många webbapplikationer är implementerade i JavaScript. Ett nytt API kallat Web workers möjliggör parallellisering av JavaScript. Web workers har dock vissa begränsningar. Denna studie fokuserar på Web workers applicerat på webbapplikationer med partikelsystem. Partikelsystem har många olika användnings- områden vilket gör att dessa kan användas för många olika typer av tillämpningar. En tillämpning är fysiksimulering i applikationer med realtidsgrafik. Studien undersöker vilka prestandaeffekter tre olika parallelliseringsstrategier implementerade med Web workers ger för fysiksimulering med hjälp av partikelsystem i en webbapplikation. För ändamålet har en enkel applikation utvecklats vilken prestandamätningar utförts med. Resultatet visar att valet av parallelliseringsstrategi begränsas av kommunikationshastigheten till och från Web workers. Ett samband mellan prestanda och antal skickade meddelanden kan påvisas men behöver undersökas närmare.

Nyckelord: Web workers, parallellisering, JavaScript, partikelsystem, fysiksimulering.

Innehållsförteckning

1 Introduktion ... 1

2 Bakgrund ... 2

2.1 Dynamiska webbsidor ... 2

2.2 HTML5 ... 3

2.3 Parallellisering ... 3

2.4 Web workers ... 4

2.5 Partikelsystem ... 5

2.5.1 Fjädrar i partikelsystem ... 6

2.5.2 Verlet-integration ... 7

2.6 Interaktiva applikationer med realtidsgrafik ... 8

3 Problem ... 9

4 Metod ... 11

5 Genomförande ... 13

5.1 Pilotstudie ...13

5.2 Implementation av fysiksimulator ...15

5.2.1 Tillämpningsapplikation ...17

5.3 Parallellisering ...19

5.3.1 En Web worker för varje partikel...19

5.3.2 En Web worker för varje partikels funktionsanrop ...19

5.3.3 En Web worker för varje rep-objekt ...20

5.3.4 En Web worker för fysiksimuleringsloopen ...21

5.4 Prestandamätningsimplementation ...22

6 Analys ... 23

6.1 Referensmätning utan Web workers ...23

6.2 En Web worker för varje partikels funktionsanrop ...25

6.3 En Web worker för varje rep-objekt ...28

6.4 En Web worker för fysiksimuleringsloopen ...30

6.5 Prestandajämförelse mellan parallelliseringsstrategierna ...32

6.6 Analyssammanfattning ...34

7 Slutsatser ... 36

7.1 Diskussion ...36

7.2 Framtida arbete ...38

Referenser ... 40

1

1 Introduktion

Det finns både en trend att webbapplikationer blir allt mer lika desktopapplikationer (Mehrara m.fl., 2011) och att antalet hårvaruplattformar med multipla processorer och/eller processorkärnor ökar (Asanovic m.fl., 2009). Det är också så att prestandakraven på webbapplikationerna ökar med tiden (Erbad m.fl., 2011). För att möta dessa krav bör webbapplikationer anpassas så att de utnyttjar tillgängliga hårdvaruresurser bättre med hjälp av parallellisering (Asanovic m.fl., 2009).

En majoritet av alla webbapplikationer är helt eller delvis implementerade i JavaScript (Richards m.fl., 2010). För att parallellisera JavaScript-kod finns en ny teknologi kallad Web workers (Erbad m.fl., 2011). Web workers har dock vissa begränsningar, t.ex.

kommunikationshastighet och avsaknad av delat minne, vilket gör att möjliga val av strategi för parallellisering begränsas och blir beroende av vilken typ av applikation som ska parallelliseras (Erbad m.fl., 2011). Det här arbetet avser att undersöka vilka prestandaeffekter olika parallelliseringsstrategier implementerade med Web workers ger för fysiksimulering med partikelsystem i applikationer med realtidsgrafik. Där valet av partikelsystem baseras på att dessa har många olika typer av användningsområden (Bouvier m.fl., 1997) vilket kan göra resultatet intressant inom flera av dessa områden.

Utvärderingen av parallelliseringsstrategierna kommer att ske genom ett jämförande experiment där varje implementerad strategi testas och jämförs med övriga strategier samt en icke-parallelliserad implementation. Jämförelsen avser att mäta vilka prestandaeffekter parallelliseringsstrategierna ger med avseende på renderingshastighet mätt i bilder per sekund och exekveringshastighet av beräkningsalgoritmer för fysiksimuleringen.

Prestandamätningen kommer att ske med olika webbläsare, operativsystem och med olika antal processorkärnor.

För studien identifierades och implementerades tre olika parallelliseringsstrategier. Den

första strategin baseras på en parallellisering av varje partikels funktionsanrop för

fysiksimuleringen i partikelsystemet (Fortuna m.fl., 2010). Den andra strategin delar upp

simuleringsvärlden i olika delar där varje del representeras av en sammanhängande samling

av partiklar (Bouvier m.fl., 1997). Den tredje strategin bygger på att applikationen delas upp i

flera olika moduler där fysiksimuleringen blir en egen modul som körs parallellt med

applikationens övriga delar (Hughes m.fl., 2007).

2

2 Bakgrund

2.1 Dynamiska webbsidor

Som trenden ser ut just nu så går webbapplikationer mot att allt mer likna desktopapplikationer och därför ställs också samma krav på prestanda på dessa som motsvarande desktopapplikationer (Mehrara m.fl., 2011). Ett par av anledningarna till denna trend är att det förenklar distributionen av mjukvaran och applikationen blir mindre plattformsberoende då det teoretiskt räcker att en plattform har en webbläsare så kan applikationen köras från denna (Martinsen och Grahn, 2011).

Det finns en mängd olika programmeringsspråk och olika typer av s.k. ”plug-in”-teknologier vilka möjliggör utvecklandet av webbapplikationer. Ett av dessa språk är skriptspråket JavaScript som introducerades i och med att Netscape Navigator version 2.0B släpptes i december 1995 (Taivalsaari och Mikkonen, 2011). JavaScript gjorde det enklare än tidigare att skapa webbplatser med interaktivt och animerat innehåll (Taivalsaari och Mikkonen, 2011). Exempel på sådant innehåll kan ses i Figur 1 nedan. Enligt Richards m.fl. (2010) använder 97% av de 100 mest besökta webbplatserna vid en viss mättidpunkt JavaScript som implementationsspråk för hela eller delar av de webbapplikationstjänster som webbplatserna tillhandahåller på klientsidan. Dessutom är JavaScript på väg att bli ett språk som används för implementation av alla typer av generella tillämpningar som tidigare har utvecklats för traditionella desktopmiljöer (Richards m.fl., 2010).

Figur 1 Två olika exempel på interaktivt dynamiskt innehåll skapat med hjälp av JavaScript. Till vänster en datumväljare och till höger en lista som går att

sortera genom att dra listobjekten med muspekaren.

Webbapplikationer kan delas upp i två olika kategorier (Mehrara m.fl., 2011). Den ena

kategorin är sådana applikationer som i huvudsak baseras på s.k. händelsedriven-

programmering där varje händelse exekverar kortare och oftast inte så beräkningsintensiva

kodstycken och den andra kategorin består av mer beräkningsintensiva applikationer

(Mehrara m.fl., 2011). Enligt Mehrara m.fl. (2011) så kommer webbapplikationer i den

senare kategorin att bli allt fler och ger som exempel på att det redan förekommer sådana i

form av bildredigerare och olika typer av webbläsarbaserade datorspel. Utvecklingsarbetet av

en webbapplikation begränsas ofta av webläsarens JavaScript-exekveringsprestanda vilket

leder till att utvecklare tvingas att ta bort eller förenkla funktionalitet i sina

webbapplikationer (Erbad m.fl., 2011; Anttonen m.fl., 2011). Eventuellt kommer den

3

kommande HTML5-standarden kommer göra det enklare att utveckla webbapplikationer (Anttonen m.fl., 2011).

2.2 HTML5

HTML5 är en standard under utarbetande av World Wide Web Consortium (W3C) och Web Hypertext Application Technology Working Group (WHATWG) som bl.a. syftar till att förenkla och förbättra utvecklingen av webbapplikationer (WHATWG, 2012a; W3C, 2011a).

HTML5 möjliggör utvecklandet av betydligt mer avancerade webbapplikationer med hjälp av HTML, CSS och JavaScript än vad som tidigare varit möjligt (Erbad m.fl., 2011).

Ett av de viktigare tillägg som gjorts i den HTML5-standard som finns under utveckling är canvas-elementet vilket möjliggör direkt utritning av procedurell interaktiv grafik på websidor med hjälp av JavaScript utan några externa tillägg (Taivalsaari och Mikkonen, 2011). Med detta menas grafik i alla möjliga typer av former och figurer men också bitmap- bilder och text som kan påverkas genom att olika event kopplas till ett canvas-element. Ett exempel på sådan grafik skapad i ett canvas-element kan ses i Figur 2 nedan.

Figur 2 Exempel på procedurellt genererad grafik i ett HTML5 canvas-element.

2.3 Parallellisering

En annan trend är att den parallella angreppsmetoden används för att hantera högre krav på prestanda inom datorberäkningar eftersom det har blivit svårt och kostnadsineffektivt att lösa prestandaproblemen med hjälp av den sekventiella angreppsmetoden (Asanovic m.fl., 2009). Detta beror på att utvecklingen av datorprocessorer har nått en övre fysisk gräns för hur mycket elektrisk spänning ett enskilt kiselchip kan hantera vilket har gjort att hårdvaruutvecklingen istället har inriktats mot multiprocessor- och multikärnprocessor- system (Asanovic m.fl., 2009). Det här skulle eventuellt kunna leda till nya möjligheter till förbättrad prestanda i flera olika avseenden som t.ex. kortare exekveringstider, förbättrad beräkningstillförlitlighet och energieffektivare beräkningar vilket i sin tur skulle kunna leda till förbättrad batteritid för mobila enheter och lägre elektricitetskostnader vid drift av stora serverhallar (Asanovic m.fl., 2009).

För att den mjukvara som ska exekveras ska kunna dra nytta av den parallella

beräkningskraften fullt ut måste den anpassas för att köras mot en parallell

hårdvaruarkitektur och detta gäller då även för webbläsare (Asanovic m.fl., 2009). Det krävs

också att mjukvaran som ska köras med den parallella hårdvaran måste vara

4

parallelliseringsbar och dessutom skalbar för att hårvaran ska kunna utnyttjas effektivt (Martinsen och Grahn, 2011).

Utvecklingen har gått relativt fort de senaste åren för både webbläsare och JavaScript- motorer vilket inneburit förbättringar av den sekventiella exekveringsprestandan av JavaScript-kod (Martinsen och Grahn, 2011). Dock begränsas JavaScript-exekveringen av att webbapplikationer exekverar i samma tråd som webbläsaren vilket innebär att de endast utnyttjar en processorkärna åt gången (Erbad m.fl., 2011). Enligt Fortuna m.fl. (2010) finns det teoretiska möjligheter för JavaScript-kod att exekveras ännu snabbare om koden parallelliseras. Det vill säga att delar av koden exekveras parallellt i olika trådar. Dessa teoretiska resultat får också stöd av praktiska försök genomförda av både Martinsen och Grahn (2011) och Mehrara m.fl. (2011) vilka visar att parallelliserad exekvering av JavaScript kan ge kortare exekveringstider. Som tidigare påpekats så ökar antalet hårdvaruplattformar som använder processorer med flera kärnor både i desktopmaskiner och portabla enheter så som t.ex. mobiltelefoner och s.k. surfplattor (Mehrara m.fl., 2010). Det kan därför antas att parallellisering kommer att spela en allt större roll i framtiden. För att förbättra exekveringsprestandan för JavaScript, genom att dra nytta av parallell exekvering på mer än en processorkärna åt gången, föreslår Erbad m.fl. (2011) att Web workers kan användas.

2.4 Web workers

Det har tidigare inte funnits något inbyggt stöd för parallell kodexekvering i JavaScript men W3C har tillsammans med WHATWG tagit fram ett förlag till en standard kallad Web workers (WHATWG, 2012b; W3C, 2011b) som gör det möjligt att exekvera JavaScriptkod i flera olika trådar samtidigt. För varje tråd med kod som ska exekveras skapas ett Web worker-objekt som tar den fil med JavaScript-kod som ska köras som argument till sin konstruktor. Exempelvis enligt koden i Figur 3 nedan.

var worker = new Worker(“workerScript.js”);

Figur 3 Exempelkod för att initiera en Web worker.

Kommunikationen mellan huvudtråden och Web worker-trådar sker med hjälp av meddelanden som skickas asynkront mellan trådarna. För att ta emot meddelanden från ett Web worker-objekt används onmessage-eventet, exempelvis enligt koden i Figur 4 nedan.

worker.onmessage = function(event) {

console.log(“Message received: ”+event.data);

}

Figur 4 Exempelkod för där onmessage-eventet används för att ta emot meddelanden från en Web worker.

I det skript som körs av en Web worker används också

-metoden för att skicka tillbaka meddelanden och onmessage-metoden för att ta emot meddelanden. Ett exempel på detta kan ses i programkoden i Figur 5 nedan.

self.onmessage(event){

postMessage(“Message received by worker”);

}

Figur 5 Exempelkod för kommunikation med onmessage-eventet och postMessage-

metoden i en Web worker.

5

Ett mer komplett exempel på hur Web workers kan användas för att addera två tal kan ses i Figur 6 nedan.

<script>

var addWorker = new Worker("additionWorker.js");

addWorker.onmessage=function(event){

document.getElementById("result").innerHTML=event.data.sum;

}

addWorker.postMessage({a : 1, b : 2});

</script>

<div id="result"></div>

Figur 6 Exempelkod för hur en Web worker kan användas.

Koden ovan skapar ett Web worker-objekt och definierar en funktion för objektets

-event vilken skriver ut resultatet från det meddelande som tas emot från Web worker-objektet. Därefter skickas ett meddelande till Web worker-objektet med de tal som ska adderas. Själva koden för Web worker-skriptet som körs när meddelandet tas emot kan ses i Figur 7 nedan. Koden adderar de två talen och skickar tillbaka summan i ett meddelande till huvudtråden.

self.onmessage = function(event){

var a=event.data.a;

var b=event.data.b;

var sum=a+b;

postMessage({sum : sum});

}

Figur 7 Exempelkod för en Web worker som adderar två tal.

Web workers har vissa begränsningar, t.ex. så delar Web workers inget minne med vare sig varandra eller med huvudtråden (Erbad m.fl., 2011). Detta innebär bl.a. att en Web worker inte kan komma åt webbplatsens DOM (Document Object Model). En annan begränsning är att det tar tid att skicka meddelanden mellan de olika trådarna (Erbad m.fl., 2011).

Något som används för flera olika beräkningsintensiva tillämpningar och som eventuellt kan vinna prestanda genom parallellisering är partikelssystem (Bouvier m.fl., 1997).

2.5 Partikelsystem

Ett partikelsystem består av ett antal individuella partiklar vilka alla har någon form av beteende vilket styrs av en uppsättning regler som appliceras utefter partiklarnas olika egenskaper, t.ex. position, hastighet eller utseende (Reynolds, 1987). Egenskaperna för individuella partiklar i ett partikelsystem kan alltså ändra värde allt eftersom tid passerar och partiklar kan både försvinna ur systemet eller tillkomma under tidens gång (Reeves, 1983).

Grundprincipen är att ett partikelsystem skapas med partiklar som tilldelas olika för

ändamålet aktuella attribut, som t.ex. rörelsehastighet och massa, och sedan utsätts dessa

partiklar för någon form av påverkan, t.ex. gravitation (Sims, 1990). Beroende på syftet med

partikelsystemet kan partiklarna också utsättas för påverkan av andra partiklar (Bouvier

m.fl., 1997). Partiklar kan användas för att modellera komplexa objekt om objektet kan

definieras som en mängd av partiklar där partiklarna utgör objektets volym (Reeves, 1983).

6

Enligt Bouvier m.fl. (1997) så finns det två generella typer av tillämpningar för partikelsystem. Det ena är datorgrafik och det andra simulering med syfte att förutsäga resultaten olika fysikaliska fenomen och visualisering av dessa, t.ex. för att modellera och simulera av gasutvecklingen i en airbag (Bouvier m.fl., 1997). Inom området datorgrafik kan partikelsystem bl.a. användas till att modellera och animera grafiska objekt på ett fysiologiskt korrekt vis, t.ex. explosioner och gräs (Reeves, 1983). Ett exempel på ett partikelsystem som visualiserar en enkel simulering av en fontän kan ses i Figur 8 nedan. Andra exempel på användningsområden för partikelsystem är studier av beteenden och rörelsemönster hos folksamlingar (Bouvier m.fl., 1997) och att simulera djurs flockbeteende med en specialvariant av partikelsystem som kallas för boidsystem (Reynolds, 1987). Partikelsystem används också inom molekylär- och partikeldynamiksforskning (Kačić-Alesić m.fl., 2003).

Figur 8 Ett enkelt partikelsystem som simulerar en fontän.

För mer komplexa tillämpningar av partikelsystem måste olika typer av begränsningar kunna sättas för partiklarna i systemet. Begränsningarna beror på typ av tillämpning. Exempel på sådana begränsningar kan vara olika typer av kollisionsytor eller avståndsbegränsningar till andra partiklar. Den senare typen av begränsning är vad som kan kallas för en fjäderbegränsning och används bl.a. inom olika typer av fysiksimuleringar (Ahmad m.fl., 2007).

2.5.1 Fjädrar i partikelsystem

Fjädrar används för att implementera relationer mellan olika objekt så som t.ex. mellan olika

partiklar där en partikel kan vara kopplad till en eller flera andra partiklar både direkt och

indirekt (Ahmad m.fl., 2007). En fjäder fungerar på så vis att när den sträcks ut skapar den

en kraft i motsatt riktning så att den dras ihop igen och på motsvarande vis skapar den en

kraft för att sträckas ut om den pressas ihop (Ahmad m.fl., 2007). Fjädern försöker med

andra ord alltid att bibehålla sin längd. Med hjälp av fjädrar kan komplexa objekt modelleras

av partiklar genom att koppla flera partiklar till varandra med fjädrar. Olika fjädrar kan ha

olika stor eller liten elasticitet. Tekniken kan t.ex. användas för att animera ett rep eller ett

stycke tyg som utsätts för olika typer av yttre påverkan, t.ex. gravitationskraften (Ahmad

m.fl., 2007). I Figur 9 nedan åskådliggörs principen.

7

Figur 9 Fyra partiklar sammanlänkade med tre fjädrar. Om en av partiklarna flyttas påverkas alla de andra partiklarna.

Ett exempel på ett datorspel vars hela spelmekanik bygger på tekniken och använder den för att animera rep som håller en tyngd är ”Cut the Rope” (ZeptoLab, 2010). En illustration inspirerad av spelet kan ses i Figur 10 nedan. Dessa rep utsätts för olika krafter, t.ex. kan spelaren blåsa med ballonger på tyngden som hänger i repen och de dras alltid nedåt av en gravitationskraft.

Figur 10 Visualisering av hur repmekaniken ser ut i datorspel av typen ”Cut the Rope”.

2.5.2 Verlet-integration

Det finns flera angreppsmetoder för att beräkna en partikels position, t.ex. kan en integrationsmetod användas. En integrationsmetod är en metod för att approximativt beräkna hur ett föremål påverkas av Newtons rörelselagar (Jiang och Wang, 2010).

Rörelselagarna beskriver dels ett objekts lägesförändring, acceleration och deformering men även hur ett föremål påverkas av yttre krafter.

Det finns flera olika integrationsmetoder bl.a. Euler, Verlet, Leap-frog och Runge-Kutta där just Verlet-metoden används inom flera vitt skilda tillämpningsområden som t.ex.

datorspelsutveckling och forskning i molekylär- och partikeldynamik (Kačić-Alesić m.fl., 2003). Verlet-metoden är både beräkningseffektiv och relativt exakt (Jiang och Liu, 2008).

Principen i ett fysiksystem baserat på Verlet-integration är att allt är byggt av partiklar vilka påverkas av olika fysiologiska faktorer som t.ex. någon form av yttre kraft vilken får partikeln att röra sig i en viss riktning. Verlet-integrationsekvationen återfinns i Formel 1 nedan där x är objektets position, a dess acceleration och t är tiden. Metoden har fått sitt namn från Verlet (1967).

(

)

Formel 1 Ekvationen för Verlet-integration p

p

p

p

8

Själva beräkningen sker iterativt över en viss tidsrymd mellan varje beräkning där tidsrymden betecknas med ∆t. Ett mindre ∆t ger ett mer korrekt värde i motsats till ett större värde som ger mindre korrekthet men som i gengäld är mindre beräkningskrävande (Yeh m.fl., 2009). Verlet-metoden lagrar föremålets hastighet implicit då hastigheten är skillnaden i nuvarande och tidigare position (Müller m.fl., 2007).

En nackdel med Verlet-metoden är att den inte startar av sig självt utan måste sättas igång med hjälp av någon annan integrationsmetod, t.ex. Euler-metoden, eftersom metoden bygger på att det finns ett tidigare värde för positionen även vid start. Valet av startmetod påverkar metodens precision (Jiang och Wang, 2010). Verlet-metoden finns även i några andra varianter utöver den ursprungliga bl.a. en som kallas för Velocity Verlet där en hastighetsberäkning görs för halva ∆t (Kačić-Alesić m.fl., 2003).

2.6 Interaktiva applikationer med realtidsgrafik

En typ av applikation där fysiksimuleringar ofta förekommer är interaktiva applikationer

med realtidsgrafik (Yeh m.fl., 2007). Dessa fysiksimuleringar bygger ofta på olika typer av

partikelsystem (Bouvier m.fl., 1997; Yeh m.fl., 2007). Exempel på sådana applikationer som

grafiskt presenterar någon form av realtidsgenererad information är olika typer av

vetenskapliga applikationer (Bouvier m.fl., 1997), applikationer för utbildning (Muoz m.fl.,

2009) och applikationer för underhållning (Yeh m.fl., 2007). Syftet med fysiksimulering i

dessa applikationer är att realistiskt återskapa olika fysiska fenomen med syftet att studera

dessa eller för att skapa trovärdiga animationer (Bouvier m.fl., 1997). Interaktiva

applikationer med realtidsgrafik är intressanta ur ett prestandaperspektiv eftersom tiden

innan nästa bildruta ska ritas ut är begränsad (Yeh m.fl., 2007).

9

3 Problem

Webbläsare har blivit en plattform som används för alla sorters applikationer vilket också innebär att högre krav ställs på plattformen (Erbad m.fl., 2011; Mehrara m.fl., 2011; Richards m.fl., 2010). Bland dessa krav finns ett ökande behov av förbättrad exekveringsprestanda då utvecklare ofta tvingas förenkla funktionaliteten eller avstå från vissa funktioner helt i de webbapplikationer de utvecklar (Anttonen m.fl., 2011; Erbad m.fl., 2011). För webbapplikationsutveckling har JavaScript använts i en majoritet av idag existerande webbapplikationer (Richards m.fl., 2010). Framsteg har gjorts för att förbättra exekveringsprestandan för JavaScript under de senaste åren (Martinsen och Grahn, 2011).

Men eftersom webbläsare exekverar JavaScript-kod sekventiellt i samma tråd som webbläsaren körs kan exekveringen inte dra nytta av andra processorer eller processorkärnor som kan finnas tillgängliga (Erbad m.fl., 2011). Det finns en tydlig trend som visar på att flerprocessor- och flerkärnsprocessorsystem ökar i antal och framtida applikationsutveckling kommer att behöva utnyttja dessa resurser för att uppnå önskad prestanda (Asanovic m.fl., 2009).

Det finns både teoretiska och praktiska studier som visar att en parallellisering av JavaScript- exekvering ger förbättrad exekveringshastighet (Fortuna m.fl., 2010; Martinsen och Grahn, 2011; Mehrara m.fl., 2011). Tidigare har inget inbyggt stöd för parallell kodexekvering funnits för JavaScript. Detta har förändrats i och med ett nytt API som är under utveckling av WHATWG och W3C kallat för Web workers vilket möjliggör parallell kodexekvering av JavaScript-kod (Erbad m.fl., 2011; WHATWG, 2012b; W3C, 2011b).

Något som används för flera olika beräkningsintensiva tillämpningar och som eventuellt kan vinna prestanda genom parallellisering är partikelssystem (Bouvier m.fl., 1997).

Partikelsystem används inom många olika områden (Bouvier m.fl., 1997) vilket visar på att studier på partikelsystem kan komma till nytta för många olika typer av tillämpningar. Ett område som partikelsystem ofta används inom är fysiksimulering i interaktiva applikationer med realtidsgrafik (Yeh m.fl., 2007). Denna typ av applikationer ställer krav på exekverings- prestanda eftersom fysikberäkningarna måste vara klara innan nästa bildruta ska ritas ut (Yeh m.fl., 2007).

Som tidigare nämnts finns det flera olika typer av tillämpningar för partikelsystem (Bouvier m.fl., 1997) och dessa tillämpningar kan ses som olika typer av konfigurationer av partikelsystem. Dessa konfigurationer anpassas efter vilken typ av applikation de skall användas till (Sims, 1990). Typen av applikation styr vilka möjliga parallelliseringsstrategier som finns (Erbad m.fl., 2011). Mycket parallelliseringsbara problem som t.ex. rendering med raytrace-tekniken är relativt oproblematiska att parallellisera men mer komplexa applikationer är svårare att parallellisera (Erbad m.fl., 2011). Alla partikelsystem har därför olika potentiella parallelliseringsstrategier beroende på vad som skall uppnås med det specifika partikelsystemet i den applikation där det ska tillämpas.

Web workers har också vissa inbyggda begränsningar, t.ex. i minnesdelning och

kommunikationshastighet (Erbad m.fl., 2011), vilka begränsar möjligheterna till

parallellisering. Det är även så att implementationen av Web worker API:et skiljer sig mellan

olika webbläsare och det finns inga garantier för hur många Web worker-trådar det är möjligt

att skapa. Helt beroende på tillämpning kan ett partikelsystem ha några få till flera tusen

partiklar (Sim, 1990). Av denna anledning, och även tidigare nämnda begränsningar som

sätts av applikationen som använder partikelsystemet, är den enklast tänkbara

10

parallelliseringsstrategin att låta varje partikel exekvera i en egen tråd inte alltid genomförbar. De för Web workers inbyggda begränsningarna, begränsningen i antalet tillgängliga trådar och de begränsningar applikationen sätter för parallelliserings- möjligheterna gör att det är icke-trivialt att identifiera och implementera möjliga parallelliseringsstrategier och avgöra hur dessa påverkar prestandan för en applikation.

Den frågeställning som detta arbete skall besvara är: Vilka prestandaeffekter ger olika

parallelliseringsstrategier implementerade med Web workers för fysiksimulering med

partikelsystem i applikationer med realtidsgrafik?

11

4 Metod

Detta arbete kommer att genomföras i form av ett experiment där en prototyp kommer att implementeras för varje parallelliseringsstrategi som ska testas. De prototyper som mätningarna skall ske med kommer att realisera en implementation av en interaktiv applikation med realtidsgrafik som bygger på ett partikelsystem med fysiksimulering.

Prestandamätningen syftar till att avgöra skillnaden i prestanda mellan olika parallelliseringsstrategier implementerade med hjälp av Web workers-teknologin. Som mätreferens kommer också en prototyp att implementeras som inte använder någon parallelliseringsstrategi. För att identifiera möjliga parallelliseringsstrategier för Web workers kommer även en litteraturstudie att genomföras.

Prestandamätningen kommer att ske på två olika aspekter, antal bilder renderade per sekund och algoritmhastighet. Renderingshastigheten är intressant eftersom denna kan ha påverkan på applikationens användbarhet i det avseendet att användaren gör färre fel och upplever applikationer med högre bildutritningshastighet som mer tillfredställande att använda (Claypool och Claypool, 2009). Det är också så att om renderingshastigheten är för låg blir interaktiva applikationer med realtidsgrafik oanvändbara (Claypool och Claypool, 2009).

Metoden används också utav Erbad m.fl. (2011) för att utvärdera deras Web worker-baserade implementation av en webbapplikation med realtidsgrafik. Mätning är också intressant med avseende på algoritmhastighet eftersom interaktiva applikationer med realtidsgrafik ställer krav på att alla beräkningar ska vara klara innan nästa bildruta ska ritas ut (Yeh m.fl., 2007).

Det här gör att tiden blir en begränsad resurs och om högre exekveringshastighet kan uppnås innebär det mer tid över till andra beräkningar eller mer avancerade beräkningar, t.ex. för att skapa mer realistiska fysiksimuleringar (Yeh m.fl., 2009).

Prestandamätningen kommer att ske med olika webbläsare där Web worker-teknologin finns tillgänglig. Detta eftersom prestandaskillnader kan finnas mellan olika webbläsare som t.ex.

visats av Erbad m.fl. (2011). Det finns flera olika webbplatser som publicerar mätningar av vilka webbläsare som är de mest använda, t.ex. http://gs.statcounter.com och http://marketshare.hitslink.com. Ingen av dessa har exakt samma resultat men de tre webbläsare som vanligen rapporteras som mest använda är Microsoft Internet Explorer, Google Chrome och Mozilla Firefox. Internet Explorer är den enskilt mest använda webbläsaren men saknar i sin nuvarande version stöd för Web workers. Detta kommer att förändras i och med Internet Explorer 10, men eftersom ingen färdig version av denna webbläsare finns tillgänglig kommer denna inte att inkluderas i mätningarna. Därför kommer prestandamätningar att ske med de vid mättillfället senaste tillgängliga versionerna av Google Chrome och Mozilla Firefox.

Prestandamätningar kommer också att genomföras med olika operativsystem för att kontrollera om det finns någon skillnad i prestanda vid olika parallelliseringsstrategier för olika operativsystem. Det mest använda operativsystemet är Windows 7, därför kommer detta att vara ett av de operativsystem som mätningar kommer att ske emot. Ett annat operativsystem som eventuellt skiljer sig från Windows 7 i parallelliseringsavseenden är Ubuntu 12.04 Desktop. Därför kommer mätningar även att ske med detta operativsystem.

Det är också så att prestandan kan påverkas av vilken hårdvara som finns tillgänglig. För att

kontrollera hur detta påverkar prestandan för olika parallelliseringsstrategier kommer också

mätningar att ske med både två och fyra processorkärnor tillgängliga. Syftet med att testa

med flera olika webbläsare och plattformar är att undvika att mätresultaten blir beroende av

en enskild webbläsarleverantör eller en viss typ av plattform.

12

För att prestandamätningar av den här typen ska bli upprepningsbara och därmed möjliga att kontrollera är det viktigt att alla premisser redovisas på ett tydligt sätt. Därför kommer det i samband med redovisningen av mätresultaten att anges exakt vilka versioner av webbläsare som har används, versioner av operativsystem och vilken hårdvara som användes för att genomföra varje mätning. På samma sätt som studien genomförd av Ratanaworabhan m.fl.

(2010), som syftade till att mäta exekveringsprestandan för JavaScript i olika webbapplikationer, kommer ett användningsscenario att skapas så att alla mätningar sker under snarlika förutsättningar. Detta för att göra resultaten jämförbara och upprepningsbara. Dessutom kommer varje sådan mätning att upprepas ett antal gånger för att säkerställa att mätresultatet är representativt.

Det finns flera olika typer av interaktiva applikationer med realtidsgrafik, en typ av webbapplikation som hör till denna kategori av applikationer är datorspel. I det här arbetet kommer en sådan applikation att implementeras som utvärderingsprototyp för de parallelliseringsstrategier som ska implementeras och testas. Detta eftersom datorspel är ett bra exempel på en prestandakrävande webbapplikation som därför är intressant att parallellisera för att vinna exekveringsprestanda men vars komplexitet gör applikationen icke-trivial att parallellisera (Erbad m.fl., 2011). Det finns flera olika exempel på datorspel som baseras på någon form av fysiksimulering som bygger på olika typer av partikelsystem.

Exempel på sådana spel är de som utvecklats av Muoz m.fl. (2009) och Agarwal och Saha

(2011) vilka syftar till att lära ut fysik respektive kemi. Andra exempel är ”World of Goo” (2D

Boy, 2008) och ”Cut the Rope” (ZeptoLab, 2010). Gemensamt för flera av dessa spel är också

att de använder sig av någon form av fjädringssystem mellan partiklar som en del av själva

spelmekaniken.

13

5 Genomförande

5.1 Pilotstudie

För att testa exekveringsprestandans förbättringspotential vid användandet av Web workers genomfördes en mindre pilotstudie. Testet mäter hur lång tid det tar att beräkna och rita ut en Mandelbrotfraktal för två olika upplösningar både med och utan Web workers. En Mandelbrotfraktal beräknas givet en upplösning som anger faktalens minsta enhet. I det här fallet blir då den minsta enheten en pixel. Fördelen med Mandelbrotfaktalen är att den är enkel att parallellisera eftersom varje pixel beräknas helt oberoende av alla andra pixlar vilket innebär att ingen data behöver delas mellan olika beräkningar. I det här testet användes en algoritm som tillät maximalt 100 iterationer per pixel. Antalet maximalt tillåtna iterationer styr fraktalberäkningens exakthet där ett högre antal maximala iterationer ger en större beräkningsexakthet. Figur 11 nedan visar den Mandelbrotfraktal som skapas av algoritmen.

Figur 11 Den Mandelbrotfraktal som genereras av algoritmen i pilotstudien.

Den plattform som användes för att genomföra pilotstudien var en Intel Q9450 processor på 2,67 GHz med fyra kärnor, 4 GB internminne och ett Windows 7 Professional 64-bitars operativsystem. Testet kördes på både Google Chrome 18 och Mozilla Firefox 11. Pilotstudien delades upp i två olika delar. Den ena delen jämför prestandaskillnaden mellan rendering av Mandelbrotfraktalen utan Web workers och med fyra Web workers i två olika upplösningar.

Varje mätning upprepades tio gånger och resultatet är ett medelvärde av dessa mätningar.

Resultatet återfinns i Tabell 1 nedan och visar på att för just denna tillämpning och för den i

testet använda plattformen ger användandet av Web workers en prestandaskillnad på mellan

46,0% till 69,2%. Testet visar också att den mer beräkningsintensiva upplösningen på

4320x3240 pixlar vinner mer i prestandaförbättring än den mindre beräkningsintensiva

upplösningen på 1024x768 pixlar.

14

Tabell 1 Den totala beräknings- och renderingstiden för genererandet av en Mandelbrotfraktal med och utan Web workers vid olika upplösningar för olika

webbläsare.

Google Chrome 18 Mozilla Firefox 11

Upplösning 1024x768 4320x3240 1024x768 4320x3240

Utan Web workers 348 ms 6788 ms 1194 ms 21131 ms

Med 4 Web workers 188 ms 2093 ms 566 ms 9615 ms

Skillnad 46,0% 69,2% 52,6% 54,5%

Den andra delen av pilotstudien syftade till att testa hur antalet Web workers påverkar prestandan. Resultatet av denna del av studien återfinns i Figur 12 nedan. Resultatet visar på att för just denna tillämpning och plattform så blir prestandaförbättringen inte automatiskt större bara för att antalet Web workers ökar. En möjlig anledning till detta är att antalet fysiska beräkningskärnor på testplattformens processor är begränsat till fyra stycken och att det därför inte ger så mycket mer prestanda om fler trådar används. En ytterligare faktor som kan påverka resultatet skulle kunna vara att fler trådar skapar större overhead för den data som skickas till och från Web worker-trådarna. Detta då samma data delas in i mindre delar men också för den tid det tar att växla in och växla ut trådar i schemaläggningsprocessen för datorns processor. Som också kan ses i Figur 12 nedan är mätresultatet inte helt entydigt, t.ex. ger nio Web workers sämre resultat än åtta eller tio Web workers. Detta beror antagligen endast på osäkerhet i mätningarna som orsakas av att dessa upprepades relativt få gånger.

Figur 12 Den totala beräknings- och renderingstiden för genererandet av en Mandelbrotfraktal med upplösningen 1024x768 vid användandet av olika antal Web

workers.

Pilotstudien visar att det finns möjligheter att uppnå förbättrad exekveringsprestanda med hjälp av Web workers. Att parallelliserera Mandelbrotfraktalsberäkningar är, som nämnts tidigare enkelt, men det finns ändå flera olika möjliga parallelliseringsstrategier. En sådan strategi är att schemalägga varje pixels beräkning på ett fast antal Web workers vilka sedan schemaläggs med pixelberäkningar där varje pixel beräknas var för sig. En annan variant är att dela upp Mandelbrotfraktalen i lika många delar som antalet tillgängliga Web workers där alla delar så långt som det är möjligt är lika stora. Varje Web worker tilldelas därefter en sådan del för vilken den sedan genomför samtliga beräkningar. I pilotstudien användes det senare alternativet.

0 200 400 600 800 1000 1200 1400

0 1 2 3 4 5 6 7 8 9 10 11 12

ms

Antal Web workers

Google Chrome 18 Mozilla Firefox 11

15

5.2 Implementation av fysiksimulator

I mer komplicerade applikationer, som t.ex. interaktiva applikationer med realtidsgrafik, kan det vara svårare att dela upp beräkningsprocesser för att uppnå parallelliseringsbarhet (Erbad m.fl., 2011). För att kunna testa olika parallelliseringsstrategier utvecklades därför en sådan applikation som bygger på fysiksimulering med ett partikelsystem. Fysiksimulering valdes eftersom partikelsystem är väl lämpade för denna typ av simulering och kan användas inom flera olika tillämpningsområden (Bouvier m.fl., 1997).

Varje partikel i partikelsystemet har en uppsättning attribut. Bland dessa återfinns dess nuvarande position angivet i x- och y-koordinater, den position partikeln innehade innan den senaste fysiksimuleringen och accelerationskrafter i x- och y-led som påverkar partikeln, som t.ex. gravitationskraften. Partikelsystemets fysiksimulering bygger på Verlet-metoden som är både beräkningseffektiv och exakt (Jiang och Liu, 2008). Det finns som tidigare nämnts flera olika varianter på denna metod men för detta arbete har den variant implementerats som redogjorts för av Jakobsen (2001). Koden som implementerar metoden kan ses nedan i Figur 13 där

betecknar en specifik partikel och

är det ∆t som valts:

//Store current x- and y-positions var tempX=this.x;

var tempY=this.y;

var dragModifier=1.0; //Set lower to implement air friction //Verlet calculations:

this.x+=dragModifier*this.x-dragModifier*this.px+this.ax*dt*dt;

this.y+=dragModifier*this.y-dragModifier*this.py+this.ay*dt*dt;

//Stored x- and y-positions are stored as previous x- and y-positions this.px=tempX;

this.py=tempY;

Figur 13 Verlet-integrationsalgoritmen.

Applikationen tillämpar även den algoritm som Jakobsen (2001) använder för att binda samman partiklar med fjädrar. För detta arbete har algoritmen implementerats på så vis att varje partikel har en array med partiklar som den är kopplad till samt en motsvarande array som definierar vilket avstånd partiklarna ska hålla till varandra. För varje partikel kopplad till en specifik partikel beräknas det relativa avståndet mellan partiklarna och utifrån detta avstånd justeras båda partiklarnas positioner i förhållande till det önskade avståndet. Koden för denna algoritm kan ses nedan i Figur 14 där

är en specifik partikel och arrayen

innehåller alla partiklar denna är kopplad till och arrayen

innehåller det motsvarande önskade avståndet mellan partiklarna:

for(var i=0;i<this.connectedTo.length;i++){

var restLength=this.restLength[i];

var deltaX=this.connectedTo[i].x-this.x;

var deltaY=this.connectedTo[i].y-this.y;

var deltaLength=Math.sqrt(deltaX*deltaX+deltaY*deltaY);

var diff=(deltaLength-restLength)/deltaLength;

this.x+=deltaX*0.5*diff;

this.y+=deltaY*0.5*diff;

this.connectedTo[i].x-=deltaX*0.5*diff;

this.connectedTo[i].y-=deltaY*0.5*diff;

}

Figur 14 Fjäderberäkningsalgoritmen.

16

En iteration av denna algoritm garanterar inte att avståndet blir det önskade men skillnaden mellan nuvarande avstånd och önskat avstånd minskar. Valet av antal iterationer är beroende av vilket slutresultat som önskas för partikelsystemets beteende. Om t.ex. ett rep eller liknande ska simuleras gör fler iterationer att repet blir styvare och färre gör repet mer elastiskt. Det är också så att ett rep med flera partiklar behöver fler iterationer för att uppnå samma styvhet som ett rep med färre partiklar. Detta innebär att en avvägning måste göras för hur långt avståndet mellan varje partikel i ett rep ska vara. Fler partiklar och kortare avstånd dem emellan ger jämnare rep där repets brytpunkter blir mindre synliga men kräver fler iterationer för att uppnå önskad styvhet. Rep med färre partiklar men större avstånd dem emellan för att uppnå samma längd på repet kräver färre iterationer för att uppnå önskat beteende men ger i gengäld ett rep med tydligare brytpunkter mellan repets delar. Viktigt att notera är också att varje iteration måste omfatta samtliga sammanlänkade partiklar i hela partikelsystemet annars kommer överkottsenergi att skapas på grund av växande skillnader mellan partiklars tidigare positioner och nya positioner. Överskottsenergin fortplantas genom alla sammanlänkade partiklar och leder till instabilitet i partikelsystemet.

Kombinationen av partiklar och fjädrar mellan dessa gör att representationer för i princip vilket objekt som helst kan modelleras under förutsättningen att objektets minsta diskreta del kan representeras av en partikel. Objektets detaljrikedom bestäms av antalet partiklar och fjädrarna binder samman partiklarna för att ge objektet dess form. Exempel på några enklare konstruktioner som kan skapas med den implementerade fysiksimulatorn kan ses i Figur 15 nedan.

Figur 15 Exempel på olika objekt modellerade med partiklar och fjädrar mellan dessa. Svarta prickar representerar partiklar, röda linjer är fjäderkopplingar mellan dessa och svarta prickar med blå kant är partiklar som inte påverkas av yttre krafter.

Fysiksimuleringen baseras på två huvudloopar där den ena loopen genomför fysik-

beräkningar för partikelsystemet samt kontrollerar om simuleringen ska startas om eller om

nästa simuleringsinstans ska initieras och den andra loopen ritar ut partiklarna i ett canvas-

element. En visualisering av fysiksimulatorns generella uppbyggnad kan ses i Figur 16 nedan.

17

Initiering

Sätt krafter för alla partiklar

Kör Verlet- beräkningar för alla

partiklar

Genomför fjäder- beräkningar för alla

partiklar Alla partiklar uppdaterade?

Alla partiklar uppdaterade?

Alla partiklar uppdaterade?

Rita ut alla partiklar och kopplingar

mellan dessa

resetSimulation==true?

Starta utdimmnings- effekten

fadeAlpha==0?

Nej

Ja

Ja Nej

Nej

Nej

Ja

Kontrollera om simuleringen ska

startas om eller nästa instans ska

initieras Ja

Nej

Nej

Ja

Är det upphängda objektet kvar i simuleringsvärlden?

Är det upphängda objektet i målpositionen?

resetSimulation=true

resetSimulation=true simulationInstance++

Nej

Ja

Ja

Figur 16 Den generella uppbyggnaden av fysiksimulatorn.

5.2.1 Tillämpningsapplikation

Som tillämpning för fysiksimulatorn har ett enklare datorspel implementeras vilket är en typ

av interaktiv applikation med realtidsgrafik. Det spel som har implementerats är en variant

av spelet ”Cut the Rope” (ZeptoLab, 2010) som finns både till mobila plattformar och i en

webbläsarbaserad version. Denna typ av datorspel valdes därför att dess mekanik baseras på

fysiksimulering. Simuleringen kan implementeras med hjälp av ett partikelsystem där

partiklar både kan försvinna och tillkomma. Dessutom är ett sådant spel ett exempel på en

applikation som ställer krav på realtidsprestanda och interaktivitet. Den fullständiga

källkoden för applikationen återfinns i appendix A.

18

Grundidén går ut på att ett föremål upphängt i ett eller flera rep ska föras till en målposition genom att dessa rep klipps av i rätt ordning vid rätt tidpunkt. De rep som återfinns i applikationen implementeras med hjälp av ett partikelsystem där varje rep består av flera partiklar sammanbundna av fjädrar. Partiklar kan både försvinna ur systemet då rep klipps av och tillkomma i systemet då rep läggs till. Det senare sker om det upphängda föremålet kommer tillräckligt nära ett speciellt spelelement som kopplar ett nytt rep till föremålet. Ett exempel på hur den färdiga tillämpningsapplikationen ser ut kan ses i Figur 17 nedan.

Figur 17 Exempel på hur den implementerade applikationen ser ut.

För att klippa av ett rep görs en svepande ”klick-och-drag” rörelse över det rep som ska klippas av. En sådan avklippning kan ses i Figur 17 ovan. Algoritmen som kontrollerar om ett rep har kapats baseras på om två linjer korsar varandra där den ena linjen är den som skapas av sveprörelsen och den andra linjen är den som finns mellan två partiklar i ett rep. För sveprörelsen sparas en array av punkter. Detta för att skapa flera linjer mellan dessa punkter vilka samtliga kontrolleras mot alla linjer som finns mellan samtliga reps partiklar.

Anledningen till att flera punkter sparas i sveprörelsen är att repen ska klippas så nära den punkt där muspekaren faktiskt passerar repet och inte på den punkt som ligger mellan sveprörelsens startpunkt och dess slutpunkt. Detta i fall sveprörelsen inte är exakt vågrät eller lodrät, t.ex. om spelaren gör sveprörelsen i en båge. Det är också så att det inte räcker att kontrollera mot muspekarens nuvarande position eftersom spelaren kan flytta muspekaren snabbare än vad spelets kontrollmekanism hinner registrera muspositioner, vilket kan innebära att en rep-avklippning inte registreras. Algoritmen som kontrollerar om de två linjerna korsas testar först om linjerna är parallella med varandra, om de inte är det så görs en kontroll för att avgöra om någon del av linjerna befinner sig på varandra.

För att möjligöra framtida mätningar med applikationen på olika typer av mobila plattformar, vilka kanske använder touch-teknik för att registrera indata från användaren i stället för en mus eller liknande inmatningsteknik, så implementerades även stöd för detta.

Touch-implementationen använder de händelseregistreringsmöjligheter som finns för denna

19

teknik i HTML5. Båda typerna av input accepteras av samma applikation och kan, om plattformen så tillåter, användas oberoende av varandra. Touch-implementationen anropar samma funktioner och algoritmer som den musbaserade inmatningsmetoden.

5.3 Parallellisering

För att identifiera vilka typer av strategier som skulle kunna var tillämpliga för Web workers i interaktiva applikationer med fysiksimulerad realtidsgrafik baserad på partikelsystem genomfördes en mindre litteraturstudie. Studien genomfördes genom en sökning på artiklar inom ämnet i flera olika artikeldatabaser. Eftersom det finns många olika parallelliserings- strategier måste ett urval bland dessa göras. De kriterier som användes vid identifierandet av för problemområdet tillämpliga parallelliseringsstrategier var att dessa har använts i en vetenskaplig studie som berör parallellisering av JavaScript, partikelsystem och/eller fysiksimulering.

Dessa kriteriet applicerade på litteraturstudien gav fyra olika parallelliseringsstrategier. Den första berör parallellisering av partikelsystem där varje partikel kan ses som en egen enhet och exekveras i en egen tråd (Sims, 1990). Den andra innebär parallellisering av JavaScript- funktioner så att flera funktionsanrop kan köras parallellt (Fortuna m.fl., 2010). Den tredje parallelliseringsstrategin delar upp fysiksimuleringen i flera av varandra oberoende delar så att simuleringen kan exekveras i olika trådar (Bouvier m.fl., 1997) och den fjärde parallelliseringsstrategin delar upp applikationen för fysiksimuleringen i olika av varandra oberoende delar så att varje del kan köras parallellt (Hughes m.fl., 2007). Denna litteraturstudie kan inte sägas vara helt uttömmande då det är troligt att det finns fler parallelliseringsstrategier än dessa som uppfyller de uppsatta kriterierna. Dock måste urvalet begränsas eftersom en studie av samtliga möjliga parallelliseringsstrategier skulle bli allt för omfattande för att kunna innefattas av detta arbetes tidsramar. Nedan följer en genomgång av implementationsgenomförandet av de identifierade parallelliseringsstrategierna.

5.3.1 En Web worker för varje partikel

En möjlig strategi för att parallellisera ett partikelsystem är att exekvera varje partikel i en egen exekveringstråd (Sims, 1990). Ett problem med denna strategi är att ingen av webbläsarna Chrome 18 eller Firefox 12 kan initiera tillräckligt många Web workers. Firefox slutar initiera nya Web workers efter att den 20:e Web workern startats och Chrome blev instabilt och kraschade om fler än mellan 40-45 Web workers initierades, resultaten varierade vid olika provkörningar. Fysiksimuleringen använder i det enklaste av simuleringsfallen som implementerats 31 partiklar och där används endast ett rep-objekt, övriga simuleringsfall använder fler partiklar. Detta innebär att varken 20 eller 45 Web workers räcker till om alla partiklar ska kunna köras i en tråd var. Denna strategi är under dessa förutsättningar omöjlig att genomföra.

5.3.2 En Web worker för varje partikels funktionsanrop

En variant på ovanstående strategi är att parallellisera partiklarnas anrop av fysikberäknings-

funktionerna (Fortuna m.fl., 2010) där ett fast antal Web workers tar hand om beräkningarna

för samtliga partiklar där partiklarnas fysikberäkningar exekveras en efter en på första lediga

Web worker-tråd tills alla partiklars fysikberäkningar genomförts. Implementationen av

denna strategi för att parallellisera funktionsanropen för Verlet-beräkningarna kunde

genomföras utan problem. Men för att kunna genomföra samma strategi för att parallellisera

funktionsanropen för fjäderberäkningarna är det nödvändigt att modifiera fjäderberäknings-

algoritmen.

20

Detta beror på att till skillnad mot Verlet-beräkningarna där varje partikel kan beräknas helt oberoende av andra partiklar och därför kan ske i vilken ordning som helst så är fjäderberäkningarna beroende av andra partiklar. En partikels fjäderberäkningar kan inte genomföras utan att fjäderberäkningarna för den partikel vilken den är kopplad till har genomförts. Det här betyder att ordningen partiklarnas beräkningar exekveras i har betydelse för beräkningarnas resultat. Med andra ord innebär detta beroende att fjäderberäkningarna måste ske sekventiellt.

För att bryta detta beroende, och på så vis uppnå parallelliseringsbarhet, genomfördes varje partikels fjäderberäkningar med positionsdata från föregående fysiksimuleringsloop för de partiklar som partikeln under beräkning är kopplad till. Resultatet av en fjäderberäkning är det relativa avståndet den aktuella partikeln ska flyttas utifrån sin nuvarande position baserat på avståndet till de partiklar denna är kopplad till. Dessutom resulterar en fjäderberäkning i hur mycket de kopplade partiklarna ska flyttas relativt avståndet till denna partikel. Detta innebär att beräkningen inte ger ett korrekt resultat för de kopplade partiklarnas egentliga positioner men om fjäderberäkningarna itereras flera gånger utjämnas skillnaden mellan det korrekta resultatet och beräkningens approximation. Detta problem fanns inte för det partikelsystem implementerat av Sims (1990) där varje partikel exekverar i en egen exekveringstråd eftersom dessa partiklar inte hade några beroenden till andra partiklar (Bouvier m.fl., 1997). Ett möjligt problem med denna strategi för parallellisering är att data måste skickas både till och från en Web worker-tråd för varje partikel i partikelsystemet. Att skicka data till och från Web worker-trådar tar tid vilket skulle kunna förlänga exekveringstiden för fysiksimuleringsloopen (Erbad m.fl., 2011). Källkoden för denna parallelliseringsstrategi återfinns i appendix B.

5.3.3 En Web worker för varje rep-objekt

En annan parallelliseringsstrategi är att dela upp simuleringsvärlden i ett antal av varandra oberoende delar för vilka fysiksimuleringen sker parallellt (Bouvier m.fl., 1997). Ett sätt att genomföra denna parallelliseringsstrategi är att dela upp fysiksimuleringen per rep-objekt som ska simuleras. Detta har fördelen att färre meddelanden med data måste skickas per iteration för fysiksimuleringsloopen. Därmed blir det möjligen också mindre data totalt som ska skickas, vilket i sådant fall sparar exekveringstid (Erbad m.fl., 2011). Fysiksimuleringen som ska parallelliseras hanterar som mest fem olika rep-objekt samtidigt. För att utnyttja detta, och på så vis även minska mängden data som måste skickas till varje Web worker-tråd för varje iteration av fysiksimuleringsloopen, så implementerades denna parallelliserings- strategi med en Web worker-tråd för varje rep-objekt. Om ett rep-objekt läggs till så skapas en ny Web worker-tråd. En nackdel med denna parallelliseringsstrategi är att om fysiksimuleringen ska fungera för t.ex. Firefox 12 så får simuleringen inte utnyttja fler än 20 olika rep-objekt.

Ett problem med att implementera denna strategi är att varje rep inte är helt oberoende av de andra repen i fysiksimuleringen. Detta eftersom alla rep är kopplade till den partikel som representerar det föremål som är upphängt i repen och som ska föras till målpositionen.

Problemet är det samma för denna partikel vid fjäderberäkningarna som när

fjäderberäkningarna för parallelliseringsstrategin att exekvera varje partikels funktionsanrop

i en egen Web worker-tråd används. Däremot finns endast detta problem för just denna

partikel i den här parallelliseringsstrategin. Fjäderberäkningarna för övriga partiklar i

partikelsystemet kan ske precis som i den icke-parallelliserade implementationen. Samtliga

Web worker-objekt kommer alltså att använda samma positionsdata för den upphängda

21

partikeln när fjäderberäkningarna sker och kommer därför inte att kunna ta hänsyn till de förändringar andra rep-objekts fjäderberäkningar har på denna partikels position. Det här leder till att beräkningarna inte kan bli exakta, vilket innebär att allt för stora förflyttningar sker på den upphängda partikelns position. Detta innebär också att problemet växer om antalet rep-objekt som är kopplade till den upphängda partikeln ökar. Resultatet blir att överskottsenergi lagras i den upphängda partikeln och denna överskottsenergi fortplantas genom samtliga partiklar kopplade till denna. För att motverka detta problem har en dämpningsmekanism införts som minskar den relativa förflyttning som fjäderberäkningarna resulterar i med en faktor som ökar med antalet rep-objekt kopplade till den upphängda partikeln.

En möjlig fördel med denna strategi är eventuellt att mindre data skickas till och från Web worker-trådarna. Anledningen till att mindre data skickas är att det för varje uppdatering endast skickas ett medelande om att repet ska uppdateras. Den enda data som då behöver skickas med är positionen för den partikel som alla rep är kopplade till, all annan data finns redan i Web worker-tråden. Däremot måste fortfarande positionsdata för rep-objektets alla partiklar skickas tillbaka när fysikberäkningarna är genomförda så att repet kan ritas ut på dess nya position. Källkoden för denna implementation av applikationen finns i sin helhet i appendix C.

5.3.4 En Web worker för fysiksimuleringsloopen

Ytterliggare en parallelliseringsstrategi är att dela upp applikationen i olika moduler där en eller flera moduler kan flyttas ut till egna exekveringstrådar (Hughes m.fl., 2007). För den här tillämpningen skulle då en variant på denna strategi vara att dela upp applikationen i en del för fysikberäkningar och en annan del för utritning med en exekveringstråd för varje del.

Eftersom utritningen måste ha tillgång till webbplatsens DOM och Web workers inte har tillgång till denna så implementerades utritningen i huvudtråden och fysikberäkningsdelen flyttades ut till en Web worker-tråd. Denna Web worker-tråd har då samtliga partiklar och deras relationer till varandra lagrade och uppdaterar både Verlet-beräkningar och fjäderberäkningarna för dessa på kommando från huvudtråden. När fysikberäkningstråden svarar med de uppdaterade positionerna för partiklarna genomförs samma kontroller som i övriga versioner, t.ex. för att avgöra om nya rep-objekt ska läggas till eller tas bort. Om någon förändring sker skickas ett meddelande till Web worker-tråden som hanterar fysikberäkningarna så att denna kan lägga till eller ta bort angivet rep-objekt. Därefter börjar iterationen om med att ett uppdateringskommando skickas till fysikberäkningstråden.

Utritning sker kontinuerligt och helt oberoende av när fysikberäkningarna uppdateras.

En eventuell nackdel med denna parallelliseringsstrategi är att endast en extra tråd används och att det därför är möjligt att parallelliseringen inte utnyttjar eventuell prestandaförbättringspotential för plattformar med mer än två beräkningsenheter.

Parallelliseringsgraden blir därför låg. En fördel med strategin skulle kunna vara att den inte

har samma problem med avsaknaden av delat minne som övriga strategier eftersom färre

meddelanden måste skickas mellan exekveringstrådarna. Dock är avsaknaden av delat minne

fortfarande ett problem eftersom data fortfarande måste skickas till och från Web worker-

tråden, t.ex. resultatet av fysikberäkningarna. I appendix D hittas källkoden som

implementerar denna parallelliseringsstrategi.

22

5.4 Prestandamätningsimplementation

För att mäta prestandan för en implementation räknas antalet gånger fysiksimuleringsloopen

och utritningsloopen har exekverats under en hel spelomgång. En spelomgång räknas från

det att spelet startar till dess att spelaren har spelat igenom samtliga spelnivåer. Därefter

delas antalet iterationer utritningsloopen exekverats med tiden det tog för spelaren att

genomföra en spelomgång för att räkna ut den genomsnittliga bildutritningshastigheten i

bilder per sekund. För att mäta den genomsnittliga tiden som krävts för att genomföra en

uppdatering av fysiksimuleringen så delas tiden för en spelomgång med antalet

fysikloopsiterationer. Dessutom lagras alla uppdateringstider för både utritningsloopen och

fysikberäkningsloopen så att det är möjligt att hitta medianvärden samt lägsta- och

högstavärden.

23

6 Analys

För att utvärdera de olika parallelliseringsstrategiernas prestanda mättes både renderingshastigheten i antalet bilder per sekund och den tid det tar för fysiksimuleringsloopen att genomföra en hel iteration. Varje sådan fysiksimuleringsiteration omfattar samtliga Verlet-beräkningar och en eller flera iterationer av fjäderberäkningar för samtliga partiklar. De värden som mättes för renderingshastigheten var dels högsta och lägsta uppmätta renderingshastighet, medianen för renderingshastigheten och medelhastigheten för renderingen där ett högre värde visar på bättre prestanda. För fysikuppdateringshastigheten mättes motsvarande värden för snabbaste och långsammaste uppdateringshastighet, median uppdateringshastigheten samt medelhastighet för fysikuppdateringen där ett lägre värde visar på bättre prestanda. Varje mätresultat baseras på 100 mätningar, om inte annat anges nedan, från vilka ett medelvärde beräknats. En mätning består av en genomkörning av applikationen. Eftersom resultatet från en mätning kan variera beroende på vilken användarinput som ges har varje genomkörning följt ett förutbestämt mönster där repen klipps av i samma ordning vid varje genomkörning. Om en genomkörning på något sätt avviker från detta mönster, t.ex. om en spelnivå misslyckas, så har denna data inte använts för det totala mätresultatet. Eftersom två av parallelliseringsstrategierna kräver att fjäderberäkningarna itereras flera gånger för att fungera använder samtliga implementationer av applikationen sex iterationer för fjäderberäkningarna.

Mätning har skett med två olika operativsystem, både 64-bitars versionen av Windows 7 Professional och 64-bitars versionen av Ubuntu 12.04 Desktop. Mätning har också skett med webbläsarna Chrome 18 och Firefox 12. Dessutom har mätning skett med både två och fyra processor kärnor. Samtliga testkonfigurationer som använts vid mätningarna återfinns i Tabell 2 nedan.

Tabell 2 De olika testkonfigurationerna för prestandamätningarna.

Testkonfiguration Webbläsare Operativsystem Antal processorkärnor

1 Chrome 18 Windows 7 4

2 Firefox 12 Windows 7 4

3 Firefox 12 Windows 7 2

4 Firefox 12 Ubuntu 12.04 4

Den hårdvara som använts vid mätningarna är en Intel Q9450 processor på 2,67 GHz med fyra processorkärnor där två av dessa avaktiverats vid mätningarna med två processorkärnor samt 4 GB DDR2 RAM monterade på ett Gigabyte GA-X45-DS5 moderkort tillsammans med ett Nvidia 9600GT grafikkort. Nedan följer en presentation och analys av resultaten från dessa mätningar samt en jämförande analys av skillnaderna i prestanda mellan de olika parallelliseringsstrategierna.

6.1 Referensmätning utan Web workers

Likt Erbad m.fl. (2011) så genomfördes först mätningar med en implementation av

applikationen som realiserats helt utan användandet av Web workers. Syftet med detta är att

kunna använda resultaten från dessa mätningar som en referenspunkt för mätningarna med

24

de olika parallelliseringsstrategierna. I Figur 18 och Figur 19 nedan återfinns resultaten av dessa mätningar. Samtliga mätresultat kan ses i appendix E.

Figur 18 Renderingshastighet utan Web workers.

Som kan ses i Figur 18 ovan så ger Firefox på Windows med två processorkärnor högst medelrenderingshastighet, men skillnaden mot samma konfiguration med fyra processorkärnor är endast 0,4 bilder per sekund. Det kan därför antas att skillnaden endast beror på osäkerhet i mätresultaten. Medelrenderingshastigheten i testkonfigurationen med Ubuntu är dock 15,8% lägre än testkonfigurationen med Firefox i Windows med fyra processorkärnor. Detta beror möjligen på att de olika operativsystemen använder olika drivrutiner för grafikkortet men kan även visa på skillnader mellan de olika implementationerna av Firefox för de olika operativsystemen. Mätresultaten visar också att Firefox med fyra processorkärnor i Windows har en 7,6% högre renderingshastighet än test- konfigurationen med Chrome.

Högsta Lägsta Medelvärde Median

Chrome 18 Windows 7 4 kärnor

115,6 70,4 98,6 105,1

Firefox 12 Windows 7

4 kärnor

133,3 75,0 106,1 114,7

Firefox 12 Windows 7

2 kärnor

134,4 76,6 106,5 114,8

Firefox 12 Ubuntu 12.04

4 kärnor

105,6 63,2 89,3 97,3

0 50 100 150 200 250

Bilder per sekund

25

Figur 19 Fysiksimuleringshastighet utan Web workers.

Mätresultaten för fysikuppdateringshastigheten som kan ses i Figur 19 ovan visar att Firefox på Windows 7 med fyra kärnor har en medeluppdateringshastighet som är 41,9% bättre än Chrome med motsvarande mjuk- och hårdvarukonfiguration. Återigen är antagligen skillnaden mellan två och fyra kärnor försumbar. Medeluppdateringshastigheten i Firefox på Windows kontra Ubuntu är 20,7% snabbare på Windows, dock är den långsammaste uppmätta uppdateringen på Ubuntu 43,3% snabbare än den långsamaste uppdateringen för Windows.

6.2 En Web worker för varje partikels funktionsanrop

För parallelliseringsstrategin att använda en Web worker för varje partikels funktionsanrop gjordes ytterligare mätningar. Dessa mätningar syftar till att kontrollera i vilken utsträckning antalet Web workers som används för parallelliseringsstrategin påverkar prestandan. Dessa mätningar genomfördes med Windows 7 med Firefox 12 och fyra processorkärnor. Samma hårdvara som i övriga mätningar användes. Dock har dessa mätningar på grund av begränsade tidsresurser endast upprepats 30 gånger per antal Web workers vilket gör mätresultaten något osäkra. Mätningar skedde med upp till och med 20 Web workers då detta är det maximala antalet Web workers som kan initieras av Firefox 12. Resultaten av dessa mätningar kan ses i Figur 20 och Figur 21 nedan. Samtliga mätresultat återfinns i appendix F.

Snabbaste Långsammaste Medelvärde Median Chrome 18

Windows 7 4 kärnor

0,26 115,99 8,33 5

Firefox 12 Windows 7

4 kärnor

0,01 52,79 4,84 4

Firefox 12 Windows 7

2 kärnor

0,00 61,03 5,08 4,05

Firefox 12 Ubuntu 12.04

4 kärnor

1,21 29,97 6,10 5,89

0 50 100 150 200 250 300 350 400

ms