Radiosity på CELL. Bachelorprojektnr.: 23. Dato for aflevering: Student: Lars Frydendal Bonnichsen (s062424) Vejleder: Sven Karlsson

Transkript

1 Radiosity på CELL Bachelorprojektnr.: 23 Dato for aflevering: Student: Lars Frydendal Bonnichsen (s062424) Vejleder: Sven Karlsson

2 Indholdsfortegnelse 1 Abstrakt Introdution Teori Måleenheder Om brug af pseudokode Radiosity Hardware termer Cell Programmøren og Cell Generelt Hukommelsesoverførsler Radiosity på Cell Kode basen Grundlæggende Typedefinitioner Beskrivelse af programmet Bestemmelse af flaskehals Originale køretider for tasks Forbedring af flaskehals Evaluering Implementering Om Visibility Tasks PPE-SPE protokol Protokollens formål Protokollens udformning SPE siden af protokollen PPE siden af protokollen Generelle problemstillinger Portering af PPE kode til SPE kode Hukommelses adgang fra SPE Kompatibilitet med eksisterende kode Race conditions ved oprettelse af visibility Tasks Floating point præcision på SPE'er Optimering af SPE kode Reduktion af hukommelsesforbrug Optimering af cachen SIMD operationer Målinger Mulige forbedringer på synkronisering og datatilgang Cooperative multitasking på SPE Forbedringer af protokollen Udlicitering af visibility Tasks Mulige forbedringer af visibility Tasks køretid Branch hints Vektoriseret BSP traversal Portering af vektoriseret kode fra SPE til PPE Konklusion Acknowledgements Referencer...48 Lars Frydendal Bonnichsen (s062424) 2

3 1 Abstrakt Radiosity er en form for global illumination, som kan simulere indirekte diffus refleksion, men ikke tager hensyn til spekulær refleksion. Radiosity algoritmer har typisk behov for at opdele geometrien i scenen den behandler i flere dele, således at forskellige dele af objekter kan belyses forskelligt. Der findes algoritmer der opdeler geometrien inden refleksionerne bearbejdes, og algoritmer der opdeler geometrien på basis af refleksionerne. I denne rapport gennemgår jeg hvorledes en radiosity algoritme som opdeler geometrien på basis af refleksionerne kan optimeres til at udføres på en Cell processor. Cell processoren indeholder en generel kerne kaldet PPE, og et otte mere primitive kerner, kaldet SPE'er. Ved at flytte de dele af koden der tog mest beregningstid over på SPE, var jeg i stand til at gøre algoritmen ca. dobbelt så hurtigt som SPLASH2 benchmark implementeringen af algoritmen, for en scene der indeholder 514 trekanter, på en PlayStation 3 med 6 SPE'er tilgængelige. Nøgleord: Radiosity, Gathering, Cell, SPE, protokol. Lars Frydendal Bonnichsen (s062424) 3

4 2 Introdution Global illumination er et udtryk der beskriver rendering af scener, hvor der betragtes indirekte belysning. Renderings algoritmer der benytter global illumination, er typisk i stand til at genskabe scener mere realistisk end algoritmer der kun betragter direkte belysning. De fleste algoritmer der benytter global illumination har dog også det problem, at de tager lang tid at udføre, selv på moderne processorer. Derfor benyttes global illumination sjældent i realtidsgrafik, selvom der de sidste år har været forsøg på at approksimere global illumination, med algoritmer der er mindre korrekte, men meget hurtigere, såsom screen space ambient occlusion[blsm1] og instant radiosity[keller1]. I modsætning bruges global illumination hyppigt i computeranimerede film, hvor det er acceptabelt at et enkelt billede tager timer at rendere. Radiosity er en form for global illumination, som dækker over en række algoritmer, der bruges til at beregne refleksioner imellem diffuse overflader, kaldet interdiffuse refleksioner[siggraph1]. Diffuse overflader udsender lige meget lys i alle retninger, så udregningerne vil kunne genanvendes til at betragte en scene fra forskellige vinkler, så længe overfladerne og lyskilderne ikke bevæger sig. Derfor bruges resultaterne fra radiosity beregninger nogle gange til at forbedre kvaliteten af realtidsgrafik, med et minimalt brug af resurser. En potentiel anvendelse af radiosity er indenfor arkitektur, til at simulere hvorledes lys reflekteres i boliger, så der tages højde for hvordan refleksion fra vægge belyser andre vægge. Radiosity bruges dog sjældent til andet end computeranimerede film og forudberegning af lysforhold i spil, da nuværende algoritmer tager meget lang tid at udføre i høj kvalitet for kompleks geometri[silion1]. Der findes mange varianter og implementeringer af radiosity algoritmer, men jeg har endnu ikke set nogle radiosity algoritmer der er udviklet til at udnytte Cell processoren. Cell processoren har en størstedelen af dens regnekraft i form af nogle relativt enkle kerner kaldet SPE'er, som ikke kan tilgå den globale hukommelse på samme måde som almindelige processorer, men skal påbegynde eksplicitte hukommelsesoverførsler. Pga. de eksplicitte hukommelsesoverførsler, kan SPE'erne ikke udføre den samme kode som typiske processorer, og det er derfor nødvendigt at implementere algoritmer der tager hensyn til dette. Formålet med denne rapport er at portere en radiosity algoritme til at kunne benytte Cell processorens SPE'er, for at forbedre køretiden af algoritmen. Jeg porterer fra radiosity algoritmen der er bruges i SPLASH-2 (Stanford Parallel Applications for Shared Memory) benchmarksuiten, som antager en delt hukommelses model. SPE'erne bliver håndteret af en mere generel kerne, som håndterer en task kø for SPE'erne. For at holde opgaven enkel, udfører SPE'erne kun den type tasks som tager mest regnekraft at udføre. For at kunne udføre de tasks på SPE'erne, har jeg isoleret steder i koden hvor indhold fra den Lars Frydendal Bonnichsen (s062424) 4

5 globale hukommelse tilgås, erstattet koden tilgangen med en en protokol og en cache, som indlæser dele af den globale hukommelsen når det er nødvendigt. For at udnytte SPE'erne effektivt, laver jeg en række optimeringer, som er mere eller mindre specifikke til Cell processoren. Optimeringerne inkluderer brug af multibuffering, fokus på lav latens i protokollen og brug af SIMD operationer. Det lykkes mig at få algoritmen til at bearbejde et datasæt der indeholder 514 tekanter dobbelt så hurtigt når den bruger SPE'erne, i forhold til når den ikke gør. Det burde være muligt at forbedre køretiden yderligere, ved bl.a. at benytte cooperative multitasking på SPE'erne, benytte branch hints og fokusere mere på hvor store opgaver skal være, før det kan betale sig at SPE'erne udfører dem. Derudover tyder de måledata jeg har på at der større forbedringer for rendering af store scener, end for små. Resten af rapporten er inddelt således: I afsnit 3 kommer jeg ind på baggrundstoffet, der er nødvendigt for at bearbejde emnet. Baggrundstoffet er primært relateret til hvordan forskellige radiosity algoritmer fungerer, hvordan Cell processorens arkitektur fungerer og hvordan SPLASH2 radiosity algoritmen er implementeret. Jeg analyserer flaskehalsen i afsnit 4 i den oprindelige algoritme, så jeg i afsnit 5 kan præsentere min tidsplan for at arbejde denne opgave, og evaluerer hvor realistisk den har været. Afsnit 6 indeholder beskrivelsen af den iterative udviklingsproces der er forbundet med portering af koden. I afsnit 7 sammenligner jeg køretiden af det endelige program med det oprindelige, og beskriver en række mulige forbedringer af den endelige algoritme. Rapporten afsluttes med en konklusion i afsnit 8. Lars Frydendal Bonnichsen (s062424) 5

6 3 Teori 3.1 Måleenheder Jeg benytter flere steder i denne rapport kb som en måleenhed der svarer til hhv bytes, hvilket svarer til kibi i IEC enheder, og ikke kb i IEC enheder. 3.2 Om brug af pseudokode Flere steder i denne rapport viser jeg eksempler på kode frem. Den kode skal er ikke taget direkte fra programmet, men er blevet omformuleret, således at den er kortere og lettere at forstå. Det er i mange tilfælde gjort ved at ændre variabelnavne, og indføre en del funktioner, som kun beskrives ud fra deres navn. Hvis de funktioner faktisk blev implementeret, vil man kunne ende med kode der svarer næsten præcist til den koden som der faktisk benyttes. 3.3 Radiosity Radiosity algoritmer kan alle beskrives ved, at de bestemmer belysningen af overflader, ved at simulere overførslen af lysenergi fra lyskilder, til overfladerne der er synlige fra lyskilderne[siggraph1]. Mængden af lysenergi der overføres imellem to overflader bestemmes ud fra hvor synlige de to overflader er i forhold til hinanden, og formfaktor ligningen. Lysenergien overføres i flere iterationer, da overfladerne der modtager lysenergi, kan reflektere den energi videre, og dermed selv fungere som lyskilder. Overfladerne bliver typisk opdelt i mindre elementer, så der kan tages højde for hvordan skygger ligger sig på overfladerne, ved at bestemme belysningen på hvert element. Opdelingen kan enten foregå dynamisk, hvor vægge bliver opdelt alt efter hvordan lyset overføres, eller statisk efter en heuristik, der forsøger at opdele væggene på intelligente måder. Der findes primært to familier af radiosity algoritmer, gathering og shooting. Gathering algoritmer fungerer ved at bestemme hvor meget lys alle overflader modtager fra alle lyskilder ved hver iteration. Shooting algoritmer fungerer ved at bestemme hvor meget lys en enkelt lyskilde udsender til alle overflader ved hver iteration. En populær variant af shooting algoritmerne er shooting and sorting, hvor lyskilden der betragtes ved hver iteration, er den lyskilde der overfører mest energi. Ideen med dette er at det er lyskilderne der lyser kraftigst der har størst påvirkning på hvorledes overfladerne belyses. For eksempel er det for udendørs scener typisk vigtigere at betragte lys der kommer fra solen, end lys der kommer fra en 20 watts pære. Af samme årsag giver radiosity renderinger ikke ligeså markant bedre resultater for uden Lars Frydendal Bonnichsen (s062424) 6

7 dørs scener i forhold til algoritmer der ikke benytter global illumination, som i indendørs scener, hvor solen ikke er ligeså alt afgørende for belysningen. 3.4 Hardware termer Inden jeg går i gang med at beskrive Cell processorens arkitektur, vil jeg gennemgå nogle termer der benyttes igennem rapporten, der beskriver de forskellige parametre for hardwaren. Pipelining er en teknik hvorved forskellige dele af hardwaren udfører forskellige dele af beregningerne, ligesom på en fabrik, hvor forskellige mennesker eller maskiner, udfører forskellige opgaver. Ved at lade de forskellige dele af beregningerne foregå på forskellig hardware, kan beregninger udføres hurtigere, da hver del af beregningen udføres parallelt, men forsinkelsen fra en beregning påbegyndes til den er færdig er den samme. Typisk kan den forsinkelse skjules for både programmør og bruger af hardwaren, da hardwaren kan gætte på hvilke beregninger der følger efter hinanden. Når der ses bort fra branches, følger hver instruktion den forrige, så det er kun ved branches at det reelt er nødvendigt at gætte. Branch prediction er teknikker der spekulerer på hvorvidt branches tages, så processoren kan forudse hvilke beregninger den skal lave. Nogle moderne processorer benytter meget avanceret og kompleks branch prediction, for at kunne benytte dybe pipelines uden at gøre branches langsommere. Cache er en lille, men hurtig, hukommelse, som husker de data der sidst er tilgået. Formålet med cache er, at den hurtigere end den hukommelse den repræsenterer, hvilket gør operationer på data som repræsenteres i cachen hurtigere. Out-of-order-execution angiver at processoren er i stand til bestemme dataafhængigheder i koden, og at den dermed kan forsinke udregninger på data der ikke er tilgængeligt. I modsætning betyder inorder-execution at processoren ikke er i stand til at ændre rækkefølgen beregninger udføres i. 3.5 Cell Cell processeoren blev lanceret i 2005 af STI gruppen (Sony, Toshiba og IBM), som en processor der forsøger at opnå højst mulig regnekraft med det antal transistorer der er tilgængelige. Årsagen til dette mål er, at ydelsen af processorer ikke har steget eksponentielt de sidste års tid, på trods af at Moores lov stadig passer nogenlunde [Intel1]. Årsagen til at man ikke har kunne få så meget ud af transistorerne er primært, at de teknikker som man tidligere har brugt til at forbedre ydelsen ikke har givet så gode resultater. Længere pipelines hjælper ikke, da branch misprediction tager længere tid med lange pipelines, og bedre automatisk branch prediction kræver mange transistorer, så man kan ikke øge processorers clockhastighed væsentligt. Større Lars Frydendal Bonnichsen (s062424) 7

8 cache reducerer ikke den gennemsnitlige ventetid på hukommelses tilgang særlig meget. Derfor har der de sidste år været en stigende interesse for processorer med flere kerner, da det vil bevare forholdet imellem ydelse og antal transistorer, for opgaver der kan beregnes parallelt, under optimale forhold. Cell er i høj grad et forsøg på at gøre op med de sidste 15 års processor design, ved at den fjerner dele af processorene som ikke giver meget ydelse per transistor, på en bekostning af kompatibilitet med tidligere udviklingsmodeller. Resultatet er at Cell er en er en in-order processor, uden hardware branch prediction, og med en minimal mængde cache. Pga. de transistorer der er blevet sparet, er det muligt at have flere kerner i processoren. Cell arkitekturen er heterogen, idet den indeholder kerner der programmeres forskellige fra hinanden. PPE'erne er kerner der er baseret på PowerPC arkitekturen, og derfor kan programmeres som de fleste andre generelle processorer, og SPE'er er mindre kerner der er optimeret imod beregningstunge opgaver. Antallet af de forskellige kerner som er i Cell processorer kan varriere, men den mest almindelige i dag, og den som jeg arbejder med, har en PPE, som har to hardware tråde, og seks SPE'er. SPE'er afviger fra konventionelle general purpose processorer på følgende punkter: I stedet for out-of-order-execution har SPE'erne udelukkende asynkron adgang til hukommelsen gennem DMA overførsler[ibm1]. I stedet for automatisk branch prediction har de program styret branch prediction[ibm1]. I stedet for en hierarkisk cache, har de en hurtigt privat hukommelse og en stor register fil[ibm1]. SPE'er understøtter ikke praktisk taget ikke skalar operationer, i stedet understøtter de et bredt spektrum af SIMD operationer[ibm1]. SPE'er understøtter ikke IEE-754 afrunding af 32-bit floating point værdier[wagner1]. Ændringerne er i høj grad at ting der tidligere gjordes automatisk af hardwaren, nu kan/skal gøres af programmerne. På den ene side betyder det at der er mere fleksibilitet, hvilket kan give bedre ydelse, på trods af at der blev sparet transistorer. På den anden side stiller det større krav til programmøren, især fordi SPE'erne ikke deler hukommelse med hovedprocessoren, hvilket ellers typisk antages er tilfældet i de fleste implementeringer af parallelle algoritmer. Lars Frydendal Bonnichsen (s062424) 8

9 3.6 Programmøren og Cell Generelt Som nævnt i forrige afsnit, stiller programmering af Cell'ens SPE større krav til programmøren end typiske general purpose processorer. Dette skyldes primært at SPE'erne ikke deler hovedprocessorens hukommelse, men kun har en hukommelse på 256 kb, kaldet local storage, eksklusivt dens register fil. Illustration 1: Oversigt over hvordan elementerne i Cell arkitekturen er forbundet SPE'er består i bund og grund af 3 dele: en SPU som laver selve beregningerne, en local storage som er hukommelsen som SPU'en kan tilgå, og en MFC som SPU'en kan bruge til at påbegynde hukommelses overførsler imellem dens local storage og data i den globale hukommelse, såsom rammene. Local storens 256 kb skal indeholde programmet, evt. frameworks programmet afhænger af, samt variabler fra både stack og heap. Hvis der ikke er plads til alle variablerne programmet afhænger af, skal dataene læses ind og ud af SPE'en local store når det er nødvendigt, vha. igennem hukommelses overførsler, kaldet DMA overførsler, der påbegyndes eksplicit af programmet via funktionskald. Det betyder i bund og grund, at koden skal ændres så den tager hensyn til hukommelses begrænsningerne, hvis der ikke er plads nok i SPE'ens local store. Bl.a. pga. de problemer, vil man typisk ikke skrive store programmer til Cell, der udføres udelukkende Lars Frydendal Bonnichsen (s062424) 9

10 på SPE'erne, men i stedet lade SPE'erne håndtere de dele af programmet, som kræver flest beregningsresurser. På den måde kan man få en høj ydelse, uden at skulle overveje Cell'ens særheder det meste af tiden. Pareto princippet, også kaldet reglen, understøtter dette [JR1]. På den måde sørger man også for at den kompilerede kode som SPE'erne udfører fylder mindre, og det bliver lettere at identificere præcist hvilke felter i datastrukturer der bruges, så datastrukturene kan slankes Hukommelsesoverførsler Kilde [IBM2] Data kan sendes imellem SPE'er og den globale hukommelse med DMA overførsler. DMA overførsler påbegyndes ved at angive en kilde og destinations adresse, samt længden af overførslen og et tag. Funktionen der påbegynder DMA overførslen venter ikke på at overførslen fuldender. Det er dog muligt for at vente på DMA overførsler færdiggøres, ud fra deres tag. SPE'er og PPE'en kan kun vente på DMA overførsler de selv påbegynder. Når en ny DMA overførsel påbegyndes, sættes den på en kø, og selve overførslen starter så snart det er muligt. Der er nogle begrænsninger på brugen af DMA overførsler: Hver DMA overførsel kan højst overføre 16 kb data. For større overførsler kan der benyttes lister af DMA overførsler. Længden af en DMA overførsel skal være 1, 2, 4, 8 eller 16 n bytes hvor n N Kilde og destinations adresserne skal gå op i 16. Overførslerne går hurtigere hvis adressernes 7 laveste bits er ens. På den udgave af Cell jeg arbejder med, kan hver SPE højst have 16 DMA overførsler i kø, og PPE'en kan højst have 8 DMA overførsler i kø. Antallet af overførsler der kan være i kø kan afhænger af den specifikke udgave af Cell processoren[sti1]. Tiden det tager at gennemføre en DMA overførsel består af en konstant opsætnings tid, der inkluderer hukommelses latency, og tiden det tager at overføre data. Derfor bør man forsøge at bruge få, men store DMA overførsler, fremfor mange små. Dette vil programmører typisk også gøre, da kravene til DMA overførsler betyder, at der skal betydelig opsætnings kode til, før DMA overførsler påbegyndes. DMA overførsler er ikke den eneste måde at overføre data på. Cell processoren har også en mailbox funktion, der gør det muligt at sende små 32-bit beskeder imellem SPE'erne og PPE'en. Det er i også muligt at sende beskeder imellem SPE'erne, ved at skrive til deres mailboxes med DMA overførsler. Lars Frydendal Bonnichsen (s062424) 10

11 3.7 Radiosity på Cell Målet med at implementere en radiosity algoritme på Cell, er i høj grad at lave en algoritme der udføres så effektivt at det er konkurrence dygtigt med allerede eksisterende algoritmer. Fælles for effektive radiosity beregninger er, at de bruger flest resurser på de overflader som overfører mest lys, da det er de overflader som typisk vil påvirke belysningen af scenen mest. En af de mest effektive nuværende algoritmer er en variant af shooting and sorting med statisk opdeling, hvor den udsendte belysning beregnes ved at projektere overfladerne på en terning der ligger på overfladen der udsender lys. Denne teknik er især effektiv, fordi projekteringen af overflader ned på terningen, samt bestemmelsen af hvilken overflader der faktisk skal modtage belysningen, kan udføres af graffikkort. Graffikkort er mere parallelle end almindelige processorer, de burde derfor være hurtigere til denne type opgave. Tiden det tager at projektere overfladerne vil typisk er lineært relativ til antallet af overflader der kan overføres lys til. Et muligt brug af SPE'erne i denne sammenhæng ville være at forsøge at reducere antallet af overflader der overvejes, ved brug af en visibility algoritme. Det at der benyttes et graffikkort giver dog problemer, da det gør det mere besværligt at opdele geometri dynamisk, og da projekteringen på en terning ikke nødvendigvis giver en præcis approksimation af hvordan lyset overføres. En anden mere præcis algoritme fungerer således: Det er en gathering algoritme, der opdeler overflader dynamisk, og beregner radiosity ved at sende et antal stråler imellem forskellige punkter på overfladerne der overføres energi imellem [PHDSLA1]. Den dynamiske opdeling udføres ud fra hvor meget lys der overføres imellem overfladerne, efter synligheden er bestemt. På den måde undgår man at opdele overflader, hvis de ikke modtager noget energi. Jeg har valgt at betragte den anden algoritme, da almindelige cpu+gpu'er sandsynligvis vil give samme resultater i shooting algoritmer, da visibility beregninger muligvis ikke vil være så tunge i forhold til transformationerne, og begrænsningen derfor ikke ligger på processoren. Den første algoritme ville dog stadig være interessant, bl.a. fordi den opstiller et problem der minder om brug af realtids grafik på Cell, hvilket er aktuelt igennem spillemaskinen PlayStation 3, der bruger en Cell og et graffikkort. Jeg har baseret min kode på en allerede eksisterende implementering af algoritmen, fra SPLASH2 benchmark suiten. På den måde består min del af opgaven i at identificere hvilke dele af koden der effektivt kan flyttes over på SPE'erne, portere koden, og lave optimeringer der er specifikke til Cell. Lars Frydendal Bonnichsen (s062424) 11

12 3.8 Kode basen Grundlæggende Typedefinitioner Koden benytter en masse nogle typedefinitioner. Jeg vil starte med at gennemgå de vigtigste, for at gøre det lettere at forklare hvordan koden fungerer: Patch Beskriver en knude i et BSP træ[sgi1]. Der oprettes i starten af programmet en knude for hver trekant i scenen, som programmet renderer. BSP træet benyttes til at bestemme hvor synlige to trekanter i forhold til hinanden. Hvor synlige to trekanter er i forhold til hinanden opgives på en skala fra 0 til 1, hvor 0 = ingen synlighed, 1 = fuld synlighed, og intervallet derimellem benyttes når rummet imellem dem er delvist blokeret Element Beskriver en trekant. Elementer kan opdeles til mindre elementer. For at understøtte dette har hvert Element 4 pointers til deres børn, og en pointer til deres forfader. Illustration 2: Elementer har referencer til Interaction deres underelementer Beskriver overførslen af lysenergi imellem Elementer. Gemmes som en enkelt lænket liste, med pointer til den næste Interaction. Indeholder en pointer til Elementet der modtager lysenergi, samt felter der bl.a. beskriver form faktoren og hvor synlig modtager og afsender element er overfor hinanden. Interactions benyttes typisk sammen med Illustration 3: Interactions grupperes vha. et felt i datastrukturen der refererer til den næste Interaction Elementer, da Interactions ikke har en reference til lyskilden Task Programmet benytter Tasks til at opdele beregningerne i mindre bidder, så flere tråde kan arbejde samtidigt, på hver deres del at beregningen. Hver tråd har sin egen kø til Tasks. Tasks indsættes og behandles i en LIFO maner, svarende til en stak. Ved indsættelse af Tasks kan nogle typer Tasks opdeles i mindre bidder, hvis det skønnes at de er for store. Trådene tilgår primært deres egen Task kø, men når deres egen Task kø er tom, stjæler de Tasks fra andre trådes køer. Lars Frydendal Bonnichsen (s062424) 12

13 Tasks kan have følgende typer: Navn Modelling* BSP* Beskrivelse Opretter geometri som trekanter og opretter et BSP Task til hver trekant Indsætter en knude i BSP træet, svarende til en trekant. Opretter FF refinement tasks til at udregne form faktoren imellem trekanten og alle eksisterende knuder i BSP træet. FF refinement Bestemmer form faktoren imellem to Elementer. Ray Visibility Rad Average Opdeler Elementer på baggrund af muligheden for fejl i formfaktoren i de Interactions Elementerne indgår i. Ved opdeling af Elementer flyttes Interactions fra Elementet til dens underelementer, og synlighed og formfaktor beregnes igen. Opretter Ray og Visibility tasks. Bestemmer synligheden imellem et Element der agerer som lyskilde, og en række Elementer der modtager energi. Synligheden bestemmes ved at sende et antal stråler på BSP træet. Disse tasks har to modes. Enten bestemmes forholdet imellem hvor meget lys Elementer modtager, og deres areal, ellers normaliserer de lysenergien, i forhold til det lyseste element (et princip der svarer til high dynamic range i realtidsgrafik). Disse tasks oprettes som det sidste i beregningerne, for at gøre det muligt at vise resultatet. Tabel 1: De forskellige typer Tasks *Der oprettes aldrig Tasks af disse typer. I stedet udføres de serielt på en enkelt processor. Grunden til at de udføres serielt er at Taskene skriver til en enkelt datastruktur, hvilket ville kræve så meget synkronisering hvis det skulle udføres parallelt, at det sandsynligvis ikke ville gavne køretiden Beskrivelse af programmet Programmet starter med at læse en række parametre ind, som bruges til at bestemme hvorledes radiosity beregnes og vises. Programmet beregner radiosity ved at oprette et antal tråde, der udfører kode svarende til: Lars Frydendal Bonnichsen (s062424) 13

14 1. radiosity() { 2. initialiser_modelling_tasks(); 3. udfør_tasks(); 4. barriere(); while(der_kan_overføres_væsentlig_lys_energi()) { 7. initialiser_ray_tasks(); 8. barriere(); 9. udfør_tasks(); 10. barriere(); 11. } 12. barriere(); initialiser_tasks_til_bestemmelse_af_areal_vægtet_radiosity(); 15. udfør_tasks(); 16. barriere(); initialiser_tasks_til_at_normalisere_radiosity(); 19. udfør_tasks(); 20. barriere(); 21. } Kodesegment 1: Koden som alle tråde udfører Alle initialiser_* funktionskald bliver kun udført af den første tråd der kalder funktionen. initialiser_* funktionskaldene opretter Tasks, som bliver fordelt i trådenes Task køer. Initialiseringen opretter et Task for hver trekant i den oprindelige geometri. Løkken på linje 6-11 er den der udfører iterationer af radiosity algoritmen. Kald til udfør_tasks udfører alle Tasks i trådenes Task køer. Barrieren der er efter udfør_tasks kaldene er implementeret indeni selve funktionen Noter angående brugerfladen Programmet har også en grafisk brugerflade, der benytter IRIS GL, der er SGI's proprietære forgænger til OpenGL, som jeg ikke har benyttet, eller forsøgt at bevare kompatibilitet med, da den benytter gamle biblioteker, som er besværlige at anskaffe til moderne arkitekturer. Det dog burde være relativt let at portere GUI'en til OpenGL, da alle kaldene til IRIS GL er gemt bag interfaces som de oprindelige udviklere af koden har defineret, og da OpenGL minder en del om IRIS GL. For god fremtidssikret understøttelse vil det dog være mere besværligt, da version 3.1 af OpenGL fjernede immediate mode[khronos1], som benyttes i af GUI'en. Lars Frydendal Bonnichsen (s062424) 14

15 4 Bestemmelse af flaskehals Koden er allerede skrevet på en måde der gør den meget portabel og parallel, så det har ikke været nødvendigt at lave store ændringer på hvordan koden fungerer på Cell'ens PPE. Det første jeg gjorde var derfor at forsøge at måle mig frem til hvilken del af koden der er flaskehals for ydelsen. Noget naivt startede jeg med at måle tiden før og efter et forskellige typer opgaver begynder, og forøge tællere ud fra dette. Det gav dog ikke korrekte resultater, da de forskellige opgaver opretter nye opgaver, og hvis opgaverne ikke er store nok, eller hvis køen der beskriver opgaverne er blevet for lang, udføres de direkte. Derfor var jeg nødt til at gøre køen meget længere end normalt, og kræve at alle opgaver sættes på køen, for at få nogenlunde korrekte målinger. For at kunne måle køretiden for individuelle tasks præcist, benyttede jeg PPE'ens mftb instruktion, som måler tid meget præcist. 4.1 Originale køretider for tasks Køretiderne er målt på en PlayStation 3 der kører Yellow Dog Linux 6.1 og benytter framebufferen som swapfil (brug af framebufferen betyder nok ikke så meget, da programmet ikke bruger så meget hukommelse). Programmet blev udført med en enkelt tråd. Jeg har målt køretiderne for to datasæt, som er indbygget i programmet: Default data set Largeroom Task Køretid Procentvis Task Køretid Procentvis BSP ,01% BSP ,78% Modellering ,02% Modellering ,78% Refinement ,10% Refinement ,90% Visibility ,30% Visibility ,59% Ray ,25% Ray ,26% RadAverage ,39% RadAverage ,30% Total ,07% Total ,59% Tabel 2: Køretider for oprindeligt program Det tager ca. 1 sekundt at køre programmet med Default data sættet, som indeholder 14 trekanter, og 30 sekunder for Largeroom data sættet, som indeholder 514 trekanter. Visibility Tasks lader til at være bottleneck, og ingen af de andre Tasks er nær så tidsrøvende. For default data set, bruges ca. 40% af tiden udenfor Tasks. Denne tid bruges på initialisering af programmet, barriere synkronisering, og synkronisering når Tasks tages af Task køen. At der bruges så en betragtelig mængde tid udenfor Tasks ved små datasæt, kunne tyde på at man burde analysere køretiden for større datasæt, eller reducere tiden der bruges udenfor Tasks. Derfor har jeg valgt at sammenligne ydelse i resten af rapporten ud fra datasættet Largeroom. Lars Frydendal Bonnichsen (s062424) 15

16 4.2 Forbedring af flaskehals Den måde man typisk udbedrer flaskehalse på Cell, er at portere den relevante kode på til SPE'erne, da størstedelen af Cell'ens regnekraft ligger i SPE'erne. De første målinger viste at flaskehalsen var Ray tasks. Disse tasks udfører kode, hvis kompleksitet er lineært relativt til antallet af gange de opdeler overfladerne, under estimationen af fejlen ved overførsel af energi. Adskillige steder i denne kode, bl.a. ved hver opdeling, skal der skrives til den globale hukommelse og benyttes låse[marshall1]. Det er besværligt at benytte låse på SPE'er, da de typisk implementeres med en delt hukommelses model i tankerne, hvilket SPE'erne ikke understøtter. En mulighed for at omgå dette, vil være at lade en enkelt SPE stå for adgang til alle låse, og tilgå låsen vha. SPE'ernes mailbox funktionalitet. Dette vil muligvis også være hurtigere end almindelige låse, der typisk implementeres benytter kald til operativsystemet (nogle versioner af libspe, som bl.a. håndterer for brug af mailboxes på PPE'en, benytter låse til at sikre sig at der kun sendes en besked af gangen). Det er dog ikke noget jeg har set dybere på, da de senere (og mere korrekte) målinger, viste at størstedelen af køretiden blev brugt på Visibility tasks. Det at bestemmelse af synligheden er flaskehalsen giver også god mening, da Visility tasks oprettes når Ray tasks opdeler overflader, og Visibility tasks sender adskillige stråler på et bsp træ, hvor kompleksiteten afhænger af den geometriske kompleksitet. Visibility tasks bruger i modsætning til Ray tasks et konstant antal adgange til låse, og det eneste de skal skrive tilbage i den globale hukommelse, er en float der angiver hvor synlige par af overflader er i forhold til hinanden. Derfor er Visibility tasks markant mere oplagte at udføre på SPE'er end Ray tasks. Hvis man antager at programmet skalerer lineært, og SPE trådene vil kunne lave beregninger lige så hurtigt som PPE trådene kan man forvente følgende køretider, for en Cell processor med 2 PPE tråde og 8 SPE tråde, hvis SPE trådene håndterer visibility tasks, og PPE trådene håndterer alt andet: Default data set Largeroom Task Køretid Procentvis Task Køretid Procentvis BSP ,02% BSP ,52% Modellering ,04% Modellering ,54% Refinement ,28% Refinement ,42% Visibility ,95% Visibility ,80% Ray ,06% Ray ,35% RadAverage ,71% RadAverage ,96% Total ,07% Total ,59% Tabel 3: Approksimerede køretider når SPE'er håndterer visibility Tasks Approksimationen viser for Largeroom, at selv om visibility Tasks håndteres på SPE'erne, er de stadig flaskehals for ydelsen. Derfor kan man argumentere for at visibility Tasks både skal håndteres af SPE og PPE tråde. Lars Frydendal Bonnichsen (s062424) 16

17 5 Evaluering Jeg påbegyndte arbejdet på denne opgave d. 16 februar I begyndelsen fulgte jeg andre kurser på DTU, og det var derfor først d. 8 juni 2009, at jeg for alvor begyndte på at arbejde på opgaven. Indtil da havde mit arbejde bestået i at læse op på hvordan Radiosity algoritmer fungerer, studeret kode basen, og udføre benchmarks for at finde de oprindelige flaskehalse. Implementeringen af algoritmen begyndte jeg på d. 8. juni, og det var først d. 15 juni (uge 25) jeg havde en tidsplan for det resterende forløb. Da jeg skrev tidsplanen, havde jeg allerede portere noget PPE kode til SPE, var derfor i stand til bestemme at kommunikationen imellem SPE og PPE skulle optimeres. Jeg var dog ikke sikker på hvad der skulle gøres efter det. Tidsplanen var opdelt i hvad der skulle laves på rapporten og hvad der skulle laves mht. implementering af algoritmen. Den oprindelige tidsplan sagde: Uge Type Beskrivelse 24 I Flyt flaskehals til SPE og bestem tidlige ydelses problemer. D 25 I Evaluer og reducer ydelses problemer på SPE relateret til kommunikation. D Teori afsnit 50 % færdigt. Rapporten skal ridses op 26 I Evaluer og reducer ydelses problemer på PPE relateret til kommunikation. D Dokumenter målinger. Teori afsnit næsten færdigt 27 I Evaluer og reducer andre ydelses problemer på SPE D Implementation 50 % færdigt 28 I Evaluer og reducer andre ydelses problemer på SPE D Målinger næsten færdigt. Implementation næsten færdigt. 29 I Ret eventuelle fejl. Kommenter koden D Rapport færdig 30 Aflevering mandag Tabel 4: Oprindelig tidsplan Den oprindelige tidsplan har relativt få risici, da det allerede fra den første uge burde være muligt at kontrollere at koden fungerer korrekt, og derefter arbejde på enkelte uafhængige dele af koden, med efterfølgende kontrol af ydelse og resultater. Det gik meget godt med at følge tidsplanen indtil uge 26. I uge 26 opdagede jeg at jeg reelt ikke havde udført grundige nok tests, til at validere at min kode fungerede korrekt, indtil da. Pga. fejl der var meget svære at fejlfinde på, og da jeg ikke havde benyttet koderevisionssystem til min kode, var jeg nødt til at starte forfra på implementeringen. Det betød at rapportskrivning blev reelt sat på standby indtil uge 28, mens jeg genskrev kode, rettede fejl og indhentede på implementerings fronten. Lars Frydendal Bonnichsen (s062424) 17

18 Bl.a. pga. kompatibilitets problemer med kodebasen, var det først i uge 28 at jeg havde kode der benyttede SPE'erne, som jeg kunne validere med sikkerhed fungerede korrekt. En anden årsag til at det tog så lang tid at få fungerende kode op at stå, var at jeg arbejdede på at implementere effektiv kommunikation, inden jeg porterede koden, da jeg fra den forrige implementering vidste, at det ikke ville være så besværligt at portere koden, og at kommunikationen var vigtig at optimere. Det lykkedes mig at indhente meget af rapportskrivningen i uge 28, og fulgte tidsplanen i uge 29. Set i bakspejlet mistede jeg meget tid på at genimplementere algoritmen, fordi jeg ikke havde udført grundige nok tests af den kode jeg havde skrevet, og fordi jeg ikke benyttede et kode revisionssystem. Derudover løb jeg en stor risiko ved at fokusere på optimeringer, før jeg havde fungerende kode, hvilket ikke var så smart. Hvis jeg skal arbejde med et lignende projekt i fremtiden, vil jeg fokusere på at starte med at lave en fungerende version først, og validere den igennem grundige test. Først derefter vil jeg forbedre koden, ved at indføre forbedringer iterativt, og dokumentere forbedringerne af køretiden. Lars Frydendal Bonnichsen (s062424) 18

19 6 Implementering 6.1 Om Visibility Tasks Inden man kan portere koden som visibility Tasks udfører, er det nødvendigt at overveje hvilke dele af koden der kan og bør porteres. Derfor var noget af det første jeg gjorde da jeg skulle til at portere koden, at lave et sekvensdiagram over koden som visibility Tasks udfører, for at få et overblik over hvad de laver, og hvilke data de tilgår. Sekvensdiagrammet kan fremstilles således: visibility_task(element*, Interaction*, n_inter, k()) compute_visibility(element*, Interaction*, n_inter) visibility(element*, Element*, n_rays) get_test_rays(vertex*, no) inner_product(vertex*, Vertex*) traverse_bsp(patch*, Vertex*, Ray*, r_min, r_max) check_patch_cache(vertex*, Ray*, r_min, r_max) intersection_type(patch*, Vertex*, Ray*, tval*, r_min, r_max) v_intersect(patch*, Vertex*, Ray*, t) traverse_subtree(patch*, Vertex*, Ray*, r_min, r_max) intersection_type(patch*, Vertex*, Ray*, tval, r_min, r_max) traverse_subtree(patch*, Vertex*, Ray*, tval, r_min, r_max) test_intersection(patch*, Vertex*, Ray*, tval) patch_tested(patch*) v_intersect(patch*, Vertex*, Ray*, t) update_patch_cache(patch*) intersection_type(patch*, Vertex*, Ray*, tval, r_min, r_max) test_intersection(patch*, Vertex*, Ray*, tval) k(element*) Illustration 4: Sekvens diagram for visibility Tasks visibility_task funktionen kalder compute_visibility, og k. k er en continuation funktion, dvs. en funktion der skal udføres efter Tasket er fuldført. I dette tilfælde vil k altid være funktionen process_rays2, som laver de samme beregninger som ray Tasks, for de Interactions som visibility Tasket lige har behandlet. compute_visibility funktionen kalder visibility for destinationen af dens Interactions, og elementet, som de Interactions hører sammen med. visibility er den første funktion som reelt laver visibility beregninger. Den opretter et antal stråler der går imellem de to Elementer, og kalder traverse_bsp, for de stråler hvor synligheden ikke kan afvises trivielt. Synligheden afvises trivielt hvis Elementerne ikke vender imod strålen. traverse_bsp kalder traverse_subtree, som rekursivt udforsker BSP træet. Det vil ikke være muligt at udføre continuation funktionen, på SPE'erne, uden at portere koden der udfører ray Tasks, så visibility_task funktionen skal ikke porteres. compute_visibility itererer over en lænket liste, hvilket ikke vil være så let at portere til SPE'erne, da pointerne referer til addresser i den globale hukommelse, og ikke til SPE'ernes local storage. Derudover udfører de funktioner heller ikke nævneværdige beregninger. visibility og alle funktionerne under den, står for at lave de Lars Frydendal Bonnichsen (s062424) 19

20 egentlige beregninger, og de benytter i bund og grund ikke data som vil være yderst besværligt at tilgå fra SPE'erne. Af den årsag har jeg valgt at portere al koden fra funktionen visibility. Selve beregningerne som udføres af visibility funktionen er ret trivielle, så man kunne argumentere det først er fra traverse_bsp at der egentlig bør porteres. Mit modargument til det er at traverse_bsp modtager markant mere data som input parametre, medmindre alle strålerne afvises trivielt. Ved at portere visibility holdes mængden af data som der overføres imellem PPE og SPE nede, for at undgå problemer på den front. For at kunne udføre visibility Tasks på SPE'erne har jeg gennemgået 4 overordnede opgaver: 1. Sæt en protokol op til at overføre input parametre og retur værdier for visibility beregningen 2. Porter koden der beregner visibility til at kunne udføres på SPE'er. 3. Gør resten af programmet kompatibelt med den måde SPE'erne beregner visibility på. 4. Optimer koden der beregner visibility til SPE'erne. De fire opgaver vil jeg gennemgå i de følgende afsnit. Lars Frydendal Bonnichsen (s062424) 20

21 6.2 PPE-SPE protokol Protokollens formål Protokollens formål er at overføre input parametre til visibility beregningen fra PPE'en til SPE'erne. Selve funktionen visibility tager to Elementer ind, og returnerer en float Protokollens udformning Protokoller til at overføre data imellem PPE og SPE på Cell kan benytte mailbox beskeder, DMA overførsler og signaler til at kommunikere. For at have få transaktioner og reducere den tid som bruges på protokollen, har jeg valgt at sende input parametrene til flere kald til visibility på en gang. Dette svarer også meget godt til den eksisterende løsning, der opretter visibility Tasks, som hver repræsenterer et antal kald til visibility funktionen. Da adskillelsen imellem PPE tråde, er mindre end den imellem PPE og SPE tråde, kan man argumentere for at visibility Tasks der udføres på SPE'erne bør være større, for ikke at spilde tid på forsinkelsen ved overførsel af data. Input parametrene til visibility funktionen er to Elementer. For et visibility Task er det første Element altid det samme, og derfor overføres dette Element også kun en gang af protokollen, som det første Element. Protokollen jeg benytter kan overordnet beskrives således: 1. PPE'en påbegynder udlicitereringen af et visibility Task ved at serialisere input parametrene til visibility funktionen. 2. Herefter sendes der besked til en SPE om hvor i den globale hukommelse at input parametrene kan læses fra, og hvor mange kald til visibility den skal udføre. 3. SPE'en læser parametrene ind, vha. en DMA overførsel. 4. SPE'en udfører kaldet til visibility. 5. SPE'en sender resultatet tilbage til PPE'en, til det samme sted som der hvor den læste input parametrene fra. 6. SPE'en sender en mailbox besked tilbage om at den er blevet færdig med at beregne visibility, samt hvor dens data kan læses fra. Hvert af de trin udføres altid i den rækkefølge som de er opgivet i. Jeg har valgt denne, noget primitive, udformning af protokollen, da den undgår at beskeder skal sendes frem og tilbage imellem PPE og SPE, hvilket kan tage lang tid, og unødvendigt lange DMA overførsler. Lars Frydendal Bonnichsen (s062424) 21

22 6.2.3 SPE siden af protokollen SPE implementationen af protokollen er relativt enkelt, den modtager en mail, indlæser parametre, beregner, sender svar tilbage og sender en mailbox besked. Hvis SPE'en altid udfører de handlinger i den rækkefølge, betyder det dog at der vil blive brugt betragtelig tid på at overføre data frem og tilbage. Dette tidsspild kan reduceres ved at benytte multibuffering [IBM3]. Kilden jeg referer til beskriver multibuffering i ALF, som er et framework der kan håndtere udlicitering af tasks på SPE'er. Jeg bruger ikke frameworket, men det kunne jeg have gjort. Formålet med multibuffering er at have flere steder at lagre input parametre og/eller resultater, så det er muligt at overføre de data samtidigt med at der laves beregninger. Da jeg er interesseret i hverken at vente på indlæsning af parametrene, eller returnering af resultaterne, findes der grundlæggende to teknikker jeg kan benytte: Jeg kan benytte fire buffere, to til input og to til output. Imens der beregnes på det ene sæt af buffere overføres der data i det andet sæt. Når alle overførsler og beregninger er færdige skiftes hvilke buffere der beregnes og overføres med. Jeg kan benytte tre buffere, en til input, en til output og en til beregning. Resultaterne af beregningerne skrives ind i den samme buffer som de læses fra, hvilket faktisk er muligt for de beregninger der laves. Når alle overførsler og beregninger er færdige roteres bufferne. Bufferen der tidligere blev indlæst parametre i, bruges nu til at regne på, bufferen der blev regnet på sendes nu og bufferen der blev sendt bruges nu til at indlæse. Jeg har valgt at benytte fire buffere. Ikke bare fordi det er enklere, men også fordi det benytter mindre hukommelse til bufferne. Det lyder måske lidt underligt at fire buffere fylder mindre end tre, men det er fordi et enkelt input buffer fylder mere end to output buffere, og størrelsen af bufferne i tre buffer løsningen skal være ligeså stor som både input og output buffere. Multibufferen kan beskrives med følgende pseudokode: Lars Frydendal Bonnichsen (s062424) 22

23 1. // Deklaration af input og output buffere 2. Element in1[max_interactions + 1], in2[max_interactions + 1]; 3. float out1[max_interactions], out2[max_interactions]; 4. int main() { 5. BufferData front_input, back_input, front_output, back_output, temp; 6. opsæt_pointere_til_bufferne(); 7. while(1) { 8. indlæs_task_beskrivelse(front_input); 9. dma_ind(front_input); 10. vent_på_overførsel_er_færdig(back_output); 11. fortæl_ppe_at_tasket_er_beregnet(back_output); 12. back_output.task_beskrivelse = back_input.task_beskrivelse; // Send svar tilbage til samme adresse 13. vent_på_overførsel_er_færdig(back_input); 14. lav_beregninger(back_output, back_input); // Laver visibility beregningerne 15. dma_ud(back_output); 16. // Byt pointere 17. temp = front_input; 18. front_input = back_input; 19. back_input = temp; 20. temp = front_output; 21. front_output = back_output; 22. back_output = temp; 23. } 24. } Kodesegment 2: Brug af multibuffering på SPE, for at skjule DMA forsinkelse. Trin 2-6 Hvor opsæt_pointere_til_bufferne opsætter front_input, back_input, front_output og back_output, og indlæs_task_beskrivelse modtager mails der beskriver hvor parametre skal læses fra, og hvor mange parametre der skal læses. BufferData objekterne gemmer den information i deres description felt. MAX_INTERACTIONS er det maksimale antal Interactions til hvert visibility Task. Der er dog et problem ved at bruge multibuffering lige efter bogen, i dette tilfælde. SPE'en blokerer i indlæs_task_beskrivelse, hvilket betyder at de tasks som repræsenteres af back_input, front_output og back_output, ikke vil blive behandlet videre, hvis der ikke kommer nye Tasks til SPE'en. Dette er uacceptabelt, da visibility Tasks kan oprette nye Tasks igennem continuation funktionen, og hver iteration af radiosity algoritmen afhænger af at alle Tasks behandles færdigt. Løsningen på dette problem er lade være med at vente på mailbox beskeder i indlæs_task_beskrivelse. Hvis der ikke er nogen beskeder sættes description for BufferData objektet til en særlig værdi. Alle efterfølgende funktionskald udføres kun hvis BufferData objekterne de modtager som parametre, ikke har den særlige værdi i deres description felt. Lars Frydendal Bonnichsen (s062424) 23

24 6.2.4 PPE siden af protokollen Datastrukturen SpeTask Til at hjælpe med at simplificere PPE siden af af protokollen benytter jeg en datastruktur SpeTask. SpeTask er en datastruktur der indeholder de data der skal sendes til SPE'en, samt en pointer til Elementet og Interaction listen, og beskrivelsen af de data som skal sendes til SPE'en. Da de data der skal sendes til SPE'en kan fylde relativt meget, har jeg lavet en funktionalitet til at allokere og deallokere SpeTasks, igennem to hjælpe funktioner, der kan beskrives med pseudokoden: 1. SpeTask spe_task_buf[max_spe_tasks]; 2. SpeTask *free_spe_task; 3. Lock free_spe_task_lock; SpeTask *get_spe_task() { 6. SpeTask *p; 7. LOCK(free_spe_task_lock); 8. if(free_spe_task == NULL) { 9. UNLOCK(free_spe_task_lock); 10. return 0; 11. } 12. p = free_spe_task ; 13. free_spe_task = p->next; 14. UNLOCK(free_spe_task_lock); 15. } void free_spe_task(spetask *task) { 18. LOCK(free_spe_task_lock); 19. task->next = free_spe_task ; 20. free_spe_task = task ; 21. UNLOCK(free_spe_task_lock); 22. } Kodesegment 3: Allokering af buffere til kommunikation med SPE'er. Del af trin 1 Hvor feltet next i SpeTask er en reference til det næste ledige SpeTask. Feltet skal være initialiseret inden brug, og det bliver vedligeholdt af funktionerne. På denne måde kan data allokeres og deallokeres indenfor det samme program, uden at lade operativsystemet stå for det, hvilket kunne være meget dyrt. Selve denne løsning har jeg tilpasset fra den måde som det originale program håndterer sine datastrukturer. Et problem ved at benytte denne form for statisk allokering er, at der ikke er nogen garanti for at der kan allokeres et SpeTask. Det kan også være et problem ved dynamisk allokering, men der vil det sandsynligvis ikke opstå på moderne systemer for dette program. Hvis det ikke er muligt at allokere et SpeTask er det ikke muligt at håndtere flere visibility Tasks på SPE'erne, og det PPE'en må derfor selv udføre Tasket. Man kunne tro at dette ville være et alvorligt problem, når SPE'erne, som repræsenterer størstedelen af Cell's regnekraft, ikke kan udføre dette Task. Men hvis der ikke kan allokeres flere Spe Lars Frydendal Bonnichsen (s062424) 24

25 Task må der allerede være garanti for at MAX_SPE_TASK SpeTask vil blive udført på SPE'erne, så vil SPE'erne have noget at lave indtil næste gang der tilføjes et visibility Task Om udvikling af PPE siden PPE'ens implementering af protokollen, er en som jeg har udviklet iterativt. Dvs. jeg har startet med at implementere en simpel udgave af den, og derefter forsøgt med mere avancerede udgaver, og målt hvordan de forskellige implementeringer påvirkede køretiden. Jeg vil derfor gennemgå udgaverne som jeg har implementeret i rækkefølge, og beskrive forbedringerne som hver ny udgave bragte Første udgave Den første udgave jeg lavede, benyttede polling, til at kommunikere med SPE'erne. Selve kommunikationen kan beskrives ved således: 1. poll_spe(spetask *task, spe_context_ptr_t spe, Lock spe_mailbox) { 2. LOCK(spe_mailbox); 3. send_task_beskrivelse(task, spe); 4. modtag_mail(spe); 5. UNLOCK(spe_mailbox); 6. sæt_visibility_for_interactions(task); 7. udfør_continuation_funktion(task); 8. } Kodesegment 4: Kommunikation med SPE ved brug af polling. Trin 2-6 Hvor spe_mailbox er en lås, der bruges til at sikre at kun en PPE tråd kommunikere med SPE'en af gangen, og spe er en reference til SPE'en der kommunikeres med. Bemærk at med denne metode venter PPE tråden, der sender SpeTasket til en SPE, på at svaret sendes tilbage, og laver intet i denne ventetid. Det betyder at PPE trådene vil lave ingenting i en stor del af tiden, at der ikke kan benyttes flere SPE'er end der er PPE tråde, og at selvom der er plads til beskrivelse af flere Tasks i SPE'ernes mailbokse, vil der aldrig sendes mere end en beskrivelse til hver SPE af gangen Anden udgave For at benytte PPE trådene og SPE'erne mere effektivt, oprettede jeg en delt task kø til SPE'erne, så PPE trådene ikke behøver at vente på SPE'erne bliver færdige, men blot kan tilføje SpeTasks til køen, og fortsætte med at lave noget andet. Jeg opretter desuden en ekstra tråd, som herfra refereres til som listener tråden, hvis eneste opgave er at modtage resultater fra SPE'erne, så de andre PPE tråde ikke behøver at bekymre sig om det. Koden som sætter et SpeTask på køen kan beskrives således: Lars Frydendal Bonnichsen (s062424) 25