VÆRKTØJ TIL AT HJÆLPE PROGRAMMØRER MED AT HÅNDTERE HUKOMMELSESMODELLEN PÅ

Transkript

1 VÆRKTØJ TIL AT HJÆLPE PROGRAMMØRER MED AT HÅNDTERE HUKOMMELSESMODELLEN PÅ CELL BE ARKITEKTUREN Specialerapport nr december 2008 KENNETH SKOVHEDE & MORTEN NØRGAARD LARSEN KØBENHAVNS UNIVERSITET DET NATURVIDENSKABELIGE FAKULTET DATALOGISK INSTITUT VEJLEDER: PROFESSOR BRIAN VINTER

2

3 ÓÖÓÖ Dette projekt er udarbejdet som afgangsspeciale fra datalogistudiet på Datalogisk Institut på Københavns Universitet og beskriver tilblivelsen af Distributed Shared Memory for the Cell Broadband Engine (DSMCBE). Først og fremmest vil vi gerne takker vores vejleder professor Brian Vinter for god vejledning gennem hele forløbet. Derudover skal der lyde en tak til ph.d. studerende Martin Rehr, for hjælp i forbindelse med MiG og DIKU s PS3 klynge. Også tak til de medstuderende, som vi gennem studiet har svedt sammen med. Vi skal også takke Georgia Institute of Technology (Sony-Toshiba-IBM center of Competence) og the National Science Foundation, for at vi har fået adgang til deres Cell Broadband Engine klynge. En særlig tak skal lyde til vores respektive familier og kærester for opmuntring og støtte gennem hele studiet. Kenneth Skovhede Morten Nørgaard Larsen

4

5 Ê ÙÑ En af de helt store udfordringer ved at udvikle programmer til Cell BE arkitekturen er fraværet af fælles delt hukommelse. Ved at analysere eksisterende DSM systemer, og sammenholde erfaringer fra disse, med viden om Cell BE arkitekturen, har vi konstrueret DSMCBE. DSMCBE er det første DSM system som er specielt udviklet til at benytte den specielle Cell BE arkitektur. Ved at skabe en illusion om, at alle enheder i en klynge af Cell BE maskiner, har fælles hukommelse, bliver det hurtigere at udvikle nye programmer. Dette baner vejen for at kunne benytte en klynge af PlayStation 3 (PS3) maskiner i stedet for en supercomputer. Derudover bliver det lettere at udvikle programmer til en enkelt Cell BE maskine, såvel som til en klynge baseret på Cell BE maskiner. Ved at lade et DSM system håndtere overførsel mellem LS og hovedhukommelsen, såvel som mellem individuelle maskiner, er det muligt at opnå en form for cache, i den ellers begrænsede LS, hvilket kan give en markant forbedret ydelse. I dette speciale fokuserer vi på udvikling og kørsel på en klynge af de 16 PS3 maskiner som DIKU har til rådighed. Resultaterne viser at det er væsentligt nemmere at benytte DSMCBE, frem for at håndtere hukommelsesoverførsler manuelt. Resultaterne viser samtidig at nedgangen i ydelsen er målbar, med acceptabel for de fleste type problemer. Selvom DSMCBE er et funktionelt system, præsenterer vi også en lang række af muligheder for yderlig optimering og udvidet funktionalitet, der kan gøre DSMCBE endnu mere attraktivt i fremtiden. Vi håber på at DSMCBE vil åbne op for at der hurtigere bliver implementeret en lang række af traditionelle HPC biblioteker på Cell BE platformen.

6

7 ØÖ Ø One of the major challenges with program development for the Cell BE architecture, is the absence of shared memory. By analyzing existing DSM systems, and combining the experience from these, with knowledge of the Cell BE architecture, we have developed DSMCBE. DSMCBE is the first DSM system especially developed for the Cell BE architecture. By creating the illusion that all units in a Cell BE cluster shares the same memory, it becomes faster to develop new programs. This enables the usage of a cluster of Play- Station 3 (PS3) machines instead of a super computer, and at the same time eases the development effort required to write programs for both a single Cell BE machine, as well as a cluster based on Cell BE machines. When the DSM system handles transfers between the LS and main memory, as well as between machines, it is possible to achieve a cache mechanism on the otherwise limited LS, which can result in a noticeable performance speedup. In this master thesis we focus on development and execution on a cluster of the 16 PS3 machines available at DIKU. The results show that it is significantly easier to use DSMCBE rather than manually handling memory transfers. The results also show that the performance reduction is measurable, but acceptable depending on the problem. Even though DSMCBE is a functional system, we present a list of possible performance and functionality enhancements, which can make DSMCBE even more attractive in the future. We hope that DSMCBE will enable faster implementation of many traditional HPC libraries on the Cell BE platform. Ú

8

9 ÁÒ ÓÐ ÓÖØ Ò Ð Forord Resumé Abstract Indholdsfortegnelse Indledning Forkortelser i iii v vii xi xiii 1 Cell BE arkitekturen Cell BE PPE SPE enheder EIB Sammenfatning Netværkets indflydelse på et distribueret system Udvidede modeller Heterogent Cell miljø Topologi Sammenfatning Vedligeholdelse af data Synkronisering af data Data lokalitet Konsistens Problemstillinger i et distribueret system Synkronisering Opdeling af data False sharing Adresseringsstruktur Netværksprotocol Ú 4.6 Heterogene og homogene systemer Fejltollerence Sikkerhed Overlapped Execution

10 ÁÒ ÓÐ ÓÖØ Ò Ð 4.10 Deadlocks og livelocks Grundlæggende løsningsmodeller Problemer i multiprogrammering Sammenfatning Eksisterende systemer Mether Dash Munin Midway CLOUDS DiSOM Message Passing Interface - MPI Parallel Virtual Machine - PVM Communicating Sequential Processes - CSP Tuplespaces CellSs Alf Sammenfatning DSMCBE design overvejelser Scenarie og designkrav DSMCBE Komponenter Erhvervelse af et dataobjekt Oprettelse af et delt dataobjekt Frigivelse af et dataobjekt Invalideringsfunktionalitet Opdatering af objekttabellen Videresendelse til home-node Asynkrone kald fra en SPU Streaming af data til SPU Sammenfatning Implementationsovervejelser Fase 1: Grundimplementation Fase 2: Tråde på SPE Fase 3: Læse adgang til data Fase 4: Klynge af maskiner Fase 5: Minimering af SPE kode Fase 6: Migration Fase 7: Streaming understøttelse på SPE Afprøvning og resultater 75 Ú 8.1 Latenstider Cell BE kommunikationsformer Prototein Braintumor Heatequation

11 ÁÒ ÓÐ ÓÖØ Ò Ð 9 Erfaringer med Cell BE SPU kontrolkode LWSYNC DMA overførsler startet af PPU DMA liste overførsler Små DMA overførsler Mailbox og signaler Events Linux og WaitForAny Fremtidigt arbejde Bruger mailbox beskeder Kumulative opdateringer Opdatering vs. Invalidering Write-only Broadcast trees Partiel acquire Konklusion og perspektivering 101 Appendices 103 A Brugervejledning 105 A.1 Forudsætninger A.2 Overordnet virkemåde A.3 SPE håndtering A.4 Håndtering af netværk A.5 Barrierer A.6 Hello world B Målinger 115 B.1 Cell BE kommunikationsformer B.2 Protein B.3 Braintumor B.4 Heat equation Litteratur 121 C Rettelser 125 Ü

12

13 ÁÒ Ð Ò Ò Dette afsnit forklarer vores motivation for dette speciale, samt hvilken indgangsvinkel vi har benyttet. Vi har tidligere manuelt flyttet programmer fra andre multiprogrammeringssystemer til Cell BE. Under dette arbejde blev vi opmærksomme på hvor meget besvær der var i en sådan opgave. Vi bemærkede også at programmer med lavt hukommelsesforbrug er væsentligt nemmere at flytte, end programmer med højt hukommelsesforbrug. Det skyldes hovedsageligt at designet af Cell BE er markant anderledes end den gængse CPU arkitektur. Vi overvejede mange spændende projekter til Cell BE, men alle disse projekter havde en fælles tråd, nemlig at lette udviklingen af programmer til Cell BE arkitekturen. Det optimale scenarie må være at muliggøre kørsel af et traditionelt trådbaseret program, uden ændringer på Cell BE arkitekturen. Herefter kan man naturligvis tilføje nogle optimeringer for at opnå en bedre ydelse. Dette projekt er tænkt som første skridt mod et værktøj, som skal lette programmeringen af Cell BE arkitekturen. Uanset hvilken indgangsvinkel vi overvejede, opdagede vi hurtigt at det var et stort problem at holde styr på hukommelsen. Vi blev derfor enige om at det er nødvendigt med en bedre hukommelsesmodel til Cell BE. Da vi ikke anser det for sandsynligt at der bliver tilføjet ekstra hardware til Cell BE, har vi valgt at fokusere på en software baseret løsning. Vi har valgt at anskue en enkelt Cell BE maskine som et distribueret system, fordi dette passer godt med den faktiske opbygning i adskilte enheder. Vi har herefter valgt at undersøge hvilke systemer der anvendes til distribuerede systemer, samt hvilke design kriterier disse fokuserer på. Efter at have undersøgt de forskellige kriterier til distribuerede systemer, har vi betragtet disse som byggeklodser til en endelig løsning. Alle valg har en indflydelse på det endelige resultat. De fleste valg der foretages, er en balance mellem ydelse og kompleksitet i anvendelse. Da Cell BE arkitekturen lægger op til at give programmøren ansvaret, har vi fokuseret meget på ydelse. Dette virker også som det naturlige valg, da man i mange tilfælde vil kunne bygge nogle funktioner ovenpå løsningerne og opnå en mindre kompleksitet i anvendelse. Et godt eksempel på dette er konsistens, hvor man kan Ã Ð Ó tilføje ekstra regler til en løs konsistensmodel for at få en mere robust model. Efter at vi havde implementeret designet (afsnit 7), er DSMCBE afprøvet på 3 problemer, nemlig prototein foldning, braintumor og heat equation. Kørsel af disse 3 problemer, giver en god baggrund for at vurdere, hvor godt implementation klare sig i forhold til en håndoptimeret version. Kildekoden til programmet er tilgængelig under GNU Lesser General Public License på værktøjets hjemmeside Ved aflevering af specialet er SubVersion revisionsnummeret 333. Denne version af kildekoden kan ses viaü

14 ÁÒ Ð Ò Ò følgende link: I bilag A findes en dansk udgave af brugervejledningen, ligesom der i afsnit A.6 findes et simpelt Hello World kode eksempel. Ü

15 ÓÖ ÓÖØ Ð Ö Forkortelse Forklaring Acq(L) Acquire lock L BIF Cell Broadband Engine Interface Protocol. Cell BE Cell Broadband Engine CPU Central Processing Unit DMA Direct Memory Access DSM Distributed Shared Memory DSMCBE Distributed Shared Memory for the Cell Broadband Engine EA Effective Address EIB Element Interconnect Bus FFT Fast Fourier Transformation HPC High Performance Computing PRAM Parameter Random Access Memory L1 Level 1 L2 Level 2 LRU Least Recently Used LS Local Storage MFC Memory Flow Controller MIC Memory Interface Controller MIPS Microprocessor without Interlocked Pipeline Stages MMU Memory Management Unit MRU Most Recently Used MTBF Mean Time Between Failure MTU Maximum Transmission Unit PPE Power PC Element PPU Power PC Unit PS3 PlayStation 3 R(x) Read x R(x)n Read x resulting in n Rel(L) Release lock L RISC Reduced Instruction Set Computer S Synkroniseringspunkt SIMD Single Instruction, Multiple Data SPE Synergistic Processing Element SPU Synergistic Processing Unit VMX Vector Multimedia Extension W(x)n Write n into x Ü

16 Ü Ú ÓÖ ÓÖØ Ð Ö

17 Ã Ô Ø Ð½ ÐÐ Ö Ø ØÙÖ Ò Siden konstruktionen af den første computer har der været en vedvarende udvikling således at der hele tiden produceres mere kraftfulde processorer. Denne udvikling har været så kraftig at processorstørrelsen, målt i antallet af transistorer, fordobles for hvert andet år[1]. Dette har foregået siden Gordon E. Moore formulerede dette i Indtil nu har denne udvikling primært været drevet af evnen til at producere stadigt mindre transistorer. Selvom grænsen for hvor små transistorer kan være, gradvist er flyttet, ser ½º½ det dog ÐÐ ud til, at den ultimative grænse rammes i den nærmeste fremtid[4]. Selvom både klokfrekvensen og antallet af transistorer er steget, er hastigheden på hukommelse ikke fulgt lige så godt med. Dette fænomen betegnes som memory-wall problemet[5]. Et andet væsentligt problem, er at transistorerne benytter meget strøm, og derfor bliver enormt varme. Sony, Toshiba og IBM (STI alliancen) har med deres innovative Cell BE arkitektur forsøgt at løse disse problemer, ved at opdele maskinen i specifikke enheder. Traditionelle maskiner er enten specialiserede til beregningstunge opgaver, eller til generel brug. Ved at opdele processoren i flere dele, er det muligt at have en maskine der er i stand til at fungere som både specialiseret og multi-purpose maskine. Dette er grundprincippet i Cell BE arkitekturen. Hovedprocessoren i en Cell BE arkitektur, kaldet PPE en, er en traditionel Power PC chip, hvilket vil sige en RISC baseret chip med MIPS instruktionssættet. Denne processor er optimeret til hurtige og ofte trådskift, og egner sig derfor til multi-purpose formål, såsom operativsystemer og brugerintensive programmer. Udover hovedprocessoren, indeholder en enkelt Cell BE maskine også 8 specialiserede processorer, kaldet Synergistic Processing Element (SPE). Disse enheder er specialiseret til at håndtere beregninger på enkelt præcision flydende tal. SPE elementerne er også RISC MIPS enheder, men indeholder ingen prefetch cache 2 eller branch prediction. SPE elementerne indeholder hver 256KB hukommelse kaldet LS, der fungerer som både instruktions og data hukommelse. Hver SPE enhed indeholder en MFC der kan overføre data fra hovedhukommelsen via asynkrone DMA overførelser. ½ SPE enhederne kan under optimale forhold udnytte SIMD instruktioner og eksekvere to instruktioner per clockcycle. Derimod er trådskift en kostbar affære, og der er kun 1 Der siges ofte 18 måneder, men faktisk er det 2 år[2, 3] 2 Kaldes også L1 og L2 cache

18 Ã Ô Ø Ð½º ÐÐ Ö Ø ØÙÖ Ò et begrænset udvalg af interrupt funktionalitet. Dokumentationen[6] fra IBM beskriver at SPE enhederne kan håndtere multimedie beregninger. Heldigvis viser det sig at en stor del af problemerne fra naturvidenskaben kræver meget beregningskraft og derfor kan drage nytte af disse højtydende SPE enheder. En oversigt over Cell BE arkitekturen kan ses i figur 1.1. ½º¾ ÈÈ Figur 1.1: Oversigt over Cell BE arkitekturen. Figuren illusterer delenhederne og deres forbindelser, med angivet hastighed. Figuren er gengivet fra IBM DeveloperWorks[7]. PPE enheden er baseret på en traditionel PPC arkitektur med MIPS instruktionssættet, men har fået tilføjet en VMX 3 chip. Herudover indeholder PPE enheden 32KB L1 cache samt 512KB L2 cache. Internt har PPE enheden en hukommelsesbåndbredde på 51.2GB/s. Udover VMX udvidelsen, adskiller PPE en sig ikke fra en traditionel arkitektur. Hvis man fjerner SPE enhederne og EIB en, har man faktisk en traditionel maskine. ¾ 3 VMX er en SIMD floating point co-processor, og ligner Intel SSE. VMX kaldes også AltiVec og Velocity Engine[8]

19 ½º ËÈ Ò Ö ËÈ Ò Ö Modsat PPE enheden, følger SPE enhederne ikke de traditionelle design mønstre for CPU er. SPE enhedens beregningsmæssige kerne er en SPU chip, med en registerfil hvori der findes 128 registre på hver 128bit. Der er ingen dataprefetch, og der er heller ingen L1 eller L2 cache. SPE er optimeret til streaming operationer, hvilket vil sige sekventiel tilgang. Den 2KB store registerfil gør rekursive kald og trådskift til en bekostelig affære. Figur 1.2 giver en oversigt over SPE arkitekturen. ÄË Figur 1.2: Oversigt over en SPE. Elementerne til venstre i billedet udgør SPU delen, mens LS og MFC findes i højre side. Pilene illustrerer hvorledes de enkelte komponenter interagerer. Figuren er gengivet fra IBM DeveloperWorks[7]. Hver SPE indeholder 256KB dedikeret lokal hukommelse. Denne dedikerede hukommelse kaldes Local Store og skal deles mellem data og kode. Hukommelsen fungerer Å ved 128 bytes operationer, og kan håndtere 16 bytes og én kommando pr. clockcycle. De 256KB hukommelse er en særdeles begrænset ressource, og meget af Cell BE arkitekturens kompleksitet opstår når et program skal forsøge at holde SPU en mættet med data. SPE enheden indeholder en MFC, der håndterer kommunikation mellem hovedhukommelsen og LS. Dette bevirker at SPU enheden kan starte en DMA overførsel, og herefter beregne uden at blive forstyrret under transmissionen. MFC enheden kan overføre 128 byte pr. operation, og kan overføre op til 16KB med en enkelt kommando. Ønskes større overførsler, kan der oprettes lister og herved kan der overføres mere data. Bemærk at

20 Ã Ô Ø Ð½º ÐÐ Ö Ø ØÙÖ Ò ËÈÍ man godt kan overføre mere data en der er ledig plads på SPE en. I disse lister, kan der indsættes kontrolpunkter, således at det ikke er et krav at data overføres fra et kontinuerligt stykke. Programmering af MFC enheden fjerner herved næsten alt hukommelsesmæssigt overhead fra SPU enheden. Selve ½º SPU Á enheden indeholder to pipelines, hvoraf den ene indeholder beregninger på flydende tal 4 eller heltal, og den anden indeholder branch og IO instruktioner (se figur 1.2). Det er altså ikke muligt at udføre to operationer på flydende tal samtidig, men SPU elementet understøtter SIMD[9] operationer og på den måde kan antallet af afgivne instruktioner reduceres. For at maksimere udbytte af de adskilte beregningsenheder, er alle enhederne forbundet med en kraftig bus, kaldet Element Interconnect Bus. EIB en forbinder de 8 SPE enheder med PPE, en Memory Controller og to I/O enheder, altså ialt 12 enheder. EIB bussen kører halv hastighed af PPE en, der går altså to PPE clock cykles per EIB clock cycle. Hver enhed på EIB bussen kan læse og skrive 16 bytes per cycle. EIB fungerer som en slags karrusel, hvori der findes 12 hylder. Der findes 4 karruseller, og hver clock cycle roterer Å Ð ÓÜ 2 karruseller med uret, og 2 karruseller mod uret. Dette design gør at det er bedre at kommunikere med den umiddelbare nabo, da der her er mindre latency, samt mindre mulighed for blokering af en anden operation. Dog gør tovejs rotationen, at der er to naboer der har mulighed for maksimal ydelse, men der er nogle specielle trafikmønstre der ikke fungerer optimalt på en EIB. Figur 1.3 giver en oversigt over EIB en. Da EIB en er beregnet til at overføre streaming data, er den ikke velegnet til at overføre små mængder data, såsom kontrol kommandoer og lignende. For at overkomme dette problem, er der implementeret et mailbox system. Det er muligt at anvende en mailbox til Ë Ò Ð Ö at overføre 32bit værdier mellem SPE erne og PPE en. Mailbox systemet indeholder en kø, således at der kan være op til fire 32bit beskeder i kø. Hver SPE har 3 mailboxe, en indgående mailbox, en udgående mailbox og en udgående interrupt mailbox. Interrupt mailboxen kan anvendes til at udføre en interrupt på en PPE når der skrives til denne. Der findes ikke en indgående interrupt mailbox. Udover mailbox e, indeholder Cell BE arkitekturen også en signal mekanisme. Signal mekanismen fungerer stort set ligesom en mailbox, men tillader at der sendes enkelte bits via et OR mode. Ved at anvende signaler i stedet for mailbox e kan PPE en aflæse 32 statusbits med et enkelt kald, i stedet for at læse et antal mailbox beskeder. Det er også muligt at konfigurere systemet således at der startes et interrupt på et SPE element ved modtagelse af et signal, ligesom SPE til SPE kommunikation er muligt. 4 Normalt antages det at et flydende tal er IEEE dobbelt precision, men SPU enheden understøtter kun enkelt precision i første udgave. Dobbelt precision understøttelse forventes dog at være tilgængelig på nye modeller, indenfor nærmeste fremtid.

21 Ë ÑÑ Ò ØÒ Ò ½º Figur Ë ÑÑ Ò ØÒ Ò 1.3: Oversigt over en EIB. For hver rampe vises, at der findes fire karrusel pladser, og de farvede pile angiver retningen. De gennemgående markerede ruter illustrere en igangværende overførsel. Figuren er gengivet fra IBM DeveloperWorks[10]. Desværre er der en del komplikationer når der skal udvikles programmer til denne arkitektur. De to hovedproblemer er at maskinen indeholder to forskellige arkitekturer, samt at de enkelte enheder ikke har fælles hukommelse. Disse to problemer betyder at programmeringen af en enkelt Cell BE maskine kommer til at minde om programmeringen af en klynge af maskiner. Forskellen mellem klynge programmering og programmering af en Cell BE maskine, er primært at de enkelte enheder er bundet sammen omkring en særdeles hurtig hukommelsesbus (EIB), og ikke et netkort. Denne forskel er dog primært en ydelsesmæssig fordel, og ændrer ikke noget ved kompleksiteten af programmering i et heterogent klynge miljø. For at udnytte det fulde potentiale af Cell BE arkitekturen, er det altså nødvendigt at skrive programmerne efter samme principper, som man benytter når man skriver programmer til distribuerede systemer. Der findes allerede en del systemer til håndtering af distribuerede programmer, f.eks. MPI[11] og PVM[12], men ingen af disse er skrevet til Cell BE arkitekturens specielle opbygning, og kan derfor ikke udnytte de hurtige SPE er. Der findes andre systemer, såsom Alf[13] og CellSs[14], der kan udnytte Cell BE arkitekturen. Vi vil beskrive disse systemer i kapitel 5.

22

23 Ã Ô Ø Ð¾ Æ ØÚÖ Ø Ò Ý Ð Ô Ø ØÖ Ù Ö Ø Ý Ø Ñ I traditionelle klynge systemer anvendes en form for kablet interconnect til at forbinde de enkelte systemer. I Cell BE arkitekturen er komponenterne forbundet med en EIB. Dette ændrer radikalt på karakteristikken for forbindelsens båndbredde og latenstider. Ifølge Cell BE dokumentationen[6], kan hver SPU enhed på bussen sende 16 byte i hver buscyklus. På en 3.2GHz maskine, er en buscyklus 1.6GHz 1, og teoretisk maksimal vedvarende kapacitet er derfor: 128Bx1.6GHz = 204.8GB/s[7]. Til sammenligning har Earth Simulator enhederne 256GB/s hukommelsesbåndbredde[15]. Som interconnect mellem Cell BE enhederne anvendes et almindeligt Ethernet kort, med en båndbredde på 1 GBit/s, dog har Cell blades mulighed for at benytte infiniband. Til sammenligning anvender Earth Simulator en fuld interconnect på 12.3 GB/s[15]. Den store forskel på båndbredden i EIB og interconnect har enorm indflydelse på den endelige ydelse af systemet. Som beskrevet i kapitel 1, er de fleste systemer ikke længere bundet af CPU ydelse, men derimod hastigheden af hukommelsen. EIB er optimeret til at streame data, og det er derfor nødvendigt at sørge for at samle data i store pakker, i stedet for at sende små mellemresultater[10]. Hver overførsel kan overføre op til 128 bytes, og da hver overførsel samtidig er låst til 8 clock cykles, vil overførsler på mindre end 128 bytes medføre tabt transmissionskapacitet. Udover båndbredde, skal der normalt også tages højde for latenstider, hvilket er den tid der går fra afsendelsen er sat igang til første data stykke er modtaget. I teorien bør latenstiden ikke variere selvom størrelsen på data der afsendes varierer, men i praksis sker dette ofte, da der skal opsættes buffere og lignende til data. For at illustrere forholdet mellem båndbredde og latenstider, har vi produceret to figurer, der henholdsvis viser tiden det tager at sende data (figur 2.1), samt latenstiden (figur 2.2) for forskellige pakkestørrelser 2. Som det ses, stiger latenstiden først markant når pakkestørrelsen overstiger 64KB. Dette skyldes formentlig at netkortet/driveren har en buffer på 64KB og derfor skal der allokeres ekstra lagerplads til data før transmissionen kan starte. Båndbredden stiger først rigtigt når pakkestørrelsen kommer over 8KB. Da en PS3 har en hypervisor til at håndtere netværkskommunikation, introduceres der en lille forsinkelse ved afsendelse af pakken. Dette overhead er konstant, og derfor bliver det mindre dominerende når pakkestørrelsen stiger. Båndbredden kommer aldrig i nærheden af de proklamerede 1Gb/s, men det er fordi der kun sendes en enkelt pakke. Når der sen- 1 Bussen kører halvt så hurtigt som processoren 2 Data til figurer er produceret af Hans Henrik Happe

24 Ã Ô Ø Ð¾ºÆ ØÚÖ Ø Ò Ý Ð Ô Ø ØÖ Ù Ö Ø Ý Ø Ñ des en strøm af pakker forsvinder opstartsforsinkelsen og herved bliver det formentlig muligt at komme tættere på den maksimale hastighed. ¾º½ Figur Í Ú ÑÓ ÐÐ Ö 2.1: Båndbredde målt med NPtcp benchmark, mellem en Playstation 3 med 1Gbit netkort og et Broadcom 1Gbit kort. Data er opsamlet og leveret af Hans Henrik Happe. Traditionelt har distribuerede systemer fokuseret på de to parametre latenstid og båndbredde. En mere varieret model er LogP modellen[16]. LogP modellen beskæftiger sig med begreberne latency, overhead, gap og processors. I denne model er båndbredde udregnet ved L/g. Ved at anvende denne udvidede model, kan det påvises at mange distribuerede programmer er meget mere følsomme overfor ændringer i overhead end latency[17] 3. En mere avanceret model er LogGP[18], som også inkluderer en ekstra G parameter der angiver tid-per-byte. Denne ekstra G parameter sikrer at burst overførsler og DMA overførsler bliver modelleret korrekt. Undersøgelser med LogGP modellen bekræfter at overhead parameteren bidrager mest til negativ ydelse, men viser også at de fleste applikationer er følsomme overfor g parameteren. ¾º¾ À Ø ÖÓ ÒØ ÐÐÑ Ð I en Cell klynge findes der både EIB og netkort. De resultater vi har fundet viser at forbedringer i kommunikationsdelen vil give kraftige forbedringer i applikationens overordnede ydeevne. Vi kan derfor forvente at en gruppering der placerer mest mulig kom- 3 overhead betegnes her for contention

25 ÌÓÔÓÐÓ Figur 2.2: Latenstider målt med NPtcp benchmark, mellem en Playstation 3 med 1Gbit netkort og et Broadcom 1Gbit kort. Data er opsamlet og leveret af Hans Henrik Happe. ¾º ÌÓÔÓÐÓ munikation på EIB vil have god ydelse, og at det omvendte gør sig gældende med kommunikation over standard TCP/IP netværk. Et netværk der har en forbindelse fra alle komponenter til alle komponenter, kaldes også full interconnect network. Et sådan netværk har den attraktive fordel at det er let at sende en besked fra et sted til et andet. Desværre er sådan en løsning også den økonomisk dyreste, og stiller store krav til den hardware der skal stå for besked håndteringen. Da der sjældent er fuld belastning på samtlige forbindelser, kan man overveje at fjerne enkelte strategiske forbindelser. Hvis hver maskine har to forbindelser, kan man bygge en ring og lade en besked vandre rundt i ringen, indtil den når destinationen. Selv i dette simple tilfælde, skal der dog benyttes routing, for at afgøre om det er hurtigst at sende den ene elle den anden vej rundt i ringen. Hvis der introduceres flere forbindelser, skal der anvendes mere og mere avancerede routing algoritmer, indtil at alle er forbundet med alle. Da routing er et kendt problem, vides det at routing ikke kan afgøres i lineær tid, specielt ikke hvis de enkelte beskeder har prioritet. I en enkelt Cell BE anvendes den specielle EIB, som er baseret på en karrusel (se afsnit 1.4). For at et Cell BE system kan yde optimalt, er det nødvendigt at EIB en yder maksimalt. Dette kræver dog at der implementeres pakke schedulering og routing, hvilket er meget svært at udføre, da tiden der kan anvendes på dette er meget begrænset. Hvis der ønskes bedre pakke schedulering, skal der findes en overordnet enhed der kan overvåge og bestemme pakkeflowet. En sådan enhed vil meget hurtigt blive en flaskehals.

26 ¾º Ë ÑÑ Ò ØÒ Ò Ã Ô Ø Ð¾ºÆ ØÚÖ Ø Ò Ý Ð Ô Ø ØÖ Ù Ö Ø Ý Ø Ñ Konklusionen fra LogGP[18] modellen viser at overhead fra et traditionelt LAN system 4 reducerer ydelsen med op til faktor 50. Selv mindre kommunikationsintensive applikationer får reduceret ydelse med en faktor 3-5. Dette betyder at enhver reduktion i antallet af pakker vil give væsentligt større ydelses forbedring, end en reduktion i pakkestørrelsen. Disse oplysninger betyder også at ydelse formentlig kan øges væsentligt, hvis der udvikles en driver der kommunikerer direkte med netkortet, og ikke går gennem operativsystemet, sådan som det er nu. Et system der håndterer netværksoperationer uden overhead fra operativsystemet er Virtual Interface Architecture, også kaldet VIA[19]. Selve VIA ser ikke ud til at blive benyttet længere, men idéerne fra VIA bliver benyttet i bl.a. Infiniband[20]. ½¼ 4 ca. 100µs

27 Ã Ô Ø Ð Î Ð ÓÐ Ð Ø I dette afsnit vil vi beskrive modeller og metoder til at sikre at data opfattes konsistent i systemer hvor data tilgås parallelt. Vi vil først beskrive de problemer, der er med at holde alle processer synkroniseret. Herefter vil vi beskrive hvorledes der kan holdes styr på data, når dette flyttes mellem flere enheder, og til sidst vil vi beskrive de formelle º½ ËÝÒ ÖÓÒ Ö Ò Ø regler for konsistens. Vi vil igennem hele kapitlet holde de relevante modeller op imod Cell BE arkitekturen. Dette kapitel, inklusiv figurer, tager udgangspunkt i Distributed Shared Memory - A Survey of Paradigms and Concepts in Distributed Shared Memory Research [21]. I en Cell BE baseret maskine, har SPE enhederne ikke direkte adgang til hovedhukommelsen. Værktøjet skal derfor flytte data fra hovedhukommelsen til LS. Så længe data ikke ændres er dette en forholdsvis simpel opgave. Desværre er der ikke meget idé i at beregne på data, uden at videregive data. Dette betyder at der på et tidspunkt skal skrives til hukommelsen, og herved opstår der kompleksitet i systemet. Specielt er det et problem hvis en SPE skal opdatere data og en anden SPE umiddelbart efter skal regne videre på det opdaterede data. Data kan typisk opdeles i read-only, read-write og write-only. Read-only er lettest at håndtere, da denne blot indebærer kopiering af data fra et sted til et andet. Read-write kræver derimod en mekanisme til at sende ændringer videre. Der har typisk været anvendt to modeller, nemlig write-invalidering og write-opdatering[22, 23]. En invalidering sender blot en besked rundt i systemet, hvor der angives at den givne datablok ikke længere er gyldig. Hvis der igen ønskes tilgang til denne, må data hentes påny. Alternativt kan der benyttes en opdatering, hvor det opdaterede indhold medsendes i invalideringsbeskeden. Hvis det typiske scenarie er, at hentet data ikke benyttes mere end en gang, kan en invalidering være bedst, mens systemer hvor de opdaterede data skal anvendes, fungerer bedst med opdaterings modellen. Hvis der anvendes en invalideringsmodel, vil en invalidering samtidig medføre at datakopien ikke længere er aktiv. Ved næste invalidering på samme objekt, er det ikke nødvendigt at sende en ny invalidering før datakopien er hentet igen. Ved opdatering, ½½ findes denne semantik ikke, og der skal derfor være mulighed for at afmelde en kopi, da der ellers vil blive sendt uønskede opdateringsbeskeder så længe systemet kører.

28 º½º½ ÖÓ Ø Ã Ô Ø Ð ºÎ Ð ÓÐ Ð Ø For at en SPE enhed kan udføre beregninger på data der er ændret af en anden enhed, skal data naturligvis placeres således at det er tilgængeligt. Hvis data kun kan læses, er det simpelt at kopiere data rundt. Hvis en SPE skriver til data, skal alle kopier af data opdateres. En alternativ model er at flytte data, således at der altid kun er en aktiv kopi af data. Dette er dog særdeles ineffektivt, da de fleste problemer har gavn af at mere end én process kan tilgå data. En umiddelbar løsning er at udføre en broadcast når data ændres. Denne broadcast kan º½º¾ ØÔÐ Ö Ò enten invalidere kopier, eller indeholde de opdaterede data. Det er dog ikke alle systemer der understøtter broadcast, og selve broadcast systemet vil benytte ressourcer på alle maskiner, selvom disse ikke har det pågældende data. Et system baseret på broadcast vil ikke kunne skalere effektivt, da antallet af beskeder stiger eksponentiel i forhold til antallet af maskiner[24]. En mere skalerbar model, er at holde en reference til alle enheder der har modtaget en kopi af data. Når data bliver opdateret, kan der sendes en besked til hver af disse enheder, og hermed reduceres antallet af beskeder til et teoretisk minimum. Problemet med denne model er at der også skal vedligeholdes en liste over kopier. Når en enhed ønsker º½º Å Ö Ö Ò at opdatere data, skal denne enhed først finde listen. Problemet bliver så at lokalisere data, og der er foreslået flere løsninger på dette problem[22]. En simpel model er at benytte den enhed der oprettede data, til at vedligeholde listen. Problemet med dette, er at denne enkelte maskine ikke nødvendigvis er den hvor data oftest opdateres. For º½º Ê Ö ÔÐ Ö Ò at løse det overstående problem, kan der anvendes migrering af data. Migrering gør dog at det ikke længere er simpelt at finde den nuværende liste, og der skal nu tages stilling til hvor ofte der skal migreres. Hvis der migreres ved hver skrivning vil der sandsynligvis opstå thrashing[25]. Hvis der aldrig migreres, er situationen det samme som ved en fast placering. En anvendt model er at flytte placering ved en skriveforespørgsel. Dette sikrer at den enhed der skriver til data også har den aktuelle liste. Dette kræver at der kun replikeres kopier der kan læses. Systemet er meget simpelt, og minder lidt om copy-on-write modellen[26]. Denne model løser dog ikke problemet, og vil i nogle tilfælde være fuldt identisk med konstant migrering. Vi har ikke fundet dokumentation for en optimal opsætning af kriterier for replikering. Vi foreslår en løsning hvor der gemmes antal forespørgsler pr. enhed, og når forholdet mellem lokale tilgange og en fjerntilgang overstiger ½¾ en given tærskel, migreres der. Eftersom forholdet i et balanceret system vil være 0.5, må denne tærskel ligge i intervallet ]0.5 : 1.0[.

29 º½º ÙÐ Ö ÔÐ Ö Ò ÙÐ Ö ÔÐ Ö Ò En speciel datatilgang er write-only data, og denne type kan optimeres. Write-only data er typisk anvendt i forbindelse med resultater, hvor flere enheder opdaterer en blok med resultater der aflæses af en enkelt enhed[21]. Det specielle ved denne datatype er at det º½º Ë ÑÑ Ò ØÒ Ò ikke er nødvendigt at kommunikere ændret data fra en enhed til en anden, og der kan derfor spares en del kommunikation. For at kunne afgøre hvilke data der er ændret, af en given enhed, gemmes der ofte en kopi af data, kaldet en twin eller replika. Når data skal sendes, beregnes forskellen mellem den ændrede version og den originale. Denne difference sendes herefter til den enhed der står for indsamling af data. Vi ønsker at systemet skal kunne skalere og give maksimal ydelse. Forsøg viser at dette bedst opnås ved at lade programmøren vælge mange indstillinger[27]. Dette er desværre det modsatte af transparent adgang til hukommelse. Vi mener derfor at det optimale system kan konstrueres ved at implementere specifik håndtering til henholdsvis readonly, read-write º¾ Ø ÐÓ Ð Ø Ø og write-only data, altså fuld replikering. Update modellen har nogle faldgrupper og kan formentlig ikke yde optimalt, hvis den anvendes på alle objekter[23]. Invalideringsmodellen har potentiale for optimering, men vil i nogle tilfælde tilføje venten og unødige beskeder. Det bør derfor være muligt at definere hvilken metode der skal anvendes, på hvert enkelt objekt, gerne med mulighed for ændring under kørslen. Et af problemerne med distribueret delt hukommelse er at finde data. Problemet løses º¾º½ËØ Ø Ö ofte ved at give data en ejer. Ejeren af data er den eneste som må skrive til data og hvis der findes kopier af data, skal disse synkroniseres ved skrivning. Vi vil senere komme ind på forskellige måde at udføre denne synkronisering på. Herunder vil vi først beskrive forskellige metoder til at styre ejerskabet og derefter beskrive forskellige metoder til synkronisering. Dette er den simpleste form for ejerskab, hvor data har den samme statiske ejer fra start til slut. Da ejeren er fikseret er det også nødvendigt for andre, som ønsker at skrive til data, at aftale med ejeren hvordan dette skal foregå. Man kunne forestille sig at en node 1 på maskine A ofte ønskede at skrive til data X som har en ejer på maskine B. Derved º¾º¾ ÝÒ Ñ Ö ville node 1 altid skulle over et netværk for at få lov til at skrive til data. Dette betyder selvfølgelig en mængde unødvendig kommunikation i forbindelse med skrivning af data, samtidig med at en ejer af noget data som der ofte bliver skrevet til, nemt bliver overbelastet. Fordelen ved statisk ejerskab er at det er nemt at finde data, da man kan anvende et adresseringssystem, hvor ejerens adresse er en del af dataadressen. ½ Det modsatte af statisk ejerskab er dynamisk ejerskab, hvor ejeren af data kan skifte undervejs. Problemet med at finde data, bliver selvfølgelig noget mere besværligt og kan foregå på flere måder, som vi vil komme ind på senere. De åbenlyse fordele ved dynamisk ejerskab er selvfølgelig at data kommer fysisk tættere på en node som ofte

30 Ã Ô Ø Ð ºÎ Ð ÓÐ Ð Ø º¾º¾º½ ÒØÖ Ð Ö Ø ÖÚ Ö skriver til data og man undgår en masse kommunikation i forbindelse med en skrivning. På den anden side, betyder det at data bliver noget sværere at finde, eftersom man ikke længere kan beregne ejeren ud fra adressen på data. En af måderne hvorpå man kan finde data, er at bruge en centraliseret server, som holder styr på hvem der ejer de forskellige data. Desuden kan denne server også overvåge hvem der har læsbare kopier af data, hvilket er meget anvendeligt i forbindelse med invalidering eller opdatering af data. Alle som ønsker at skrive til noget data, sender en besked til serveren, som behandler beskederne efter tur f.eks. ved hjælp af en FIFO kø. Serveren kan enten give den spørgende node adressen på den nuværende ejer, eller bede ejeren om at tage kontakt til spørgeren. Hvis man kan garantere at ingen beskeder bliver tabt, kan den sidstnævnte metode spare en besked fordi spørgeren ikke skal have adressen º¾º¾º¾ ØÖ Ù Ö Ø ÖÚ Ö på ejeren. Hvis der derimod kan opstå beskedtab, kan man ikke garantere, at ejeren der bliver spurgt, er den samme, som den centraliserede server tror er ejeren. Ulemperne ved en centraliseret server, er selvfølgelig single-point-of-failure dvs. at hvis serveren går ned, så virker intet. Derudover skalerer løsningen meget dårligt, da arbejdsmængden for den centrale server vokser lineært med mængden af data. Hvis det viser sig at den centraliserede server bliver for belastet kan man udvide med flere servere, som så holder styr på hver deres del af data. Det ligner umiddelbart en god løsning, men det flytter, i den yderste konsekvens, bare problemet et niveau op, således at problemet nu bliver at finde den server, som holder styr på ejerskabet af det data man ønsker at tilgå. Det kan løses med broadcast, men broadcast kommer dog ikke uden en pris. Prisen er at der i store systemer vil blive sendt så mange broadcast beskeder, at det overskygger de almindelige beskeder. Derudover skal en node hver gang den modtager en broadcast, stoppe sit nuværende arbejde og tage stilling til broadcast beskeden. En anden løsning på dette problem er at lade hver node have en log som indeholder den sidste kendte position af data. Denne information vil naturligvis ikke kunne være rigtigt hele tiden, da positionen sagtens kan flytte sig. Dog vil den sidste kendte position havde en bedre idé om hvor data befinder sig og man vil på den måde nærme sig sandheden º¾º¾º ÀÓÑ om hvor data befinder sig. Da man kan antage at den node som kommer med forespørgselen på et tidspunkt vil finde data og blive den nye ejere, kan alle tidligere ejere som bliver spurgt, med fordel opdateres, således at de peger på denne node som ny ejer. Prisen for denne løsning er at der bliver sendt en del beskeder rundt i netværket, men i praksis har det vist sig at være en god løsning[21]. Home based distribution fungerer ved at hver datablok har et origo dvs. et sted hvor den hører til. Alle anmodninger om at ændre data går gennem dette origo. Dette minder meget om den måde hvorpå de distribuerede servere fungerer, dog med den ændring at udover ½ at holde øje med hvor data befinder sig, har dette origo også en aktuel version af datablokken. Denne hjemme-node skal løbende sørge for at indsamle ændringer i data, således at dens aktuelle version hele tiden er opdateret. Når en anden node anmoder om adgang til data, invaliders alle læsbare kopier af data og der kan sendes en kopi af den aktuelle version af data.

31 º¾º¾º Ö ØÓÖÝ Ö ØÓÖÝ Denne form for data konsistens fungerer ved at alle noder deles op i nogle biblioteker og º¾º Ë ÑÑ Ò ØÒ Ò hver af disse biblioteker har en lokal biblioteksserver som holder styr på, hvilke noder der ejer hvilke data. Disse lokale biblioteksservere er forbundet til en super biblioteksserver som ligger et niveau højere. Der er ingen begrænsning i hvor mange niveauer der kan være. Directory based er fortrinsvist beregnet til store hardware implementerede DSM systemer og f.eks. Dash[28] benytter sig at dette system, til at finde data. º ÃÓÒ Ø Ò Home based distribution giver god ydelse i forhold til kompleksiteten af algoritmen. Derfor virker den som det oplagte valg i vores tilfælde når man ser på en klynge af Cell BE maskiner. Når man ser på den enkelte Cell BE maskine, vil en centraliseret server model var oplagt. Dette skyldes at PPE en er oplagt til at være den centrale server og SPE erne kan så spørge PPE en, hvor data befinder sig i hovedhukommelsen. En god model til at sikre konsistens i hukommelsen er essentiel i forhold til ydelsen af DSM systemer. Igen består valget mellem god ydelse og let tilgang, og ofte vil man vælge at tillade at hukommelsen ikke altid er konsistent, mod at få en betydelig bedre ydelse. º º½ËØÖ Ø ÓÒ Ø ÒÝ I dette afsnit vil vi gennemgå de mest gængse metoder og vil afslutningsvis komme med en sammenfatning. Vi starter med den mest strikse metode og derefter opblødes kravet til konsistens langsomt. Fælles for de 5 første metoder er at synkronisering foregår implicit, mens synkronisering for de resterende, fra og med weak consistency, foregår eksplicit. Denne model giver den mest strikse form for konsistens af hukommelsen og defineres ved at: Det skal til enhver tid gælde at enhver læsning af lokalitet X, resulterer i det senest skrevne til lokalitet X. Dvs. at hvis W(x)1 udføres på tidspunkt n, skal R(x) på tidspunkt n + ǫ returnere 1. Figur 3.1 giver et eksempel på at strict consistency overholdes, hvorimod figur 3.2 giver et eksempel på at strict consistency ikke overholdes. Figur 3.1: P0 og P1 overholder strict consistency, da P1 læser henholdsvis 0 og 1 fra x før/- efter at P0 har skrevet 1 til x. Figur 3.2: P0 og P1 overholder ikke strict consistency, da P1 læser et 0 fra x efter at P0 har skrevet 1 til x. ½ Strict consistency fungerer kun i systemer med én CPU og kan derfor ikke ses som en løsning til vores system. Årsagen til at strict consistency kun egner sig til én CPU, er

32 Ã Ô Ø Ð ºÎ Ð ÓÐ Ð Ø º º¾Ë ÕÙ ÒØ Ð ÓÒ Ø ÒÝ at man altid kan vælge et ǫ som er så lille at der ikke er tid til at en skrivning udført af en CPU kan nå at propagere til en anden CPU, da denne propagering begrænses af lysets hastighed. Sequential consistency er lidt mindre striks end strict consistency og blev defineret af Lamport [29]. Definitionen for sequential consistency lyder: A multiprocessor system is a sequentially consistent if the result of any execution is the same as if the operations of all the processors were executed in some sequential order, and the operations of each individual processor appears in this sequence in the order specified by its program. Dvs. at alle processorer skal se alle resultater i samme rækkefølge, men der er ikke noget krav om at processorerne skal se et givet resultat på samme tid. Både figur 3.1 og 3.2 overholder sequential consistency. Figur 3.3 og figur 3.4 giver to eksempler på at sequential consistency ikke overholdes. I det første tilfælde brydes kravet om at processerne skal se to eller flere ændringer i samme rækkefølge og i det andet brydes kravet om at den enkelte processors program orden overholder det originale programs orden. Figur 3.3: Kravet om at processerne ser ændringer i samme rækkefølge brydes. Figur 3.4: Kravet om at den enkelte processors program orden brydes. Modsat strict consistency kan sequential consistency implementeres og benyttes i et DSM º º Ù Ð ÓÒ Ø ÒÝ system. Sequential consistency er desværre ikke løsningen på alle problemer, da køretiden er begrænset af r + w t, hvor r og w er latenstiden for henholdsvis læsning og skrivning, mens t angiver den mindste inter-processor kommunikations tid. Dette betyder at en forbedring af latenstiden for læsning implicit forværrer latenstiden for skrivning[30]. Causal consistency[31] bygger på årsagssammenhæng, dvs. at der f.eks. er en sammenhæng mellem en W(x) og en R(x) operation. Tanenbaum definerede causal consistency sådan: Writes that are potentially causally related must be seen by all processes in ½ the same order. Concurrent writes may be seen in a different order on different machines. Figur 3.5 giver et eksempel på at causal consistency overholdes, hvorimod figur 3.6 giver et eksempel på at det ikke overholdes.

33 È Ô Ð Ò Ê Ò ÓÑ Å ÑÓÖݹÈÊ Å ÓÒ Ø ÒÝ Figur 3.5: Kravet om årsagssammenhæng overholdes da P1 ud- Figur 3.6: Kravet om årsagssammenhæng brydes af P2 da R(x)0 føre R(x)1 efter at P0 har udført W(x)1. Derudover udfører kommer efter R(y)1 som igen kommer efter at P1 har udført P2 R(y)1 efter at P1 har udført W(y)1 der kommer efter R(x)1. W(y)1. Til slut udføre P2 R(x)1. º º È Ô Ð Ò Ê Ò ÓÑ Å ÑÓÖݹÈÊ Å ÓÒ Ø ÒÝ Causal consistency ligner en god kandidat for DSM systemer, men igen er der problemer. Årsagen er at det skal holdes styr på hvem har det set hvilke skrivninger og dette er meget dyrt, da det ofte kræver en fuld afhængighedsgraf. Næste løsning er at gøre kravet til konsistens endnu mere løst. Lipton[30] definerede PRAM således: Writes done by a single process are received by all other processes in the order in which they were issued, but writes from different processes may be seen in a different order by different processes. Dette siger at alle processer ser en skrivninger udført af en enkelt process i sammen orden som de er udført i. Dette gjaldt også for causal consistency, men opblødningen består i at skrivninger udført fra forskellige processer kan blive set i forskellige orden af forskellige processer. Dvs. at en række skrivninger udført af process A og B, kan bliver set i forskellige rækkefølge af process C og D, dog skal det enkelte process s skrivninger ses i sammen rækkefølge af alle processer. Det betyder at figur 3.6, som ikke var lovlig under causal consistency, er lovlig under PRAM. Dog brydes kravet om at skrivninger udført af en enkelt process ses i samme rækkefølge af alle processser i figur 3.7. Figur 3.7: P2 bryder PRAM kravet om at skrivninger udført af en enkelt process, ses i samme rækkefølge af alle processer, hvorimod P1 overholder det. Dette er den første løsning som giver et realistisk bud, men man skal være opmærksom på at kravet om konsistens er blevet betydeligt løsere end da vi startede med strict ½ consistency. Denne lettelse af kravet, betyder at programmøren skal udføre mere arbejde for at oprette holde en form for synkronisering af memory.

34 º º ÈÖÓ ÓÖ ÓÒ Ø ÒÝ Ã Ô Ø Ð ºÎ Ð ÓÐ Ð Ø º º Ï ÓÒ Ø ÒÝ Processor consistency er en forbedring af PRAM, hvor man har sat en begrænsning på PRAM. Begrænsningen ligger i at alle processer acceptere rækkefølgen af to eller flere skrivninger foretaget af den enkelte process. Dvs. at de acceptere den enkelte process programorden. Weak consistency og de efterfølgende modeller bygger, modsat de forrige modeller, på at synkronisering angives eksplicit af programmøren. Dvs. at ansvaret for at indsætte synkronisering således at race conditions m.m. undgås, ligger hos programmøren og ikke i modellen. Fordelen ved dette er selvfølgelig at det er muligt at slække endnu mere på kravet om konsistens og derved opnå betydelig bedre ydelse. Weak consistency defineres således[32]: Accesses to synchronization variables are sequentially consistent. No acesss to a synchronization variable is allowed to be performed until all previous writes have completed everywhere. No data access (read or write) is allowed to be performed until all previous accessses to synchronization variables have been performed. Figur 3.8 og 3.9 viser to eksempler på weak consistency, hvor den første overholder weak consistency og den anden ikke overholder weak consistency. Weak consistency giver betydelige bedre ydelse, men giver selvfølgelig også programmøren mere ansvar, da man selv skal holde styr på synkronisering. Det skal også bemærkes at weak consistency er nødt til at opdatere både lokale og globale variabler ved hver synkronisering. Dette skyldes at den eksplicitte synkronisering kun definere hvor der er en kritisk region, og derfor skal alle variabler på det tidspunkt synkroniseres. Figur 3.8: Når P1 kører den første R(x), kan resultatet blive enten 1 eller 2. Derimod skal resultatet af den anden kørsel af R(x) blive 2, da den kommer efter synkroniseringen S. Derved overholdes weak consistency. º º Ê Ð ÓÒ Ø ÒÝ Figur 3.9: Da resultatet af P1 s første R(x), som kommer efter en synkronisering, ikke resulterer i 2, overholdes weak consistency ikke. ½ Release consistency er en udbygning af weak consistency, således at der nu defineres hvornår en en kritisk region starter og slutter. Derved kan man begrænse det antal af variabler, lokale som globale, der skal synkroniseres. Resultatet af dette er selvfølgelig mere syntaks, men også endnu bedre ydelse. Definitionen er[33]:

35 Ä ÞÝÊ Ð ÓÒ Ø ÒÝ Before an ordinary access to a shared variable is performed, all previous acquires done by the process must have completed succesfully. Before a release is allowed to be performed, all previous reads and writes done by the process must have completed. The acquire and release accesses must be processor consistent. Grafisk er dette illustreret ved figur 3.10 og et modeksempel i figur Figur 3.10: Release consistency overholdes og det skal bemærkes at eftersom P2 ikke benytter sig af låsen L, er der ingen garantier for at få det korrekte resultat. º º Ä ÞÝÊ Ð ÓÒ Ø ÒÝ Figur 3.11: I dette tilfælde bruge P2 låsen L, men R(x) resultere i en forkert værdi, og derfor overholdes release consistency ikke. I stedet for at sende alt delt data til alle de noder som har en kopi af data i forbindelse med en frigivelse af en lås, kan man i stedet vente med at sende data til det er nødvendigt. Man kan vente med at sende data, til en node anmoder om at få en lås. I forbindelse med denne anmodning, kan man sende den opdaterede version af data. Lazy release consistency svarer til release consistency, dog med den ændring at man venter med at sende data, hvilket kan forbedre ydelsen. º º ÙØÓÑ Ø ÍÔ Ø ÓÒ Ø ÒÝ º º½¼ ÒØÖÝ ÓÒ Ø ÒÝ Automatic Update consistency bygger på at man via hardware kan opdage hvornår der skrives til en delt variabel og når dette sker, kan man propagere dette videre til andre node som skal bruge den delte variabel. Teoretisk vil dette resultere i meget få beskeder og vil derfor give en god ydelse, men det kræver at man har noget specifik hardware. I stedet for at have en eller flere synkroniseringsvariabler, kunne man tage skridtet fuldt ud og lade hver variabel have en synkroniseringsvariabel. Entry consistency defineres således[34]: ½ An acquire access of a synchronization variable is not allowed to perform with respect to a process until all updates to the guarded shared data have been performed with respect to that process.

36 Ã Ô Ø Ð ºÎ Ð ÓÐ Ð Ø Before an exclusive mode access to a synchronization variable by a process is allowed to perform with respect to that process, no other process may hold the synchronization variable, not even in non-exclusive mode. After an exclusive mode access to a synchronization variable has been performed, any other process next non-exclusive mode access to that synchronization variable may not be performed until it has been performed with respect to that variable s owner. Figur 3.12 giver et eksempel på hvordan entry consistency fungerer. º º½¼º½ ÒØÖÝ ÓÒ Ø ÒÝÔ ÐÐ Figur 3.12: Da P0 og P1 kun har en lås på variablen x, er det kun variablen x der bliver opdateret korrekt. I entry consistency findes kravet: Before an exclusive mode access to a synchronization variable by a process is allowed to perform with respect to that process, no other process may hold the synchronization variable, not even in non-exclusive mode.. Dette sikrer at en process ikke skriver til data, mens en anden læser dette, og hindrer altså at en process ser en delvis opdatering. Som beskrevet i afsnit 3.3.1, er det ikke muligt at have et absolut synkroniserings punkt, da beskedernes hastighed begrænses af lysets hastighed. Da det vides at der kun er en process der kan have en skrive lås (exclusive lock), må alle andre kopier have læse-adgang til dataobjektet. Eftersom data bliver opdateret af skriveoperationen, skal alle disse kopier invalideres. I traditionel entry consistency er der en periode mellem data bliver erklæret ugyldigt vha. invalideringsbeskeder og skrivelåsen kan gives. Længden af denne periode afhænger af hvor hurtigt kopierne af dataobjektet bliver frigivet. Figur 3.13 viser hvordan entry consistency opfører sig med tre involverede parter. Det kan ses at processè¼er inaktiv i lang tid før den får skriveadgang, da denne skal vente på at alle processer med en kopi af data svarer på invalideringsbeskeden. Denne venten forsinker også processè½, da der går længere tid før atè¼er færdig med at anvende data. I Cell BE arkitekturen findes der flere separate fysiske hukommelsesblokke (hovedhukommelsen og LS erne). Dette bevirker, at der i mange tilfælde ikke er nogen mulighed for at en process ser en delvist opdateret variable. Det samme gør sig gældende på en klynge af maskiner, da disse har adskilte fysiske hukommelsesblokke. Hvis man antager at alle processer har en fysisk adskilt kopi af data, bliver det muligt at slække på kravet om at alle processer skal opgive læselåsen, før der gives en skrivelås. For at adskille denne consistency model fra entry consistency, vælger vi at benævne modellen Partioned Entry Consistency, hvor partioned henviser til den adskilte hukommelse. ¾¼ Ved at tillade at skrivelåsen gives tidligere, kan man overlappe skrivningen og invalideringen. Denne ændring mindsker ventetiden, og denne effekt bliver markant, hvis der er mange kopier af data der skal invalideres. Så længe det garanteres at data er placeret på fysisk adskilte placeringer, er det ikke problematisk at tillade dette overlap. I en Cell BE maskine, kan dette krav håndhæves på henholdsvis SPE og PPE, ved at invali-

37 ÒØÖÝ ÓÒ Ø ÒÝÔ ÐÐ Figur 3.13: P0 ønsker at få skriveadgang til et dataobjekt. P1 står i en løkke, hvor den ønsker at få læseadgang til samme dataobjekt, efter den har læst værdien af dataobjektet, frigives dataobjektet igen. P2 er hjemmenode (home-node) for dataobjektet, og skal derfor informeres når en process ønsker skriveadgang til dataobjektet. De grønne linier markerer en læse eller skrive operation på et dataobjektet. dere kopier, når skrivelåsen modtages. Dette vil bevirke at der igen skal hentes en kopi, hvilket vil blokeres så længe skrivelåsen ikke er frigivet. Figur 3.14 viser hvorledes denne konsistens model virker. Som det fremgår af figur 3.14, er der nu kortere tid hvor de enkelte processer er inaktive, og derfor virker denne model bedre, hvis P0 og P1 ikke arbejder på samme hukommelsesblokke. I figuren kunne man forestille sig, at P0 og P1 var to SPE er. Derved arbejder de to processer på dataobjektet i hver deres LS. Figur 3.14: Partioned Entry Consistency med en tidslinie. De grønne linier markerer en læse eller skrive operation på et dataobjekt (A). De røde linier markerer at to processer udføre henholdsvis en læse og skrive operation samtidigt på et ¾½ dataobjekt (A), dog har de to processer ikke samme fysiske hukommelse. Det skal dog bemærkes, at data først kan skrives tilbage til hovedhukommelsen, når det kan garanteres at alle som har læseadgang til dataobjektet, har hentet data fra ho-

38 Ã Ô Ø Ð ºÎ Ð ÓÐ Ð Ø º º½½Ë ÑÑ Ò ØÒ Ò vedhukommelsen. Senere vil vi definere et signal, som kan bruges til at signalere at data kan skrives tilbage til hovedhukommelsen. For at kunne få en god ydelse i et DSM system, er det centralt at konsistensmodellen giver god ydelse. Dette betyder at det ikke vil være relevant at benytte nogle af de modeller, som anvender implicit synkronisering. Dette resulterer dog i at programmøren får mere ansvar, hvilket passer godt til tanken med Cell BE arkitekturen. Normalt vil det være altovervejende vigtigt at mindske datakopiering, da dette vil betyde tab af ydelse. Men i Cell BE maskiner er det nødvendigt at kopiere data, for at få data placeret på den korrekte fysiske hukommelsesenhed. Denne duplikering af data betyder, at partioned entry consistency virker oplagt som en konsistensmodel til Cell BE arkitekturen. ¾¾

39 Ã Ô Ø Ð ÈÖÓ Ð Ñ Ø ÐÐ Ò Ö Ø ØÖ Ù Ö Ø Ý Ø Ñ I º½ det foregående ËÝÒ ÖÓÒ Ö Ò kapitel har vi gennemgået nogle af de større problemstillinger, der er ved design og valg af et system til multiprogrammering. Udover disse emner er der naturligvis en mængde andre. I dette kapitel vil vi gennemgå flere af disse problemstillinger. Ë Ñ ÓÖ I ethvert system til multiprogrammering skal der forefindes et antal operationer der synkroniserer kørslen. Disse specielle operationer er typisk en form for data som har specielle adgangskrav, men opfattes ikke af programmøren som decideret data. En semafor er en tæller som er beskyttet mod samtidig adgang. En semafor har typisk to funktioner, som kunne kaldes Òog, men af historiske grunde kaldesîogè.î ÅÙØ Ü tæller en op, ogèventer til tælleren er større end nul, og tæller herefter en ned. Begge operationer skal være atomiske, og det er derfor en god idé at implementere specielle funktioner til håndtering af en semafor, da datamængden er meget lille og funktionen har skrappe konsistenskrav. ÖÖ Ö En speciel udgave af en semafor, er en mutex. En mutex kan kun tælle til en, og anvendes derfor ofte til at beskytte en mængde data mod parallel adgang. En barriere er en konstruktion som sikrer at et bestemt antal processer er nået til samme ¾ sted. Et eksempel er matrix multiplikation, hvor resultatet først er endeligt kendt når alle processor er færdige. I dette tilfælde oprettes en barriere, hvor tælleren er lig antallet af processorer. Når hver processor er færdig, signaleres dette til barrieren. Når alle processer er færdige tillader barrieren at alle processer fortsætter.

40 º½º½Ë ÑÑ Ò ØÒ Ò Ã Ô Ø Ð ºÈÖÓ Ð Ñ Ø ÐÐ Ò Ö Ø ØÖ Ù Ö Ø Ý Ø Ñ Hvis systemet understøtter semafor, kan de andre synkroniseringsprimitiver implementeres ved at anvende denne. På samme måde kan primitiverne implementeres hvis der findes º¾ en ÇÔ Ð Ò Ø mutex operation. Implementationen behøver ikke være en del af systemet, men kan implementeres af programmøren. Cell BE arkitekturen indeholder synkroniseringsprimitiver der kan anvendes til at synkronisere alle enheder på en enkelt maskine. På netværket skal disse implementeres, enten via en fejltolerant protokol f.eks. Two-Phase- Commit[23], eller med hjælp fra en konsistensmodel. For ethvert system skal det afgøres, hvordan data opdeles og sendes. Der har været mange forskellige måder hvorpå denne opdeling udføres. Hardware baserede systemer har traditionelt anvendt en side som opdeling, da dette passer fint til en page fault. Problemet er naturligvis at hvis der kun skal sendes meget små mængder data, kommer der et stort overhead. Da hardware baserede løsninger har en tendens til at have et højt overhead, virker det naturligt at kigge på software baserede løsninger. I sådanne systemer kan man stadig anvende en side baseret opdeling, men man kan nu vælge side størrelsen frit. Denne model kaldes segment baseret, og har samme problem som en side baseret opdeling, men er mere fleksibel, da segment størrelsen ikke er bundet af hardware størrelsen. En endnu mere fleksibel model er at anvende forskellige størrelser for forskellige data. Den variabel baserede model har en størrelse for hver variabel, og størrelsen er således tilpasset variablen. Der er ikke noget spild ved en overførsel, men opdelingen kan medføre at der skal udføres flere kald ved mange små overførsler. Denne model kan ofte integreres med compileren, og herved fjerne kravet om at brugeren skal angive størrelsen. Hvis programmeringsmiljøet er objektorienteret, såsom C++, kan modellen anvende objekter og herved fås samme muligheder som ved variabel baseret, men virtuelle funktioner i objektet kan udføre de kald der før skulle implementeres i compileren. º En udvidelse, Ð Ö Ò af en variabel baseret model, er at der også medsendes typen af data f.eks. en ÒØ. Herved kan der udføres forespørgsler på data, der hvor data findes, uden at de først skal hentes lokalt. En sådan struktureret type data er implementeret i systemet TuppleSpaces[35]. I et sådan system bliver migrations parametre (se afsnit 3.1.3) vanskeligere at afgøre, da der nu også skal tages stilling til processor kræfter. À Ò Ú Ù Ò ØÖÙ Ø ÓÒ Ö Hvis der vælges meget små størrelser for data, stiger sandsynligheden for at der opstår false sharing. False sharing er et problem hvor to variabler deler en fysisk placering. Hvis f.eks variablerne A og B er på hver 16 bytes og transportmekanismen er på 32 bytes, vil Å ÒÓÔ Ö Ø ÓÒ ÖѺ Ð Ö Ò ½ ½ der opstå følgende sekvens ved skrivning til A og herefter B: À ÒØ ¾

41 ÇÔ Ø Ö ÁÒÚ Ð Ö Ð Ö Ò Ë Ö Ú À ÒØ ÒÚ Ð Ö Øµ Å ÒÓÔ Ö Ø ÓÒ ÖÙº Ð Ö Ò ÇÔ Ø Ö Ë Ö Ú À ÒØ ÇÔ Ø Ö Ë Ö Ú À ÒØ ÇÔ Ø Ö Ë Ö Ú Figur 4.1: Illustation af register og hukommelses brug under false sharing. Kasserne angiver registre, pilene angiver hukommelses operationer. Skraverede kasser angiver ugyldigt data. Figur 4.2: Illustation af register og hukommelses brug uden false sharing. Kasserne angiver registre, pilene angiver hukommelses operationer. ¾ False sharing er illustreret med figur 4.1. Til at sammenligning viser figur 4.2 dette uden false sharing.

42 Ã Ô Ø Ð ºÈÖÓ Ð Ñ Ø ÐÐ Ò Ö Ø ØÖ Ù Ö Ø Ý Ø Ñ False sharing kan have meget stor indvirkning på programmets effektivitet, og det kan være særdeles svært at opdage årsagen til false sharing. Dette sklydes at CPU en vil se ud til at køre med fuld belastning under hentning og skrivning. º Et andet Ö Ö Ò ØÖÙ ØÙÖ problem opstår hvis der er stor efterspørgsel på samme stykke data, hvorved en process konstant må invalidere og genindhente samme stykke data. Når problemet vokser, bruger systemet til sidst mere tid på at invalidere og hente data end på at udføre beregninger. Det essentielle i et distribueret system med delt hukommelse, er tilgangen til hukommelsen. En model er at antage at alt hukommelse findes i samme adresse område. To adresse lokaliteter der er numerisk tæt på hinanden, kan sagtens befinde sig på to forskellige fysiske placeringer. I den anden ende af spektret, findes modeller hvor intet adresseområde er delt. Mellemløsningen er at anvende en del af adresseområdet til ikke delt hukommelse, og en anden del til den delte hukommelse. Ved at anvende en model med delt adresseområde, kan man indkode oplysninger om º placering Æ ØÚÖ ÔÖÓØÓÓÐ i hukommelsesadressen. Dette kan være en stor hjælp, specielt hvis der anvendes hardware baseret lookup. Hvis der ikke umiddelbart er mulighed for at tilgå data direkte via en pointer, er der ikke vundet det store ved at anvende en model med delt adresseområde. Som tidligere nævnt er netværket ofte en flaskehals i kommunikationen. I netværket kan der anvendes forskellige netværksprotokoller, og valget af netværksprotokol har naturligvis indflydelse på ydelse. TCP protokollen er den protokol der anvendes til pålidelig kommunikation over internettet. Den har en del gode egenskaber, såsom pålidelig overførsel, håndtering af fragmentering, checksum, m.m. TCP protokollen har også nogle egenskaber º À Ø ÖÓ Ò Ó ÓÑÓ Ò Ý Ø Ñ Ö som er attraktive for internettet, men ikke for en klynge. Det er specielt congestion kontrol og opstartsramper der bør håndteres anderledes i et netværk. Det er muligt at skrive en protokol selv, evt. baseret på UDP, og hermed omgå mange af disse problemstillinger. Man kan betegne en klynge som værende homogene eller heterogene, alt efter om enhederne i klyngen er ens eller ej. Det er klart at man skal gøre sig nogle overvejelser, alt efter om man arbejde med den ene eller anden type klynge. Ofte vil man opleve at heterogene systemer, hvor man f.eks. har en blanding af forskellige computer arkitekture, er mere besværlige end homogene systemer. Selvom en Cell BE maskine indeholder forskellige ¾ beregningselementer (PPE og SPE er) og derved er et heterogent system, er der stadig nogle aspekter der er ens. Både PPE og SPE benytter MIPS instruktionssættet og samme endian notation. Dette bevirker at data i de fleste tilfælde kan flyttes uændret fra en placering til en anden. Nogle systemer såsom PVM[12] understøtter både forskellige arkitekturer og forskellig endian notation.

43 º ÐØÓÐÐ Ö Ò ÐØÓÐÐ Ö Ò Nogle systemer er designet med stor fejltolerance som mål. Fejltolerancen kan være med henblik på netværk, hukommelse, denial of service eller hele maskiner. Fejl er mere hyppige i distribuerede systemer, da der indgår flere elementer. MTBF stiger med antallet º Ë Ö af involverede enheder. Fejltolerance er specielt interessant i forbindelse med systemer hvor man kan tilføje og fjerne maskiner løbende, så udskiftninger og tilføjelser kan ske on-the-fly. º ÇÚ ÖÐ ÔÔ Ü ÙØ ÓÒ Hvis et system benytter et usikkert netværk f.eks. internettet, bliver det nødvendigt at kontrollere at de beskeder der modtages er gyldige, og har en gyldig afsender. Dette løses normalt ved at tildele hver maskine et certifikat, samt anvende en protokol hvori kryptering og godkendelse foretages. Begge operationer medføre naturligvis tab af ydelse. I alle distribuerede systemer, er der perioder hvor data skal transmitteres. Hvis der kan udføres beregninger mens data overføres, opnår man at overførselstiden skjules. En sådan teknik kaldes normalt overlapped execution, men Cell BE kalder teknikken dobbelt buffer[36], fordi teknikken minder om dobbelt buffer teknikken kendt fra video operationer. I et moderne operativsystem, kan denne teknik let udnyttes ved at oprette flere tråde. Når en tråd venter på data, får de andre tråde mere eksekveringstid. På hardware siden, er dette koncept også implementeret i form at f.eks. Intel s Hyperthreading teknologi[37]. Fordelen ved at anvende tråde, er at programmering af tråde er et velkendt område. I et distribueret system, kan hver maskine eller enhed betragtes som en eller flere tråde. Herved kan man anvende samme teknik i et distribueret system. I Cell BE kan der foretages trådskifte ved at anvende POSIX pthread[38] kald. Hvor trådskifte på en PPE er forholdsvist problemfrit, er trådskifte på en SPE er dog en bekostelig affære, da dette indebærer at alt data fra en SPE overføres til hovedhukommelsen. º½¼ ÐÓ Ó Ð Ú ÐÓ Udover at overføre ca. 258KB 1 data begge veje, annullerer et trådskift også alle igangværende DMA overførsler. Dette bevirker at tråde ikke fungerer til dobbelt buffering ved venten på DMA overførsler. Det er dog muligt at udføre et user-mode context skift, ved at oprette en stack til hver tråd, samt at kopiere og genskabe registerfilen ved skift. De distribuerede systemer vi har undersøgt, nævner ikke deadlocks og livelocks. Alligevel er disse fænomener interessante, da de kan detekteres under kørselen. Begge ¾ fænomener kan dog undgås ved at programmøren strukturerer sit program fornuftigt. Deadlocks kan opdages via timeout, men det er svært at angive en god værdi for denne timeout[23]. En anden model er at have en overordnet koordinator, som holder 1 256KB LS + 2KB registerfil

44 Ã Ô Ø Ð ºÈÖÓ Ð Ñ Ø ÐÐ Ò Ö Ø ØÖ Ù Ö Ø Ý Ø Ñ øje med systemet, og kan opbygge en komplet afhængighedsgraf, og opdage eventuelle cykler i denne[23]. En variation er at rundsende en token, som opsamler oplysninger om blokeringer. På den måde kan en maskine selv konstruere en afhængighedsgraf når den modtager denne token, og herved opdage cykler. Den centraliserede model skalerer dårligt, fordi denne ene maskine skal have oplysninger º½½ ÖÙÒ Ð Ò Ð Ò Ò ÑÓ ÐÐ Ö fra alle maskiner for at kunne udføre opgaven. Token modellen skalerer lidt bedre, men tiden det tager at sende tokenen rundt, stiger lineært hver gang der tilføjes en process. Ligeledes mister systemet ydelse, da grafen der skal bygges og evalueres vokser betydeligt, for hver process der tilføjes. Når programmer afvikles på mere end en processor stiger kompleksiteten af programmet. Dette grundlæggende problem har der været forsket meget i, af forskellig årsager. Der har i mange år været stort behov for processor kraft, og selvom processorerne bliver kraftigere, kan en enkelt maskine ikke levere tilstrækkeligt computerkraft. For nogle opgaver º½½º½Å Ô Ò kan problemet deles op i underproblemer, der så kan sættes til at køre på hver sin maskine. For nogle problemer er denne opdeling ikke triviel, specielt hvis resultatet af en mellemregning skal bruges ved næste beregning. I dette tilfælde er det særdeles ineffektivt manuelt at oprette og tilpasse programkørsler på flere maskiner. For at håndtere denne problematik, er der udviklet en del forskellige modeller og systemer. Message passing[11] består i udveksling af beskeder mellem maskiner. Forskellen på message passing og almindelig netværkskommunikation, er at message passing typisk har simplificerede metoder til at udveksle data. Den mest anvendte model til message passing, er MPI. MPI indeholder funktioner til oprettelse og definition af beskeder, således º½½º¾ ØÖ ÙØ Ö Ñ ÑÓÖÝ at der kan kommunikeres mellem heterogene maskiner. MPI indeholder også funktioner til forskellige typer af broadcast. Problemet med MPI er at programmeringsmodellen er forholdsvis kompleks, i og med at det er programmøren der skal holde styr på hvilke maskiner der skal have hvilke datablokke. Der er således ikke indbygget cache og prefetch i MPI. De fleste maskiner har mulighed for en form for side inddeling af hukommelsen. Hvis hukommelsesforbruget stiger over den tilgængelige fysiske hukommelse, kan en eller flere sider skrives til et andet lagringsmedie f.eks. en harddisk. Når et program beder om en side der ikke er i hukommelsen, starter processoren en page fault handler, som sørger for at indlæse denne side. Dette system introducerer begrebet virtual memory address space, da en adresse i hukommelsen, kan pege på en vilkårlig data side. Ved at skrive en tilpasset page fault handler, er det muligt at hente en side fra en anden ¾ maskine. Ved at anvende et meget stort virtual memory address space, kan det se ud som om at alle maskiner deler den samme hukommelse. Dette fjerner behovet for eksplicitte beskeder, og muliggør prefetch. Programmøren skal nu ikke længere holde styr på hvem der har hvilket data. Desværre introducerer denne model en række andre ulemper.

45 ÈÖÓ Ð Ñ Ö ÑÙÐØ ÔÖÓ Ö ÑÑ Ö Ò En page fault medfører ofte en hardware interrupt, som typisk koster mange CPU cycles[39]. Selvom det også er muligt at udføre software detektion af tilgang, er der stadig et væsentligt overhead[40]. Herudover bliver det nu et problem at holde konsistens º½¾ i hukommelsen. ÈÖÓ Ð Ñ Ö ÑÙÐØ ÔÖÓ Ö ÑÑ Ö Ò Da programmøren ikke længere indikerer hvornår data skal hentes og frigives, skal DSM systemet afgøre dette. Vi har i kapitel 3 beskrevet nogle modeller til håndtering af dette. I praksis betyder dette ofte at programmøren skal markere variabler i kildekoden, for at DSM systemet kan optimere brugen af variablerne. I kapitel 5 gennemgår vi kendte systemer der håndterer DSM på forskellige måder. Å ØÖ ÜÅÙÐØ ÔÐÝ I multiprogrammering er der nogle ganske bestemte problemer som gentager sig. Mange andre problemer minder om disse, med hensyn til hvordan data tilgås. I mange problemer optræder der en eller flere matrixmultiplikationer. En matrixmultiplikation involverer en søjle og en række i to forskellige matricer, og bryder derfor et ÅÓÒØ ÖÐÓÈÁ eventuelt adgangsmønster med spatial lokalitet. Resultatet skal skrives i et delt hukommelsesområde, og kræver derfor at systemet kan håndtere samtidige skrivninger. En matrix multiplikation er på mange måder en god målestok for ydelsen i et multiprogrammeringsmiljø. Samtidig er problemet meget teoretisk, da der stort set altid er andre beregninger involveret i løsningen af et problem. Monte Carlo PI tilhører en klasse af problemer der betegnes embarrassingly parallel. Udtrykket henviser til at problemets mellemregninger ikke har interne afhængigheder og derfor meget let kan beregnes i parallel. Beregningen af pi vha. en monte carlo simulation, foregå ved at man tager en cirkel med radius r og putter den ind i en firkant med sidelængderne 2r. Arealet af cirklen er selvfølgelig πr 2 og arealet af firkanten er ËÙ Ú ÓÚ ÖÖ Ð Ü Ø ÓÒ (2r) 2 og derved bliver forskellen på arealet af cirklen og firkanten π 4. Nu sættes monte carlo simulationen igang og den tæller antal af afgivne skud N, hvor det antages af alle skud rammer indenfor firkanten. Derudover tælles antallet af skud som rammer indenfor cirklen M. Pi kan nu defineres som π = 4M N. Denne metode er rimelig til at beregne pi og jo flere skud der afgives, jo mere præcis bliver pi. Successive over relaxation er en type af problemer hvori et element påvirkes af nabo elementer. Simulationen inddeles i trin, og i hvert trin opdateres et element med værdier º½¾º½ËØ Ò Ö Ø Ø fra naboelementerne. Denne type problemer er specielle, fordi alle mellemresultater er afhængige af forrige mellemresultater. Et multiprogrammeringssystem skal derfor kunne håndtere mange samtidige læsning og skrivninger. Simulationen kan f.eks. anvendes til at simulere udbredelsen af varme i et givet materiale også kaldet Heat equation. ¾ For at kunne sammenligne ydelsen mellem forskellige multiprogrammerings systemer, har Stanford University udgivet en mængde programmer der simulerer konkrete pro-

46 Ã Ô Ø Ð ºÈÖÓ Ð Ñ Ø ÐÐ Ò Ö Ø ØÖ Ù Ö Ø Ý Ø Ñ De pro- blemer i multiprogrammering. Disse programmer findes i pakkenëèä ËÀ¾[41]. grammer der nævnes som kerne programmerne er: Ocean Simulation Hierarchical Radiosity Water Simulation with Spatial data structure Barnes-Hut FFT (Fast fourier transformation) Blocked Sparse Cholesky Factorization Radix Sort Nogle af disse programmer kunne implementeres i DSMCBE og derved kan man sammenligne hvor godt DSMCBE skalere. Desuden kan man sammenligne hvor godt DSMCBE skalerer, i forhold til hvor godt programmerne skalerer på andre systemer, º½ Ë ÑÑ Ò ØÒ Ò f.eks. en klynge af alm. PC er. For at får kende den præcise ydelse af DSMCBE, kunne man implementere disse programmer på den rene Cell BE arkitektur og derved kunne man sammenligne kørselstider med kørselstiderne for at kører programmerne med DSMCBE. Dette er dog en krævende opgaver, og ligger uden for dette speciale. Da der ikke umiddelbart er mulighed for hardware traps til SPE erne og disse i øvrigt har vist sig at være ineffektive, mener vi ikke at der er noget der taler for at opdele data i faste størrelser. Cell BE understøtter dog kun overførsler som er aligned med 16 bytes, og har en størrelse der kan deles med 16. Dette gør at alle allokeringer af hukommelse skal være aligned med 16 bytes og have en størrelse som er et multiplum af 16 byte. Dette giver et lille overhead ved overførsel af små mængder data. Thrashing kan detekteres, og vil typisk komme til udtryk ved kraftig nedgang i ydelse. Vi mener ikke at der behøver at være håndtering af thrashing i systemet, da thrashing ofte fremkommer ved mangel på plads eller dårligt design. Begge dele er derfor brugerens ansvar, og ikke noget der kan løses med et system, men blot hjælpe med at detektere det. Da der ikke er mulighed for at en maskine i en klynge kan tilgå data via en EA adresse, er der ingen gevinst i at benytte et delt adresseområde. Vi vurderer derfor at det virker mest fornuftigt at nummerere alle oprettede data objekter. Dette muliggør også migrering. Til denne opgave har vi vurderet, at det ikke vil være realistisk at skrive en ny netværksprotokol. Forbedringer på dette område, vil formentlig øge ydelsen på store klynger markant. Specielt er det interessant at undersøge mulighederne i InfiniBand på et ¼ Cell Blade Center. Da vi kun vil fokusere på et system opbygget af Cell BE maskiner, er det unødvendigt at implementere funktionalitet til oversættelse mellem forskellige arkitekturer. Ligeledes vil vi antage at al kommunikation er fejlfri. Vi vil ligeledes antage at systemet er opstillet et betryggende sted, således at der ikke kan indsættes ugyldige beskeder i kommunikationen. Vi vil ikke håndtere deadlocks eller livelocks i systemet.

47 Ë ÑÑ Ò ØÒ Ò Vi vil implementere user-mode context skift på SPE erne, for at kunne udføre dobbeltbuffering på en simpel måde. På en PPE er det tilstrækkeligt at anvende almindelige pthreads for at opnå denne funktionalitet. Grundlæggende er message passing den mest effektive programmeringsmodel, men også den som er mest besværlig at arbejde med. Ved at forbedre metoderne til at detektere mønstre i datatilgang, kan DSM systemer få en ydelse der ligger tæt op af message passing, uden at introducere væsentlig kompleksitet for programmøren[42]. ½

48

49 Ã Ô Ø Ð Ø Ö Ò Ý Ø Ñ Ö I dette kapitel vil vi gennemgå nogle af de eksisterende systemer til håndtering af distribueret hukommelse. Vi vil for hvert system give en kort gennemgang af systemet, og fremhæve særlige egenskaber eller detaljer for systemet. Alle disse systemer er konstrueret før den første Cell BE maskine blev bygget, men de håndterer alle det samme º½ problem, Å Ø Ö nemlig overførsel af data mellem flere fysiske placeringer. Dette foregår på en måde der er mere eller mindre transparent for brugeren af systemet. Under nedenstående gennemgang vil vi nævne et udpluk af egenskaber, som er specielt interessante ved systemet. Vi har igennem arbejdet med DSMCBE undersøgt de nævnte systemer, og forsøgt at anvende de erfaringer og funktionaliteter der er dokumenteret heri. Mether er et software baseret system som simulerer en virtuel hukommelsesdriver[43]. Ved at reservere et ganske særligt adresseområde på 4MB, kan Mether håndtere alle kald til dette område, herunder specielt page faults. I programkoden er det ikke umiddelbart synligt for programmøren, at der faktisk er tilgang til delt hukommelse, og ikke nødvendigvis lokal hukommelse. Mether understøtter både parallel tilgang til data fra samme maskine, såvel som til andre maskiner. Selvom Mether er software baseret, er Mether kun tilgængelig ved page faults. Dette bevirker at Mether ikke kan afgøre om tilgangen til data er med henblik på læsning eller skrivning. Ved at give en enkelt maskine tilgang til samme fysiske hukommelsesportion, giver Mether ikke noget overhead så længe alt º¾ tilgang er fra samme maskine. Mether s idé med at anvende et fiktivt adresserum til at håndtere delt hukommelse, er en meget elegant måde hvorpå adgang til delt hukommelse kan maskeres. Desværre er det nødvendigt at anvende en page fault mekanisme, som dels er en langsommelig affære[39], og dels ikke er mulig, da en SPE ikke har paging mekanismer på dens LS. DASH er en forkortelse for directory architecture for shared memory, og er et hardware baseret system. DASH er udviklet på Stanford University, og er konstrueret som en fysisk maskine[28]. Da DASH blev udviklet var balancen mellem tilgængelig hukommelse og tilgængelig regnekraft ikke den samme som i dag, og der er derfor nogle dele af DASH som ville være udviklet anderledes idag. Eftersom DASH er et hardware system, er der en del valg der er givet på forhånd. Det er for eksempel side baseret lookup. DASH an-

50 Ã Ô Ø Ð º Ø Ö Ò Ý Ø Ñ Ö vender º ÅÙÒ Ò release consistency, og et specielt udviklet hierarkisk lokaliseringssystem. Dette system giver en træopdeling, og derfor kan data lokaliseres i n log(n). Dette bevirker at DASH skalerer ganske godt, men det er også et forholdsvist kompliceret system. DASH på mange måder er et ideal for konstruktionen af et skalerbart system, men da det er hardware baseret er det ikke det oplagte valg til brug på Cell BE arkitekturen. Munin er et DSM system som benytter sig af kode annotering[44, 45]. For alle delte variabler er det muligt at angive hvilken konsistensmodel der skal anvendes. Effekten af dette er naturligvis, at programmøren har mulighed for at håndtilpasse datatilgangen. Munin har også mulighed for at detektere adgangsmønstre til data, og automatisk skifte konsistensmodel undervejs. Munin var det første system som anvendte release consistency. Munin er software baseret, men kræver en speciel præprocessor for at kunne håndtere annoteringen i koden. Som med DSMCBE er mening med Munin at give programmøren et simpelt interface, uden at gå på kompromis med ydelsen. Munin kan præstere ganske gode resultater, men disse resultater fremkommer primært ved at programmøren angiver adgangsmønstre eksplicit på alle variabler. º I Munin Å Û Ý er det specielt interessant at kigge på hvor lidt arbejde der faktisk er ved at understøtte mere end én adgangsmodel, samt hvor god ydelse dette kan give. Kodeannoteringen skjuler den transformation som koden undergår, men det virker som om at denne fordel bliver en ulempe, når man forsøger at gennemskue hvad der præcist sker i en given sekvens. Midway er, ligesom Munin, et DSM system som benytter kode annotering[34, 46]. Midway benytter kun én model, nemlig entry consistency. Det er ganske tydeligt at Midway får overordentlig øget ydelse, primært fordi entry consistency reducerer antallet af nødvendige synkroniseringsbeskeder. Selv om det ikke nævnes i de rapporter vi henviser til, er disse observationer direkte henførbare til netværksmodellen LogGP[18], fordi der nu sendes væsentligt færre beskeder. Kode annoteringen er næsten ligeså omfattende som i Munin, men i Midway skal programmøren ikke tage stilling til hvilket adgangsmønster en variable har, men blot markere de områder hvor den er delt. Dette gør programmørens º arbejde ÄÇÍ Ë markant lettere på nogle punkter, men introducerer også større sandsynlighed for at danne deadlocks. I Midway har vi kigget på den overraskende store ydelse som fås ved at skifte fra release consistency til entry consistency. I Midway virker annoteringen som om at den let ville kunne erstattes af et enkelt funktionskald eller en makro. Clouds er et DSM system, som betragter hukommelse og processor kraft som to ressourcer, og distribuerer begge[47, 48]. Modsat de ovenstående systemer er CLOUDS objekt orienteret og tillader udførsel af programkode på en anden maskine. Man kan sige at man med CLOUDS kan vælge at flytte programkoden hen til hukommelsen, eller flytte hukommelsen hen til programkoden. De ovenstående systemer anvender udelukkende den sidste metode. CLOUDS anvender en home-based algoritme til at synkronisere

51 ËÇÅ datatilgang. Programmering til CLOUDS virker umiddelbart ganske simpelt, og det er næsten ikke til at se på koden at denne ikke bare er almindelig tråd programmering, men faktisk er distribueret programmering. Ved at tillade at programkode kan flyttes, er det muligt at udføre nogle meget avancerede optimeringer. Desværre kræver CLOUDS at operativsystemet har et globalt tilgangsområde til alle enheder herunder disk, hukommelse m.m., º ËÇÅ hvilket ikke er almindeligt forekommende. Måden hvorpå CLOUDS behandler tilgængelige ressourcer som ligeværdige, kan formentlig overføres til en enkelt Cell BE maskine, da man kan dele operativsystemets komponenter, såsom et filhåndtag mellem SPU er. Det ville formentlig være særdeles besværligt at implementere CLOUDS på en klynge af Cell BE maskiner. DiSOM er et software baseret objektorienteret DSM system[27]. DiSOM anvender entry consistency og virtuelle funktionskald. Ved at benytte DiSOM er det muligt at betragte et objekt som værende delt. DiSOM kan automatisk serialiserer og de-serialisere objektets data ved funktionskald. Samtidig skjules alle kald til synkroniseringsvariable. Ved at anvende en piggy-back model, kan DiSOM reducere antallet af beskeder der sendes. Kompleksiteten i DiSOM er således begrænset, og er i mange tilfælde kun til stede i de delte objekter, og ikke i den omkringliggende kode. Ved at anvende virtuelle funktionskald, er det muligt at påvirke mange dele af DiSOM, og DiSOM understøtter derfor også º heterogene Å È Ò ÁÒØ Ö ¹ÅÈÁ arkitekturer. DiSOM virker utroligt elegant og vi har studeret den måde hvorpå synkroniseringsvariable anvendes her. Da vi har ønsket at implementere et system i C og ikke C++, har vi ikke haft mulighed for at anvende objekter. Det ville dog være særdeles simpelt at implementere et system som DiSOM, hvis der eksisterer et system med entry consistency. MPI er ikke et DSM system, men en industri standard indenfor multiprogrammering[49]. Der findes i dag flere implementationer af MPI, f.eks. OpenMPI, LAM/MPI og MPICH. MPI fungerer på et meget lavt niveau, og understøtter i princippet udelukkende udveksling af kontrolbeskeder. Det er så muligt at gøre disse beskeder meget store, og herved º kunne udveksle È Ö ÐÐ ÐÎ ÖØÙ ÐÅ Ò ¹ÈÎÅ reel data. Det er forholdsvist komplekst at programmere til MPI, da alt synkronisering sker eksplicit. MPI s store fordel er, at det kan være særdeles hurtigt, og at der findes optimerede metoder til mange almindelige operationer, såsom beregning af summen af en variabel på flere maskiner. Nogle af disse metoder er dog kun tilgængelige ved brug af MPI2, f.eks.åèá Ø Ö. PVM er et system som forsøger at omdanne en samling heterogene maskiner til en supercomputer[12]. For at kunne gøre dette, understøtter PVM oversættelse af datatyper, f.eks. double, fra en arkitektur til en anden. Som med MPI, foregår alt dataudveksling eksplicit, og det er forholdsvist komplekst at programmere til PVM. PVM modellen er af ældre dato, og er derfor også en smule sværere at sætte op end andre systemer. Selvom idéen med PVM er at bygge en computer med høj ydelse, ved at bruge en masse billige systemer, er god, har det vist sig at det i praksis er problematisk. Dette skyldes at

52 Ã Ô Ø Ð º Ø Ö Ò Ý Ø Ñ Ö mange beregningsopgaver afhænger af høj ydelse i forbindelserne mellem enhederne. Jo dårligere de enkelte komponenter bliver, jo flere skal der til for at kompensere for dette, hvilket º ÓÑÑÙÒ Ø Ò Ë ÕÙ ÒØ ÐÈÖÓ ¹ ËÈ igen øger mængden af kommunikation der skal udføres. Idéen bag PVM er grundlæggende den samme som idéen med at samle flere PS3 maskiner til en super computer. Forskellen er her at alle maskiner vil have heterogen arkitektur, og man kan derfor spare en masse af den konvertering som er indbygget i PVM. CSP er egentlig et sprog til at beskrive interaktion mellem processer, skrevet af C. A. R. Hoare[50]. Udfra sproget er det så muligt at programmere et parallelt system. CSP markerer sig ved at være simpelt og overskueligt, og samtidig have en indbygget modstand mod deadlocks og race conditions. Ved at anvende ganske få primitiver, er det muligt at bevise korrektheden af en lille enhed, og herefter anvende denne som byggeklods i en større enhed. Ulempen ved CSP er at hver lille enhed er en process eller tråd, og der skal således anvendes et ret stort antal processer for at afvikle et CSP program. Da traditionel hardware primært har været i stand til at afvikle en enkelt process af gangen, giver dette et stort overhead i form af kontekst skift. Hvis man forsøger at reducere antallet af processer, vender man sig mod almindelig trådbaseret programmering, og mister herved alle º½¼ fordele ÌÙÔÐ Ô ved CSP. I fremtiden bliver CSP måske mere interessant, da udviklingen ser ud til at give flere processorer til alle maskiner. Selvom CSP bliver implementeret effektivt på Cell BE arkitekturen, vil der stadig være et behov for at overføre data mellem de forskellige enheder. Et DSM system vil derfor kunne fungere som et supplement til en CSP implementation. Tuplespaces[51] er model med flere implementationer, ligesom CSP. En kendt tuplespaces implementation er sproget Linda[35]. Tuplespaces minder overordnet som en slags database. Ved at gøre information om objektets indhold tilgængeligt for det underliggende system, er det muligt at udføre lokalisering og filtrering af objekter uden at hente disse ned til maskinen der udfører forespørgslen. Fordelene er naturligvis at dataoverførsler º½½ kan ÐÐË reduceres væsentligt, men ulempen er at man risikerer at får en flaskehals på den maskine der evaluerer forespørgslen. Tuplespaces kan implementeres ovenpå en DSM implementation. Specielt kan dette udføres forholdsvist simpelt ved at anvende home-node princippet fra afsnit , hvorved data lokaliteten bliver let håndterbar. CellSs[14] er et sprog som er konstrueret specielt med henblik på Cell BE arkitekturen. Systemet fungerer ved at programmøren indsætter annoteringer i programkoden. Et specielt præprocessor program omsætter disse annotationer til kode, hvorefter det hele kompileres med en almindelig Cell compiler. Systemet fungerer ved at annotere f.eks funktionskald med angivelse af parametrenes tilgængelighed (read, write eller begge). Udover at håndtere dataoverførsel og synkronisering, indeholder CellSs også en scheduleringsmekanisme således at et sekventielt program kan opdeles i enkeltstående op-

53 Ð gaver. En avanceret scheduleringsalgoritme holder styr på dataafhængigheder, og på º½¾ den måde Ð er det muligt at optimere afviklingen af kode på SPE enhederne, uden at programmøren eksplicit holder styr på dette. CellSs er et meget ambitiøst projekt, og kan fjerne en del af de vanskeligheder som programmeringen af Cell BE arkitekturen medfører. CellSs mangler dog at blive udvidet til at fungere på en klynge af maskiner før det bliver et virkelig interessant projekt. Alf[13] er IBMs svar på hvordan man kan lave et værktøj som programmøren kan bruge til at håndtere hukommelsesmodellen på Cell BE arkitekturen. Alf yder support for multiple-program-multiple-data, hvilket betyder flere programmer med flere datasæt. Meningen er at hjælpe programmøren med håndteringen af data overførsler, parallelle opgaver, dobbelt buffering og load balancering af parallelle opgaver. Alt dette kan Alf håndtere på en enkelt Cell BE maskine, desværre virker dette ikke på en klynge af Cell BE maskiner. Alf fungere ved nogle funktionskald, som giver programmøren mulighed for at oprette opgaver og arbejdsblokke (data). En opgave kan godt være afhængig af en anden opgave, hvilket betyder at nogle opgaver skal færdiggøres før andre opgaver kan startes. En arbejdsblok indeholder normalt noget input og output data. Input data º½ er det data Ë ÑÑ Ò ØÒ Ò der skal bruges til at løse en delopgave, mens output data er resultatet af delopgaven. Når man på PPE en har oprettet opgaver og arbejdsblokke, kan SPE erne begynde at behandle disse opgaver og disse opgavers tilhørende arbejdsblokke. Alf giver programmøren en godt værktøj til at programmere Cell BE arkitekturen, men værktøjet understøtter ikke en klynge af Cell BE maskiner. De ældste DSM systmer er primært hardware baserede, og derfor ikke umiddelbart relevante for en implementation i forbindelse med dette projekt. Dog er de stadig relevante, da de nyere softwarebaserede systemer bygger på erfaringer fra disse projekter. Selvom CSP og Tuplespaces er nogle overordnetligt interessante systemer, mener vi at DiSOM har den simpleste kerne. Ved at implementere et system der udelukkende baserer sig på entry consistency modellen, fås et simpelt basis system. Når dette basis system er robust, bliver det væsentligt lettere at implementere f.eks. Tuplespaces eller CSP ovenpå. Hvis CellSs eller Alf udvides til at understøtte klynger af maskiner, kan disse vise sig at være gode bud på en håndtering af Cell BE maskiner.

54

55 Ã Ô Ø Ð ËÅ ÒÓÚ ÖÚ Ð Ö Problemet med Cell BE arkitekturen er at det er forholdsvis svært at komme i gang med at bruge denne arkitektur. Nogle systemer, såsom Alf[13] og CellSs[14], forsøger at hjælpe på dette. Men problemet er at der kræves en masse viden om mailbox e, DMA overførelser osv., hvilket man normalt ikke har kendskab til fra den gængse computer arkitektur. Ser man isoleret på PPE delen af Cell BE arkitekturen, er denne programmeringsmæssigt, og med hensyn til fælles delt hukommelse, magen til de fleste arkitekturer. Problemet ligger i de lynhurtige og uundværlige beregningsenheder, SPE erne. Disse har ikke direkte adgang til hovedhukommelsen. En klynge af Cell BE maskiner med fælles delt hukommelse, er som standard selvfølgelig utopi. For at opnå fælles delt º½ hukommelse Ë Ò Ö Ó Ò Ö Ú for både PPE er, SPE er og Cell BE maskiner, er distribueret delt hukommelse en løsning. Dette giver dog anledning til en masse spørgsmål om hvordan sådan et system skal designes. I dette afsnit vil vi give vores bud på hvordan det kan gøres. Vi har valgt at kalde systemet DSMCBE (Distributed Shared Memory for the Cell Broadband Engine). Scenariet er en mængde Cell BE maskiner, som hver især består af en PPE og 8 SPE er 1. Disse maskiner er alle forbundet via et netværk og hver maskine har en hovedhukommelse, som er delt mellem PPE ens to kerner. For at kunne dele denne hukommelse mellem PPE erne og SPE erne på disse Cell BE maskiner, er det naturligvis nødvendigt at tilføje et system som kan håndtere denne deling. Figur 6.1 giver et overblik over scenariet hvor flere Cell BE maskiner, med PPE og SPE enheder, er forbundet til et system kaldet DSMCBE. Idéen er at skabe et system, hvori det er muligt at PPE er og SPE er kan hente data fra hovedhukommelsen på en vilkårlig maskine. Hvis data er placeret i hovedhukommelsen på en anden maskine, er det naturligvis nødvendigt med en dataoverførsel via netværket. Den nødvendige kommunikation mellem de forskellige enheder er tiltænkt at foregå gennem DSMCBE og er således transparent for brugeren. DSMCBE er tiltænkt en placering på PPE en, da den har direkte adgang til hovedhukommelsen. Desuden ville en placering på en eller flere SPE er være urealistisk pga. størrelsen på SPE ernes LS samt SPE ernes ringe evne til trådhåndtering og system operationer. Nu har vi defineret hvad scenariet er og i resten af afsnittet, vil vi definere de krav der er til designet af DSMCBE. Vi ønsker at det skal være muligt for programmøren at få adgang til et delt dataobjekt fra en PPE tråd eller SPE, uden på forhånd at kende noget til 1 Sony s Playstation 3, som vi har benyttet, har kun 6 SPE er til rådighed.

56 Ã Ô Ø Ð º ËÅ ÒÓÚ ÖÚ Ð Ö Figur 6.1: Oversigt over et scenarie med 3 Cell BE maskiner forbundet via netværk. Hver Cell BE maskine har 1 PPE med 2 tråde og 8 SPE er. Derudover indeholder hver Cell BE maskine værktøjet DSMCBE. dataobjektets placering. Det må selvfølgelig forventes at programmøren på en eller anden måde, kan identificere dataobjekterne og derved hvilket dataobjekt, programmøren ønsker adgang til. Placeringen af dataobjekterne kan være på en vilkårlig Cell BE maskine i klyngen, hvor det dog kan tænkes at klyngen kun består af én enkelt maskine. Det skal være muligt for programmøren at bede om enten læse eller læse/skrive adgang til dataobjektet. For at systemet skal virke er det nødvendigt jf. afsnit 3.3, at programmøren º¾ fortæller ËÅ ÃÓÑÔÓÒ ÒØ Ö systemet at noget data er et delt dataobjekt. Ligeledes skal programmøren fortælle systemet at denne ønsker at tilgå et delt dataobjekt og at denne er færdig med at benytte et delt dataobjekt. Dette dikteres mere eller mindre af entry consistency model, som bliver benyttet i DSMCBE. I dette afsnit vi vil beskrive de komponenter som DSMCBE består af, samt hvordan de enkelte ¼ komponenter kommunikere med hinanden. I starten vil flere af komponenterne være sorte bokse (eng: black box), dvs. at komponenten fungerer uden at være beskrevet endnu.

57 º¾º½ ËÅ ÖÒ Ø ÐÈÈ ³ ÒÓ ËÈ ³ ÖÒ ËÅ ÖÒ Ø ÐÈÈ ³ ÒÓ ËÈ ³ ÖÒ Hvis man ser isoleret på de enkelte Cell BE maskiner, vil programmøren typisk have noget bruger kode på både PPE en og SPE erne, som skal have fat i hovedhukommelse. PPE kode kan, som tidligere nævnt, få fat i hovedhukommelsen direkte, hvorimod SPE kode ikke kan. Derfor kunne man godt lade PPE en fungere som normalt og bare lade DSMCBE hjælpe SPE erne med at få fat i hovedhukommelsen, men dette kommer dog ikke til at fungere. Problemet er at man gerne vil vide hvem der har adgang til hvilket data, især i forbindelser med skrive-operationer. Derfor er det nødvendigt at DSMCBE hjælper både PPE en og SPE erne med at få fat i hovedhukommelsen. Placeringen af DSMCBE på PPE en, gør at det ikke er nødvendig med kommunikation mellem bruger koden på PPE en og DSMCBE. Programmøren kan kalde funktioner direkte i DSMCBE. Vi har dog valgt at lave en komponent, kaldet DSMCBE PPE, som danner et mellemled mellem programmørens kode og DSMCBE. Dette gør vi for at have en klar adskillelse mellem den interne funktionalitet i DSMCBE og den funktionalitet som bruger koden har adgang til. Det er nødvendigt med en eller anden form for kommunikation mellem DSMCBE og bruger koden på SPE erne. Det er også nødvendigt med noget kode, som programmøren kan kalde, når denne ønsker at benytte sig af DSMCBE fra SPE erne. Derfor er det nødvendigt at have en komponent, som vi giver betegnelsen DSMCBE SPE, på º¾º¾ÈÈ ¹»ËÈ Ò Ø SPE en, som kan kommunikere med DSMCBE på PPE en og som har nogle funktioner som programmøren kan kalde. Vi vil senere komme ind på, hvilke funktioner i DSMC- BE PPE og DSMCBE SPE, der skal være tilgængelige for programmøren. Figur 6.2 giver et overblik systemet efter vi har tilføjet de to første komponenter. Nu har vi for PPE en og SPE erne defineret hvilke komponenter der skal til for at brugerkoden kan kommunikere med DSMCBE. Næste skridt er at definere hvilke komponenter DSMCBE skal bestå af. PPE en skal gennem DSMCBE PPE kommunikere med DSMCBE. Da DSMCBE og DSMCBE PPE begge er placeret på PPE en, er det naturligt at de kommunikere via interne funktionskald, hvilket giver et simpelt og enkelt system. Derfor skal der være en komponent med nogle funktioner som DSMCBE PPE kan kalde og derved stå for kommunikationen til DSMCBE. Dette giver også mulighed for at flere PPE tråde kan kalde funktionalitet i samme komponent, og derved kan der spares noget overhead, i forhold til at hver tråd skulle have hver deres komponent på DSMC- BE siden. Vi har valgt at kalde denne komponent for PPE håndtaget, efter det engelske udtryk handle. Hvis man kigger på hvordan SPE erne kan kommunikere med DSMCBE, findes der, som beskrevet i afsnit 1.4, 3 muligheder; nemlig signaler, mailbox e og DMA overførelser. Signaler er mest egnede til at sætte registre med 32 kontrol bits og egner sig ikke til overførelse af heltal. Mailbox e derimod egner sig netop til at sende sekvenser af heltal. DMA overførelser kan bruges til at sende enkelte heltal og strenge, men egner sig bedst til at sende større mængde data f.eks. et udsnit af et billede. Mailbox e virker derfor som et naturligt valg. Ulempen ved dette valg er, at programmøren ikke umiddelbart kan ½ benytte sig af mailbox systemet, da dette vil skabe kollisioner mellem programmørens mailbox beskeder og de interne mailbox beskeder i DSMCBE. Som tidligere beskrevet findes der 3 typer af mailbox e set fra SPE erne, nemlig udgående, udgående interrupt og indgående. Fra PPE en er det selvfølgelig indgående, indgående interrupt og udgåen-

58 Ã Ô Ø Ð º ËÅ ÒÓÚ ÖÚ Ð Ö Figur 6.2: I forhold til figur 6.1 har PPE en og SPE erne fået tilføje noget bruger kode samt den del af DSMCBE som bruger koden kalder. de, til hver SPE. Da vi forventer at DSMCBE skal sende pakker begge veje, vil DSMCBE beslaglægge en indgående og den udgående for hver SPE. Derved kan programmøren godt sende pakker fra SPE erne til PPE en via den anden udgående mailbox, men det er ikke muligt at sende pakker den anden vej. Vi vil dog senere i afsnit 10.1, beskrive hvordan det alligevel kan gøres, ved at lade programmøren sende mailbox beskeder igennem DSMCBE. Nu har vi defineret hvordan DSMCBE SPE kan kommunikere med DSMCBE og omvendt. Situationen er altså, at vi har et antal SPE er der forventer at kunne kommunikere med DSMCBE via hver deres DSMCBE SPE. På PPE en siden er det nødvendigt º¾º ÃÓÓÖ Ò ØÓÖ med en komponent i DSMCBE til at sende/modtage mailbox beskeder til/fra den enkelte DSMCBE SPE komponent, således at SPE erne og DSMCBE kan kommunikere. Vi vælger at kalde denne komponent SPE håndtaget. Figur 6.3 viser hvordan systemet ser ud med de to håndtag. Nu ¾ har vi altså to håndtag som kan kommunikere med SPE erne og PPE en, men vi mangler et bindeled mellem de to. Dette bindeled, som vi kalder koordinatoren, er den centrale enhed i DSMCBE. Målet med denne opdeling, med håndtag og koordinator, er at man senere kan tilføje flere håndtag, f.eks. håndtag til forskellige typer netværk m.m. Koordinatoren, som er det centrale element i DSMCBE, forbinder PPE en, SPE erne

59 ÃÓÓÖ Ò ØÓÖ Figur 6.3: I forhold til figur 6.2 har DSMCBE systemet fået tilføjet de to håndtag som skal kommunikere med DSMCBE modulerne på PPE en og SPE erne. og netværket, som vi vil se i næste afsnit. Dette betyder at koordinatoren er den komponent som er ansvarlig for at DSMCBE fungerer korrekt. Koordinatorens opgave bliver, i kraft af dens centrale role, at holde styr på hvilke dataobjekter der er oprettet i systemet, hvor de befinder sig i hovedhukommelsen, samt hvem der har adgang til dem og hvilken type adgang de har. Da vi forestiller os at alle håndtag ligger på PPE en, kan koordinatoren og håndtagene kommunikere via interne funktionskald og strukturer. En løsning kunne være at håndtagene og koordinatoren kunne kalde interne funktioner til at udføre de forskellige operationer. Dette giver en simpel løsning, som dog har nogle problemer. Koordinatoren, som skal håndtere beskeder fra alle håndtagene, kan kun betjene et håndtag af gangen. Derfor er det nødvendigt med en låse mekanisme på alle funktioner, som håndtagene kan kalde. Dette giver et noget stift design, som betyder at det ikke er muligt for håndtagene at aflevere en pakke og udføre noget andet arbejde, mens man venter på et svar som ikke nødvendigvis kommer med det samme. Denne simple idé giver et stift design, hvor kommunikationen bliver for dybt integreret i resten af systemet. En anden løsning kunne være at koordinatoren havde en indgående og udgående kø, således kunne de forskellige håndtag sende og modtage beskeder via disse to køer. Dette er dog kun en god løsning, hvis koordinatoren udelukkende sender pakker som håndtagene forventer. Ellers ville alle de andre håndtag hele tiden skulle undersøge om den udgående kø, indeholdt nogle beskeder til dem, hvilket ikke er optimalt. Da vi forventer, i forbindelse med invalidering, at koordinatoren skal sende nogle beskeder, som

60 Ã Ô Ø Ð º ËÅ ÒÓÚ ÖÚ Ð Ö håndtagene ikke står og venter på, dur denne løsning ikke. Derfor kunne en god løsning være at lade alle håndtag samt koordinatoren, have én indgående kø. Derved har hver komponent én kø, som den skal holde øje med. Dette betyder dog også at alle som ønsker at sende en besked til en enhed, skal bruge samme kø. PPE og SPE håndtaget er i denne sammenhæng lidt speciel, da de har flere fysiske enheder (PPE tråde/spe er) koblet til sig. Vi ser det som en fordel at disse håndtag har én indgående kø per enhed der er koblet på håndtaget. Dette skyldes at man sagtens kunne forestille sig at flere enheder står og venter på en besked fra koordinatoren samtidigt og at de derved skulle deles om adgang til samme kø. Når de forskellige enheder skal undersøge om der en besked i disse køer, findes der flere måder at gøre det på, men de kan deles i to grupper, nemlig aktivt venten og passiv venten. Den aktive venten vil hele tiden undersøge om der er kommet en ny besked og derved bruge CPU tid, mens den passive først undersøger når den har fået et tegn på at der er en besked i køen. Et sådan tegn kunne f.eks. være et event. At vente passivt, er klart at foretrække og derfor vælger vi at bruge en form for events til dette formål. Hvordan ved de forskellige komponenter hvor de skal sende svaret på en givet pakke hen? En simpel løsning er at hver pakke, som man ved der kommer et svar på, skal indeholde information om hvilken kø svaret skal skrives til, hvilken lås køen bruger, samt hvilket begivenhed skal kaldes når man har indsat noget i køen. Derved opnår man º¾º Æ ØÚÖ Ò Ø en forholdsvis simpel struktur, som gør at pakkerne nemt kan sendes mellem de forskellige komponenter og selve kommunikation bliver uafhængigt af resten af systemet. Som figur 6.4 viser, har vi nu beskrevet overordnet hvordan DSMCBE skal se ud i den situation hvor vi har en enkelt Cell BE maskine. Indtil videre har vi beskrevet et system, som fungerer på en enkelt Cell BE maskine, men nu ønsker vi at kunne sætte flere Cell BE maskiner med DSMCBE sammen. Cell BE maskinerne har hver især et netværkskort og en Playstation 3, som vi har benyttet, har et 1Gb Ethernet kort. Derfor er det oplagt at bruge dette netværkskort, til at lade DSMCBE kommunikere med DSMCBE på andre maskiner. For at kunne gøre dette, er det nødvendigt med en komponent, som kan sende beskeder via netværkskortet og som samtidigt º Ö Ú ÖÚ Ð Ø Ø Ó Ø kan kommunikere med koordinatoren. Vi vælger at kalde denne komponent netværkshåndtag. Vi har nu defineret alle de komponenter som DSMCBE består af. Figur 6.5 giver et overblik over det komplette system. For at få adgang til et delt dataobjekt skal programmøren kalde en funktionen, som vi kalder acquire. Da programmøren ikke kender det delte dataobjekts pointer, må vi have en måde hvorpå vi kan identificere det ene dataobjekt fra det andet. En god løsning er at give hvert delt dataobjekt et ID, således at man kan sammenkoble ID er og pointere. Da vi ikke ønsker at ændre på nogle kompilere, kræves det at programmøren tildeler hvert dataobjekt et globalt unikt ID (GUID). Programmøren giver således det globale ID som argument til funktionen.

61 Ö Ú ÖÚ Ð Ø Ø Ó Ø Figur 6.4: I forhold til figur 6.3 har DSMCBE systemet fået tilføjet en koordinator, som er den centrale enhed i DSMCBE og som behandler forespørgslerne fra de forskellige håndtag. ÚÓ ÕÙ Ö ÍÁ ÙÒ Ò ÐÓÒ Þ ÒØØÝÔ µ Ligeledes kunne det tænkes at programmøren gerne ville have størrelsen på objektet og til dette formål kan man sende en pointer til en variabel af typen long med som argument. Da vi ønsker at have mulighed for både at tilgå data med læse eller skrive adgang, er det nødvendigt at angive, hvilken type adgang man ønsker. Funktionen skal returnere en pointer til data og samlet giver dette følgende funktionsdefinition. Hvis der kaldes ÕÙ Ö, og data ikke er oprettet, findes der tre logiske handlinger. Funktionen kan returnere en fejl, oprette data eller vente på at data oprettes. Vi vurderer at det vil være uhensigtmæssigt at oprette data automatisk, da data sjældent er brugbart uden at være udfyldt med meningsfyldt indhold. Da funktionen også venter hvis data er låst, mener vi at det er mest fornuftigt at vente på at data oprettes. På sigt kan der implementeres en timeout på ÕÙ Ö, og ved at sætte timeout lavt, får man mulighed for at returnere en fejl. For at opnå, at der ventes på at dataobjektet oprettes, er det nødvendigt at holde en kø over processer der venter på oprettelsen af et givet objekt. Når objektet oprettes, skal de processer der venter, svares som normalt. Vi antager at dataobjektet er oprettet medö Ø funktionen, som vi beskriver i næste afsnit. I de følgende afsnit beskrives hvad der skal ske i de respektive komponenter, når en programmør ønsker at tilgå delte dataobjekter med henholdsvis en læse- og skrivelås fra henholdsvis en PPE og en SPE. En erhvervelsesforespørgsel som kommer fra

62 Ã Ô Ø Ð º ËÅ ÒÓÚ ÖÚ Ð Ö Figur 6.5: I forhold til figur 6.4 har DSMCBE systemet fået tilføjet et netværks håndtag, som skal håndtere kommunikationen med netværks håndtag på andre Cell BE maskiner. Denne figur viser den endelige opbygning af DSMCBE. netværket er lidt anderledes en erhvervelsesforespørgslen fra PPE en og SPE en. Netværkshåndtaget, º º½ÈÈ Ò Ø Ö Ø Ö Ú ÖÚ Ð Ñ Ð Ò er som tidligere beskrevet, ledet mellem netværket og koordinatoren, og derfor er netværkshåndtaget hovedopgave at oversætte beskeder, således at koordinatoren kan forstå beskeder der kommer fra netværket og netværket kan forstå beskeder der kommer fra koordinatoren. Derfor kan netværket, i sig selv, ikke erhverve et dataobjekt. Programmøren ønsker fra PPE en at få læse adgang til et delt dataobjekt og kalder derfor acquire funktionen med de nævnte parametre. Vi vurderer at asynkron erhvervelseskald ikke er nødvendige på PPE en, da PPE en har et glimrende trådbibliotek og asynkrone kald derved kan håndteres vha. af tråde, vælger vi at gøre erhvervelseskaldene synkrone. Når programmøren ønsker at tilgå et delt dataobjekt, kalder denne direkte acquire funktionen i DSMCBE PPE komponenten. Dette betyder at DSMCBE har 3 informationer om det dataobjekt programmøren ønsker at tilgå, nemlig GUID, en pointer til en ÙÒ Ò ÐÓÒ samt hvilken tilstand(læse/skrive) programmøren ønsker at tilgå dataobjektet i. Som beskrevet tidligere, kommunikerer DSMCBE PPE og PPE håndtaget ved direkte funktionskald. Derfor er næste skridt at DSMCBE PPE kalder en acquire

63 håndtaget.èè Ò Ø Ö Ø Ö Ú ÖÚ Ð Ñ Ð Ò funktion i PPE PPE håndtaget, som modtager acquire forespørgslen fra DSMCBE PPE, kan ligesom DSMCBE PPE, ikke vurdere om forespørgslen kan accepteres på nuværende tidspunkt. Dette skyldes at det kun er koordinatoren som har adgang til information om hvilke dataobjekter der er oprettet, hvor de befinder sig i hukommelsen, samt hvem der på nuværende tidspunkt har adgang til dem og hvilken type adgang de har. Derfor kan PPE håndtaget ikke tage stilling til, om forespørgslen kan godkendes eller ej, og derfor må den sende forespørgslen videre til koordinatoren. Dette betyder naturligvis at koordinatoren vil blive meget belastet. Som tidligere beskrevet, skal det være muligt at flere kan tilgå data samtidigt med en læselås, hvorimod en skrivelås giver eksklusiv adgang til data. Der kan dog, jf. afsnit , opstå situationer hvor to enheder kan have læse og skrive adgang samtidigt til et dataobjekt, hvor dataobjektet dog er placeret i forskellige hukommelsesblokke. Hvis PPE håndtaget gemmer en liste over objekter, som er blevet tilgået tidligere, så bliver det muligt for PPE håndtaget at godkende acquire forespørgsler på objekter med læselås. Fordi PPE håndtaget allerede har objektet, vides det at koordinatoren også ved at PPE håndtaget har objektet. Hvis objektet senere tilgås med en skrivelås, vil koordinatoren sende en invalideringsbesked. Denne form for erhvervelse kaldes lokal generhvervelse (eng: local reacquire), da man henter data lokalt i stedet for at hente det via koordinatoren. Disse lokale generhvervelser er potentielt meget farlige. Det skyldes at koordinatoren sagtens kan give en skrivelås på et dataobjekt, som PPE håndtaget lige skal til at give en læselås på. Hvis dette sker, kan en process stå og læse data, mens en anden skriver til samme data. Dette løses normalt med at der jf. partioned entry consistency modellen, udsendes en invalideringsbesked til alle som har haft en læselås på et dataobjekt, før der tildeles en skrivelås på dataobjektet. Dette virker også i langt de fleste tilfælde, hvis man sørger for at kontrollere at der ikke er nogle udstående invalideringer hos PPE håndtaget, inden den godkender en lokal generhvervelse. Dette er dog ikke altid nok, da man sagtens kan nå at godkende den lokale generhvervelse, inden invalideringsbeskeder kommer frem til PPE håndtaget. Vi vil under beskrivelsen af erhvervelse af et dataobjekt med en skrive lås, beskrive hvordan man løser dette problem, ved ikke at tillade at data må skrives tilbage til hovedhukommelsen, før alle har frigivet deres læselåse på dataobjektet. Hvis PPE håndtaget kan godkende erhvervelsesforespørgslen, skrives størrelsen af dataobjektet til den pointer som blev sendt med forespørgslen og derudover returneres en pointer til dataobjektet. Kan forespørgslen derimod ikke godkendes lokalt, sendes den videre til koordinatoren. Da PPE håndtaget ikke ved om koordinatoren kan håndtere beskeden eller om den sender den videre til en koordinator på en anden maskine, er der her fordelagtigt at pakke beskeden ind i en pakke. Pakken skal herefter overføres til koordinatoren, ved at indsætte pakken i koordinatorens indgående beskedkø. Med henblik på at modtage et svar på denne forespørgsel, har PPE håndtaget en kø, hvor den ønsker at koordinatoren skal svare. Ud over denne kø, indeholder pakken også en mutex samt et event, som skal signaleres, når svaret er klart. Når koordinatoren modtager denne pakke, er første skridt at undersøge om dataobjektet er oprettet. Hvis dette ikke er tilfældet, skal koordinatoren, jf. tidligere diskussion, sætte forespørgslen i en kø, som venter på at objektet oprettes. Hvis dataobjektet ikke er ledigt, skal det tilføjes en kø over forespørgsler, der afventer på at dataobjektet bliver ledigt. Hvis objektet eksisterer og er ledigt, dvs. at ingen har låst dataobjektet med en skrivelås, kan forespørgslen godkendes. Da vi tillader lokale generhvervelser uden

64 Ã Ô Ø Ð º ËÅ ÒÓÚ ÖÚ Ð Ö om koordinatoren, er der ingen grund til at markere dataobjektet som låst i forbindelse med en læselås erhvervelse. Nu mangler koordinatoren bare at sende et svar til PPE håndtaget. Koordinatoren ved ikke hvem den skal sende svaret til, så derfor opretter den en pakke til dette formål. Denne pakke ligges i køen fra forespørgslen og eventet fra forespørgslen signaleres. På et tidspunkt modtager PPE håndtaget en pakke fra koordinatoren, som er et svar på erhvervelsesforespørgslen. For at finde ud af hvilken forespørgsel pakken fra koordinatoren hører til, er det nødvendigt at bruge et sekvens nummer, således kan man give forespørgsler et unikt nummer og svaret på disse forespørgsler har så samme unikke nummer. Når PPE håndtaget modtager svar pakken fra koordinatoren, skal den først registre informationerne med henblik på at kunne udføre en lokal generhvervelse senere. Når dette er gjort kan pointeren sendes videre til DSMCBE PPE og derved til brugerkoden. Nu har brugerkoden fået en pointer til data og kan derfor bruge data direkte. Selvom programmøren har bedt om dataobjektet med en læselås, er der intet der forhindrer denne i at ændre data. Det skyldes at når programmøren har en pointer til data, kan man skrive direkte til det data denne peger på. Det er selvfølgelig ikke optimalt, så derfor kunne man tage en kopi af data, og så sende denne pointer til programmøren. Når programmøren ikke længere skulle læse fra data, kunne man slette denne midlertidige kopi º º¾ÈÈ Ò Ø Ö Ø Ö Ú ÖÚ Ð Ñ Ö Ú Ò af dataobjektet igen. Vi vurderer dog, at det vil give, betydeligt ringere ydelse, at skulle tage kopier af et dataobjekt hver gang dette skal tilgås med læse adgang. Derfor giver vi programmøren ansvaret for ikke at skrive til dataobjekter, som der kun er erhvervet læse adgang til. Udover at erhverve et dataobjekt med en læselås, kunne det tænkes at programmøren ønsker at erhverve dataobjektet med en skrivelås. Hvis dette er tilfældet ser kaldet til acquire funktionen ud som i forrige afsnit, dog sættes type-flaget til en skrivelås fremfor en læselås. Ligesom før, starter kaldet i funktionen acquire i DSMCBE PPE komponenten, hvorefter kaldet overgår til PPE håndtaget. Modsat en erhvervelse med en læselås, kan man med en skrivelås ikke udføre en lokal generhvervelse. Dette skyldes at koordinatoren, skal have besked om at en enhed ønsker en skrivelås, således at den kan forbyde andre enheder at få adgang til dataobjektet imens. Derfor sendes erhvervelsesforespørgslen videre til koordinatoren. Denne kontrollerer, som før, om objektet er oprettet eller ej. Hvis dataobjektet er oprettet, kontrolleres om dataobjektet er ledigt og hvis det er det, låses dataobjektet. Næste skridt er at sørge for at der bliver sendt invalideringsbeskeder til de enheder som har haft dataobjektet med en læselås. Dette gælder både lokale enheder, samt enheder på netværket. Herefter kan pointer til dataobjektet og størrelse af dataobjektet skrives til PPE håndtaget. Som beskrevet i forrige afsnit er der et problem, når man benytter sig af lokale generhvervelser. Problemet er at nogle kan komme til at læse et dataobjekt, mens en anden skriver til det. Der findes to løsninger på dette problem. Det ene er at man ikke benytter lokale generhvervelser og derved går alt trafik igennem koordinatoren og problemet forsvinder derved. En anden løsninger er at vente med at skrive data tilbage til hovedhukommelsen, indtil alle har svaret på invalideringsbeskederne tilhørende et givet dataobjekt. Dermed ved man, at ingen har dataobjektet længere og enheden som har skrivelåsen på dataobjektet, kan trygt skrive resultaterne tilbage til hovedhukommelsen. Dette fungerer dog ikke på PPE en, da den har direkte adgang til hovedhukommelsen.

65 ËÈ Ò Ø Ö Ø Ö Ú ÖÚ Ð Ñ Ð Ò Man kunne løse dette problem ved at tage en kopi af data ved skrivelås erhvervelser. Dette ville betyde at man ikke skulle bekymre sig om hvordan programmøren besluttede sig for at skrive til data og derved kunne man returnere pointeren hurtigere til programmøren. Vi vurdere dog at det vil være en forholdsvis dyr affære at skulle udføre mange kopieringer af hukommelsen. Vi vælger derfor at forsinke udleveringen at pointeren, indtil at PPE håndtaget modtager et signal fra koordinatoren om at alle invalideringsbeskederne er indsamlet. Vi kalder dette signalûö Ø Ù ÖÊ Ý. Denne virkemåde svare til den normale entry consistency model, som beskrevet i º º ËÈ Ò Ø Ö Ø Ö Ú ÖÚ Ð Ñ Ð Ò Nu kan pointeren til dataobjektet og størrelsen sendes tilbage til PPE håndtaget. For at undgå at en anden PPE tråd, kan udføre en lokal generhvervelse af dataobjektet, er det nødvendigt at blokere dataobjektets mulighed for lokale generhvervelser. Denne blokering kan ophæves, når dataobjektet frigives. Til slut sendes pointeren og størrelsen, sendes DSMCBE PPE og derved til programmøren. I dette afsnit undersøger vi hvad der sker, når en programmør ønsker at tilgå et dataobjekt med læseadgang fra en SPE. Programmøren kalder, ligesom på PPE en, funktionen på PPE en, er et funktionskald i komponenten DSMCBE SPE ÕÙ Ö som, modsat fremfor komponenten DSMCBE PPE. SPE en har, som tidligere beskrevet, ikke direkte adgang til hovedhukommelsen og kan ikke kalde funktioner i DSMCBE direkte. Derfor skal DSMCBE SPE kommunikere med SPE håndtaget via mailbox beskeder. Når DSMCBE SPE håndtaget har modtaget en mailbox besked fra en SPE er første skridt er undersøge hvilken type besked der er tale om. Når pakke typen er fastlagt, ved SPE håndtaget hvilke informationer den skal læse fra mailbox en. Ligesom for PPE håndtaget, kan SPE håndtaget nu undersøge om det er muligt at lave en lokal generhvervelse fra dataobjektet. Hvis dette er muligt sendes pointeren til dataobjektet, samt dataobjektets størrelse tilbage til DSMCBE SPE, via mailbox beskeder. Hvis dette derimod ikke er muligt oprettes en pakke, på samme måde som i PPE håndtaget og sendes til koordinatorens indgående kø. Nu kan SPE håndtaget så begynde at vente på et svar på forespørgslen, men modsat PPE håndtaget foregår dette asynkront, dog kun internt i DSMCBE. Ligesom PPE håndtaget, bruger SPE håndtaget også sekvens numre, til at skelne mellem de forskellige forespørgsler og svar. Derfor kan den nu behandle pakken korrekt. Når SPE håndtaget har pointeren og størrelsen på dataobjektet, kan den, ligesom PPE håndtaget, sende disse videre, i dette tilfælde dog til SPE en. Når SPE en modtager disse informationer, kan den allokere plads til dataobjektet i dens LS og starte en eller flere DMA overførelser, for at hente dataobjektet fra hovedhukommelsen. Dette er den løsningen, som normal er mest oplagt, men desværre viste nogle tidlige test af DSMCBE at det er en dårlig løsning i dette tilfælde. Dette skyldes bl.a. at man får en masse kald til Ñ ÐÐÓ/ Ö for at allokere og deallokere data i LS en. Derudover forsvinder muligheden for at udnytte dobbelt buffer systemet, hvor man overføre data, mens man beregner på noget andet. Senere vil det også vise sig at det er nødvendigt med en del bogføring angående hvilke objekter der er allokeret i LS, og denne form for bogføring er ikke det SPE erne er bedst til. Deres beregningskraft er bedst anvendt på beregninger og ikke på bogføring. Heldigvis er det muligt at starte DMA overførelser fra PPE, og derved skubbe data ud i SPE ens LS. Dette kræver dog at SPE en enten fortæller hvor i LS en PPE skal overføre data til eller at PPE opretter et hukommelsesbilled (eng: memory map) over

66 Ã Ô Ø Ð º ËÅ ÒÓÚ ÖÚ Ð Ö hvilket plads der er allokeret i LS en. Denne sidste løsningen fjerner en masse kald til Ñ ÐÐÓog Ö på SPE erne og må derfor ses som den bedste. Ulempen ved denne løsning er selvfølgelig at man skal kunne finde ledigt plads i LS ens hukommelse, på en nem og hurtig måde, men dette findes der en løsning på, som vi vil se på i afsnit Indtil videre antager vi at PPE håndtaget ved hvor data kan placeres i LS en. Ligesom på PPE en er det fordelagtigt at udføre en lokal generhvervelse. Hvis objektet findes i LS en i forvejen, kan man tilmed spare DMA overførelsen. Hvis dataobjektet ikke findes i hukommelsen i forvejen, er det selvfølgelig nødvendigt at starte en DMA overførsel. Disse, kan som tidligere skrevet, maksimalt overføre 16KB, så derfor skal man muligvis starte flere DMA overførelser for at overføre et dataobjekt. Disse DMA overførelser er asynkrone, derfor er det nødvendigt at gemme informationer om hvilke og hvor mange igangværende DMA overførelser vi har gang i. Dette skyldes at vi ikke kan fortælle SPE en hvor data befinder sig, før vi har overført hele dataobjektet til LS en, dvs. at alle DMA overførslerne tilhørende dette dataobjekt er færdige. Således kan vi hurtigt, º º ËÈ Ò Ø Ö Ø Ö Ú ÖÚ Ð Ñ Ö Ú Ò når vi opdager at en DMA overførelse er færdig, finde ud af om det var den sidste og om vi derfor kan sende pointeren og dataobjektets størrelse via mailbox beskeder til DSMCBE SPE. Desuden vil det i forbindelse med invalidering af dataobjekter, vise sig at det er fordelagtigt at kunne se hvilke igangværende DMA overførelser der er på en SPE. En erhvervelse med skriveadgang til dataobjektet, som startes på SPE en, minder i store træk om samme type erhvervelse startet af en PPE. Både måden hvorpå forespørgslen oprettes º º ËÈ Ù ÓÑÑ Ð ÐÐÓ Ö Ò og sendes til koordinatoren, samt koordinatorens håndteringen af forespørgslen, er ens. Når svaret på forespørgslen, kommer tilbage til SPE håndtaget, startes en DMA overførsel af dataobjektet, med mindre dataobjektet allerede findes i SPE ens LS. Når dataobjektet befinder sig i LS en, evt. efter at der er udført en DMA overførelse, sendes pointeren til SPE en som herefter kan benytte dataobjektet. Som nævnt i forrige afsnit, og senere i afsnit 9, er det fordelagtigt at starte DMA overførelser fra PPE en (SPE håndtaget). Dette kræver dog at vi har et hukommelses kort over hver SPE s LS. I dette afsnit vil vi beskrive hvordan sådan et kort kan designes. Et hukommelseskort er et kort over hukommelsen, som viser hvilke områder er allokeret og hvilke områder der er tilgængelige. Når man har dette, er det muligt at allokere noget plads, hvilket normalt sker medñ ÐÐÓog frigive allokeret plads, hvilket normalt sker med Ö. Da SPE håndtaget ikke direkte kan allokere og frigive plads på LS en medñ ÐÐÓog Ö, er det nødvendigt at SPE en gør dette. Dette kunne man f.eks. gøre ved at sende nogle mailbox beskeder som får SPE en til at allokere plads eller frigive en pointer. Dette er dog ikke særligt optimalt, da man på denne måde bibeholder mange dyre kald tilñ ÐÐÓog Ö. En anden løsning kunne være at hver SPE i forbindelse med opstarten undersøgte hvor meget plads der var ledigt i LS en og derefter allokerer en ¼ stor del af dette. Derefter kunne SPE en sende disse oplysninger til SPE håndtaget og herved ville SPE håndtaget kunne håndtere allokering og frigivelser af data lokalt. Den sidste løsning virker som den mest fornuftige, da man sparer en masse kommunikation mellem SPE håndtaget og SPE en. Derudover sparer man en masse kald tilñ ÐÐÓog Ö på SPE en.

67 ËÈ Ù ÓÑÑ Ð ÐÐÓ Ö Ò Næste problem er at afgøre hvordan et kort skal se ud, således at man hurtigt kan vurdere hvor man kan allokere et antal bytes. Der findes et hav af metoder til hukommelsesallokering, men vi har kigget på dynamic partitions [52], fordi den er enkel at implementere og giver en forholdsvis god ydelse. Alternativt kunne man bruge fixed partitions, men denne metoder deler hukommelsen op i lige store dele, hvilket giver et stort spild af hukommelsen. Man kunne også have set på mere avancerede og moderne metoder, men vi har vurderet, at eftersom hukommelsen på SPE erne er meget begrænset, er der ingen grund til at implementere en kompleks metode. Dynamic partitions går ud på at man definerer hvilke områder af hukommelsen er ledige. Et eksempel kunne være at SPE håndtaget havde fået at vide, at SPE en kunne allokere 215KB i LS en medñ ÐÐÓog atñ ÐÐÓreturnere pointeren Nu ville man så skrive start pointeren og størrelsen ind i en tabel (215KB) Derefter ønskede SPE håndtaget måske at allokere 16KB plads på SPE en. Nu kigger den i tabellen og ser at der er 215KB ledigt fra pointeren (10000). Derfor opdateres tabellen, således at den nu ser sådan ud (199KB) Vi kan se at pointeren er blevet 16KB større og at pladsen er blevet 16KB mindre. Når en pointer frigives, sker det omvendte. Denne tabel vil sagtens kunne få flere elementer og derfor skal man være ekstra opmærksom i forbindelse med frigivelse af data. Følgende situationer kan opstå i forbindelse med opdatering af tabellen, når man frigiver data. 1. Det frigivende data ligger i forlængelse af et element i tabellen. Data kan enten ligger før eller efter et element i tabellen. Et eksempel kunne være at tabellen indeholdt element (10,5) og den pointer man ønsker at frigive er 5 og denne har størrelsen 5. Nu ser tabellen således ud (5,5) (10,5), hvilket svarer til (5,10). 2. Det frigivende data ligger imellem to elementer i tabellen. F.eks. kunne tabellen indeholde to element (10,5) (20,5). Den pointer vi ønsker at frigive er 15 og har størrelsen 5. Dette betyder at tabellen nu indeholder (10,5) (15,5) (20,5), hvilket svarer til (10,15). 3. Det frigivende data ligger ikke i forlængelse af eksisterende elementer i tabellen og derfor skal pointer og størrelse bare indsættes i tabellen. Ud over at have et kort over hukommelsen, er det også nødvendigt at have en oversigt over allokerede pointere og størrelsen af den allokerede plads. I forbindelse med frigivelse af data, vil man kun få en pointer til det dataobjekt der skal frigives. Da det er nødvendigt at kende størrelsen af den allokerede plads, som pointeren peger på, kan man med fordel gemme denne oplysning i en tabel, når man allokerer plads i hukommelsen. Alternativt kunne man allokere 4 bytes mere plads end nødvendigt og skriver ½ størrelsen i disse 4 bytes, alá. den mådeñ ÐÐÓ Ð Òfungere på. Denne beskrevne model er dog ikke helt perfekt. Et stort problem, når man snakker allokering af hukommelse er fragmentering. Fragmentering opstår når man har allokeret og frigivet en mængde objekter af forskellig størrelse. På et tidspunkt ønsker man

68 Ã Ô Ø Ð º ËÅ ÒÓÚ ÖÚ Ð Ö måske at allokere et stort objekt på 16KB og man kan se at den samlede mængde frie hukommelse er 32KB, så alt er godt. Dog ligger alle de allokerede element således at den største mængde sammenhængende ledige hukommelse kun er 8KB, og derved kan man ikke allokere objektet på 16KB. Dette problem kan dog delvist fjernes ved at ændre på den metode man finder ledig hukommelse på. Når man har tabellen og ledige mængder hukommelse, vil man ofte søge listen igennem og tage den første pointer, hvor der er nok ledigt plads. Dette betegner man som en first-fit søgning og ulempen ved denne type søgning, er at den ofte kan resultere i fragmentering. En anden løsning er at søge gemme tabellen med en best-fit søgning. Denne søgning returnere den pointer, hvis størrelse er tættest på den mængde plads man skal bruge. Derved kan man i betydelig større grad undgå fragmentering, men man kan ikke udelukke det. Ulempen ved denne type søgning, er at man ofte skal løbe hele tabellen igennem. Kun hvis man finder et element º º Ö Ú ÖÚ Ð ÓÚ ÖÒ ØÚÖ i tabellen, som har samme størrelse, som det element man vil allokere, kan man slippe for at løbe hele tabellen igennem. Dynamic partition scheme egner sig godt til at finde ledigt hukommelse på LS erne. Dette skyldes hovedsageligt at mængden af plads i LS en er stærkt begrænset og derved kan tabellen over ledigt hukommelse, aldrig indeholde særligt mange elementer. Netværkshåndtaget kan i sig selv ikke starte en erhvervelse, men den kan sende en forespørgsel om en erhvervelse videre over netværket. Netværkshåndtaget kan derfor også modtaget et svar på en erhvervelse og dermed selve dataobjektet. Når dette sker, er det muligt, dog mindre sandsynligt, at dataobjektet allerede eksisterer på den lokale maskine. Situationen er at, f.eks. en PPE tråd, har har læseadgang til et dataobjekt. En anden maskine får skriveadgang til samme dataobjekt og frigiver efterfølgende dataobjektet igen. Dette betyder at SPE en fra før, får en invalidering af dataobjektet, den har dog ikke frigivet dataobjektet endnu. En anden SPE på samme maskine får efterfølgende læseadgang º ÇÔÖ ØØ Ð Ø ÐØ Ø Ó Ø til sammen dataobjekt, dog i en opdateret version. Det samme dataobjekt findes derfor nu to steder i hukommelsen, det ene dataobjekt er invalideret, men stadig i brug og det andet er den nyeste version af dataobjektet. For at håndtere dette er det nødvendigt at opretholde en liste over de objekter der burde være slettet, således at disse kan slettes når data bliver frigivet. For at markere noget data som et delt dataobjekt i hovedhukommelsen, ville det simpleste være at programmøren opretter noget data og så kalder en funktion, kaldet create, med pointeren til data som argument. Dette er der dog flere problemer i. For det første kræver det at data bliver oprettet korrekt, dvs. at data er 128bit aligned og størrelse er et multiplum af 16 bytes, da det ellers ikke er muligt at overføre dataobjekter via en DMA overførelse. Dette kunne man godt stille som krav til programmøren, men eftersom DS- MCBE er et værktøj til at hjælpe programmøren, virker det mest fornuftigt at funktionen create selv allokerer pladsen i hukommelsen. Dette betyder dog at programmøren skal angive ¾ størrelsen af det delte dataobjekt som argument til funktionen. Selvom dataobjektet oprettes fra en SPE, er det optimale at det gemmes i hovedhukommelsen. Dette skyldes naturligvis at SPE erne kun har en meget begrænset mængde hukommelse. For at oprette et dataobjekt, skal man give det globale ID med til create funktionen, således at det er muligt at identificere dataobjektet senere. Funktionen create kommer

69 ÈÈ Ò Ø Ö ØÓÔÖ ØØ Ð ÚÓ Ö Ø ÍÁ ÙÒ Ò ÐÓÒ Þ µ derfor til at se sådan ud og funktionen returnerer en pointer til det delte dataobjekt. Oftest vil man, når man har oprettet noget data, skrive til data, inden andre får adgang º º½ÈÈ Ò Ø Ö ØÓÔÖ ØØ Ð til det. For at undgå at andre får adgang til data, inden en givet tråd er færdig med at oprette det, vil det være naturligt at create funktionen automatisk låser det delte dataobjekt. Således vil den som har oprettet dataobjektet have mulighed for at skrive data, inden andre får adgang til data. Dette medfører at programmøren eksplicit skal frigive dataobjektet igen, således at andre enheder kan få adgang til dataobjektet. Hvis programmøren ønsker at oprette et objekt, bruges funktionen create, som beskrevet i forrige afsnit. På PPE en findes denne funktion i komponenten DSMCBE PPE, der ligesom med acquire, kalder en funktion i PPE håndtaget. Data skal derefter pakkes ind, så koordinatoren kan læse det. Pakken indsættes i koordinatorens indgående kø. Når koordinatoren er nået til at behandle oprettelsesforespørgslen, håndterer den beskeden lokalt, hvis maskinen er ansvarlig for oprettelser af dataobjekter, hvis ikke sendes forespørgslen videre via netværket til den maskine der har ansvaret for oprettelser. Når koordinatoren på den maskine, som er ansvarlig for oprettelser, modtager en oprettelsesforespørgsel, er første skridt at undersøge om dataobjektet findes i forvejen. Hvis det ikke er tilfældet, kan man enten sende en fejlbesked, eller erhverve objektet med skrive adgang. Vi vurderer at en fejlbesked er den bedste løsning, fordi man efter en oprettelse normalt vil skrive nyt data ind i dataobjektet. Hvis dataobjektet ikke findes, skal det oprettes i listen over allerede oprettede objekter. Vi vælger at kalde denne liste for en objekttabel (eng: objecttable), og vi vil efterfølgende bruge denne term. Næste spørgsmål er så hvilke informationer elementerne i denne objekttabel skal indeholde. Objektets id, størrelse, samt placering i hovedhukommelsen er selvfølgelig selvskrevne informationer, man ønsker at gemme. Derudover vil vi gerne kunne vurdere om et dataobjekt er låst, dvs. at en har skrive adgang til det. Hvis man ønsker adgang til dataobjektet og det ikke er ledigt, vil det være en fordel, hvis man kan blive skrevet på en venteliste, således at når dataobjektet igen bliver ledigt, kan man hurtigt håndtere dem som venter på adgang. En løsning er, at slå disse to informationer sammen, således at man opretter én samlet venteliste. Ved at undersøge om der er nogle som venter, kan man derfor samtidigt undersøge om objektet er låst. Hvis man venter på at et dataobjekt bliver ledigt, indsætter man blot erhvervelsesforespørgslen i listen. Hvis man derimod ønsker at låse køen, kan man indsætte en værdi i ventelisten, for at markere at forespørgslen er behandlet, og at én nu har skriveadgang til dataobjektet. Er ventelisten tom, er dataobjektet ikke låst og ingen venter derfor på at det bliver ledigt. Inden vi kan indsætte et element i objektettabellen, skal der først allokeres plads til dataobjektet i hovedhukommelsen. Som tidligere nævnt, skal dette foregå lidt specielt. For at kunne overføre dataobjektet til SPE erne med DMA overførelser er det nødvendigt at data størrelsen er et multiplum af 16 bytes. Derudover skal dataobjektet allokeres således at det ligger sig på en 128bit grænse i hukommelsen. Til dette formål benyttes funktionñ ÐÐÓ Ð Ò, dog skal man stadig manuelt beregne det rigtige størrelse. Sidste ting, som skal undersøges, inden vi kan indsætte elementet i objekttabellen, er om der er nogle som venter på at objektet bliver oprettet. Hvis nogle havde forsøgt at tilgå objektet inden, det blev oprettet, vil forespørgslerne stå i en venteliste, og denne

70 Ã Ô Ø Ð º ËÅ ÒÓÚ ÖÚ Ð Ö venteliste, º º¾ËÈ Ò Ø Ö ØÓÔÖ ØØ Ð skal naturligvis overføres til elementet. Derefter kan dataobjektet låses ved at indsætte en værdi i toppen af listen, og elementet kan indsættes i objekttabellen. Herefter sendes pointeren til data og størrelsen tilbage til den enhed som har bedt om oprettelsen. Dette foregår på samme måde som svaret på en erhvervelse med skrive adgang. Oprettelse af et dataobjekt fra en SPE foregår i store træk på samme måde som en oprettelse fra en PPE. Da SPE erne ikke har meget hukommelse, oprettes dataobjektet naturligvis º Ö Ú Ð Ø Ø Ó Ø i hovedhukommelsen, så derfor er eneste forskel den måde hvorpå oprettelse forespørgslen sendes til koordinatoren. Dette foregår ved at DSMCBE SPE sender nogle mailbox beskeder til SPE håndtaget, som opretter en pakke og sætter den ind i koordinatorens indgående kø. Derefter udfører koordinatoren samme procedure som hvis den havde fået pakken fra PPE håndtaget. For at fortælle systemet at man ikke længere ønsker adgang til et dataobjekt, skal man kalde funktionenö Ð. En givet enhed som ønsker at frigive et dataobjekt, kan enten have en læse- eller skrivelås på dataobjektet. Handlingen for at frigive dataobjektet er forskellig afhængig af hvilken type lås man har. Dette skyldes, at hvis man har en skrivelås, skal dataobjektet skrives tilbage til hovedhukommelsen. Derudover kan der være nogle enheder som venter på at få en lås på dataobjektet og disse skal også informeres. Dette kan også ske hvis man opretter et dataobjekt, da den enhed som opretter dataobjektet, automatisk får en skrivelås på dataobjektet. Derfor er det nødvendigt at kommunikere med koordinatoren i forbindelse med en frigivelse af et dataobjekt. Anderledes ser det ud for et dataobjekt som man har en læselås på. Her skal data ikke skrives tilbage til hovedhukommelsen og der er ikke nogen som venter på at enheden frigiver dataobjektet, da andre enheder godt kan tage en læse- eller skrivelås på et dataobjekt som en anden enhed har en læselås på. Det eneste som er problematisk i denne forbindelse er invalideringen, men vi vil i afsnit 6.6, komme ind på hvad problemet er og hvordan det løses. Indtil videre beslutter vi at en frigivelse af et dataobjekt med en læselås, kan foregå lokalt på enheden og ikke kræver kommunikation med andre komponenter i DSMCBE. For at opnå en lighed med Ö funktionen, og på den måde markere at pointeren ikke º º½ÈÈ Ò Ø Ö Ø Ö Ú Ð ÚÓ Ö Ð ÚÓ Ø µ længere er gyldig, tager release en pointer til den lokale kopi af data og ikke det globale ID. Funktionsdefinitionen for release ligner bevidst Ö og ser således ud: Hvis programmøren ønsker at frigøre et dataobjekt, kaldesö Ð funktionen i DS- MCBE PPE. Ligesom med kaldene tilö Ø og ÕÙ Ö, videresendes kaldet direkte til PPE håndtaget. Første skridt på vejen til at frigive et dataobjekt er at finde ud af hvilket dataobjekt, frigivelsen drejer sig om. Som beskrevet tidligere, ønsker vi atö Ð skal ligne Ö, og derfor tagerö Ð en pointer som parameter. For at kunne finde ID et og størrelsen på det dataobjektet vi har en pointer til, må vi slå op i en tabel. Når vi har

71 ËÈ Ò Ø Ö Ø Ö Ú Ð fundet det rigtige element, er det nødvendigt at vide hvilken type adgang vi har til dataobjektet, for at kunne vurdere om vi skal informere koordinatoren eller ej. Da PPE en har direkte adgang til hovedhukommelsen, er det selvfølgelig ikke nødvendigt at skrive data tilbage. Dog kunne man forestille sig at, dataobjektet skulle skrives tilbage til ejeren, som kunne være en anden maskine. Da PPE håndtaget ikke ved, hvem der er ejer af dataobjektet, skal dette håndteres af koordinatoren. Er der derimod tale om en læseadgang, er det ikke nødvendigt at informere koordinatoren, og derfor kan man udføre frigivelsen lokalt i PPE håndtaget. Hvis der er tale om en frigivelse, hvor PPE en har haft skriveadgang til dataobjektet, skal koordinatoren informeres, som tidligere nævnt. Derfor oprettes en pakke, som sættes ind i koordinatorens indgående kø. Når koordinatoren skal behandle enö Ð pakke, findes dataobjektet i objekt tabellen og låsen på dataobjektet skal derefter fjernes. Hvis der nu var nogle der har ønsket at få adgang til dataobjektet, mens PPE en havde en skrivelås på dataobjektet, vil de stå i ventelisten. Da vi nu har fjernet låsen på dataobjektet, er det oplagt at informere de næste i køen om at de nu kan få adgang til dataobjektet. De som venter på at dataobjektet bliver ledigt, kan enten ønske at tilgå dataobjektet med læse eller skriveadgang. Den º º¾ËÈ Ò Ø Ö Ø Ö Ú Ð første forespørgsel på ventelisten behandles, og hvis denne forespørgsel ønsker læseadgang til dataobjektet, kan næste forespørgsel også behandles, da en læse adgang ikke låser dataobjektet påny. Dette kan fortsætte så lang tid, der ikke kommer en forespørgsel som ønsker skriveadgang til dataobjektet. Hvis dette sker, skal dataobjektet, selvfølgelig låses på ny, og derefter kan man ikke behandle flere forespørgsler på ventelisten. En frigivelse på en SPE foregår i store træk som på PPE en, men der er dog nogle forskelle. Programmøren kalder funktionen release, som befinder sig i elementet DSMCBE SPE. Denne sender nogle mailbox beskeder til SPE håndtaget. Når SPE håndtaget har modtaget mailbox beskederne og fundet ud af at SPE en ønsker at frigive et dataobjekt, finder den først ud af hvilket dataobjekt det drejer sig om. Hvis SPE en har læseadgang til dataobjektet, kan man udføre en lokal frigivelse uden om koordinatoren. Da dataobjektet befinder sig i SPE ens LS, kan man, som tidligere beskrevet, undlade at fjerne elementet fra LS en, således at man senere har mulighed for at udføre en lokal generhvervelse. Hvis man derimod er ved at løbe tør for hukommelsen i LS en, er det selvfølgelig nødvendigt at slette dataobjektet. Spørgsmålet er så hvornår det er mest fordelagtigt, at vurdere om dataobjektet skal slettes. Vi har vurderet, at det vil give mest mening at slette, gamle frigivne, men stadig allokere dataobjekter i forbindelse med at man skal allokere plads til et nyt dataobjekt. Dette gør data befinder sig så lang tid som muligt i LS en. Som tidligere nævnt er fragmentering et problem på LS en, og forsinket fjernelse af gamle dataobjektet er med til at gøre problemet større. Når man står i en situation, hvor man skal fjerne et gammelt dataobjekt for at gøre plads til et nyt, kan man med fordel slette et gammelt dataobjekt som har samme størrelse, som det dataobjekt man ønsker at allokere plads til. Derved kan man i større grad undgå fragmentering, men dette tager dog lidt længere tid, da man skal løbe hele listen af gamle dataobjekter igennem, og desuden bryder det med MRU princippet. Dog ses det klart som en fordel i dette tilfælde, hvor mængden af hukommelse og antallet af gamle dataobjekter er minimal. Hvis frigivelsen drejer sig om et dataobjekt med skriveadgang, er det nødvendigt at sende data til hovedhukommelsen. Det mest naturlige er at lade SPE håndtaget sørge for dette, ligesom med erhvervelserne. Derved opnår man at det kan foregå asynkront. Da det ikke kan garanteres, at alle som har læseadgang til et dataobjekt, er færdi-

72 Ã Ô Ø Ð º ËÅ ÒÓÚ ÖÚ Ð Ö ge med at benytte data fra hovedhukommelsen, kan man ikke uden videre starte DMA overførelsen fra LS en til hovedhukommelsen. Først når det kan garanteres at alle har svaret på invalideringsbeskeden, dvs. at PPE trådene har frigivet data og SPE erne har fået º º Æ ØÚÖ Ò Ø Ö Ø Ö Ú Ð data overført fra hovedhukommelsen til LS en, kan man skrive data til hovedhukommelsen.ïö Ø Ù ÖÊ Ýsignalet bruges til at markere at data trygt kan skrives til hovedhukommelsen. Når man har modtagetûö Ø Ù ÖÊ Ýsignalet kan man starte DMA overførelserne og når disse er færdige kan man informere koordinatoren herom. Den kan nu starte samme procedure, som for PPE en. Igen fungerer netværkshåndtaget som et relæ mellem netværket og koordinatoren. Der er dog en situation, som man skal være opmærksom på. Når der kommer en frigivelse ind via netværket, dvs. at en anden enhed vil skrive data tilbage til hovedhukommelsen, kan man umiddelbart ikke overskrive dataobjektet i hovedhukommelsen. Dette skyldes at på den lokale maskine, kan der være en enhed som ikke har frigivet dataobjektet endnu, og derfor ikke har svaret på invalideringen. Derfor kan det ikke garanteres, at den lokale enhed har læst dataobjektet og det er derfor nødvendigt at tage en kopi af dataobjektet º ÁÒÚ Ð Ö Ò ÙÒ Ø ÓÒ Ð Ø Ø i frigivelsesforespørgslen. Først når når alle lokale enheder har svarer på invalideringen, kan dataobjektet i hovedhukommelsen overskrives. Ved at anvende den samme liste som nævnt under erhvervelse i afsnit 6.3.6, kan dette problem håndteres ret simpelt. I et system hvor man kan tilgå data i enten en skrive- eller læse tilstand, vil følgende scenarie opstå før eller siden. Nogle har en læsbar kopi og en anden beder om en skrivbar kopi. Nu skal dem som har en læsbar kopi, gøres opmærksomme på, at deres data ikke længere er gyldigt. Dette kan løses ved at sende en invalideringsbesked og derved invalidere data som ikke længere er gyldigt. En anden løsning er at sende en opdateringsbesk og derved opdatere ugyldigt data således at det bliver gyldigt. Da vi på sigt forventer at DSMCBE skal kunne køre på flere Cell BE maskiner forbundet af et netværk, ser vi det som fordelagtigt at benytte invaliderings metoden, da den ikke kræver at data sendes med rundt og derfor bliver data pakkerne mindre. Derfor skal det være muligt at invalidere data. Som det ses af figur 3.14 fra side 21, udsendes invalideringen i forbindelse med svar pakken på erhvervelsesforespørgsel. Da den eneste komponent, som kan godkende en skrive forespørgsel er koordinatoren, må det nødvendigvis også være den, som er ansvarlig for at starte invalideringsprocessen. Det er klart at der skal udsendes en invalidering hver gang en enhed beder om skriveadgang til et dataobjekt, under forudsætning at en anden enhed tidligere har haft læse- eller skriveadgang til dette dataobjekt. Da koordinatoren ikke kan vurdere hvem der skal invalideringerne, sendes disse til alle 3 håndtag. De 3 håndtag, har hver især mulighed for at holde styr på, hvem der har/har haft en kopi af data, kan disse forhindre broadcast ved kun at sende invalideringen til de relevante enheder. Når PPE håndtaget modtager en invalideringsforespørgsel fra koordinatoren, kan dataobjektet have følgende 3 tilstande på PPE en:

73 ÇÔ Ø Ö Ò Ó ØØ ÐÐ Ò Dataobjektet kan være i brug. Dataobjektet kan være frigivet, men PPE håndtaget har stadig en reference til data. Dataobjektet kan være frigivet og PPE håndtaget har ingen reference til data. Hvis referencen er slettet, kan PPE håndtaget selvfølgelig svare direkte på forespørgslen. Hvis dataobjektet er frigivet uden at referencen er slettet, kan PPE håndtaget slette referencen og derefter svare på forespørgslen. Hvis dataobjektet derimod er i brug, må man vente til at brugerkoden frigiver dataobjektet, før der kan svares på invalideringsforespørgslen. Situationen på SPE håndtaget er lidt anderledes, da SPE erne benytter LS en som lokal hukommelse. Derved kan man svare direkte på en invalideringsforespørgsel, såfremt DMA overførslen af dataobjektet fra hovedhukommelsen til LS en er færdig. Hvis dette ikke er tilfældet, må man vente med at svare, til DMA overførslen er færdig. Efter man har svaret på forespørgslen, skal man selvfølgelig sørge for at slette hukommelsen, så hurtigt så muligt, dvs. når dataobjektet frigives. Når netværkshåndtaget modtager en forespørgsel om at invalidere et dataobjekt fra koordinatoren, skal forespørgslen sendes videre til de relevante maskiner i klyngen. Da man ikke kan garantere, at netværkshåndtaget har læst data fra hovedhukommelsen, før det er blevet sendt, kan netværkshåndtaget først svare på invalideringsbeskeden, når der ikke længere er udestående overførelser med det pågældende dataobjekt. Man kunne alternativt tilbageholde dataobjektet indtil det igen blev frigivet, men dette kunne resultere i udsultning (eng: starvation). Netværkshåndtaget kan også modtage en forespørgsel om at invalidere et dataobjekt fra netværket. Hvis dette sker, skal den sende forespørgslen videre til koordinatoren, som skal behandle denne, som om den selv havde igangsat invalideringen. Dette betyder dog at netværkshåndtaget igen vil modtaget invalideringsforespørgslen, men da der her ikke vil være udestående overførsler, kan der svares med det samme. Netværkshåndtaget vil ikke sende et invalideringssvar tilbage over netværket, da det ikke er nødvendigt at vente på frigivelsen af data på den anden maskine. º Den ÇÔ Ø Ö Ò Ó ØØ ÐÐ Ò koordinator som oprindeligt svarede på erhvervelsesforespørgslen, skal beholde en reference til den enhed som også modtog skrivelåsen. Når alle enheder har svaret på invalideringen, skal denne reference benyttes til at signalere at det nu er sikkert at skrive til hovedhukommelsen. Dette giver signaletïö Ø Ù ÖÊ Ý, som beskrevet tidligere. Objekttabellen i DSMCBE er egentlig bare et normalt delt objekt, som dog kun kan hentes internt. Når der sker en større mængde oprettelser vil objekttabellen blive invalideret mange gange. Dette medfører meget netværkstrafik og skaber et tidsrum hvor maskinen ikke kan håndtere beskeder, fordi den ikke har en gyldig objekttabel. For at modvirke dette kan man lade alle maskiner oprette objekttabellen lokalt. Ved opstart er ingen objekter er oprettet, og denne tabel er derfor ens for alle maskiner. Når hoved maskinen oprettet et objekt, sender den blot en opdatering til de andre maskiner. Når en maskine modtager en opdatering, vil det være muligt at aktivere eventuelt ventende forespørgsler. Hvis en maskine, der ikke er hoved maskinen, ønsker at oprette et objekt, kan den videresende forespørgslen til hoved maskinen. Forespørgslen må herefter vente på den

74 Ã Ô Ø Ð º ËÅ ÒÓÚ ÖÚ Ð Ö lokale maskine, indtil der modtages et svar. Når der modtages en opdatering, vides det at oprettelsen lykkedes korrekt, og den ventende oprettelse kan besvares. Hvis oprettelsen fejler besvares dette med enæ Ãbesked. º Hvis Î Ö Ò Ð Ø Ð ÓÑ ¹ÒÓ man ved, at programmet ikke forsøger at oprette samme objekt to gange, kan man undlade at vente på opdateringen, og opdatere objekttabellen lokalt. Dette giver mulighed for meget hurtigere oprettelser, men man kan komme i den situation at to enheder har oprettet samme objekt. Da begge enheder har fået en gyldig pointer til data, er det ikke muligt at afvise oprettelsesforespørgslen. Eftersom vi har valgt at anvende en home-based model, er det nødvendigt at overføre alle forespørgsler til den maskine som er home-node. I et system med kun en maskine, vil dette aldrig ske, fordi maskinen altid er home-node. Når der er mere end én maskine opstår der let en situation hvor forespørgslen ikke kan håndteres lokalt. For at det kan opdages, at den lokale maskine ikke er home-node, skal den lokale maskine have en opdateret objekttabel. Da dette skal afgøres ret ofte, er det en fordel hvis alle maskiner sørger for at have en opdateret objekttabel hele tiden. Hvis der kommer en forespørgsel på et objekt, hvor ejeren ikke kendes, er det ensbetydende med at objektet endnu ikke er oprettet. Den lokale koordinator skal herefter blot sætte forespørgslen i venteposition, som beskrevet i afsnit 6.3. Når objektet bliver oprettet, enten lokalt eller på en anden maskine, vil der blive rundsent information om at objektet er oprettet. Når denne information modtages, bliver det muligt at behandle forespørgslen. Da home-node for det pågældende objekt nu kendes, kan forespørgslen vidresendes til den korrekte maskine, hvilket ikke nødvendigvis er en anden maskine end den lokale. Denne model bevirker at der kan opstå en ændring i rækkefølgen af beskederne, da der bliver et kapløb om at videresende forspørgslerne når objektet bliver oprettet. Dette vurderer vi som værende mindre betydende, da det udelukkende kan ske i forbindelse med oprettelser, og derfor ikke kan medføre udsultning. En alternativ model kunne være at vælge en maskine som midlertidig home-node, og så holde en samlede liste på denne maskine. Når objektet så oprettes bliver forespørgslerne så sendt fra denne liste, og herved bibeholdes forespørgslernes indbyrdes orden. Denne model bevirker at der kommer unødig netværkstrafik, og unødig belastning på den midlertidige home-node, og vi vurderer derfor at den foregående model er at foretrække, på trods af muligheden for forstyrrelse af den indbyrdes orden. Når det opdages at en besked ikke kan håndteres lokalt, skal denne sendes til netværks håndtaget, sammen med nummeret på den maskine der er home-node. Netværks håndtaget sørger så for at tildele pakken et sekvensnummer og sende denne afsted. Når svaret kommer tilbage, skal dette sendes dette sendes tilbage til koordinatoren, således at denne kan vedligeholde systemet. Således kan koordinatoren registrere når et nyt objekt ankommer, og eventuelt uddele dette ved en lokal generhvervelse. º ÝÒ ÖÓÒ Ð Ö ÒËÈÍ I alle HPC systemer er dobbelt buffering et godt værktøj til at skjule latenstider. Dette er også tilfældet på Cell BE arkitekturen. En dobbelt buffering går ud på at bede om data, beregne på noget andet data, og herefter modtage det første stykke data. Dette sikrer at

75 ËØÖ Ñ Ò Ø Ø ÐËÈÍ der hentes mens der beregnes. Da alle kald i DSMCBE fra programmørens synspunkt er defineret som værende blokerende, dvs. synkrone, er det ikke muligt udføre dette. Det gør naturligvis at det ikke bliver muligt at holde SPE erne konstant forsynet med data, og herved falder ydelsen markant. En løsning kunne være at anvende tråde. Dette fungerer ganske fint på en PPE, men ikke på en SPE. Årsagen er at SPE ens hardware ganske enkelt er uegnet til at udføre kontekstskift, hvad angår SPU en, men også fordi der skal bruges en del af den sparsomme hukommelse til hver tråd. En løsning på dette er at tilføje asynkrone kald på SPE en. Dette øger kompleksiteten af at bruge DSMCBE, men har ikke umiddelbart andre bivirkninger. Da det ikke er et krav at brugeren anvender asynkrone kald, virker denne tilføjelse som et ganske fornuftigt tiltag. For at kunne understøtte asynkrone kald, er det nødvendigt at have en funktion der igangsætter funktionalitet, men ikke blokerer. For at kunne have flere samtidige igangværende asynkrone kald, skal hvert kald have et ID. Dette ID kan så anvendes når det asynkrone kald afsluttes. Da der som regel findes et punkt hvor der ikke længere kan udføres arbejde uden data, virker det logisk at have en funktion der blokerer indtil det º½¼ asynkrone ËØÖ Ñ Ò Ø Ø ÐËÈÍ kald skal afsluttes. Det kan tænkes at der er situationer hvor det er muligt at vælge mellem to handlinger, afhængigt af om data er tilgængelig eller ej. Derfor bør der også være en funktion der undersøger om data er tilgængelig, og returnerer denne information. Herved bliver det muligt at undgå blokerende kald. Ved at anvende asynkrone kald åbnes der op for overlapped execution. Dette øger effektiviteten ganske markant, men det er besværligt at udnytte dette til at udføre tredobbelt eller firedobbelt buffering. Ved at tillade at en SPE kan bede om en liste af objekter, bliver det muligt at udnytte overlapped execution i en meget høj grad, uden at øge kompleksiteten for programmøren. Da lister er en smule besværlige at håndtere på en simpel måde i C, og skal overføres via. en mailbox, foreslår vi at indføre en funktion der indsætter en enkelt forespørgsel i en kø. Forespørgsler i denne kø skal så udføres så langt som det er muligt. Det vil sige at forespørgslen skal afsendes til koordinatoren. Når svaret kommer, skal data overføres til SPE en via. en DMA overførsel, hvis der er plads på SPE en. Hvis der ikke er plads, skal overførslen vente indtil der kommer plads. Hvis der kommer en ÒÚ Ð Ø besked før pointeren er overgivet til SPE en, skal forespørgslen sendes igen. Herved opstår der ekstra aktivitet, men forsinkelsen bliver i værste tilfælde den samme som hvis forespørgslen først blev startet når data skal hentes. Det virker oplagt at SPE håndtaget står for at håndtere den funktionalitet, da den hele tiden har et overblik SPE ens hukommelse, gennem de føromtalte hukommelseskort. Det skal naturligvis være muligt at angive hvor mange forudgående forespørgsler der skal startes, for at minimere unødige overførsler. Brugssituationen er tænkt således at en SPE på forhånd ved at den skal bruge en række af objekter, men der er ikke plads til eller brug for, alle objekterne på en gang. Ved at starte en forespørgsel på alle objekter på en gang, kan disse forespørgsler køres i forvejen, således at der konstant er data til stede. Denne situation betyder potentielt at en SPE arbejder på fuld kraft hele tiden, og hermed kan den optimale ydelse opnås. Når data skal bruges kaldes en funktion der frigiver det nuværende objekt, og retur-

76 Ã Ô Ø Ð º ËÅ ÒÓÚ ÖÚ Ð Ö nerer en pointer og størrelsen på det næste objekt. Ved at anvende denne model kræves der º½½ stort set Ë ÑÑ Ò ØÒ Ò ingen specialkode fra programmøren, for at opnå meget høj ydelse. Ulempen ved at anvende en sådan model, er at det bliver muligt at introducere deadlocks på en måde, som ikke er umiddelbart indlysende. Dette ansvar bliver overdraget til programmøren, da distribueret deadlock undersøgelse har en negativ indflydelse på ydelsen[23]. Vi har i overstående afsnit beskrevet hvordan et design af et værktøj til at hjælpe programmøren med at håndtere hukommelsesmodellen på Cell BE arkitekturen kan se ud. Ved kun at have et begrænset antal funktioner som programmøren kan kalde, er det forholdsvist simpelt at komme i gang med at bruge Cell BE arkitekturen. Designet er tiltænkt at give et robust system der samtidigt er muligt at implementere, og derved få nogle erfaringer med DSM på Cell BE arkitekturen. Derudover skal det være muligt senere at tilføje mere funktionalitet f.eks. håndtag til andre typer netværk m.m. ¼

77 Ã Ô Ø Ð ÁÑÔÐ Ñ ÒØ Ø ÓÒ ÓÚ ÖÚ Ð Ö I º½ dette afsnit ½ ÖÙÒ ÑÔÐ Ñ ÒØ Ø ÓÒ gennemgås den overordnede opbygning af DSMCBE. Vi har valgt at dele implementationen op i afgrænsede faser, på en sådan måde at der er en klar grænse for hvornår én fase er afsluttet, og en ny begynder. Hver fase bygger på indholdet af den foregående fase og udvider systemet med funktionalitet eller effektivitet. ÀÒ Ø Ö Ò ÓÖ Ô Ö Ð Ö I første fase er det afgørende mål at få PPE og SPE er til at kommunikere på en enkelt maskine. For at forsimple implementationen, er det i denne fase kun muligt at tage en skrivelås og derved blokere for samtidig adgang til data. De fastlagte funktioner i denne fase er: ÕÙ Ö,Ö Ð ogö Ø. I denne fase implementeres et modul til at holde styr på alle forespørgsler. For at sikre en sekventiel ordnet håndtering af indkomne forespørgsler, virker det mest fornuftigt at benytte en kø-struktur. Ved at indsætte forespørgsler i en kø, undgår man den blokerende adfærd et funktionskald vil have. Da det er nødvendigt at holde forespørgslernes indbyrdes orden, bl.a. for at undgå udsultning, virker det logisk at anvende en enkelt tråd til at læse og bearbejde forespørgsler. Dette system giver en form for tovejs producer/consumer system. Da der anvendes en enkelt tråd, betyder det at resten af modulet bliver relativt simpelt at implementere fejlfrit. Da der kun er en tråd, er det kun nødvendigt at synkronisere adgangen til køen, da andre tråde udelukkende kan tilgå denne. Dette giver et næsten fuldstændigt fravær af låse i programkoden. Hvilket giver en væsentlig fordel ydelsesmæssigt, da der ikke skal aktiveres låse hele tiden. Dette valg har dog den ulempe at denne ene tråd bliver en potentiel flaskehals. Da der skal udføres et relativt lille antal operationer ved hver forespørgsel, virker denne risiko acceptabel i forhold til gevinsten. En anden ulempe er at der som minimum skal udføres følgende sekvens ved alle forespørgsler: lås, indsæt i kø, lås op. Og på samme måde skal det foregå ved læsning af forespørgslen, ligesom svaret gennemgår samme to sekvenser. Dette betyder ½ at der er et overhead på 4 sekvenser for hver operation. Dette overhead giver længere køretid og bruger naturligvis flere CPU cykler. Det største problem med denne model er at der introduceres unødige latenstider. Dette er særdeles problematisk for applikationer der ikke har mulighed for at udnytte dobbelt buffering. Vi vurderer at vi i denne opga-

78 Ã Ô Ø Ð ºÁÑÔÐ Ñ ÒØ Ø ÓÒ ÓÚ ÖÚ Ð Ö ve kan få en acceptabel ydelse, men på sigt skal det overvejes om nogle funktioner kan implementeres uden brug af en kø. ÀÒ Ø Ö Ò ÈÈ Ð Som nævnt har vi kun skrive adgang til delt data. Dette gør at der skal implementeres funktionalitet til at forsinke svaret på en forespørgsel hvis en anden process allerede har adgang til data. Herudover er der kontrolmæssig ikke de store udfordringer. Modulet som implementere dette kaldesê ÕÙ Ø ÓÓÖ Ò ØÓÖ, og det er en implementation af den i analysen benævnte enhed "koordinator". Som nævnt er det valgt at benytte en enkelt tråd til at håndtere forespørgsler, men samtidig har vi i analysen (se afsnit 6), redegjort for at at alle kald til DSMCBE skal være blokerende. Vi ved også at der senere kommer et netværks modul. Disse overvejelser gør at vi mener det er mest fordelagtigt at lade hver process have en indgående kø. Denne indgående kø er så beskyttet af etñùø Ü, og tilknyttet enóò Ø ÓÒsåledes at flere tråde ÀÒ Ø Ö Ò ËÈ Ð kan tilgå den indgående kø, og det er muligt at vente på at data bliver indsat. Efter denne beslutning, er det særdeles nemt at implementere PPE delen af systemet, den skal blot oprette en kø, etñùø Üog enóò Ø ÓÒ. Herefter sendes det hele til Ê ÕÙ Ø ÓÓÖ Ò ØÓÖmodulet, og PPE tråden venter så blot på et signal fraóò Ø ÓÒ. Når signalet modtages, kan svaret hentes ud af køen og returneres til kalderen. En SPE kan ikke kommunikere direkte medê ÕÙ Ø ÓÓÖ Ò ØÓÖmodulet, da der ikke kan kaldes PPE funktioner direkte fra SPE en. I stedet kan en forespørgsel sendes som mailbox beskeder. Ved at have et modul på PPE siden, der overvåger en mailbox, kan denne læse mailbox beskeder, og danne de samme strukturer som PPE koden benytter sig af. Herefter bliver sekvensen den samme som for PPE koden, men når svaret modtages, skal dette igen omdannes til mailbox beskeder. Der foregår altså en serialisering og Ë ÑÑ Ò ØÒ Ò de-serialisering af forespørgsler og svar. Når SPE en venter, går dette ud på at læse en mailbox, hvorved koden blokerer indtil svaret modtages. Når svaret er modtaget, skal data overføres via en DMA overførsel. SPE en skal så igangsætte denne, og vente på at den er afsluttet. Herefter kan resultatet returneres til kalderen. En implementation af et system i fase 1, vil give et ineffektivt, men fungerende system. Et program der er skrevet til en fase 1 implementation bør kunne benyttes uden ændringer på en implementation af en af de senere faser. Idéen med fase 1 er at give en simpel grundlæggende implementation, som nemt kan udvides senere. º¾ ¾ ÌÖ ÔËÈ ¾ Da det er oplagt at SPE erne benytter overlapped execution, fungerer det ikke optimalt at alle kald er blokerende. En oplagt løsning er at introducere tråde, således at hver SPE simulerer flere fysiske enheder, og dermed kan udføre arbejde mens der ventes. Det minder om den måde hyper-threading[37] fungere på. Ved at anvende tråde opnås der en situation der minder meget om den måde hvorpå traditionelle programmer skrives. Det

79 ¾ ÌÖ ÔËÈ er ønskværdigt at funktionaliteten implementeres på en sådan måde, at selve trådfunktionaliteten kan benyttes i andre projekter. Da der ikke er hardware support for tråde, og interrupt funktionaliteten ikke virker som en oplagt mulighed, er der kun mulighed for user-mode tråde, dvs. non-preemptive trådskift. Der findes en mulighed for trådskift via operativ systemet, men et sådan trådskift, udskifter hele LS og annullerer alle igangværende DMA overførsler. Da vi netop ÁÑÔÐ Ñ ÒØ Ø ÓÒ ønsker at skifte tråd imens der overføres data, er dette ikke brugbart. Da brugeren kalder en funktion som vil vente på data, er det oplagt at anvende denne funktion til at udføre trådskift så længe data ikke er tilgængeligt. Et user-mode trådskift, indebærer at hver tråd har en separat stak. Selve trådskiftet består således i, at skifte den nuværende stak ud med den nye tråds stak. Ved hjælp af de almindelige Ø ÑÔogÐÓÒ ÑÔinstruktioner, er dette muligt uden brug af indlejret assembler kode. Da det udelukkende drejer sig om at give mulighed for at skifte tråd under den ellers passive venten, er der ikke meget idé i at implementere f.eks.ñùø Üoperationer. For at opnå den simplest mulige implementation, har vi kigget på ÓÖ µfunktionen i Linux. Denne funktion opretter en kopi af den kaldende process, og returnerer herefter et ID til de to processer. Dette ID giver kalderen mulighed for at afgøre hvilken af de to returnerede kald der er det originale og hvilket der er kopien. I Linux implementationen vil begge processer have adgang til de samme åbne handles m.m. Da man på SPE en kører i samme kontekst vil alle handles ligeledes være tilgængelige efter trådoprettelse. Da der ofte er en del opsætning i forbindelse med opstarten af en SPE, er det fordelagtigt at brugeren angiver hvornår der skal aktiveres tråde, således at fælles opsætning ikke skal udføres to gange. I dette kald skal der dels oprettes et antal stakke, svarende til antallet af tråde der ønskes oprettet, og disse skal initialiseres. Initialiseringen går ud på at undersøge og kopiere den nuværende stak, således at alle stak allokerede variabler og retur adresser er ens for alle de nyoprettede tråde. For hver tråd indsættes der en stakbaseret værdi som angiver hvilket ID den pågældende tråd er tildelt. Herefter vælges en tråd, og dennes stak indsættes som den nuværende stak ved hjælp af kaldet ÐÓÒ ÑÔ. For at undgå forvirring med ÓÖ µkaldet, vælger vi at kalde denne funktion for Ö Ø Ì Ö. For at udføre et trådskift, kalder en tråd en funktion, vi har valgt at kalde Ð. Denne funktion skal gemme stakken for den kaldende tråd med kaldet Ø ÑÔ. Herefter udvælges en ny tråd, og dennes stak gendannes medðóò ÑÔkaldet. Da en tråd optager en del hukommelse, er det ikke realistisk at have mere end et par tråde. Dette betyder at trådscheduleringen ikke behøver at være særligt avanceret, og vi har valgt at blot vælge den næste tråd, baseret på ID. Når programmet er færdigt med at anvende tråde, skal disse termineres med kaldet Ì ÖÑ Ò Ø Ì Ö. Denne funktion skal så markere den nuværende tråd som termineret og skifte til en anden ikke-termineret tråd. Hvis alle tråde er termineret, returneres der til den oprindelige stak, tilhørende kalderen af Ö Ø Ì Ö. Returværdien bliver her sat til 0, således at brugerkoden kan håndtere fælles terminering af SPE en.

80 med resultatet til den kaldende tråd. For at opnå portabilitet, har vi tilføjet makroer- makroer fungerer uanset om der kaldes fra en tråd eller ej. I DSMCBE foregår alle kald tilñ ÐÐÓvia PPE en, ogå ÄÄÇ makroerne benytter derfor dette kald i stedet. ÝÒ Ñ Ù ÓÑÑ Ð ÐÐÓ Ö Ò Ã Ô Ø Ð ºÁÑÔÐ Ñ ÒØ Ø ÓÒ ÓÚ ÖÚ Ð Ö Det viser sig at den måde hvorpåñ ÐÐÓfungerer på SPE en afhænger af stakpointeren. Dette betyder at når der anvendes en stak der befinder sig i det dynamisk allokerede hukommelsesområde vurdererñ ÐÐÓfunktionen, at der ikke er mere tilgængelig hukommelse (se figur 7.1). Herved bliver det umuligt at anvende dynamisk hukommelsesallokering samtidig med at der anvendes tråde. For at håndtere dette, har det været nødvendigt at udvikle ekstra funktionskald. Disse ekstra funktioner skifter tilbage til den oprindelige stak, og udførerñ ÐÐÓeller Ö operationen, og returnerer herefter neå ÄÄÇ, Ê,Å ÄÄÇ ÄÁ Æog Ê ÄÁ Æ. Disse Figur 7.1: Til venstre ses hvordan situationen er, når man returnere til opstartstråden og kalder malloc. Modsat til højre, hvor man kalder malloc direkte fra tråden. Malloc bruger stak og hob pointerens størrelser til at vurdere om der er ledig plads i LS en. De vertikale pile angiver den retning som stakken og hob en vokser i. ÁÒØ Ö Ø ÓÒ ËÅ Dette har desværre den ulempe at det ikke er muligt at anvende præ-kompilerede biblioteker på SPE en, hvis disse anvenderñ ÐÐÓ, da et sådan kald ikke kan udføres fra en tråd. Når først den grundlæggende trådfunktionalitet er implementeret, skal der identificeres steder i koden hvorfra der normalt ville være blokerende kald. Disse kald skal så omskrives til en løkke der kontrollerer om det er muligt at udføre kaldet uden at blokere, og så kalde Ð indtil dette er muligt. Der er to kald der blokerer, nemlig venten på mailbox beskeder, og venten på DMA overførsler. Til begge disse funktionaliteter findes der funktioner til at kontrollere om hvorvidt kaldet blokerer. Herved bliver det ganske simpelt at ændre eksisterende kode. For at opnå optimal ydelse under en ikke-trådet afvikling, skal der bibeholdes mulighed for at udføre det blokerende kald, hvis der ikke køres med tråde.

81 ÝÒ ÖÓÒ Ð Ä Ò Ø Ð Ø Da der skal være mulighed for at kunne sammenkoble et svar med en forespørgsel, er det naturligt at anvende en form for sekvensnummer. I forlængelse af dette er det logisk Ë ÑÑ Ò ØÒ Ò at kunne kalde en funktion der undersøger og returnerer status på en forespørgsel. Dette gør samtidig at det virker mest logisk at konstruere det således, at der findes en funktion til at starte en operation, en funktion til at undersøge om operationen er færdig, samt en funktion til at udtrække resultatet. I alt giver dette faktisk et asynkront interface. Hvis dette interface bygges robust, er der ingen grund til at skjule dette fra programmøren. Efter en del empiriske forsøg med replikering af kaldstakken, blev det muligt at udvikle et minimalt modul til trådskifte. Dette modul kan indeholdes i en enkelt fil. Desværre viser det sig at den begrænsede mængde hukommelse på SPE en gør at det er særdeles uattraktivt at benytte en del af hukommelsen til at holde flere stakke. Dette gør sig gældende for langt de fleste problemer, men der findes situationer hvor mængden af º Ä Ò Ø Ð Ø tilgængelig hukommelse ikke er altafgørende. I fremtiden kunne det måske være mere interessant med tråde, hvis der f.eks. kommer 1MB hukommelse på en SPE. Da hukommelsesoverheadet er konstant, vil det være mindre betydende hvis der kommer mere tilgængelig hukommelse. Efter at det grundlæggende system er implementeret i fase 1, er det tydeligt at det er problematisk at der ikke tillades adgang fra mere end én process af gangen. Problemet med at tillade flere processer adgang er kun et problem så længe der skrives. Ved at ÈÈ Ò Ø Ö Ò anvende konsistens modellen fra afsnit 3, er det muligt at tillade flere processer læse adgang på samme tid. Dette åbner op for at kunne udnytte parallelitet i beregningerne, og dette er kritisk for at opnå acceptabel ydelse. Samtidig introducerer dette en hel del kontrolkode for at holde styr på hvilke kopier af data der er gyldige. Da der ikke tidligere har været brug for håndtering af invalidering af PPE data, skal der ske en del med denne funktionalitet. Der skal nu findes en fælles liste for samtlige PPE tråde, hvori det registreres hvilke objekter der pt. er i brug. Denne liste skal så anvendes når der modtages en ÒÚ Ð Ø besked fraê ÕÙ Ø ÓÓÖ Ò ØÓÖmodulet. Ved at vedligeholde denne liste er det i nogle tilfælde muligt, at håndtere en erhvervelse med læse adgang til et dataobjekt lokalt, og herved spare beskedudveksling med Ê ÕÙ Ø ÓÓÖ Ò ØÓÖmodulet. Da en PPE tråd typisk kalder DSMCBE, og herefter står og beregner, er der mulighed for at der går meget lang tid før en ÒÚ Ð Ø besked besvares. Dette vil bevirke at der introduceres store forsinkelser i hele systemet. For at undgå dette, skal der anvendes en dedikeret tråd til at besvare disse kald (se figur 7.2). Ved at sende alle be- skeder igennem denne tråd fjernes også muligheden for at der kan opstå en situation hvorê ÕÙ Ø ÓÓÖ Ò ØÓÖmodulet har givet en tråd et objekt, men dette endnu ikke er registreret i den fælles liste (se figur 7.3).

82 Ã Ô Ø Ð ºÁÑÔÐ Ñ ÒØ Ø ÓÒ ÓÚ ÖÚ Ð Ö Figur 7.2: Der kan ikke opstå raceconditions og man får en hurtig svartid, da SPE/PPE håndtaget altid kan svare på invalideringsforespørgsler. 1 = Erhvervelsessvar, 2 = Invalideringsforespørgsel, 3 = Opdater leasetable, 4 = Videresend erhvervelsessvar, 5 = Invalideringssvar, 6 = Undersøg leasetable. Figur 7.3: Mulighed for at der opstår race conditions, da DSMCBE SPE/PPE muligvis ikke har indsat objektet i leasetable, inden SPE/PPE håndtaget svare på invalideringsforespørgslen. 1 = Erhvervelsessvar, 2 = Invalideringsforespørgsel, 3 = Undersøg leasetable, 4 = Opdater leasetable, 5 = Invalideringssvar. Det er pakke 3 og 4, der giver en race condition. Det er væsentligt at forsøge at reducere antallet af låse så meget som muligt, for at sikre mindst muligt overhead. For hver enkelt pakke bør det overvejes om hvorvidt pakken kan sendes direkte tilê ÕÙ Ø ÓÓÖ Ò ØÓÖmodulet, for at introducere mindst mulig latenstid. Da PPE en ikke benytter adskilt hukommelse, overholdes konsistens modellen ikke hvis en PPE tildeles skrive adgang før alle andre har svaret på invalideringsbeskeden. Da vi har valgt modellen partioned entry consistency må svaret på forespørgslen afvente både det almindelige svar, samt enïö Ø Ù ÖÊ Ýbesked, der indikerer at alle har bekræftet at data fra hovedhukommelsen ikke længere er i brug.

83 ÄÓ Ð Ò Ö Ú ÖÚ Ð Ö Ä Ò Ø Ð Ø Det er åbenlyst at hvis data allerede befinder sig på SPE en, så skal det naturligvis ikke hentes over igen. Dette bevirker at der skal være en form for cache på SPE en. Det mest logiske her, er umiddelbart enåêícache. Dette vil give væsentligt forbedret ydelse, men skaber desværre to problemer. Det ene er at man på et tidspunkt løber tør for hukommelse. Ved at anvende enåêícache kan man fjerne objekter for at gøre plads til nye. Problemet med dette er at der ret hurtigt opstår fragmentering af hukommelsen, og fordi SPE en ikke understøtter paging af LS en kan dette ikke håndteres. Det andet problem, som kan håndteres, er at data skal invalideres, således at det ikke er muligt at få en gamle kopi af data. For at dette kan lade sig gøre, skal der sendes invalideringsbeskeder ud. Som nævnt i analysen (se afsnit 6), er det ikke en god løsning ËÈ Ò Ø Ö Ò at broadcaste invalideringsbeskeder. Den måde hvorpåê ÕÙ Ø ÓÓÖ Ò ØÓÖmodulet svarer på beskeder, fjerner desværre muligheden for atê ÕÙ Ø ÓÓÖ Ò ØÓÖmodulet kan identificere afsenderen, og der er derfor ikke andet at gøre end at udføre en broadcast herfra. PPE/SPE håndtaget bliver nu nødt til at holde styr på hvilke PPE tråde og SPE er der har fået hvilke dataobjekter, således at der ikke broadcastes til hver PPE/SPE. Da det er muligt for to tråde at tilgå sammen dataobjekt, skal denne situation håndteres. Med læse adgang til data er dette ikke et problem, men der skal holdes styr på hvor mange gange der er kaldt ÕÙ Ö, således at den sidsteö Ð kommando kan frigive objektet. For skrivning, skal der egentlig bare holdes styr på, at kun den tråd der har ønsket skriveadgang, rent faktisk får adgang til objektet. Da SPE tråde er non-preemptive opstår der et problem fordi der ikke længere er en tråd der venter, og således ikke kan besvare en ÒÚ Ð Ø besked. Heldigvis kan dette delvist ignoreres, da data befinder sig på en anden fysisk enhed, og der derfor ikke er mulighed for at der skrives mens data læses. SPE koden skal blot sørge for at bearbejde alle indkomne beskeder før denne forsøger at aktivere en lokal kommando. SPE håndtaget skal derimod holde styr på hvilke SPE er der har fået data, og dermed reducere antallet af ÒÚ Ð Ø beskeder der sendes videre. Desværre er der stadig et problem, fordi en SPE kan være igang med at overføre data via en DMA overførsel. Mens overførslen er igang kan SPE håndtaget derfor ikke svare er ret problematisk, da SPE håndtaget ikke har mulighed på ÒÚ Ð Ø beskeden. Dette for at vurdere hvornår DMA overførslen er afsluttet. Den eneste mulighed der findes er at SPE en skal sende en eller anden form for signal når DMA overførslen er afsluttet. Desværre er det ikke sikkert at koden sender beskeden så snart overførslen er færdig, da tråde åbner op for at udføre andet arbejde mens der ventes på DMA overførslen. Der er desværre ikke mulighed for at detektere afslutningen af SPE igangsatte DMA overførsler fra PPE en. Der er mulighed for at indsætte en fenced overførsel, men dette er særdeles ineffektivt. Vi vælger at lade det være op til programmøren at kalde en funktion i DSMCBE, eller Ð for på den måde at bearbejde udestående hændelser. SPE en kan, modsat PPE en, modtage data uden at vente påïö Ø Ù ÖÊ Ý. Til gengæld må SPE en vente med at skrive data tilbage når dette bliver frigivet, indtil der er modtaget enïö Ø Ù ÖÊ Ýbesked. Dette er en klar fordel, da data kan anvendes uden behov for synkronisering med de andre enheder.

84 Ë ÑÑ Ò ØÒ Ò Ã Ô Ø Ð ºÁÑÔÐ Ñ ÒØ Ø ÓÒ ÓÚ ÖÚ Ð Ö Fase º 3 er ÃÐÝÒ Ñ Ò Ö en stor udvidelse, men absolut nødvendig for systemets ydelse. Den problematiske signalering af overført DMA data gør dog at løsningen ikke yder helt så godt som kunne forventes. Udover dette er systemets grundfunktionalitet komplet efter fase 3, men fungerer dog kun på en enkelt maskine. ÄÓ Ð Ö Ò Ø I dette afsnit vil vi beskrive de ændringer der skal laves, for at få systemet fra fase 3, kommer til at fungere på en klynge af Cell BE maskiner. Vi vil i dette afsnit gennemgå de funktionaliteter der skal til for at understøtte dette. Som beskrevet i analysen (se afsnit ), er det problematisk at afgøre hvor et givet stykke data befinder sig. Problemet er egentlig at der findes et stykke data som forklarer hvor objekterne findes. Man kan anskue dette stykke data som om det var et distribueret hukommelses objekt. Herved er det oplagt at anvende så meget som muligt af det allerede eksisterende system til at holde styr på denne information. Vi har ligeledes i analysen gjort rede for at home-based er en god løsning. Da alle objekter har et GUID og hver maskine et ID, er der altså behov for en tabel hvorfra det kan afgøres hvilken maskine der er home-node for et givet objekt. En sådan tabel kaldes normalt for en objekttabel, for at gøre opmærksom på afvigelsen fra det funktionelt ækvivalente page-table. Problemet med at anvende systemet til at distribuere egne oplysninger, er at der mangler en måde hvorpå maskinerne kan tilgå tabellen med oplysninger. Ved at anvende et fast ID samt en fast placering af denne objekttabel, løses problemet. Dog vil det være væsentligt mere bekosteligt for andre end indehaveren af objekttabellen at oprette objekter. Men da oprettelsen af objekter typisk udgør en minimal del af et samlet program, bør dette ikke have særlig stor indflydelse. Da systemet håndterer invalidering og beskytter mod at to processer kan skrive til data på samme tid, er det mest oplagte at anvende et array af objekter, hvor hver indgang i arrayet har et maskinid. Herved kan relationen opnås ved at objektets GUID anvendes som nøgle, og værdien er således maskinens ID. Ved at reservere et specielt ID til brug for ikke oprettede objekter, bliver det muligt at sikre at et objekt ikke kan oprettes to gange. På sigt kan denne mekanisme også udvides til at understøtte slettede elementer. En ulempe ved denne model er at antallet af mulige objekter skal kendes på forhånd, da det ikke er muligt at ændre størrelsen på objekter. Samtidig har antallet af objekter en betydning for størrelsen af objekttabellen, da der skal være en indgang pr. objekt. På sigt kan man reservere det sidste element i objekttabellen til at angive hvilket ID næste fragment af objekttabellen har. På denne måde opstår der en form for linked list, der i princippet kan vokse uendeligt. Ved at anvende home-based systemet, er det et problem at alle forespørgsler skal over samme maskine. Dette problem kan mindskes en smule ved at anvende den konvention at den maskine som opretter objektet, også bliver home-node for objektet. Dette system virker naturligvis kun så længe at det er forudsigeligt hvorledes adgangsmønstret er, og at adgangsmønstret ikke ændrer sig under kørselen.

85 ÇÔ Ø ÖØ ÃÐÝÒ Ñ Ò Ö Det er ønsket at man ikke skal ændre i et program når dette går fra at køre på en enkelt maskine til at køre på en klynge. Dette er stort set muligt, men det er dog nødvendigt at fortælle programmet hvilke maskiner der indgår i klyngen. Da vi benytter PS3 maskiner og Ethernet netkortet på disse, skal der anvendes en form for liste med IP adresser og tilhørende porte. Vi har i analysen beskrevet at det er fordelagtigt at skrive en ny protokol, men at vi her kun vil anvende TCP over IP. Vi har ligeledes i afgrænsningen til denne opgave beskrevet at vi kun vil betragte et fuldt forbundet netværk. Ud fra denne liste skal der så oprettes forbindelser imellem alle maskiner. Da TCP forbindelser er to-vejs forbindelser, er der kun behov for en enkelt forbindelse mellem to maskiner. Da der anvendes TCP skal der benyttes permanente forbindelser, og en sådan forbindelse består af at en maskine lytter (server), og en anden maskine forbinder (klient). Ved at udpege en maskine til opstartskoordinator bliver det simplere at håndtere opstartssekvensen. Hvis alle andre end opstartskoordinatoren står og lytter på en given port, kan opstartskoordinatoren herefter forbinde til disse maskiner, en af gangen. For at forklare sekvensen, har vi tildelt opstartskoordinator maskinen nummer 0, og de efter følgende maskiner bliver så tildelt fortløbende numre. Opstartskoordinatoren starter med at forbinde til den maskine med højeste nummer, og forbinder herefter til alle maskiner i rækkefølge, efter aftagende maskin nummer. Efter at en maskine har modtaget en forbindelse fra opstartskoordinator maskinen, forbinder denne til alle maskiner med et nummer der er større end dens eget. Herefter afventer maskinen forbindelse fra alle maskiner med et nummer der er mindre end dens eget. Dette system sikrer at der er netop én to-vejs forbindelse mellem alle maskiner. Figur 7.4 viser hvordan opstarten foregår og figur 7.5 viser at alle maskiner i netværket er fuldt forbundet (eng: fully interconnected). Å Ò Ñ Ò Ú Ö ÓÖ ÓÓÖ Ò Ö Ò Figur 7.4: Figuren viser hvordan netværket startes op. Numrene angiver i hvilken rækkefølge forbindelserne oprettes. Som det fremgår af de overvejelser der er beskrevet i dette afsnit, er det væsentligt at der findes et fast udgangs- eller opstarts-punkt. Vi har vurderet at der ikke er nogen argumentation for at vælge en vilkårlig maskine, men eftersom vi ved at der altid er mindst en maskine involveret, nemlig maskine 0, har vi udpeget denne til at udfylde denne position. Det skal bemærkes at denne maskine derved bliver mere belastet, og herved får større sandsynlighed for at introducere forsinkelser i systemet.

86 Ã Ô Ø Ð ºÁÑÔÐ Ñ ÒØ Ø ÓÒ ÓÚ ÖÚ Ð Ö ÇÔØ Ñ Ö Ò Ö Figur 7.5: Figuren viser hvordan alle maskiner i netværket er fuldt forbundet (eng: fully interconnected) med hinanden. Som beskrevet i fase 1, er det nødvendigt at begrænse antallet af ÒÚ Ð Ø beskeder der sendes rundt i systemet. Dette gør at netværkshåndtaget skal udføre en del bogholderi for at holde styr på hvilke maskiner der skal have en given ÒÚ Ð Ø besked. Ved at registrere hvilke ÕÙ Ö ogö Ð beskeder der sendes til og fra en given maskine, kan en sådan tabel holdes opdateret. Selvom det overvejende er antallet af pakker, og ikke størrelsen af disse som har betydning for ydelsen[18], er det alligevel en let optimering at sørge for at ikke sende indholdet af et objekt hvis det vides at dette objekt findes på destinationsmaskinen. Afhængig af netværket vil dette have en effekt på data der overstige netværkets minimale pakkestørrelse. Da flere enheder på en enkelt maskine kommunikerer over samme netværkslink, er der stor sandsynlighed for at der på et tidspunkt sker en kollision i pakkernes sekvensnumre. For at modvirke dette, er det nødvendigt at netværkshåndtaget vedligeholder en oversættelsestabel, således at alle sekvensnumre over en given netværksforbindelse er unikke. Ë ÑÑ Ò ØÒ Ò º Å Ò Ñ Ö Ò ËÈ Ó ¼ At udvide systemet, således at det også omfatter klynger, er en ikke triviel opgave. Der er både en del design beslutninger der skal tages, ligesom der også er mange implementationsdetaljer. Dette er dog nødvendigt for at for at få nytte af flere maskiner. Efter fase 4 er der plads til en del optimeringer. Specielt er fase 3 et problem med den nævnte notifikationsproblematik for SPE igangsatte DMA overførsler. I fase 5 vil vi derfor udføre en omskrivning af SPE håndtaget, således at dette problem modvirkes. Igen er det et væsentligt problem at der ikke er særlig meget plads på en SPE. Samtidig er en SPE ikke god til at håndtere kompleks kontrolkode, herunder er dynamiske lister og lignende særdeles ineffektive på en SPE.

87 ËÈ Ö Ù Ø ÓÒ Å Ò Ñ Ö Ò ËÈ Ó I fase 5 vil vi skære alt væk fra SPE en således at denne kun indeholder det allermest nødvendige. Før dette kan udføres, er det nødvendigt at have kontrol over allokering af Ñ ÐÐÓ. Ved plads på SPE en. Vi har allerede i fase 2 introduceret specielle makroer til håndtering af at benytte disse makroer er det nu muligt at videresendeñ ÐÐÓog Ö kald til PPE en. Ved at allokere det meste af den tilgængelige plads på SPE en, fås en sammenhængende blok af hukommelse der kan disponeres over fra PPE en. Dette åbner op for at oplysninger om cache m.m. nu kan vedligeholdes på PPE en, som er væsentlig bedre egnet til at håndtere dette. Når alle forespørgsler håndteres af PPE en, har denne også alle de oplysninger der er nødvendige for at afgøre om en DMA overførsel er igangværende. Ved at starte DMA overførsler fra PPE en opnås to markante fordele, navnlig at det nu er muligt, uden at involvere SPE en, at udføre hele erhvervelsesproceduren dvs. at SPE en kan arbejde imens. Derudover bliver det også muligt at vurdere præcis hvornår en DMA overførsel er afsluttet. Cell BE manualen[6] advarer mod at starte DMA overførsler fra PPE en, da sådanne overførsler bliver sekventielle, hvor der via. SPE igangsatte DMA overførsler er potentiale for parallelitet. Dette er dog kun muligt hvis SPE en på forhånd ved hvilken adresse der skal hentes eller skrives til. I det tilfælde hvor denne oplysning skal kommunikeres via PPE en, er denne fordel ikke til stede. Ved at bibeholde det asynkrone interface fra fase 2, bliver det muligt at reducere SPE ÈÈ Ò Ö Ò Ö koden til en simpel liste over igangværende forespørgsler. Selve mængden af data der skal sendes, er nu begrænset til en tre-fire beskeder for en forespørgsel 1, og tre beskeder ved et svar 2. Denne begrænsning fjerner næsten alt kode på SPE en uden at ændre på brugen af systemet. Dette betyder at flere SPE cykler er tilgængelige til beregning, ligesom der er markant mere tilgængelig hukommelse. Ved at flytte håndteringen over på PPE en, bliver det nu væsentligt nemmere at håndtere optimeringer. En af optimeringerne er, at det nu ikke længere er nødvendigt at vente på at enö Ð kommando bliver udført, da denne kan håndteres af SPE håndtaget. Der kan også implementeres mere effektive algoritmer til allokering af data, f.eks. en best-fit søgning, der i nogen grad kan mindske fragmentering. Det er nu muligt at svare væsentligt hurtigere på ÒÚ Ð Ø beskeder, ligesom objekter kan markeres som ugyldige, uden at SPE en skal involveres. Dette giver systemet en væsentligt bedre ydelse. Det er dog ikke muligt at udføre DMA list transfer kommandoer fra PPE en. Dette kan dog simuleres ved at starte flere enkelt DMA overførsler. Der kan også optimeres for overførsler af meget små objekter, ved at anvendeñ ÑÔÝkommandoen i stedet for at udføre en DMA overførsel. Dette er specielt fordelagtigt for kontrolværdier, såsom en tæller. ÕÙ Ö På sigt er det også særdeles fordelagtigt at have alle adresser tilgængeligt på PPE en, da dette letter SPE til SPE overførsler. ½ 1 Et sekvensnummer, et operationsnummer, et GUID eller en adresse, og en type i forbindelse med 2 Et sekvensnummer, en pointer og i nogle tilfælde en størrelse

88 Ë ÑÑ Ò ØÒ Ò Ã Ô Ø Ð ºÁÑÔÐ Ñ ÒØ Ø ÓÒ ÓÚ ÖÚ Ð Ö Fase º 5 går Å Ö Ø ÓÒ på nogle punkter imod manualen[6], men det færdige resultat virker væsentlig mere robust, og benytter væsentligt færre ressourcer på SPE erne. Da det netop er SPE erne der er i stand til at levere den enorme ydelse virker disse ændringer særdeles attraktive. Vi har i fase 4 redegjort for hvorledes det er problematisk at systemet ikke understøtter migration af dataobjekter. Ved at tilføje migration til systemet kan der opnås en væsentlig forbedring af den samlede ydelse af en klynge. Når der skal udføres en migration skal en eventuel liste over ventende processer på et objekt overføres til den nye home-node. Da registreringen af en ventende process er baseret på et mutex, og en kø, er det ikke muligt at blot kopiere disse værdier til den nye maskine. Det er muligt at videresende forespørgsler til en anden maskine, men hvis forespørgslen kom fra en anden maskine, vil man opnå en form for nested kald. Dette er ikke særlig attraktivt, fordi svaret skal løbe igennem den tidligere ejer, og herved tilføjer både forsinkelse og unødig aktivitet på denne maskine. Da sekvensnumre er bundet til en given forbindelse, kan det ikke lade sig gøre bare at svare over en anden forbindelse. Det er heller ikke muligt, at bede afsenderen af beskeden om at modtage på en anden forbindelse, da der herved opstår mulighed for sammenfald i sekvensnumre. Indtil videre har det ikke været muligt forê ÕÙ Ø ÓÓÖ Ò ØÓÖmodulet at se hvorfra en forespørgsel oprinder. Ved at tilføje denne information til alle forespørgsler, bliver det muligt for enê ÕÙ Ø ÓÓÖ Ò ØÓÖmodulet at sende en besked til afsenderen af en forespørgsel, og bede denne om at sende forespørgslen igen til en anden maskine. Desværre er der et væsentligt problem ved at udføre en sådan operation. Forespørgslernes indbyrdes rækkefølge bibeholdes ikke. For at kunne håndtere dette er det nødvendigt at kunne bede en maskine om at omdirigere en tidligere afsendt pakke til et nyt sekvensnummer over en anden forbindelse. Da det kun er muligt for den oprindelige afsender af pakken at afgøre hvilke sekvensnumre der kan anvendes, skal der ske en form for registrering på modtageren af en migration, således at forespørgsler i køen kan bindes til den nye destination. Dette system indebærer dog en overordentlig masse pakker, som er uønskede, ligesom det er vanskeligt at udføre en dobbelt migration mens der stadig er udestående migrations forespørgsler. Når antallet af maskiner stiger bliver det umuligt at anvende et globalt sekvensnummer, da dette vil overløbe særdeles hurtigt. For at håndtere dette problem, er det nødvendigt at registrere nogle ekstra oplysninger om hver forespørgsel. For at kunne sende svaret direkte til afsenderen, skal der registreres hvilken maskine der oprettede forespørgslen. Når svaret så sendes direkte, skal modtageren vide hvilket sekvensnummer der oprindeligt blev anvendt, samt hvilken maskine der oprindeligt blev sendt til. Ved modtagelsen kan maskinen så godkende pakken som om den kom fra den korrekte afsender. Dette system giver et overhead, da der ¾ skal sendes et par ekstra værdier med rundt, men LogGP[18] modellen viser at dette ikke har en væsentlig effekt. En positiv effekt, er at systemet håndterer flere på hinanden følgende migrationer, uden at introducere ekstra kompleksitet eller ekstra beskeder.

89 Å Ö Ø ÓÒ ØÖ Ð ËØÖ Ñ Ò ÙÒ Ö Ø ØØ Ð ÔËÈ For at afgøre hvornår der skal udføres en migration, vælger vi at kigge på antallet af ÕÙ Ö kald i skrive tilstand, da læsetilstand er optimeret lokalt. Ved at holde en cirkulær Ë ÑÑ Ò ØÒ Ò buffer med maskinid er, er det muligt at se hvem der senest har anmodet om et objekt i skrivetilstand. Hvis dette antal overstiger en given tærskel udføres en migration. Dette ekstra bogholderi kan implementeres uden væsentlige ulemper i ydelsen. Dog er selve migrationen en bekostelig affære, hvorfor migrationstærsklen formentlig bør sættes ret højt. Understøttelse º ËØÖ Ñ Ò ÙÒ Ö Ø ØØ Ð ÔËÈ af migration er en væsentlig faktor for at opnå høj ydelse i en klynge. Dette er specielt vigtigt i en klynge af PS3 maskiner, da disse har ekstra høje latenstider pga. hypervisor systemet. Eventuelle ulemper i forbindelse med migration vil let kunne opvejes af den øgede ydelse der følger ved fraværet af ekstra netværkspakker. Denne udvidelse er ikke implementeret i DSMCBE. Med de asynkrone metoder der blev indført i fase 2, er det muligt at udføre overlapped execution. Ved at udvide dette koncept, er det muligt at lade SPE håndtaget udføre forespørgslerne på forhånd. For at dette kan fungere skal der være en kø i SPE håndtaget, til at holde styr på alle forespørgslerne. Hver indgang i denne kø vil gennemgå et antal stadier: Ikke startet, Forespørgsel sendt, Svar modtaget, DMA startet, DMA afsluttet. Normal vil der skiftes direkte fra Svar modtaget til DMA startet, men i det tilfælde hvor der ikke er plads på SPE en til data, må dette udskydes til et senere tidspunkt. Når det sidste stadie nås, er data helt klar, og en pointer kan overføres direkte til SPE en når dette ønskes. Herved opnås der større fleksibilitet end det ville være muligt at udføre ved asynkrone kald. Alle funktioner der internt skal anvendes for at understøtte streaming er allerede til stede fra fase 5. Dog skal der implementeres selve køen, ligesom der skal håndteres at der kan modtages invalideringsbeskeder før, mens eller efter data er overført til SPE en. I denne situation skal forespørgslen sendes igen, og status skal nulstilles til Forespørgsel sendt. Ë ÑÑ Ò ØÒ Ò Ligesom invalideringsbeskeder kan nulstille en streaming operation, kan eksplicitte ÕÙ Ö kald også gøre dette, hvis det er den eneste måde hvorpå der kan skaffes nok ledig hukommelse. På den måde prioriteres eksplicitte kald højere end streaming operation, fordi det antages at brugeren kun vil anvende eksplicitte kald hvis dette er strengt nødvendigt. Streaming operationer er en forholdsvis lille udvidelse uden store kompleksiteter eller nyudvikling. Til gengæld åbner dette op for markant forbedret ydelse, da man i realiteten får mulighed for at udføre n-buffering, uden at programmøren skal holde styr på mange delvise operationer eller ledig hukommelse. Denne udvidelse er ikke implementeret i DSMCBE.

90

91 Ã Ô Ø Ð ÔÖ ÚÒ Ò Ó Ö ÙÐØ Ø Ö I dette afsnit gennemgås de resultater som diverse kørsler med DSMCBE har medført. Indledningsvis udfører vi en række små test kørsler der benyttes til at vise hvor meget overhead der grundlæggende er i de enkelte dele af en Cell BE maskiner. For de efterfølgende kørsler starter vi med at beskrive hvordan og hvilke programmer vi har brugt til at afprøve og hastighedsteste DSMCBE med. Dernæst kommer en dybde gående beskrivelse af hvert scenarie og til slut giver vi en konklusion på afprøvningerne og hastighedstestene. º½ I alle Ä Ø Ò Ø Ö sammenligninger med håndoptimeret kode, er success kriteriet at der udføres nøjagtigt samme beregninger i begge implementationer. Der er altså bevidst ikke indført optimeringer i metoden hvorpå resultatet opnås. På den måde sikres det at målingerne viser den faktiske effekt af DSMCBE. Tallene som figurerne 8.1 til 8.8 bygger på kan ses i appendix B. For at estimere det overhead der er forbundet med de forskellige kommunikationsformer der findes i en Cell BE maskine, har vi udviklet følgende små programmer: Mailbox overførsel DMA + Mailbox overførsel Netværk + DMA + Mailbox DSMCBE uden netværk DSMCBE med netværk I alle programmerne indgår 2 SPE enheder, der modtager data fra PPE enheden. Ved modtagelsen tælles værdien en op og returneres. Dette gentages 10 millioner gange. I den første test overføres værdien som en mailbox besked. I den næste test overføres en pointer til data via en mailbox, og det faktiske data overføres så via en DMA overførsel. I netværkskørslen simuleres der et netværksled via. loopback adapteren, og værdien sendes også igennem dette led. Endelig har vi forsøgt at gøre det samme med DSMCBE. Dette er dog ikke helt muligt, da det ikke er muligt at vente på at den anden enhed har skrevet til data. Vi har forsøgt at simulere dette ved at lade hver SPE tage et objekt med skrivelås, og så kun

92 Ã Ô Ø Ð º ÔÖ ÚÒ Ò Ó Ö ÙÐØ Ø Ö 4 bytes 10 Kbytes Mailbox overførsel ms. - DMA + Mailbox overførsel ms ms. Netværk + DMA + Mailbox ms ms. DSMCBE uden netværk ms. - DSMCBE med netværk ms. - Tabel 8.1: Resultater af 5 kørsler med en pakke størrelse på 4 bytes, samt 2 kørsler med en pakke størrelse på 10 Kbytes. º½º½Ê ÙÐØ Ø Ö tælle objektet op, hvis værdien er ændret i forhold til sidste gang. Dette sikrer at hver SPE tæller på skift, men forhindrer ikke at objekt bliver erhvervet flere gange af samme SPE, uden at blive talt op. Dette medvirker naturligvis til et noget større overhead. Resultaterne af kørslerne er samlet i tabel 8.1. De basale tests af DMA og Mailbox viser at DMA overførsel ikke koster noget videre, så længe datastørrelsen er lille. Til gengæld kan man se at netværkskommunikation øger tiden med en faktor 3. Når pakkestørrelsen øges til 10Kb er der ikke væsentlig forringelse af ydelsen i DMA udgaven, og dette skyldes at EIB en ikke bliver belastet af de enkelte overførsler på under 16Kb. Derimod kan det ses at 10Kb er større end netværkets MTU, og derfor resulterer i flere pakker i netværkslaget. Dette giver så udslag i en væsentligt forøget køretid. DSMCBE udgaverne er markant langsommere, og dette skyldes til dels at det ikke er º¾ muligt at ÐÐ ÓÑÑÙÒ Ø ÓÒ ÓÖÑ Ö sende forespørgslerne så kontrolleret når der benyttes DSMCBE. Herudover er der naturligvis et overhead i forbindelse med brugen af DSMCBE, og der foregår ingen væsentlig beregning, hvorfor det ikke er muligt at skjule det overhead DSMCBE medfører. Denne effekt er specielt synlig når der køres på netværk. Cell BE arkitekturen tilbyder en del forskellige kommunikationsformer, som alle har specielle karakteristika. For at kunne vælge imellem disse, har vi udført en række simple tests. Vi har anvendt det samme testprogram til alle målingerne, og udelukkende ændret på måden hvorledes DSMCBE kommunikerer internt med SPE enheden. Optimal (1 SPE) Interupt mailbox, enkelt og dobbelt buffer (1-6 SPE er) Normal mailbox, enkelt og dobbelt buffer (1-6 SPE er) Event baseret, enkelt og dobbelt buffer (1-6 SPE er)

93 º¾º½ÅÐ Ò Ö ÅÐ Ò Ö º¾º¾ÇÔØ Ñ Ð Alle målinger er kørt iö Ð ÑÓ og º¾º ÆÓÖÑ ÐÑ Ð ÓÜÚ ÒØ ÖÖÙÔØÑ Ð ÓÜ º¾º Ú ÒØ Ö Ø på samme enkeltstående maskine. Resultaterne er meget stabile og der er derfor kun udført 3 kørsler hvor hver opsætning, og gennemsnittet af køretiderne er anvendt. For at kunne udregne det absolut optimale resultat, har vi kørt eksempelprogrammet i en håndoptimeret version uden DSMCBE. Dette program er kun kørt med en enkelt SPE, og det optimale resultat er således baseret på en lineær skalering af dette. Hvis man vil anvende events er det et krav at der benyttes interrupt mailbox e. Vi forventer derfor at der er et overhead i forbindelse med brugen af disse, for at kunne aktivere de omtalte events. I figur 8.1 viser det sig faktisk ikke at være tilfældet, og interrupt mailbox udgaven er den hurtigste i alle målingerne. Da DSMCBE anvender polling af mailbox e får man den uønskede bivirkning, at en enkelt PPU kerne vil køre konstant. En måde at håndtere dette på er ved at anvende events, º¾º Ò ÐØ Ù ÖÚ º Ó ÐØ Ù Ö hvorved det er muligt at sætte PPU en i pausetilstand så længe der ikke er noget arbejde at udføre. Som det fremgår af figur 8.1 er events meget langsomme. Udover at events i sig selv virker forsinkede spiller det også ind at Linux mangler enû ع ÓÖ¹ ÒÝfunktion, således at hvis en tråd ønsker at vente på flere forskellige events, skal der udføres noget indbyrdes signalering mellem flere tråde (se afsnit 9.8). Det er normalt at man kan skjule overhead ved at udføre overlappende eksekvering, men ofte er der også en skjult omkostning ved dette. Vi har valgt at køre alle eksemplerne igennem med både enkelt og dobbelt buffer, for at vise hvor meget overhead det er º¾º Ë ÑÑ Ò ØÒ Ò muligt at skjule. Som det ses på figur 8.1 er dobbelt buffer udgaven altid hurtigere end enkelt buffer udgaven, på nær med events. Som det ses yder events markant dårligere, og specielt når der anvendes dobbelt buffer bliver resultatet dårligt. Selvom dobbelt buffer ser ud til at nærme sig enkelt buffer udgaven ved 6 SPE er, er der stadig markant afstand til de øvrige målinger. Samlet set kan man udlede at dobbelt buffer med interrupt mailbox giver det bedste resultat. Enkelt buffer med normal mailbox giver ca. 74% af den optimale ydelse. Ved at skifte til interrupt mailbox stiger ydelsen med ca. 4%, og ved at også benytte dobbelt buffer stiger ydelsen yderligere 2% til samlet set næsten 80% af den optimale ydelse.

94 Ã Ô Ø Ð º ÔÖ ÚÒ Ò Ó Ö ÙÐØ Ø Ö Figur 8.1: Resultater af forskellige kommunikationsformer i en Cell BE maskine.

95 º ÈÖÓØÓØ Ò ÈÖÓØÓØ Ò Prototein programmet simulerer en forsimplet udgave af protein foldning. Opgaven går ud på at folde et prototein således at færrest mulige hydrofobe aminosyrer er i kontakt med opgivelserne. Forsimplingen består i at prototeinen kun kan folde i to dimensioner, kun har to typer aminosyrer, og kun kan folde i vinkler på 90 grader. Den sekventielle løsning af problemet består i at danne et beslutningstræ, og herefter evaluere hvert blad i træet. Evalueringen tæller antallet af hydrofobe aminosyrer der er i kontakt med omgivelserne, og jo lavere tal jo bedre. Opdelingen til distribueret beregning er gjort ved at indføre et forberegningsstadie, hvor træet delvist udfoldes til et fastsat niveau. Efter denne delvise udfoldning, omdannes hver delvist udfoldede gren til en arbejdspakke. Disse pakke placeres i en stor kø, og hver beregningselement tager så en pakke fra køen. Denne model kaldes også bag of tasks modellen. Udover forberegningen er problemet i den gruppe af problemer der kaldes embarrassingly parallel, fordi de enkelte opgaver ikke har nogen indbyrdes relationer. Forventningen til ydelsen i dette program er ganske høj. Dette skyldes til dels at DS- MCBE kun anvendes til at transportere data til og fra beregningsenheden, og samtidig at de enkelte beregninger ikke skal synkroniseres. For at måle ydelsen af systemet har vi udført følgende målinger: Reference (1-6 SPE er) Enkelt buffer (1-96 SPE er) º º½ÅÐ Ò Ö Dobbelt buffer (1-96 SPE er) Trådet (1-6 SPE er) Målinger er udført ved at gentage hver kørsel 3 gange og derefter tage et gennemsnit af disse. Det viser sig at kørslerne er meget stabile i deres køretider og derfor er 3 gentagelser nok. Både den håndoptimerede og den DSMCBE baserede kode er kørt med 1-6 SPE er. Herefter er DSMCBE udgaven kørt med 1-16 PS3 maskiner via MiG, for at kunne måle udviklingen i ydelse på en klynge. º º¾ Ó ÐØ Ù ÖÚ º Ò ÐØ Ù Ö For at vise effekten af dobbelt buffering, er alle tests kørt med og uden dobbelt buffering. Da tråde udgør en form for dobbelt buffering er disse også medtaget. Da resultaterne ligger meget tæt har vi valgt at producere to figurer, nemlig målinger fra en enkelt maskine (figur 8.2) og for netværkskørsler 8.3. Da tråde ikke afviger væsentligt fra dobbeltbuffer udgaven er tråde kun kørt på 1-6 SPE er. I dobbelt buffer udgaven hentes næste arbejdsudgave på forhånd. Der er stort set ikke forskel på køretiden af de to udgaver. Dog begynder der at vise sig en forskel når der køres med 16 maskiner (altså 96 SPE er). I teorien burde dobbelt buffer yde mere stabilt, men da der stadig synkroniseres omkring hvilken opgave der skal hentes som den næste, fås et svagt dårligere resultat end forventet.

96 Ã Ô Ø Ð º ÔÖ ÚÒ Ò Ó Ö ÙÐØ Ø Ö ¼ Figur 8.2: Resultatet af at køre prototein problemet med enkelt og dobbelt buffer på en enkelt maskine.

97 Ó ÐØ Ù ÖÚ º Ò ÐØ Ù Ö Figur 8.3: Resultatet af at køre prototein problemet med enkelt og dobbelt buffer på op til 16 PS3 maskiner. ½

98 º º Ó ÐØ Ù ÖÚ ºØÖ ØÙ Ú Ã Ô Ø Ð º ÔÖ ÚÒ Ò Ó Ö ÙÐØ Ø Ö Da tråde udgør en form for dobbelt buffer, kommer det ikke som den store overraskelse at disse kører på stort set samme tid. Den trådede udgave er en lille smule langsommere end º º Ó ÐØ Ù ÖÔ ÐÐ Ð de to andre udgaver, dog så lidt at det ikke kan ses på figur 8.2. Denne hastighedsnedsættelse opstår fordi der skiftes tråd under kald til DSMCBE. I nogle tilfælde vil disse trådskift tage længere tid at udføre end den tid der skal ventes på operationen. Hvis begge tråde skal vente, bliver dette trådskift kun en ulempe, og medfører derfor forringet ydelse. º º Ë ÑÑ Ò ØÒ Ò Vi har også kørt prototein problemet på en klynge bestående af fire Cell Blade maskiner med hver 16 SPE er. Resultatet for denne kørsel viser at ydelsen er stort set identisk med ydelsen fra PS3 maskinerne. Dog er der ved 64 SPE er en lille fordel for Cell Blade klyngen. Dette skyldes primært, at når der kun er fire maskiner, så er der også mindre netværkstrafik. I regionen 1-6 er kurven stort set liniær, hvilket indikerer at løsningen skalerer ganske godt for problemer der ligner prototein. Denne udvikling fortsætter næsten upåvirket af antallet af maskiner. Ved 16 maskiner (96 SPU er) er ydelsen kun aftaget med 7% i forhold til det teoretisk optimale. Dette er ganske som forventet, og viser at det grundlæggende overhead i DSMCBE er forholdsvist minimalt. Da alle arbejdspakker i prototein problemet tager vilkårlig tid at beregne, er det nødvendigt med dynamisk opdeling af data. Dette betyder at selvom der anvendes dobbelt buffering af arbejdspakken, er der stadig synkronisering omkring uddelingen af opgaver. Dette bevirker at der stort set ikke er nogen effekt af dobbelt buffering i prototein º Ö ÒØÙÑÓÖ problemet. De pæne resultater for prototein problemet er ikke en indikation af at DSMCBE er et godt valg til alle typer af problemer, men mere en indikation af at distribuering af data fungerer godt. Braintumor problemet som går ud på at simulere stråling af en hjernetumor, er et problem som egner sig godt til Cell BE arkitekturen. Vi har tidligere omskrevet en Python version til Cell BE arkitekturen og det er denne implementation som bliver benyttet som reference implementation. Braintumor problemet går ud på at bestråle et billede af en hjerne med et antal strålekanoner, hver strålekanon har en position og samt en retning hvori der afgives et antal skud. Hvert skud bliver afgivet og vandrer gennem billedet og afhængig af densiteten i de enkelt pixels, afgives skuddets energi til en given pixel. Både vandringen og om skuddet afgives i en given pixel, indeholder en tilfældigshedkomponent. ¾ Derfor vil to kørsler sjældent giver helt samme resultat. I denne implementation bliver der afgivet et antal skud med 5 kanoner, og antallet af skud bliver fordelt mellem SPE erne enten dynamisk eller statisk. Når alle skud er afgivet fra den første kanon, fortsættes med den næste osv. Reference implementationen kan kun køre på en Cell BE maskine, mens DSMCBE versionen kan kører på en mængde

99 Ò ÐØ Ù ÖÚ º Ó ÐØ Ù Ö af Cell BE maskiner. Derfor er der nogle ændringer i koden, for at optimere kørslen på netværket. For at kunne give et billede af hvilken ydelse man kan få ved at bruge DSMCBE, skal følgende tests køres. Enkelt buffer vs. dobbelt buffer (1-96 SPE er) º º½ Ò ÐØ Ù ÖÚ º Ó ÐØ Ù Ö Dynamisk vs. statisk opdeling af opgaver (1-96 SPE er) Reference lignende version vs. netværksoptimeret version (1-96 SPE er) Kørsel på PS3 klynge vs. kørsel på Cell Blade klynge (1-64 SPE er) I denne test undersøges det om der er noget vundet ved at benytte sig af dobbelt buffer fremfor at hente det dataobjekt man skal bruge når man skal bruge det (enkelt buffer). Dobbelt buffer betyder kodemæssigt, at man henter det næste objekt på forhånd, og derved kan udføre beregninger og hentninger på samme tid. Det må forventes at ydelsen bliver bedre med dobbelt buffer, da dette vil skjule noget af den forsinkelse som man får ved at bruge DSMCBE. På netværket kan dobbelt buffer i større grad være med til at skjule latenstiden, end på på den enkelte maskine. Som det ses i figur 8.4 ses der først en synlig forskel på enkelt og dobbelt buffer, º º¾ ÝÒ Ñ Ú º Ø Ø ÓÔ Ð Ò ÓÔ Ú Ö når man benytter 5 og 6 SPE er. Dette er også naturligt, da man må forvente at PPE en skal udføre mere arbejde jo flere SPE er den skal betjene. Målingerne af kørsler foretaget på netværket, er afbilledet i figur 8.5. Det ses at dobbelt buffer også har en effekt på netværket, dog ikke så stor en effekt som man umiddelbart kunne tro. På netværket burde man kunne skjule mere overhead med dobbelt buffering. Denne test skal vise forskellen på at opdeler antallet af skud statisk og dynamisk. En statisk opdeling, går ud på at man kender antallet af SPE er og dividere dette med antallet af skud. Derved ved man hvor mange skud, hver enkelt maskine skal afgive. En dynamisk opdeling, går derimod ud på at tildele hver SPE et antal skud f.eks. 2048, og når SPE en har simuleret disse skud, får den en ny opgave med 2048 skud. En dynamisk opdeling er normalt at foretrække især med dette problem, da to opgaver med hver 2048 skud ikke nødvendigvis tager lige lang tid. Årsagen til dette er, at der benyttes nogle tilfældighedsmekanismer i simuleringen. Hvis man ser på en enkelt maskine er en dynamisk opdeling klart at foretrække, men på netværket får en dynamisk opdeling nogle problemer. Problemet skyldes at alle SPE er komme til at kæmpe om skriveadgang til ét dataobjekt og derved serialiseres kørslen. Årsagen til at alle SPE er skal skrive til samme dataobjekt er, at det er nødvendigt at SPE erne fortæller systemet hver gang de tager en ny opgave, da det ellers ikke er muligt at vurdere hvornår man er færdig. Derfor må det antages at den dynamiske opdeling er bedst egnet, når man benytter en enkelt maskine, hvorimod den statisk opdeling er fordelagtig på netværket. Som det ses af figur 8.4, fungere dynamisk godt på en enkelt maskine, men så snart man begynder at bruge netværket (se figur 8.5) falder ydelsen dramatisk. Den statisk opdeling, giver en smule langsommere ydelse på en enkelt maskine, men til gengæld er den særdeles effektiv på netværket.

100 Ã Ô Ø Ð º ÔÖ ÚÒ Ò Ó Ö ÙÐØ Ø Ö Figur 8.4: Resultatet af at køre braintumor på en enkelt maskine.

101 ÝÒ Ñ Ú º Ø Ø ÓÔ Ð Ò ÓÔ Ú Ö Figur 8.5: Resultatet af at køre braintumor på et netværk.

102 º º Ê Ö Ò Ð Ò Ò Ú Ö ÓÒÚ ºÒ ØÚÖ ÓÔØ Ñ Ö ØÚ Ö ÓÒ Ã Ô Ø Ð º ÔÖ ÚÒ Ò Ó Ö ÙÐØ Ø Ö I denne test forsøges det at optimere DSMCBE versionen af braintumor, således at man kan opnå en bedre ydelse. Der er indlysende at hvis man, mens man udvikler koden, har DSMCBE s fordele og ulemper in minde, kan man få en bedre ydelse. Derfor har vi lavet º º Ã Ö ÐÔÈË ÐÝÒ Ú º Ö ÐÔ ÐÐ Ð ÐÝÒ nogle optimeringer, hvilke burde give en betydelig bedre ydelse end den version som ligner reference implementationen. Desuden vil reference implementationen lide under at have en dynamisk opdeling. Figur 8.5 viser at den reference lignende version ikke yder specielt godt på netværket. Dette skyldes i stor grad at den benytter dynamisk opdeling, ligesom reference implementationen. For at undersøge hvor stor ydelsesmæssigt forskel, der er på en klynge af PS3 maskiner og en Cell Blade, er braintumor kørt på begge systemer. Det må forventes at ydelsen på Cell Blade, er noget bedre. Der er flere årsager til dette, men hovedsagligt skal nævnes at Cell Blade kan være forbundet med et hurtigere netværk (InfiniBand), men også der større hukommelse på PPE en kan spille ind. Hver enhed i en Cell Blade består ofte af to Cell BE enheder, hvor man har deaktiveret den ene PPU enhed og så lader den anden PPE enhed styre alle 16 SPE er. Dette betyder at hver enhed har 16 SPE er og ikke 6 som PS3 en. Figure 8.6 viser to tests. Den første graf viser test kørsler, hvor der kun er benyttet 6 SPE er pr. Cell Blade. Den anden graf viser kørsler hvor der er brugt 16 SPE er pr. Cell Blade samt kørslen på én Cell Blade med 1-16 SPE er. Grafen med 6 SPE er pr. Cell Blade viser en acceptabel speedup og hvis man sammenligner med figur 8.5, ses at speedup en bliver en smule bedre med Cell Blades fremfor med PS3 er. Ser man derimod på grafen, hvor der er brugt 16 SPE er pr. Cell Blade, er resultatet ikke imponerende. Man får dog en liniær graf, når man kommer ud over første maskine, men dens hældning og startpunkt er betydeligt dårligere. Årsagen til dette kan tydeligt aflæses på første del af grafen, hvor der er kørt på en maskine med 1-16 SPE er. Det kan ses at de to grafer ligger oven i hinanden, når man bruger 6 SPE er, men derefter begynder grafen for 16 SPE er pr. maskine at dale kraftigt. Det viser sig faktisk at det at gå fra 8 til 16 SPE er stort set ikke tilføjer noget regnekraft til systemet, men kun overhead. Dette er der flere årsager til, bl.a. den måde SPE håndtaget er implementeret på. Problemet er at der benyttes 1 tråd til at læse og skrive mailbox beskeder fra/til SPE erne. Dette er implementeret med º º Ë ÑÑ Ò ØÒ Ò en løkke, hvilket vil sige at jo flere SPE er, jo længere tid går der mellem hver SPE kan kommunikere med DSMCBE. Derudover bliver koordinatoren og PPE en i det hele taget belastet voldsomt, når man bruger mere end 8 SPE er. Dette sås ikke i prototein problemet, så mængden af data der sendes gennem DSMCBE har selvfølgelig også en indvirkning. Samlet set kan man se at ved at bruge én SPE opnås en speedup på 90% og at denne falder til ca. 78%, når man bruger 6 SPE er. På netværket, hvor alle maskiner kører med 6 SPE er, er speedup en for én maskine altså 78%. Når man tilføjer den næste maskine og derved begynder at bruge netværket falder ydelsen til ca. 69%, så tabet for at gå på netværk er altså 9 procentpoint. Når man benytter sig at 16 maskiner er speedup en faldet til ca. 65%. Dette viser at man på netværket kun vil se et ganske begrænset tab af

103 Ë ÑÑ Ò ØÒ Ò Figur 8.6: Resultatet af at køre braintumor på et netværk af Cell Blades

104 Ã Ô Ø Ð º ÔÖ ÚÒ Ò Ó Ö ÙÐØ Ø Ö º À Ø ÕÙ Ø ÓÒ ydelse og intet tyder på at det ikke skulle være muligt at tilføje mere end 16 maskiner til DSMCBE systemet, når man skal løse braintumor problemet og lignende problemer. Programmet forsøger at simulere hvorledes varme fordeler sig i et materiale. Ved opstarten sættes toppen, og den ene side, af materialet til at have stue temperatur, mens de resterende to kanter sættes til at være det absolute nulpunkt. Herefter simuleres diskrete tidsintervaller, hvor temperaturerne forsøger at udligne hinanden. Dette er en forsimplet udgave af en fysik simulation, der normalt foregår i tre dimensioner. Det er problematisk at beregne på dette problem, fordi hvert punkt skal opdateres, men ikke påvirkes af punkter der allerede er opdateret. En løsning på dette problem er at anvende en model der hedder successive over relaxation. Modellen fungerer ved at opdele alle punkter i henholdsvis sorte og røde punkter, således at hver andet punkt tilhører samme gruppe. Ved en opdatering læses der udelukkende fra værdier fra en gruppe, og opdateres udelukkende værdier fra den modsatte gruppe. Dette bevirker at der ikke er problemer med at værdierne er delvist opdateret. Da beregningen i princippet kan foregå i det uendelige, stopper simulationen efter et forudbestemt antal iterationer. Opdelingen af problemet til brug i distribueret beregning er egentlig ret simpel, nemlig lad hver beregningsenhed håndtere en delmængde af alle punkter. Dog skal der synkroniseres ved skift fra røde punkter til sorte punkter og omvendt. Der er samtidig en del ekstra udveksling af data, da en rød/sort opdeling forhindrer opdatering af kant værdier, og en opdeling indfører ekstra kanter. Denne type beregning er meget følsom overfor forsinkelser, da alle stadier involverer synkronisering. Dette betyder at den langsomste beregningsenhed sætter grænsen for beregningshastigheden. På samme tid er de enkelte beregninger forholdsvis kortvarige, og º º½ÇÔ Ð Ò dette bevirker at der anvendes meget tid i synkroniseringskoden. Hvis den enkelte beregning bliver for lille vil synkroniseringsomkostningerne være dominerende, og dette vil bevirke at ekstra regnekraft faktisk gør beregningerne langsommere. Dobbelt buffering er kun lidt brugbart, da alle beregninger er afhængige af forrige stadie. Hvis der anvendes den almindelige metode til at måle speedup, skal man benytte en konstant mængde data og herefter øge antallet af beregningsenheder. Dette bevirker at man skal have en problemstørrelse der er stor nok til at dele mellem samtlige beregningsenheder. Da vi ønsker at køre målingen på 16 maskiner, skal der ved kørsel på en maskine ligge data nok til 16 maskiner. Da en PS3 kun har 256MB hukommelse, sætter dette en øvre grænse på 16 MB på hver maskine, og en faktisk grænse på ca. 10MB. En simulering med 10MB data vil give hver SPE ca 1.5MB data, hvilket betyder at en enkelt SPE har ganske lidt data at beregne. For at omgås dette problem anvender vi en opdeling hvori mængden af data stiger lineært med antallet af maskiner. Dette betyder at hastigheden, optimalt set, er konstant, da mængden af data stiger. Herved bliver det muligt at drage nytte af den samlede mængde hukommelse, og samtidig sikres det at hver SPE får en rimelig mængde af data til bearbejdning.

105 º º¾ÅÐ Ò Ö ÅÐ Ò Ö º º ½¹ ËÈ ³ Ö Det viser sig at målingerne er meget stabile, og de er derfor kun udført en gang. Figur 8.7 og figur 8.8 viser resultatet af kørslen. Bemærk at figuren er en omvendt graf, da køretiden er konstant, men mængden af arbejde stiger. º º ½¹¾ ËÈ ³ Ö Som det fremgår af figur 8.7, skalerer programmet fint til og med 3 SPE er. Herefter går det nedad og ydelsen aftager nogenlunde proportionalt med mængden af tilføjet arbejdskraft. Dette skyldes at mængden af kommunikation bliver større end mængden af arbejde. Vi har under målingen observeret at PPE ens belastningsniveau er nogenlunde konstant fra 3 SPE er og fremefter. Vi kan derfor konkludere at der er en klar flaskehals når kommunikationsmængden stiger i DSMCBE. Denne kørsel er udført på Cell Blades. I figur 8.8 ses udviklingen af køretiden fra en til 4 maskiner med hver 6 SPE er. Denne kørsel er udført på Cell Blades. Det er forventeligt at ydelsen falder en smule efter tilføjelse af første maskine, da dette involverer kommunikation over netværket. Når næste maskine tilføjes, er der en enkelt række mere der skal deles mellem to maskiner. Der må her forventes et ekstra fald i ydelse, da der nu er en enkelt processer der har to delte rækker. Dette fald er til stede, men har en ubetydelig størrelse. Herefter burde køretiden º º Ë ÑÑ Ò ØÒ Ò være nogenlunde stabil, fordi der er lige mange delte rækker, men det er den ikke. Det skyldes at vi har implementeret en global barriere for alle SPE er. Herved sikres det at alle SPE er er i samme runde, men samtidig stiger den samlede mængde koordinering. En løsning til dette, kunne være at benytte en barrierer til hver delt række, som kun involvere de to SPE er der deler den pågældende række. Som det fremgår af målingerne skalerer problemet ikke helt optimalt. Udgaven på en enkelt maskine bliver svær at optimere helt godt. Men der er mulighed for optimeringer hvis man afskaffer koordinator tråden, og opdeler håndteringen af SPU en i flere tråde. Specielt kunne der optimeres hvis events fungerede optimalt. Netværksdelen kan lettere optimeres, ved at benytte flere barrierer der kun involverer to SPE er. Herved vil der dels forsvinde nogle netværkstransmissioner, og samtidig vil den helt stramme synkronisering forsvinde. Dette kan give mulighed for større tolerance overfor udsving i svartider på netværket.

106 Ã Ô Ø Ð º ÔÖ ÚÒ Ò Ó Ö ÙÐØ Ø Ö ¼ Figur 8.7: Heat kørt med henholdsvis 1-6 SPE og 2 maskiner med 6 SPE er

107 Ë ÑÑ Ò ØÒ Ò Figur 8.8: Heat kørt med henholdsvis 1-6 SPE og 2 maskiner med 6 SPE er ½

108

109 Ã Ô Ø Ð Ö Ö Ò ÖÑ ÐÐ º½ ËÈÍ ÓÒØÖÓÐ Ó I dette afsnit vil vi beskrive nogle af de tekniske erfaringer vi har fået af at arbejde med Cell BE arkitekturen, således at andre kan drage nytte heraf, og ikke behøver at opdage dette selv. En SPU er beregnet til at bearbejde streaming data, og kan derfor ikke håndtere context skift særlig godt. Det er der ikke noget nyt i, og det er også beskrevet i håndbogen[6]. Det er dog fristende at forsøge at flytte en del logik over på SPU enheden, da man herved opnår en parallel udførsel af kontrol koden. Dette giver bagslag på to måder. For det første er det væsentligt at have alle oplysninger der hvor der skal tages beslutninger. Hvis kontrolkoden er spredt ud over to enheder skal man enten duplikere informationer, eller undvære dem. Mange optimeringer er kun mulige ved hjælp af avancerede datastrukturer og kræver meget hukommelse, og dette er derfor ikke muligt at udføre på SPU enheden. Det andet problem er at SPU enheden har begrænset hukommelse. Det er selvfølgelig også ganske logisk, da det også står i håndbogen[6]. Hvis man begynder at flytte kontrol kode og kontrolstrukturer ud på SPU enheden tager man en del af denne plads. Dette gør naturligvis at der er mindre plads til det program som skal arbejde der. Det betyder også at de enheder der kan bearbejdes har mindre plads, og derfor må skæres ned i mindre stykker, hvilket giver mere overhead. På baggrund af dette kan vi fraråde at man forsøger at implementere eller bruge user-mode tråde på SPU enhederne. Vi har implementeret dette og umiddelbart virker det som en ganske god ting. Men når man begynder at bruge tråde opdager man at der er markant mindre hukommelse at tage af. I vores implementation kopieres hele register filen, og dette medvirker til et stort hukommelsesforbrug. Man kan ikke umiddelbart anvende register forbrugsalgoritmer på SPU en fordi de både optager hukommelse og koster tid at afvikle. Man kan justere på størrelsen af den allokerede stak, men dette vil kun give en begrænset forbedring og skal således tilpasses hver gang der ændres i programkoden.

110 º¾ ÄÏË Æ Ã Ô Ø Ð º Ö Ö Ò ÖÑ ÐÐ Ñ ÚÓÐ Ø Ð ÐÛ ÝÒ Ñ ÑÓÖÝ µ I håndbogen[6] står der at man skal udføre instruktionenäïë Æ efter DMA overførsel fra LS til hovedhukommelsen. Der står ikke umiddelbart hvordan dette udføres, men det gøres således: º Å ÓÚ Ö Ö Ð Ö Ø ÖØ Ø ÈÈÍ Når der anvendesäïë Æ kan der måles en tydelig nedgang i ydelsen. Dette er naturligt da PPU en skal synkronisere sin adgang til hukommelsen. Vi har forsøgt at fremprovokere en delvis overførsel, men det er ikke lykkedes. Så længe SPU en ikke signalerer at overførslen er afsluttet, før den har registreret, at DMA overførslen er afsluttet kan man undværeäïë Æ. Det er en lidt farlig påstand, men den bakkes op af håndbogens forfatter[53]. I håndbogen[6] og på diverse fora, anbefales det at starte DMA overførsler fra SPU enheden. Begrundelsen for dette er at 8 SPU enheder kan starte 8 DMA overførsler på samme tid, hvor en PPU må starte disse en af gangen. Dette argument er fuldt gyldigt, men for at kunne starte en DMA overførsel må SPU enheden kende adressen data skal hentes fra. Hvis denne adresse leveres af PPU en via mailbox beskeder, bliver det således bare udleveringen af adresser der er sekventiel, og herved opnås der ikke væsentlig parallelitet º i overførslen. Å Ð Ø ÓÚ Ö Ö Ð Ö I specielle tilfælde kunne det tænkes at adressen på næste datablok er indeholdt i nuværende, således at PPU en ikke er involveret i uddeling af adresser. I et sådan tilfælde vil det formentlig være bedre udelukkende at benytte overførsler startet fra SPU enheden. I DSMCBE har vi ikke kunne måle hastighedsforbedringer ved at anvende overførsler startet af SPU enheden. Det er kun muligt at starte DMA overførsler på over 16Kb via SPU enheden. Vi har forsøgt at benytte dette system til at overføre data, på den måde at der sendes en startadresse, en længde og en destination til SPU enheden via mailbox. Når overførslen er afsluttet kvitterer SPU enheden med en mailbox besked. Vi kan måle en klar hastighedsforbedring º hvis ËÑ Å ÓÚ Ö Ö Ð Ö vi i stedet starter flere individuelle 16Kb overførsler fra PPU en. Vi har ikke forsøgt at simulere en listeoverførsel på SPU en ved at starte flere individuelle overførsler. Man skal specielt bemærke at der er et overhead i forbindelse med DMA lister, da disse kræver oprettelse og initialisering af en DMA kæde. Dette fratager SPU enheden både regnekraft og hukommelse. Fra PPU enheden er det muligt at starte en SPU med memory mapping. Dette bevirker at SPU ens LS kan adresseres via. en EA, ganske ligesom normal hukommelse. Denne mulighed åbner for at data kan kopieres via en almindeligñ ÑÔÝkommando. Ved at benytteñ ÑÔÝistedet for DMA overførsler, spares der en del overhead i forbindelse med overførsel af små mængder data. Det kan ikke betale sig at overføre større mængder data medñ ÑÔÝfordi denne kommando udføres synkront, og derfor blokerer kaldet. Vi har

111 Å Ð ÓÜÓ Ò Ð Ö ikke undersøgt den præcise grænse for hvornår den ene måde er bedre end den anden, fordi man primært sender små kontrolblokke eller store datablokke i et DSM system. Vi º forventer Å Ð ÓÜÓ Ò Ð Ö at grænsen er omkring 128bytes, da det er den mindste datamængde EIB en kan overføre effektivt. Det skal også bemærkes at det ikke er muligt at overføre mere end 16KB med en enkeltñ ÑÔÝkommando, men man kan overføre data i mængder der ikke er delelige med 16 bytes. Der findes tre måder at kommunikere med en SPU, via. memory, mailbox og signaler. Hvis data er store mængder er det naturlige valg hukommelsesoverførsel. Når data mængderne er små kan man anvendeñ ÑÔÝsom beskrevet ovenfor. Men selve overførslen er betinget af at der i forvejen er afsat plads til data på destinationen. Valget mellem signaler og mailbox beskeder er let, da mailbox beskeder er hurtigere end signaler 1. Når der skal kommunikeres fra SPU til PPU findes der også en ÒØ ÖÖÙÔØÑ Ð ÓÜ. º Ú ÒØ Ved at skrive til denne mailbox kan PPU en benytte en speciel event håndtering i stedet for at poll e mailboxen. Vores målinger viser dog at det er målbart hurtigere at benytte interrupt mailboxen til kommunikation. Vi har ikke fundet en forklaring på dette, og havde faktisk forventet det modsatte, da der er ekstra logik forbundet med en interrupt mailbox. I stedet for konstant at poll e for mailbox beskeder og signaler, kan man registrere en event handler. Denne event handler kan så blokere koden indtil et eller flere events forekommer. Man kan vælge at vente på at modtage en mailbox besked, vente på plads til at ßÙÒ Ò ÒØÛÖ ØØ Ò ÚÓ Ë Ò Å ÙÒ Ò ÒØ Ø ÙÒ Ò ÒØÓÙÒص sende en mailbox besked eller vente på et signal. Desværre er det ikke lykkedes os at få brugbar ydelse ud af events. Specielt det event der fortæller om der er plads til at sende en mailbox Û Ð ÓÙÒØ ¼µ besked er uheldigt implementeret. Det er forventet at koden der anvender eventet ß Ô Ú ÒØ Û Ø ÔÙ Ú ÒØ Ò Ð Ö ² Ú ÒØ ËÈ Å Î ÆÌ ÇÍÆÌ ¼¼¼µ ser således ud: ÐÛÖ ØØ Ò Ô Ò Ñ ÓÜ ÛÖ Ø ÓÒØ ÜØ ² Ø ÓÙÒØ ËÈ Å Ç Æ ÄÇ ÃÁÆ µ ÓÙÒع ÛÖ ØØ Ò ÐMen det betyder at hvis mailbox en ikke er fyldt aktiveres eventhandleren konstant. For at kunne anvende dette må man således hele tiden opdatere de events man lytter til, afhængig af om man forventer at mailbox en har været fyldt. 1 Signaler har dog en speciel OR mode, og kan benyttes ved SPU til SPU kommunikation

112 º Ä ÒÙÜÓ Ï Ø ÓÖ ÒÝ Ã Ô Ø Ð º Ö Ö Ò ÖÑ ÐÐ I Linux mangler der enï Ø ÓÖ ÒÝkommando. For at simulere dette skal blokerende kald til forskellige hændelser implementeres i hver deres tråd. Herefter skal alle tråde aktivere en fælles kondition variabel der så bliver en slags proxy for etï Ø ÓÖ ÒÝkald. Denne mangel bevirker at når man ønsker at vente på toóò Ø ÓÒÚ Ö Ð Öog en mailbox besked, skal man have fire tråde. I Linux foregår venten påóò Ø ÓÒÚ Ö Ð Öved at en tråd går ind in en kritisk region og venter. Hvis en anden process signalereróò Ø ÓÒÚ Ö Ð Òmens der ikke ventes i den kritiske region, forsvinder signalet. Dette betyder at en tråd skal kontrollere om der er mulighed for at dette er sket, inden der igen ventes. Alle disse omstændigheder gør det kompliceret at undgå polling, og det omfattende brug af synkroniseringsprimitiver har en negativ indflydelse på ydelsen.

113 Ã Ô Ø Ð½¼ Ö ÑØ Ø Ö At konstruere et software system er typisk en uendelig opgave, forstået på den måde at der er et ubegrænset antal af ekstra funktioner og optimeringer der kan udføres eller afprøves. Vi har med DSMCBE fokuseret primært på at få korrekt basis funktionalitet, med et ½¼º½ begrænset ÖÙ ÖÑ Ð ÓÜ Ö antal tilgængelige bruger funktioner. Herudover har vi forsøgt at optimere programmet med henblik på ydelsen. Vi mener at have nået disse mål ganske godt, og dette afsnit beskriver de ændringer vi gerne vil implementere såfremt de har en positiv effekt. Hvis der kun arbejdes på en enkelt DSMCBE maskine er mailbox beskeder en god måde at kommunikere på, hvis beskederne er ganske små. Desværre tager DSMCBE denne mulighed væk, da DSMCBE selv benytter mailbox systemet. For at kunne gøre dette, skal der oprettes en buffer på SPU og PPU til at lagre disse beskeder. Herefter skal der implementeres et funktionskald til at sende, og et til at modtage, altså ialt 4 funktioner. Hvis der sendes fra SPU enheden, skal der defineres en speciel pakke type der indikerer bruger kontrolleret mailbox indhold. Herefter sendes en mailbox besked, der blot placeres i en buffer på PPU en. Når der senders fra PPU til SPU forventer SPU en at der kommer etö ÕÙ ØÁ som første besked. Hvis der reserveres f.eks.íáæì Å, til dette ½¼º¾ kan næste ÃÙÑÙÐ Ø Ú ÓÔ Ø Ö Ò Ö mailbox besked være brugerdefineret data. Ved at anvende en buffer på begge enheder, er det muligt at afgøre om der findes beskeder, uden at kræve at læsning og skrivning foregår synkront. Dette giver naturligvis en smule overhead, da der både anvendes en buffer og skal sendes dobbelt så mange mailbox beskeder. Når data sendes over netværket, er det tydeligt at en PS3 har forøget latenstiden, formodentlig pga. hypervisor softwaren. I denne forbindelse kan LogP[16] modellen anvendes til at afgøre at det er vigtigere at reducere antallet af pakker, også selvom dette sker på bekostning af pakkestørrelsen. Ved at introducere en logik for hvornår beskeder til en given maskine skal sendes, kan man muligvis kombinere flere pakker, og hermed reducere antallet af pakker. Denne logik er dog ikke helt uden problemer, da akkumuleringen medfører en forsinkelse af pakkerne, hvilket kan give en betydelig nedgang i ydelsen.

114 ½¼º ÇÔ Ø Ö Ò Ú ºÁÒÚ Ð Ö Ò Ã Ô Ø Ð½¼º Ö ÑØ Ø Ö ÕÙ Ö ÐÓ Ð ÓÔ Ö ØÙÖÒ Ö µ Vi har valgt at anvende invalideringsmodellen, da vi har vurderet at de fleste applikationer Ê Ð ÐÓ Ð ÓÔ ØÖÙ Ö µ vil fungere bedst med denne. Der er dog nogle applikationer, og specielt nogle variabler i en applikation, som vil fungere bedre med en opdatering. Dette er typisk en variabel ÕÙ Ö À ÒØ ÖÒÝ ÓÔ µ ÁÒÚ Ð Ø Ö ÕÙ ØÑÓ Ø der læses fra en enhed, men skrives fra en anden. Hvis variablen læses under invalidate À ÒØ ÖÒÝ ÓÔ Ö Ö ÁÒÚ Ð Ø Ö ÔÓÒ Ò modellen, vil følgende sekvens opstå: ÕÙ Ö ÐÓ Ð ÓÔ Ö ØÙÖÒ Ö µ ÍÔ Ø ÑÓ Ø Ê Ð ÐÓ Ð ÓÔ Ù Ø Ñ ÙÔ Ø µ ÕÙ Ö ÓÔ Ø Ö ØÐÓ Ð ÓÔ Ö ØÙÖÒ Ö µ ½¼º ÏÖ Ø ¹ÓÒÐÝ Hvis der medsendes opdateringer, vil dette se således ud: Som beskrevet i analysen er der ofte fordele i invalideringsmodellen, og af og til fordele i opdateringsmodellen. Ved at lade brugeren angive hvilken model der skal benyttes til et objekt, kan der opnås bedst mulig håndtering af konsistensmodellen. Vi har implementeret opdateringsmodellen, men kun for objekttabellen, da vi igennem kontrolmålinger kunne udlede at der blev sendt store mængder data på netværket. Samme ydelsesfordele kunne det tænkes at der kunne hentes for andre objekter. I særlige tilfælde, er det ikke nødvendigt at data kan læses fra et dataobjekt. Dette er oftest tilfældet med et resultat, hvor flere enheder skriver til hver sin del af resultatobjektet. I ½¼º et sådan ÖÓ ØØÖ tilfælde er det muligt for flere processer at have en skrivelås på objektet samtidig. Ved at holde styr på hvilke dele af objektet der er opdateret kan man så samle det endelige resultat. Fordelen ved dette er, udover at flere kan have en skrivelås samtidig, at eksisterende data ikke behøver at gøres tilgængelig, samt at det ikke er nødvendigt at sende hele resultatobjektet tilbage, men kun de ændrede dele. Når flere maskiner venter på samme objekt, står disse internt i en kø. Når en bestemt begivenhed opstår, skal nogle, eller alle, maskiner have en besked. I den nuværende model sendes disse ganske sekventielt. Ved at introducere en broadcast pakke, kan man pakke en vilkårlig besked sammen med en liste af modtagere. Ved modtagelsen af en sådan pakke, kan en maskine læse hvilke andre maskiner der skal have pakken, samt læse selve pakken. Maskinen kan herefter sende pakkerne videre, og håndtere sin egen kopi. Ved at lægge broadcast pakker inde i andre broadcast pakker, kan man danne en træstruktur. Selvom der kun anvendes et enkelt broadcast niveau, vil det være muligt at distribuere belastningen på netkortet fra en maskine, ud over andre. Da alle maskiner

115 È ÖØ Ð ÕÙ Ö ½¼º È ÖØ Ð ÕÙ Ö har et unikt ID i DSMCBE, og alle forespørgsler allerede findes i en kø, er dette en forholdsvis simpel ændring som stort set ikke har nogen negative konsekvenser. Dog skal man gemme afsender maskinens ID sammen med forespørgslen, da man ellers ikke kan afgøre om beskeden kommer fra en anden maskine eller ej. I nogle tilfælde kan det være brugbart at oprette et enkelt stort objekt, men kun tilgå en del af objektet. I Brain Tumor eksemplet kunne det være brugbart at definere hele billedet som et stort objekt, men kun hente et segment af gangen, da hele objektet ikke kan være på SPU en. I den nuværende implementation af DSMCBE kan man simulere dette ved at oprette mange objekter, som hver har en del af det samlede objekt. Dette fungerer, og giver samtidig programmøren ansvar for at vælge granulariteten af objekterne. I Heat Equation ville det være meget brugbart at kunne definere hele kortet som et stort objekt og så hente det antal linier ud af den store blok som er krævet. Dette er primært en logisk hjælp til programmøren, og gør oprettelsen af objekterne mere simpel. Denne udvidelse har dog den ulempe at der skal holdes styr på en masse flere detaljer vedrørende offsets og lignende. Samtidig kan det være svært for programmøren at se hvilke objekttilgange der blokerer for andre.

116

117 Ã Ô Ø Ð½½ ÃÓÒ ÐÙ ÓÒÓ Ô Ö Ô Ø Ú Ö Ò Formålet med dette speciale var at designe og implementere et værktøj som kan hjælpe programmører med at komme i gang med Cell BE arkitekturen. Da der kun eksisterede et ringe udvalg af værktøjer, som oftest var svære at benytte, var det et krav at dette værktøj skulle være nemt at kommer i gang med at anvende. Desuden var det et krav at værktøjet skulle fungere på såvel en enkelt Cell BE maskine, men også på en klynge af Cell BE maskiner, hvilket ingen af de eksisterende værktøjer understøtter. Med DSMCBE har vi konstrueret et værktøj som giver programmøren 3 funktioner (create, acquire, release) til at håndtere Cell BE s hukommelsesmodel. Derudover findes der en funktion, til at starte DSMCBE samt SPE erne, både på en enkelt maskine samt på en klynge af Cell BE maskiner. Mere avancerede funktioner findes også, men er ikke nødvendige for at komme i gang. Dette opfylder kravet om at det er forholdsvist nemt at bruge og derved får programmøren nemmere ved at komme igang med Cell BE arkitekturen. Ved at anvende DSMCBE på nogle forskellige beregningsproblemer, har det på relativt kort tid været muligt at implementere løsninger, som resulterer i forholdsvis god ydelse. Det er klart at man ikke kan opnå samme ydelse, som et håndoptimeret program, men dette skal opvejes mod den reducerede udviklingstid. Ligeledes er der problemer som er mindre egnet eller giver mindre god ydelse end andre. F.eks. er heat equation ikke specielt godt egnet til netværk, da der kræves meget synkronisering. Andre problemer som f.eks. prototein og braintumor giver en ganske fornuftig ydelse. DSMCBE giver i sin nuværende udformning, en god basis for videreudvikling. I kapitel 10, er der nævnt flere mulige udvidelser som må forventes at forbedre ydelsen. Derudover er det også tænkeligt at man kunne udskifte nogle af de interne kontrolstrukturer og algoritmer, for at opnå bedre ydelse. Ønsker man at implementere et andet kommunikationssystem, såsomìùôð Ô eller ËÈ, er DSMCBE oplagt som underliggende hukommelsessystem. Dog vil man formentlig have gavn af at implementere nogle af de optimeringer og udvidelser der nævnes i kapitel 10. Det kunne også tænkes, at man kunne bruge dele af DSMCBE, f.eks. hukommelseshåndteringen af SPE erne eller SPE tråde, i andre værktøjer til Cell BE arkitekturen. Alt i alt giver DSMCBE i sin nuværende form, nogle erfaringer med DSM på Cell BE arkitekturen. Herved er det nemmere for andre at komme med deres bud på et DSM system til Cell BE arkitekturen, hvor de kan lære noget af de erfaringer vi har gjort os med DSMCBE. ½¼½

118

119 Appendices ½¼

120

121 Ð ÖÙ ÖÚ Ð Ò Ò º½ ÓÖÙ ØÒ Ò Ö º¾ ÇÚ ÖÓÖ Ò ØÚ Ö Ñ 1 Þ Ø 2 ÍÁ ÑÝ ¾ for ¼ µ int ÑÝ Ø create ÑÝ sizeof intµ µ Ö Ø (se listing release ÑÝ Ø µ ÑÝ Ø Dette afsnit forklarer hvordan programmører kan anvende DSMCBE til at lette programudviklingen på Cell BE arkitekturen. For at kunne benytte denne brugervejledning og DSMCBE, er det nødvendigt at læseren er bekendt med programmering i sproget C på Cell BE arkitekturen. Herudover er det fordelagtigt hvis læseren også har kendskab til, eller erfaring med andre DSM baserede systemer. DSMCBE fungerer ved at håndtere overførsel af data mellem PPE enheder (tråde) og SPE enheder. DSMCBE kan overføre data på tværs af maskiner, og sørger for at programmøren ikke skal håndtere hverken lokalisering eller overførsel. I DSMCBE har hver enkelt dataobjekt et unikt id, kaldet et GUID 1. Et GUID er et 32 bit tal, og angives ved oprettelsen af delt data 2. Oprettelsen af data foregår ved kaldet A.1). Listing A.1: Create eksempel Som det ses, kan der oprettes objekter af vilkårlig størrelse. Efter oprettelse af ½¼ et objekt kan alle enheder, PPE er såvel som SPE er tilgå objektet, ved hjælp af funktionen ÕÙ Ö (se listing A.2). 1 GUID står for Globally Unique ID 2 Tallet 0 er reserveret til intern brug i DSMCBE

122 1 Þ Ø 2 Þ ØÑÝ Þ Ð º ÖÙ ÖÚ Ð Ò Ò 3 ÍÁ ÑÝ ¾ for ¼ µ 5 int ÑÝ Ø acquire ÑÝ ²ÑÝ Þ ACQUIRE_MODE_READµ release ÑÝ Ø µ ÔÖ ÒØ ÑÝ Ø ± ± Ò ÑÝ Ø µ Listing A.2: Acquire eksempel Alle kald i DSMCBE er blokerende. Det betyder at hvis objektet endnu ikke er oprettet når der kaldes ÕÙ Ö, venter tråden indtil dette sker. Dette er specielt brugbart i forbindelse Ò Å Á ¾ med opstartsfaser, og indsamling af resultater. Ved oprettelse af et objekt, låses objektet med det samme, således at den tråd der opretter objektet kan skrive data ind i objektet før eventuelt ventende tråde får adgang til data. Da alle enheder i systemet skal være enige om hvilket GUID der anvendes, kan statisk tildelte GUID værdier med fordel angives som Ò direktiver i en header fil: DSMCBE anvender en konsistens model der hedder entry-consistency. Denne model tildeler hver enkelt objekt en lås, og garanterer at data ikke ændrer sig ved læsning såfremt låsen er taget. På samme måde garanteres det at kun én process kan have skrivelåsen til et objekt af gangen. Umiddelbart efter at data er opdateret ved skrivning, bliver disse ændringer tilgængelige for alle andre processer. For at denne model kan anvendes, er det nødvendigt at kalde funktionenö Ð kalde ÕÙ Ö når data ikke længere skal anvendes. Jo kortere tid en lås holdes, jo mindre sandsynlighed er der for at andre processer blokeres, og herved sikres bedst mulig ydelse. Bemærk atö Ð tager en pointer til data, og ikke et GUID. Det er ikke tilladt at mere end én gang på samme GUID, uden at der er kaldtö Ð. Med andre atö Ð ord er DSMCBE s låse ikke re-entrant. DSMCBE er trådsikkert, og kan håndtere flere samtidige tråde der tilgår samme data. Et data objekt kan erhverves som READ-ONLY eller READ-WRITE. Et objekt hentes som READ-ONLY ved at kalde ÕÙ Ö med argumentet ÉÍÁÊ ÅÇ Ê. Det er programmørens ansvar at sikre at programmet ikke forsøger at skrive til data modtaget som READ-ONLY, ligesom der heller ikke må læses eller skrives til data efter er kaldt. DSMCBE garanterer at data ikke ændres før der kaldesö Ð. Et data objekt kan hentes med READ-WRITE adgang, ved at kalde ÕÙ Ö med argumentet ÉÍÁÊ ÅÇ ÏÊÁÌ. Et objekt der er erhvervet i READ-WRITE får automatisk en ekslusiv lås. DSMCBE garanterer at der kun er en process der har et objekt som READ-WRITE af gangen. Umiddelbart efter atö Ð er kaldt på et objekt med READ-WRITE, ½¼ bliver disse ændringer synlige for andre processer. Hvis alle processer udelukkende benytter ÉÍÁÊ ÅÇ ÏÊÁÌ til at tilgå objektet, garanteres det at alle tidligere ændringer er tilgængelige i det øjeblik objektet modtages.

123 º ËÈ Ò Ø Ö Ò ËÈ Ò Ø Ö Ò En SPE kan tilgå data på nøjagtigt samme måde som en PPE. Alle kald og alt funktionalitet er den samme. Men da systemets ydelse i høj grad afhænger af SPE ernes ydelse, findes der ekstra funktionalitet til disse. SPE programmer har i høj grad brug for at udføre overlapped 1 Þ ØÛÓÖ ÓÙÒØ ½¼¼¼ execution, også kendt som dobbelt buffering. Denne teknik går ud på at næste stykke data 2 Þ ØÑÝ Þ 3 ÍÁ ÑÝ ¾ hentes, mens der beregnes på det nuværende. Dette sikrer at der ikke ventes unødigt på data. For at kunne udnytte dette findes der i DSMCBE et trådbibliotek, der kan håndtere sådanne situationer. Som eksempel anvendes følgende ikke optimerede kode (se listing A.3). 8ßfor ¼ ÛÓÖ ÓÙÒØ µ void ÑÝ Ø acquire ÑÝ ²ÑÝ Þ ACQUIRE_MODE_READµ ÐÙÐ Ø ÓÒ Ø ÑÝ Ø ÑÝ Þ µ release ÑÝ Ø µ initialize µ 6 12Ð terminate µ Listing A.3: Simpelt acquire eksempel I eksemplet hentes der en mængde data der bearbejdes. Men efter hvert gennemløb ventes der på data fra ÕÙ Ö kaldet. En simpel ændring kan ses i listing A.4. Som det ses bliver programmet ikke væsentligt mere kompliceret af at der nu anvendes tråde, men til gengæld ventes der nu ikke længere på data. Denne model fungerer fint for programmer der har begrænsede hukommelseskrav. Desværre er SPE en meget begrænset af de 256Kb hukommelse, og trådene tager en god del af denne begrænsede resource. For at undgå dette, kan man anvende de asynkrone funktioner i DSMCBE. Disse funktioner er kun tilgængelige på SPE en, og gør at koden kommer til at minde meget om traditionel overlapped execution (se listing A.5). Ved at anvende asynkrone kald, opnås der hastighedsmæssige fordele uden det ekstra hukommelsesforbrug. Koden bliver desværre en smule mere kompliceret, men ikke mere kompliceret end traditionelóú ÖÐ ÔÔ Ü ÙØ ÓÒ. Ved at anvende asynkrone º kald, kan ÀÒ Ø Ö Ò Ò ØÚÖ der startes flere overførsler samtidigt, og mere avanceret kode kan håndtere at operationerne afsluttes i en anden rækkefølge end de blev startet i. Bemærk at SPE en er begrænset af 256Kb hukommelse, og kan ikke hente objekter der er større end den ledige hukommelse. Dette er specielt et problem i forbindelse med asynkron overførsel, da der her kræves dobbelt så meget hukommelse. ½¼ I DSMCBE håndteres kald over netværket helt transparent for brugeren. Men for at kunne kommunikere over et netværk, skal DSMCBE have oplysninger om hvilke maskiner

124 1 Þ ØÛÓÖ ÓÙÒØ ½¼¼¼ 2 Þ ØÑÝ Þ Ð º ÖÙ ÖÚ Ð Ò Ò 3 ÍÁ ÑÝ ¾ intø Ö ÆÓ Ö Ø Ì Ö ¾µ int Ó ÓÙÒØ ¼ if Ø Ö ÆÓ ¼µ 5 static 9 while Ó ÓÙÒØ ÛÓÖ ÓÙÒص 10 void ÑÝ Ø acquire ÑÝ Ó ÓÙÒØ ²ÑÝ Þ Ó ÓÙÒØ 17 Ì ÖÑ Ò Ø Ì Ö µ ÐÙÐ Ø ÓÒ Ø ÑÝ Ø ÑÝ Þ µ release ÑÝ Ø µ initialize µ 8 11ß 12 terminate µ 13 return 14Ð 15 else 16ßß Ð ACQUIRE_MODE_READµ Ð Listing A.4: Trådet eksempel der deltager, samt hvordan der forbindes til disse. Disse oplysninger angives i en fil, som så indlæses af DSMCBE ved opstarten. Et eksempel på en sådan fil kunne være: ÈË ¹¼½¾¾ ÈË ¹¼¾ ¾ ÈË ¹¼ Hver linie i filen angiver en maskine og et port nummer, adskilt med mellemrum. Maskinerne nummereres således at den første linie angiver maskine 0, den anden maskine 1, og så fremdeles. Det er vigtigt at alle maskiner har nøjagtigt ens opsætningsfiler. Listing A.6 giver et eksempel på hvordan DSMCBE startes med en netværksfil. Ved at angive maskinens nummer på kommandolinien, er det muligt at anvende samme kompilerede program på alle maskiner. Hvis der angives NULL som filnavn, antages det at der kun køres på én maskine. Det er naturligvis også muligt at angive filnavnet på kommandolinien, ligesom det også er muligt at køre helt forskellige programmer på alle maskiner. Maskinen der tildeles nummer 0, altså den første på listen, har en speciel rolle i opstartsfasen, da den sørger for at igangsætte kommunikationen mellem alle maskinerne. Det anbefales derfor at starte denne maskine som den sidste. Hvis dette ikke gøres, kan ½¼ der komme fejlbeskeder når maskinen forsøger at forbinde til de andre maskiner. Hvis der opstår en fejl under forbindelsesforsøget, venter maskinen fem sekunder, og forsøger igen. Der bliver maksimalt forsøgt 5 gange. DSMCBE foretager ikke pakkeplanlægning, og det anbefales derfor at der anvendes et switched netværk med fuld interconnect.

125 1 Þ ØÛÓÖ ÓÙÒØ ½¼¼¼ 2 Þ ØÑÝ Þ ÖÖ Ö Ö 3 ÍÁ ÑÝ ¾ int Ò Ð ½ int Ò Ð ¾ for ¼ ÛÓÖ ÓÙÒØ µ 5 unsigned 6 unsigned void ÑÝ Ø endacquire Ò Ð ½ ²ÑÝ Þ µ ÐÙÐ Ø ÓÒ Ø ÑÝ Ø ÑÝ Þ µ if ½ ÛÓÖ ÓÙÒص Ò Ð ¾ beginacquire ÑÝ ½µ 12 Ò Ð ½ Ò Ð ¾ release ÑÝ Ø µ initialize µ 9 10 Ò Ð ½ beginacquire ÑÝ ACQUIRE_MODE_READµ 11 13ß Ð terminate µ Listing A.5: Asynkront acquire eksempel Maskine nummer 0 er også speciel fordi den vedligeholder en tabel der hjælper med º ÖÖ Ö Ö at finde placeringen af data. Ved oprettelse af et nyt dataobjekt, placeres dataobjektet på den maskine der udfører oprettelsen, og maskine nummer 0 får besked om at dette er sket. Hvis programmet opretter mange objekter, kan der derfor komme en del belastning på maskine nummer 0, men dette burde ikke ske under normale forhold. En barriere kan i DSMCBE implementeres ved at oprette et objekt der indeholder et heltal, sat til værdien 0. Hver komponent der skal mødes i barrieren tager objektet i Ê ÏÊÁÌ mode. Tallet i objektet tælles en op, og der kontrolleres om tallet nu er lig antallet af komponenter. Hvis dette er tilfældet, sættes værdien til 0, og objektet frigives. Hvis ikke der var nået det ønskede tal, skal komponenten blive ved med at læse variablen iê ÅÇ indtil denne er 0. Et eksempel på brugen af barrierer gives i listing A.7. Dette fungerer ganske fint, og optimeringer i DSMCBE reducerer kraftigt mængden af data, men efter hver skrivning til det delte objekt, bliver disse ændringer propageret rundt for at kunne læses. Da indholdet ikke har anden brug end at afgøre om alle processer er nået til barrieren, kan dette optimeres bort. DSMCBE har derfor en optimeret barriere, hvor data ikke sendes rundt. En barriere oprettes ved at kalde funktionenö Ø ÖÖ Ömed barrierens GUID ½¼ og antallet af processer der skal mødes i denne. Processer der ønsker at vente på en barriere kalder ÕÙ Ö ÖÖ Ömed barrierens GUID. Kaldet blokerer indtil alle processer har nået barrieren. Modsat en traditionel ÕÙ Ö, modtages der ikke en pointer, og der skal derfor ikke kaldesö Ð.

126 intñ Ò int Ö char Ö Úµß char Ù ¾ Ð º ÖÙ ÖÚ Ð Ò Ò Ñ Ò ¼ int Ô Ø Ö Ô Ø Ö intñ Ò 1 Ð Ñ Ò Ð ØºØÜØ char Ð ÔØ Ö Ø Ø Ö simpleinitialize Ñ Ò Ð Ô ÓÙÒص if Ö ¾µß Ñ Ò ØÓ Ö Ú ½ µ 8 9 ººººÓ Ø ØÔ Ö ÓÖÑ ÛÓÖ ºººº #define ÊÊÁ Ê ÇÍÆÌ 6 ÖÖ Öµ #define ÊÊÁ Ê Á ¾ 1 2 while ÖÖ Ö ¼µ if ÖÖ Ö ÊÊÁ Ê ÇÍÆ̵ ÖÖ Ö ¼ 7 release ÖÖ Öµ acquire ÊÊÁ Ê Á ² Þ ACQUIRE_MODE_READµ release ÖÖ Öµ º À ÐÐÓÛÓÖÐ 15 º º½ Ù º ½½¼ Ð terminate µ int Þ 3 unsigned 4 5 unsigned int ÖÖ Ö acquire ÊÊÁ Ê Á ² Þ ACQUIRE_MODE_WRITEµ 9 11ß 14Ð 20Ð Listing A.6: Netværks eksempel Listing A.7: Eksemple på en manuel barriere I dette afsnit gennemgåes et eksempel på hvordan man bruger DSMCBE. For at følge traditionen vælger vi at lade hver process udskrive Hello World til skærmen. Koden til eksemplet kan hentes på projektet hjemmeside ( For at alle processer kan kommunikere skal de aftale et fælles objekt id (et GUID). Vi har lagt det ene GUID, som eksemplet benytter sig af, ud i filen Ù º (se listing A.8).

127 #ifndef ÍÁ Ë À #define ÍÁ Ë À ËÈͺ #define ÇÍÆ̽ #endif» ÍÁ Ë À» º º¾ËÈͺ 6 #include Ø Óº #include Ñ ÔÙº 7ß#include Ù º 1 2 ÔÖ ÒØ ËÈ ±ÐÐÙ Ý Ò À ÐÐÓÏÓÖÐ Ò Ô µ long ÒÚÔµ 4 ÓÙÒØ ÓÙÒع½ long Þ 6 intñ Ò unsigned ÔÖ ÒØ ËÈ ±ÐÐÙ Ý Ò ÇÍÆÌ ±Ù Ò Ô ÓÙÒص long Ô unsigned long long Ö Ô unsigned long release ÓÙÒص 9 unsigned 10 if ÓÙÒØ ¼µ release ÓÙÒص ÔÖ ÒØ ËÈ ±ÐÐÙ Ý Ò ÓÓ Ý Ò Ô µ release ÓÙÒص º º ÈÈͺ 3 5 Listing A.8: Hello world guids.h eksempel Da SPE en er selve arbejdshesten, er det denne som skal udskrive Hello World. Herefter henter SPE en en værdi og tæller denne en ned. Når værdien når 0 er alle SPE er færdige, og SPE en afslutter kørslen. Koden kan ses i listing A initialize µ unsigned int ÓÙÒØ acquire ÇÍÆÌ ² Þ ACQUIRE_MODE_WRITEµ while ½µ ß ÓÙÒØ acquire ÇÍÆÌ ² Þ ACQUIRE_MODE_READµ ß ÐÐ break terminate µ 30 31Ðreturn¼ Listing A.9: Hello world SPU.c eksempel ½½½ PPE koden sørger for at oprette det delte dataobjekt, og initialisere dette til antallet af SPE er. Herefter venter den blot til alle SPE er er færdige. Der er lidt ekstra logik i starten

128 Ð º ÖÙ ÖÚ Ð Ò Ò #include Ø Ð º #include Ø Óº #include Ñ ÔÔÙº #include Ù º #defineå Ü Ýµ ܵ ݵ ݵ ܵµ 1 intñ Ò int Ö char Ö Ú µ char Ð intëèí ÌÀÊ Ë 7 if Ö ¾µ intèè 9 ËÈÍ ÌÀÊ Ë ØÓ Ö Ú ½ µ 11 ÈÈ ¼ 12 unsigned Ð ÆÍÄÄ ËÈÍ ÌÀÊ Ë ØÓ Ö Ú ½ µ ÈÈ ØÓ Ö Ú ¾ µ 18 Ð Ö Ú if Ö µ else ÔØ Ö Ø Ø Ö simpleinitialize ÈÈ Ð ËÈÍ ÌÀÊ Ëµ if ÈÈ ¼µ ÔÖ ÒØ ÏÖÓÒ ÒÙÑ ÖÓ ÒÔÙØ Ò µ 26 ÓÙÒØ ËÈÍ ÌÀÊ Ë Å ËÅ Å Ò ÓÙÒØ µ ½µ 29 release ÓÙÒص Ð Ô ½µ for ¼ ËÈÍ ÌÀÊ Ë µ ÔØ Ö Ó Ò Ø Ö ÆÍÄĵ º º ÃÓÑÔ Ð Ö Ò Ó Ð Ò Ò Ò ½½¾ af programkoden, således at det er muligt at køre samme program på en klynge såvel som på en enkelt maskine. Koden kan ses i listing A ß 14 int 15 ß 17 Ð ß else 30 Ð intµµ unsigned int ÓÙÒØ create ÇÍÆÌ sizeof unsigned return¼ 46Ð Listing A.10: Hello world PPU.c eksempel Kompileringen foregår, som normalt til Cell BE, ved at SPE modulet først kompileres. Herefter kompileres PPE modulet, og SPE modulet indlejres så i den endelige eksekverbare PPE fil (se listing A.11).

129 1» Ò» 2 Ø ÒØ Ø ËÅ Ö Ò Ø ÐÐ Ö ØÓ ÓÑÔ Ð Ö Ø»ÖÓÓØ» Ñ» ËÅ ÃÓÑÔ Ð Ö Ò Ó Ð Ò Ò Ò 3 ÑØ ØËÈÍºÓ ÈÈÍºÐ Ö ÒÙÚÖ Ò Ñ ÔÔ 5 ËÈÍ ÓÑÔ Ð Ö Ò Ó Ð Ò Ò Ò 10ÔÔÙ¹ Ñ ÔÙ¹Ñ ¾ËÈÍËÈÍËÈÍºÓ 6 ÔÙ¹ ¹Á»ÖÓÓØ» Ñ» ËÅ ¹¹ÑØÙÒ ÐÐ¹Ñ Ö ÐÐ¹Ñ ¾¹Ó ÔÙºÓ ÔÙº 7 ÔÙ¹ ¹Ä»ÖÓÓØ» Ñ» ËÅ»ËÈÍ» ÔÙ¹ ÒÙ¹Ö Ð ¹Ó ËÈÍ º» ÔÙºÓ¹Ð Ñ ÔÙ 12 ÈÈÍ ÓÑÔ Ð Ö Ò Ó Ð Ò Ò Ò 13ÔÔÙ¹ ¹¹Ñ ¾¹Ó ÔÔÙºÓ ¹Á»ÖÓÓØ» Ñ» ËÅ ºº»ÔÔÙº 9 Ö Ø Ð Ò Ð ËÈÍÓ Ø 14ÔÔÙ¹ ¹Ä»ÖÓÓØ» Ñ» ËÅ»ÈÈÍ»ÔÔÙ¹ ÒÙ ¾¹Ö Ð ¹Ä»ÖÓÓØ» Ñ» Ð ¹ÔÔ ¾»Ù ֻР¹ 16 Ð ÒÈÈÍ ÖÒÙ Ð ÖØ Ð Ö Ð Ñ ¾¹Ó ÈÈÍ º»ÔÔÙºÓËÈÍºÓ¹Ð Ô ¾¹Ð Ñ ÔÔÙ¹ÐÔØ Ö ¹Ð Ð ¹¾º¼¹Ð Ø Ö ¹¾º¼ Listing A.11: Linking eksempel ½½

130

131 Ð ÅÐ Ò Ö º½ ÐÐ ÓÑÑÙÒ Ø ÓÒ ÓÖÑ Ö Ó ÐØ Ù Ö Ú ÒØ ÈÍÑ Ò Ñ Ñ ËÔ ÙÔÈÖÓ ÒØÇÔØ Ñ Ð ½ ½¾ ¾ ¾ ¾¼ ½ ½ ¾±½ ¾¾½¾¾ ½ ¾¾ ¼ ¾ ½½±¾ ½ ½ ± Herunder ses målinger af Cell BE kommunikationsformerne. 1 2 Ó ÐØ Ù ÖÁÒØ ÖÖÙÔØÅ Ð ÓÜ ½ ½ ¾ ½ ± 3 ÈÍÑ Ò Ñ Ñ ËÔ ÙÔÈÖÓ ÒØÇÔØ Ñ Ð ½ ½ ¾ ½¼ ¾½± ¾ ¾ ¾ ¾ ½ ½ ¾ ± 4 ½½ ¾½¼ ¾¼ ¼ ±½ 5 ½ ¼±¾ ¾ ½ ½ ¼¾± Ó ÐØ Ù ÖÆÓÖÑ ÐÅ Ð ÓÜ ¾ ¼ ¾ ¼ ¼ ¾ ± ¾ ¾ ¾¼ ½ ± ¾½ ¾¾¾½ ¾¾ ± 12 ÈÍÑ Ò Ñ Ñ ËÔ ÙÔÈÖÓ ÒØÇÔØ Ñ Ð ½½ ¼ ½½¼ ¼ ±½ ½ ½½ ½ ¾±¾ ¾ ¾ ¾ ½ ¼ ± Ò ÐØ Ù Ö Ú ÒØ ¼ ¼¼ ± ¾ ¾ ¼ ¼ ± ¾¾ ¼¾¾ ¼ ¾ ± 21 ÈÍÑ Ò Ñ Ñ ËÔ ÙÔÈÖÓ ÒØÇÔØ Ñ Ð ½¾½ ½½ ½¼ ±½ ¾½½ ½ ¼ ¼¾±¾ ¼ ½ ¼ ½ ¾ ¼ ± Ò ÐØ Ù ÖÁÒØ ÖÖÙÔØÅ Ð ÓÜ ¼ ¼ ¾ ± ¼ ¼ ¼¼ ¼ ½ ± ½¾¼ ½¾¼ ½ ¾ ± 30 ÈÍÑ Ò Ñ Ñ ËÔ ÙÔÈÖÓ ÒØÇÔØ Ñ Ð 31 ½½ ¼ ½½¼ ¼ ¾ ¾ ±½ ½½ ¾ ¾

132 ¾ ¾ ½ ½ ±¾ ¾ ¾ ¾ ¼½ ¼ ¼ ± Ð ºÅÐ Ò Ö Ò ÐØ Ù ÖÆÓÖÑ ÐÅ Ð ÓÜ ¾ ¾¼¾ ¾¼ ± ÈÍÑ Ò Ñ Ñ ËÔ ÙÔÈÖÓ ÒØÇÔØ Ñ Ð ¾ ½ ¾ ¼½ ½ ¾ ± ½½ ¾ ¾ ½½¾ ¾ ¼ ½ ½ ±½ ¾½ ½ ¾½ ½ ¾¼ ± ½ ½½ ±¾ ¾ ½ ½½± ¼ ½ ¼ ½ ¾ ¼ ± ¾ ¾ ± ¾ ¾¾ ¼ ¾ ¾± º¾Ë Ò Ð ÈË ÈÖÓØ Ò ÈË Ñ Ò Ñ Ñ ËÔ ÙÔÈÖÓ ÒØÇÔØ Ñ Ð Ê ¼ ½ ½ ¼ ¼½ ½ ¼½ ¼¼ ½¼¼ ¾ ±½ ¾½ ¼ ¾½¼ ¾ ¼¼ ½¼¼ ¾ ±¾ ½¼¾¾ ½ ¼¼ ½¼¼ ½ ± Herunder ½ ½½ ¼¼ ½¼¼ ½¾± ses målinger for protein kørslerne. ½¾ ¾ ¼ ¾ ¼¼ ½¼¼ ½ ± 1 ½½ ¼ ¼¼ ½¼¼ ¼ ± 2 ½¾¾ ½ ½½ ±½¾ 3 ½ ½ ½ ¾½¼ ¾½ ¾¼ ¼¼±½ 4 ¾ ½¾ ½ ½¾ ½¼±¾ 5 ¼½¼¾ ¾ ¼ ¾ ¾ ¼¾ ± ¼ 6 ¼ ¾¼ ½ ± 7 ¾ ¾ ¾ ½ ¾ ½ ½ ½½¼ ± ¾ 8 ¼ ± 9 ¼½¼ ¼½¼ ¾ ± 10 ¼ ½ ½¾ ½ ½¾ ½½ ± ¼ 11 ¼ ¾ ¼ ½ ± 12 ¾ ¾ ¼ ¾ ¼ ± ¾ 13 ¾ ½ ± 14 ¼¾ ¾¾ ¼¾ ¾ ¼ ¾¼ ± 15 ¼ ¾½ ¼ ½ ± ¼ 16 ¾¾ ¼¾¼¾ ¼ ½ ½ ¾ ± ÓÙ Ð ÈË 20 ÈË Ñ Ò Ñ Ñ ËÔ ÙÔÈÖÓ ÒØÇÔØ Ñ Ð 21 Ê ¼ ½ 22 ½ ¼ ¼ ½ ¾¼¼ ½ ¼¼ ½¼¼ ¾ ±½ 23 ¾½ ¼ ¾½¼ ¾ ¼¼ ½¼¼ ¾ ±¾ 24 ½¼¾¾ ½ ½ ½ ¼¼ ½¼¼ ½ ± 25 ¾½½¼ ½¾½½¼ ¼¼ ½¼¼ ½½± ½¾ ¼¼ ½¼¼ ½ ± 27 ½½ ¼ ¼¼¾½¼¼ ¼ ± 28 ½¾¾ ¼½ ¼½½ ¾ ¼±½¾ 29 ½ ½ ½ ½¼ ½ ¼ ½ ±½ ½½ ¾ ½¾ ¾ ¼ ±¾ ¼½¼¾ ½ ¾ ½¾ ¾± ¼ ¾ ¾

133 ½ ¾½¼ ± ¾ ¼ ¼ ¼ ½ ± ¾ Ö ÒØÙÑÓÖ ¾ ± ½ ½¼ ¾ ¼ ¾± ¼ ½ ¾ ½ ¾ ¼½ ¼± ¼ ¼ ¼¾ ¼ ¼ ½ ¼± ¾ ¾ ¾ ¼½ ± ¾ ½½ ¾ ½½ ± 40 ¼ ¾ ¼ ¼ ¼ ± 41 ¼ ¼¾½ ¼ ¾ ± ¼ 42 ¾ ¾¼ ¼ ¼ ¼ ¾ ± ÓÙ Ð ÐÐ Ð 45 ÈË Ñ Ò Ñ Ñ ËÔ ÙÔÈÖÓ ÒØÇÔØ Ñ Ð 46 Ê ¼ ½ 47 ½ ¼ 48 ¾½ ½ ½¼ ½ ½¼¾ ¼¼ ½¼¼ ±¾ 49 ½¼¾ ¾ ½¾ ¾ ¼½ ½¼¼ ± 50 ¼ ¾ ¼¼ ¾ ¼½ ½¼¼ ± ½½ ¼ ¼ ¼¾½½¼¼ ¾± ½ ¼ ¼¼¼½ ¼¼ ½¼¼ ±½ 52 ½ ¼ ¼½ ½¼¼ ¾ ± 53 ¾ ¾ ¾¼ ¼½ ½¼¼ ¾ ± 54 ¾½¾ ¼¾ ¼½¾ ¼ ¼¾ ½¼¼ ¾± 55 ¾ ½¾¼ ¾ ½ ¼¾½½¼¼ ¾ ± 56 ½¼ ¼ ¾ ¾½ ¾ ¾½¼ ¼¾½½¼¼ ¾½±½¼ 57 ½½¾ ½½ ½½½ ¼½¼½¼¼ ¼ ±½½ 58 ½¾¾ ½ ½¾ ¼¼¾½¼¼ ¼¾±½¾ 59 ½ ¾ ¼ ½ ¾¼ ½¾ ±½ 60 ½ ¾½ ½¼½ ½ ½¼½ ¼¼ ½¼¼ ¼ ±½ 61 ½ ¾¼ ¼ ¼ ½¾ ¼ ¼ ½ ¼¼ ½¼¼ ¼ ±½ 62 ½ ½ ½ ½ ½½ ½ ½ ±½ 63 ¾ ½ ¼ ± ¾ 64 ¾ ¾ ¼¾¾ ± 65 ½¾ ½ ¾ ¾½¼ ¾¼± ÌÖ Ø ÐÐ Ð 68 ÈË Ñ Ò Ñ Ñ ËÔ ÙÔÈÖÓ ÒØÇÔØ Ñ Ð 69 Ê ¼ ½ 70 ½ ¼ ½ ¾¼ ½ ½ ¾¼ ½ ¼¼ ½¼¼ ±½ 71 ¾½ ½ ½ ¾ ¼¼ ½¼¼ ±¾ 72 ½¼¾¾ ½ ½ ½ ¼¼ ½¼¼ ½½± 73 ½ ¼¼ ½¼¼ ¼ ± 74 ½ ¼ ± º ½¾ ¼ ¼ ¼ ¾ ¼± Ö ÒØÙÑÓÖ ËØ Ø ¹ ÓÙ Ð ÈË Ñ Ò Ñ Ñ ËÈ ³ ÖÈÖÓ ÒØÇÔØ Ñ Ð Ê ¾ ¾ ½ ¾ ½¾ ¾ ½½ ¼ ½¼ ¼ ¼ ±½ ¾½ ½ ½ ½ ±¾ ¾ ¼ ¼¾ ½ ¼± Herunder ¾¾ ¾ ± ses målinger for braintumor kørslerne. ¾ ¼¾ ¼ ½ ± 1 ½ ¾ ½ ¾ ¾½ ± 2 3 ½½

134 ½¾¾ ½ ½ ¾±½¾ ½ ¾¾ ½¾¾ ½¾ ½ ½ ±½ Ð ºÅÐ Ò Ö ¾ ½ ¾ ¾ ½ ½ ±¾ ¼½½ ½ ½ ¾¼ ½ ± ¼ ½¼ ¾ ¼ ¾ ¾ ± ¾¼ ½ ½ ¾ ¼ ± ¾ ¼ ½ ± ¼ ¾ ¾ ¾ ¾ ¼¾ ± 10 ¼¼ ¾ ¾ ¼ ¼ ¼ ¾± ¼ 11 ¼ ¼ ¾ ½ ± 12 ¾¼ ½ ½¼ ¼ ± ¾ 13 ¼¾ ¾ ¼ ¼ ½ ± 14 ¼¾ ¾¾ ¾ ± 15 ¼¼¾ ¾¼¾ ¼¾¼ ± ¼ 16 ¼¾ ¾ ¾ ¾ ¾ ± ÝÒ Ñ ¹ ÓÙ Ð 19 ÈË Ñ Ò Ñ Ñ ËÈ ³ ÖÈÖÓ ÒØÇÔØ Ñ Ð ½¾ ¾¼½ ½ ¾¼¼ ¾¾ ¾ ½ ±½ 22 ¾½ ¼ ¾ ¼½ ½½ ¼ ±¾ 23 ¾ ¼ ¾ ¾± 24 ½ ½ ½ ½ ± 25 ½ ½¼ ½ ¾ ¼± 26 ½½ ½ ½½ ½ ¼± 27 ½¾ ¾ ¾ ±½¾ ½ ¾ ½ ¾ ±½ 29 ¾ ½ ½ ¾ ½ ±¾ 30 ¼ ½ ½ ¼ ½ ¼ ½¾ ¼¾± ¼ ÝÒ Ñ ¹Ë Ò Ð 33 ÈË Ñ Ò Ñ Ñ ËÈ ³ ÖÈÖÓ ÒØÇÔØ Ñ Ð ½¾ ½ ¼ ±½ 36 ¾½ ¼ ¼ ½ ½ ±¾ 37 ½¼½¼¾¼ ½¼¾¼ ¾ ½ ± 38 ¼ ¼¼ ½ ¼± 39 ¾ ± 40 ½ ½ ½ ¼½± 41 ½¾ ¾ ¾ ¾ ¼¼ ½ ±½¾ ½ ¾ ½ ±½ 43 ¾ ¾ ¾½ ¼¾½ ¼½ ¼ ±¾ 44 ¼ ½ ¼ ½ ½¾ ½ ± ¼ ËØ Ø ¹Ë Ò Ð 47 ÈË Ñ Ò Ñ Ñ ËÈ ³ ÖÈÖÓ ÒØÇÔØ Ñ Ð ½¾ ½½ ½ ½½ ¼ ¼ ¼ ±½ 50 ¾½ ½ ½ ½ ±¾ 51 ½¼½½¾¾ ½½¾¾ ¾ ½ ¾± 52 ¾½ ¾ ¾½ ¾ ½ ¾ ¼ ± 53 ½ ½ ½ ¾ ± 54 ½ ¼ ½ ¼ ¾ ¼± 55 ½¾ ½¼ ½ ¼¼ ±½¾ ½ ¾ ¾¾ ½¾ ¾¾ ½½ ¾¾ ¾ ±½ 57 ¾ ½ ¼ ¼½ ¾ ±¾ 58 ¼½½ ½ ½± ¼ 59 ½¾ ¾ ¾ ¼ ± ½½ ¾ ¾¾ ¾ ¼ ± ¾ ¼ ¾ ± ¾ 69

135 ½¾ ¼½¾ ½¼ ¾ ± ½¾ ½¾ ½ ¾ ± ¼ Ö ÒØÙÑÓÖ ½ ± ¾ ¼ ¾ ¼ ± ¾ ¼½½ ¼½½ ± ÝÒ Ñ ¹ ÓÙ Ð ¹Ê ¾ ¾ ± ÈË Ñ Ò Ñ Ñ ËÈ ³ ÖÈÖÓ ÒØÇÔØ Ñ Ð ¾ ¾ ½ ½ ¼± ¼ ¾ ¾ ¼ ¾ ½ ± ½¾ ¾ ½ ¼ ¼ ¼ ½±½ ¾½ ½ ½ ¼ ±¾ ¾¼ ¼ ¾ ¾ ± ¾ ½ ½ ¾¾± ¼ ½ ¾ ± 79 ½ ½ ± 80 ½¾ ½ ¾¾ ½ ±½¾ ½ ½ ¾ ±½ 82 ¾ ¾ ¾ ½ ¼±¾ 83 ¼ ½½½ ¾ ½½ ¾ ¾½½ ± ¼ 84 ½ ¼± 85 ¾ ½ ± ¾ 86 ¾ ½ ¼¾ ½ ¼ ¾± 87 ½ ¾ ½ ¾ ½ ¼ ± 88 ¼ ¾ ¼ ¼ ± ¼ 89 ¾ ± 90 ¾ ½ ½ ½ ± ¾ 91 ½¾ ¼ ¾ ¼ ¼½¼ ½ ± 92 ¾ ¾ ½ ± 93 ¼ ¾ ¾ ½½± ¼ 94 ¼ ¼ ¼ ± ÐÐ Ð ½ ËÈ 97 ÈË Ñ Ò Ñ Ñ ËÈ ³ ÖÈÖÓ ÒØÇÔØ Ñ Ð ½¾ ¾¾ ½ ¾¾ ¼ ¼ ¼ ±½ 100 ¾½ ¾ ¾ ½ ¾ ±¾ 101 ¾ ¾¾ ½ ¼ ± 102 ¾ ½ ½ ± 103 ½ ½ ¼¾± 104 ¼ ¼ ¼ ¼ ½ ¾ ± 105 ¾ ¼ ¼ ¼ ¾ ¾ ± ¾ ¾ ¾ ¾¼ ± 107 ¾¾½ ¾ ¾½ ¾ ± 108 ½¼ ¾ ¼ ¼ ¼ ¼±½¼ 109 ½½ ¾ ½ ±½½ 110 ½¾ ¾ ¼ ¾ ±½¾ 111 ½ ½¾¾ ¾¾½¾¾ ½ ½±½ 112 ½ ½¼¾¾ ½¼ ½±½ 113 ½ ½ ½ ¾ ½ ½ ¼ ±½ 114 ½ ¾¾ ¼ ¼ ±½ 115 ¾½ ¾ ¼ ½½¾ ¼ ½ ¾ ½ ± ¾ 116 ½½ ½ ½¼ ½ ± ÐÐ Ð ½¾ËÈ 120 ÈË Ñ Ò Ñ Ñ ËÈ ³ ÖÈÖÓ ÒØÇÔØ Ñ Ð ¾ ½ ½ ± ¼ ¾ ¼ ½½

136 ½¾ ¾¾ ±½¾ Ò ÐÐ Ð ½¾¾ ¼½ ¼ ½½ ±½¾ÌÓ ÐÐ Ð Ð ºÅÐ Ò Ö ÐÐ Ð ËÈ ÈË Ñ Ò Ñ Ñ ËÈ ³ ÖÈÖÓ ÒØÇÔØ Ñ Ð ¼ ¼ ¼ ¼ ½ ¾ ± ½¾¾ ¼½ ¼ ½½ ±½¾ 130 ½ ½ ¾ ½¼ ¾ ½ ±½ º ¾ ½¾ ¾½ ¾½ ½ ¾ ±¾ À Ø ÕÙ Ø ÓÒ À Ø ÐÐ ÈË Ñ Ò Ñ Ñ ËÔ ÙÔÈÖÓ ÒØÇÔØ Ñ Ð Ê ½¼ ¾ ¼ ¾¼ ¼± Herunder ½½ ¼ ¼ ¼ ± ses målinger for heat equation kørslerne. ½¾ ½ ½ ¼ ½¾ ½ ½ ± ¾ ½ ¾ ½½ ¼¼¼½¼¼ ¼¼±½ ¼ ¼±¾ 1 ½ ¼ ¼¼ ± 2 ½ ½ ¾ ½½½ ¾ ¼ ¼±½¾ 3 ¾½½ ½ ½ ¼ ¼ ¼ ¾ ±½ À Ø ÐÐ 6 ÈË Ñ Ò Ñ Ñ ËÔ ÙÔÈÖÓ ÒØÇÔØ Ñ Ð 7 Ê ¾½ ½ ¾ ½ ½ 8 ¾½ ½ ¾ ½ ½ ½ ¼¼¼½¼¼ ¼¼±½ 9 ½¾ ½½ ¾ ¼ ±¾ 10 ½ ¾¼ ¾ ¾¼ ¼ ¼± 11 ¾ ¾ ¾ ¼ ± ½ 5 ¾ 12 ½¾¼

137 Ä ØØ Ö ØÙÖ [1] Gordon E. Moore. Cramming more components onto integrated circuits. Rapport, Electronics, Intel Museum, april [2] Hentet 13. feb 2008 fra s_law. [3] Hentet 13. feb 2008 fra [4] Maurice V. Wilkes. The memory wall and the cmos end-point. SIGARCH Comput. Archit. News, 23(4):4-6, [5] Wm. A. Wulf og Sally A. McKee. Hitting the memory wall: Implications of the obvious. Computer Architecture News, 23(1):20-24, [6] IBM. Cell broadband engine - programming handbook v Rapport, [7] Hentet 13. feb 2008 fra /library/pa-cellperf/#sec2. [8] Hentet 1. apr 2008 fra [9] Hentet 1. apr 2008 fra [10] Hentet 05. mar 2008 fra /library/pa-expert9/. [11] Hentet 1. apr 2008 fra [12] Hentet 7. okt 2008 fra [13] IBM. Accelerated library framework for cell broadband engine programmers guide and api reference. Rapport, [14] J. P. Perez, P. Bellens, R. M. Badia og J. Labarta. Cellss: making it easier to program the cell broadband engine processor. IBM J. Res. Dev., 51(5): , [15] Gulfem Isiklar. The architecture of earth simulator. Rapport, Department of Computer Science, Bogazici University, [16] David E. Culler, Richard M. Karp, David A. Patterson, Abhijit Sahay, Klaus E. Schauser, Eunice Santos, Ramesh Subramonian og Thorsten von Eicken. LogP: ½¾½ Towards a realistic model of parallel computation. Rapport, [17] Chris Holt, Mark Heinrich, Jaswinder Pal Singh, Edward Rothberg og John Hennessy. The effects of latency, occupancy, and bandwidth in distributed shared memory multiprocessors. Rapport CSL-TR , 1995.

138 Ä ØØ Ö ØÙÖ [18] Richard P. Martin, Amin Vahdat, David E. Culler og Thomas E. Anderson. Effects of communication latency, overhead, and bandwidth in a cluster architecture. Rapport, [19] Brian Vinter John Markus Bjørndalen Otto J. Anshus og Tore Larsen. The impact on latency and bandwidth for a distributed shared memory system using a gigabit network supporting the virtual interface architecture. Rapport, [20] Hentet 7. okt 2008 fra [21] Brian Vinter. Distributed shared memory - a survey of paradigms and concepts in distributed shared memory research. Rapport, Department of Computer Science, Tromsø University, maj [22] Alan Judge, Paddy A. Nixon, Vinny J. Cahill, Brendan Tangney og Stefan Weber. Overview of distributed shared memory. Rapport TCD-CS , Department of Computer Science, Trinity College, oktober [23] George Coulouris, Jean Dollimore og Tim Kindberg. Distributed Systems - Concepts and Design. Addison Wesley, [24] Michael Stumm og Songnian Zhou. Algortihms implementing distributed shared memory. IEEE Computer, 23(5):54-64, [25] Hentet 2. apr 2008 fra [26] Hentet 2. apr 2008 fra [27] Paulo Guedes og Miguel Castro. Distributed Shared Object Memory. I Proc. 4th Wshop. on Workstation Operating Systems (WWOS-IV), Napa, CA (USA), IEEE Computer Society Press. [28] Daniel Lenoski, James Laudon, Kourosh Gharachorloo, Anoop Gupta og John Hennessy. The directory-based cache coherence protocol for the dash multiprocessor. SIGARCH Comput. Archit. News, 18(3a): , [29] Leslie Lamport. How to make a multiprocessor computer that correctly executes multiprocess programs. IEEE Trans. Computers, 28(9): , [30] R. J. Lipton og J. S. Sandberg. PRAM: A scalable shared memory. Rapport , Department of Computer Science, Princeton University, sep [31] Mustaque Ahamad, Ranjit John, Prince Kohli og Gil Neiger. Causal memory meets the consistency and performance needs of distributed applications! I EW 6: Proceedings of the 6th workshop on ACM SIGOPS European workshop, side 45-50, New York, NY, USA, ACM. [32] Sarita V. Adve og Mark D. Hill. Weak ordering a new definition. SIGARCH Comput. Archit. News, 18(3a):2-14, ½¾¾ [33] Kourosh Gharachorloo, Daniel Lenoski, James Laudon, Phillip Gibbons, Anoop Gupta og John Hennessy. Memory consistency and event ordering in scalable shared-memory multiprocessors. I In Proceedings of the 17th Annual International Symposium on Computer Architecture, side 15-26, 1990.

139 Ä ØØ Ö ØÙÖ [34] Brian N. Bershad og Matthew J. Zekauskas. Midway: Shared memory parallel programming with entry consistency for distributed memory multiprocessors. Rapport CMU-CS , Pittsburgh, PA (USA), [35] Nicholas Carriero og David Gelernter. Linda in context. Commun. ACM, 32(4): , [36] Hentet 12. mar 2008 fra powerarchitecture?entry=ibomb_alf_sdk30_5. [37] Hentet 7. okt 2008 fra [38] Hentet 1. apr 2008 fra [39] Matthew J. Zekauskas, Wayne A. Sawdon og Brian N. Bershad. Software write detection for a distributed shared memory. I In Proceedings of the First Symposium on Operating Systems Design and Implementation, side , [40] Antony L. Hosking, J. Eliot og B. Moss. Protection traps and alternatives for memory management of an object-oriented language., [41] Hentet 09. mar 2008 fra [42] Honghui Lu, Hya Dwarkadas, Alan L. Cox og Willy Zwaenepoel. Message passing versus distributed shared memory on networks of workstations. I In Proceedings SuperComputing 95, [43] Ronald G. Minnich og David J. Farber. The Mether system: Distributed shared memory for SunOS 4.0. side 51-60, Summer [44] John B. Carter. Design of the Munin distributed shared memory system. Journal of Parallel and Distributed Computing, 29(2): , [45] J. K. Bennett, J. B. Carter og W. Zwaenepoel. Munin: Distributed shared memory based on type-specific memory coherence. I Proc. of the Second ACM SIGPLAN Symp. on Principles and Practice of Parallel Programming (PPOPP 90), side , [46] Matthew J. ; Sawdon Wayne A. Bershad Brian N. ; Zekauskas. The midway distributed shared memory system. Rapport, Pittsburgh, PA (USA), [47] Parta Dasgupta Richard J. LeBlanc Mustaque Ahmad Muthusamy Chelliah og Mark Pearson. Shared memory programming in a distributed system. Rapport, Atlanta, Georgia, (USA), [48] R.J. Jr. Ahamad M. Ramachandran U. Dasgupta P. LeBlanc. The clouds distributed operating system. Rapport , Arizona, AZ, (USA), [49] Hentet 7. okt 2008 fra [50] C. A. R. Hoare. Communicating sequential processes. Communications of the ACM, 21: , [51] Hentet 7. okt 2008 fra [52] Hentet 30. okt 2008 fra bab/classes/ist341/ch02.ppt.½¾

140 Ä ØØ Ö ØÙÖ [53] Hentet 1. okt 2008 fra ½¾

141 Ð Ê ØØ Ð Ö Figur 1.3 side 5. Den røde linie mellem IOIF1 og SPE4, skal gå fra IOIF1 s udgående kanal til SPE4 s indgående kanal. Teksten på y-aksen i figur 8.7 på side 90 og figur , skal være Utilization i stedet for Speedup. De Cell BE Blade vi havde til rådighed, er ikke forbundet via InfiniBand. Figur 7.2 på side 66, beskrivelsen af pakke 5 og 6 er byttet om.