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.