VORtech Computing. Experts in Technisch Rekenwerk MEMO. Onderzoek van cache-eecten in de performance van Waqua/Triwaq

Transcriptie

1 Experts in Technisch Rekenwerk MEMO EV/M Datum 30 december 2008 Auteur(s) Onderwerp Edwin Vollebregt Postbus AG DELFT tel fax Onderzoek van cache-eecten in de performance van Waqua/Triwaq Documentinformatie Versie Auteur Datum Opmerkingen Review 0.8 EV Eerste verslag van bevindingen JD Bestandslokatie: /v3/e05q bo simona/c85904-perform-cache/report 1 Inleiding De gangbare procedure voor het optimaliseren van de performance van parallel Waqua/Triwaq op Linux-clusters is als volgt: 1. beginnen met een initiele roosteropdeling, uitvoeren van een run ten behoeve van performance-data; 2. inlezen van de rekentijden per subdomein in het hulpprogramma Visipart; 3. handmatig verschuiven van subdomeingrenzen: kleiner maken van subdomeinen die te lang rekenen, vergroten van subdomeinen die minder tijd vergen; 4. terug naar stap 1, itereren totdat er niet voldoende winst meer wordt behaald. In stap 3 spelen schattingen van de rekentijden per subdomein een cruciale rol: je hebt vuistregels nodig om te bepalen hoe ver je subdomeingrenzen moet verschuiven voor een gewenst eect op de rekentijd. Een simpele vuistregel is dat de rekentijd voor een subdomein proportioneel is met het aantal roosterpunten in dat subdomein. Deze regel blijkt niet goed te voldoen. Daarom is in Visipart een verjning geprogrammeerd. Visipart bepaalt de rekensnelheid per subdomein als zijnde het aantal roosterpunten dat per tijdseenheid wordt verwerkt. In de zo bepaalde rekensnelheid komen inke variaties voor, tot een factor twee of meer afhankelijk van de vorm en grootte per subdomein. De aanname die vervolgens in Visipart wordt gemaakt is dat kleine veranderingen in de subdomeingrenzen beperkte invloed zullen hebben op de snelheid per subdomein. De

2 Memo EV/M versie 0.8, 30 december vuistregel die hieruit volgt is dat de rekentijd per (nieuw) subdomein gelijk is aan het aantal roosterpunten gedeeld door de snelheid van het (oude) subdomein. De vuistregel die in Visipart wordt gebruikt blijkt in praktijk niet goed te voldoen. De rekensnelheid per subdomein blijkt vooralsnog vrij onvoorspelbaar te zijn. Daardoor is er momenteel geen goede methode voor het optimaliseren van roosteropdelingen. Door deze onvoorspelbaarheid van de performance blijft naar schatting 10-30% van de capaciteit van een parallelle computer of cluster onbenut. De grilligheid van de rekentijd per subdomein heeft te maken met het precieze gedrag van moderne processoren, met name met de tijd die nodig is voor het ophalen van waardes uit het main memory. Als de tijd voor het ophalen van data constant zou zijn dan zou de rekentijd praktisch evenredig met het aantal bewerkingen zijn en was de performance voorspelbaar geweest. In praktijk is de geheugentoegangstijd verre van constant, en spelen zogenaamde \cache-eecten" een belangrijke rol. Zulke eecten zijn al gerapporteerd voor de eerste versies van parallel Triwaq [1, 2]. Meer recent zijn ze onder anderen opgedoken bij het optimaliseren van roosteropdelingen voor het ScalWest-model [3, 5], in opdracht van WLH Borgerhout. Recente experimenten op AMD Opteron-processoren hebben laten zien dat het vermijden van machten van 2 in de roosterafmetingen MMAX en NMAX een betere performance geeft ([4], in opdracht van het Havenbedrijf Rotterdam). Naar aanleiding hiervan heeft VORtech voorgesteld om te onderzoeken of dit ook geldt voor Intel Xeon processoren. Vervolgens zouden MMAX en NMAX automatisch door Waqpre en Coppre moeten worden verhoogd zodat ongunstige waardes worden omzeild. Dit is gemeld in het kader van service call m van het SIMONA beheer en onderhoud. In september 2008 heeft Edwin Spee hiervoor change c85904 aangevraagd. In dit memo doen we verslag van het werk dat is uitgevoerd voor deze change. 2 Aanpassing van MMAX en NMAX in Waqpre Het eerste wat we hebben gedaan in deze change is het uitbreiden van Waqpre. Met de uitbreiding is het mogelijk gemaakt om de groottes van arrays precies in te stellen. Met deze aanpassing kan de invloed van arraygroottes op de performance door middel van sequenti ele sommen worden onderzocht. Er zijn twee nieuwe keywords gedenieerd voor de simulatie-invoerle: MESH - GRID - AREA - ARRSIZM en ARRSIZN. Deze keywords worden tegelijk ingelezen met de roosterafmetingen MMAX en NMAX. De waardes moeten groter of gelijk zijn aan de waardes van MMAX en NMAX. Als ze niet worden opgegeven dan worden MMAX en NMAX als defaults gehanteerd, of zou Waqpre kunnen kiezen voor iets grotere waardes voor het vermijden van machten van twee. In Waqpre worden nu twee verschillende roosterafmetingen onderscheiden: 1. mmaxi en nmaxi, de waardes die de gebruiker heeft gehanteerd in de simulatie-invoerle, en

3 Memo EV/M versie 0.8, 30 december mmaxa en nmaxa, de waardes die Waqpre en Waqpro hanteren voor de groottes van arrays. In heel Waqpro en op de meeste plaatsen in Waqpre nemen mmaxa en nmaxa de rollen over van de oude mmax en nmax. Daarom worden de oude namen mmax en nmax als synoniemen voor mmaxa en nmaxa gebruikt en worden alleen mmaxi en nmaxi als nieuwe variabelen gezien. Deze variabelen worden opgeslagen op de SDS-le in array MESH IDIMEN (posities 44 en 45). Op een aantal plaatsen in Waqpre zijn ook de waardes mmaxi en nmaxi van belang: Bij het bepalen van de computational grid enclosure, indien die niet door de gebruiker is gespeciceerd, bij het inlezen van een rgf-le, waarin op de grootte van het rooster wordt gecontroleerd, bij het inlezen van velden in SIMONA box-formaat, waar waardes voor alle roosterpunten worden verwacht als de gebruiker geen grootte voor een box speciceert, bij het controleren of een restart is toegestaan, inclusief vergelijken van de oude en nieuwe lgrid-tabellen, bij het kopieren van waardes in geval READ FROM wordt gebruikt, waar alleen waardes voor 1..mmaxi en 1..nmaxi kunnen/moeten worden gekopieerd. De aanpassingen zijn getest door mmaxa en nmaxa default iets groter te kiezen dan de opgegeven mmaxi en nmaxi en de hele testbank te draaien. In de testbank traden geen verschillen in berekende grootheden op, maar kwamen wel verschillen in bodemwrijving, viscositeit, turbulentie en schotjes voor die aan het landpunt (iadlnd) zijn gerelateerd. In de testbank kwam geen Triwaq-som voor waarin READ FROM werd gebruikt. Daardoor werd het gebruik van ARRSIZM en ARRSIZN in eerste instantie niet volledig getest. De test \read from" is aangepast van een Waqua- naar een Triwaq-berekening, waarbij de uitgangs SDS-le wel met Waqua is aangemaakt. Verder is de test \inteullag" aangepast zodat ook hierin een READ FROM wordt gebruikt. In dit geval wordt bij de READ FROM ook de laagverdeling iets aangepast en wordt het turbulentiemodel aangezet. Deze testen zijn eerder uitgevoerd in het kader van change c Een mogelijke uitbreiding van de opties ARRSIZM en ARRSIZN is om ook waardes kleiner dan MMAX en NMAX toe te staan, wanneer een gedeelte van het rooster niet wordt gebruikt, dus wanneer en voor zover de computational grid enclosure kleinere waardes dan MMAX/NMAX toestaat. Dat heeft als voordeel dat er in Waqpro minder geheugen nodig is omdat er dan met kleinere mmaxa/nmaxa wordt gewerkt. Let wel dat dit alleen voor sequentiele berekeningen geldt. In geval van parallel rekenen en domein decompositie wordt de overbodige ruimte uit mmaxa/nmaxa sowieso al gestript.

4 Memo EV/M versie 0.8, 30 december Rapportage van rekentijden in Waqpro In Waqpro zijn enkele aanpassingen gemaakt waarmee aanvullende informatie over de rekentijden wordt gerapporteerd. Voor de grootste onderdelen van de berekening worden nu ook percentages van de totale tijd afgedrukt. De totale rekentijd wordt omgerekend naar geschaalde grootheden. Met name de tweede wijzigingen is voor de huidige werkzaamheden relevant. Het idee is dat de rekentijd voor een berekening op zich niet direct veel zegt, en dat bepaalde geschaalde grootheden beter vergelijkbaar zijn. Hierbij is met name de rekentijd per roosterpunt per tijdstap van belang. We introduceren de \roosterpunt-tijdstap" (gpstp) als eenheid van berekening, analoog aan de \op" die in de lineaire algebra vaak wordt gebruikt. Het aantal gpstp's van een berekening wordt berekend met #gpstp = numstp numgp kmax (1 + nmode) (1) Hierin is numstp het aantal hele tijdstappen dat is uitgevoerd, numgp het aantal interne punten van het rooster, kmax het aantal lagen en nmode het aantal modes indien het RRSQRT Kalman lter wordt gebruikt (ikalmn.eq.2). Aan het einde van de berekening worden twee getallen afgedrukt: de totale gebruikte cputijd per miljard gpstp's [sec/ggpstp] en de daarmee corresponderende rekensnelheid in [Kgpstp/sec]. De eenheden zijn zodanig gekozen dat de resulterende getallen prettig leesbaar zijn: voldoende resolutie bij twee cijfers achter de komma. Merk op dat de gerapporteerde tijd ook de tijd voor initialisaties omvat en dat de cpu-tijd in plaats van de wall-clock tijd wordt gerapporteerd. Met de cpu-tijd levert de uitvoer in parallelle berekeningen nuttige informatie per subdomein op. Het gebruik van de wall-clock tijd zou relevant zijn wanneer de rekensnelheid voor alle subdomeinen samen wordt gerapporteerd. In de SIMONA testbank levert de nieuwe uitvoer voor verschillende testmodellen heel verschillende uitvoer op. De waardes varieren van ca sec/ggpstp voor het maasdemo-model via voor een subdomein van het czuno.0kalman-model tot voor een subdomein van ddh test 10a. In veel gevallen worden hoge waardes veroorzaakt door een klein aantal roosterpunten in het model of een korte simulatieduur. In andere gevallen, met langere simulaties voor grotere modellen, is er nog geen duidelijke reden voor de grotere rekentijd per roosterpunt bepaald. Het zou nuttig zijn om dit verder uit te zoeken omdat hiermee berekeningen kunnen worden opgespoord waaraan onnodig veel tijd wordt gespendeerd. 4 Performance-eecten van multi-core PC's Vervolgens zijn we met de echte performance-testen voor het onderzoeken van cache-eecten gestart. Hierbij is eerst een moeilijkheid met betrekking tot multi-core PC's opgelost.

5 Memo EV/M versie 0.8, 30 december In de testen voor het Havenbedrijf is al een grote variatie in de rekentijden voor identieke sommen geobserveerd, zie [4]. Deze hebben te maken met de tijd voor geheugentoegang, en met de Linux kernel-optie numa=on. Als de optie numa=on wordt gebruikt dan verdeelt Linux het geheugen over de verschillende cores, zodanig dat het geheugen per core voor die core sneller toegankelijk is dan het andere geheugen of dan dit geheugen voor de andere cores. Dit levert performancewinst op. Alleen kunnen rekenprocessen door de Linux kernel naar andere cores worden verhuisd, bijvoorbeeld als de kernel merkt dat de ene core veel zwaarder is belast dan een andere. Het blijkt dat het geheugen van zo'n rekenproces niet mee-verhuist, zodat berekeningen van een rekenproces na het verhuizen tot 20% langzamer gaan. Dit eect van multi-core PC's wordt gellustreerd door onze eerste performance-testen voor het CSM8-model (Triwaq-berekening, twee lagen), zie Figuren 1 en 2. In deze guren worden de geschaalde rekentijden getoond voor variatie van MMAX (ARRSIZM) in Figuur 1 en van NMAX (ARRSIZN) in Figuur 2. Per guur worden aparte graeken getoond voor de Linux PC \vortech25", met twee dual core AMD Opteron processoren en voor de Linux PC \vortech32", met twee quad core Intel Xeon processoren. In de guren wordt met de blauwe lijnen de gemiddelde (geschaalde) rekentijd van drie identieke runs getoond als functie van de parameter MMAX of NMAX. De rode lijnen laten de variatie in de gemeten rekentijden zien. Deze lopen van het minimum naar het maximum van de tijden per drie identieke runs. De guren 1 en 2 laten een grote variatie in de metingen zien. Deze is groter voor de machine met Xeon processoren dan voor de AMD Opteron-machine. In beide gevallen kan echter worden geconcludeerd dat de variatie tussen identieke runs van dezelfde orde van grootte is als de variatie in tijden voor runs met verschillende MMAX of NMAX. Op basis van deze experimenten is het dus moeilijk om echte eecten van variatie in MMAX en NMAX te herkennen in de metingen. De grote variatie in rekentijden voor identieke runs kan worden tegengegaan met behulp van het Linux taskset-commando. Met dit commando kunnen rekenprocessen hard op een specieke core worden gemapped c.q. vastgepind. Het resultaat hiervan voor het CSM8-model wordt getoond in de guren 3 en 4. Enerzijds is te zien dat de variatie in rekentijden sterk is gereduceerd, anderzijds is de benodigde tijd consequent aan de lage kant van de range van tijden uit guren 1 en 2. Het taskset-commando is voor de huidige testen op een ad-hoc manier in SIMONA verwerkt: alle sequentiele rekenprocessen die via de routine RunApplic van genproc.pm worden opgestart worden hard op core 3 (de vierde core) van de gebruikte machine gemapped. Dat heeft een aantal duidelijke beperkingen: Als de gebruikte machine minder dan vier cores bevat dan geeft taskset een foutmelding en wordt het programma niet opgestart; Als er meerdere SIMONA-programma's tegelijk worden opgestart zitten ze elkaar volledig in de weg.

6 Memo EV/M versie 0.8, 30 december Rekentijd per gridpunt per tijdstap voor CSM8, Triwaq, 2 lagen "niet vastgepind" MMAX Figuur 1: Geschaalde rekentijden voor het CSM8-model (Triwaq, 2 lagen) bij variatie van MMAX. Eerste serie experimenten, zonder harde mapping van berekeningen naar cores Rekentijd per gridpunt per tijdstap voor CSM8, Triwaq, 2 lagen "niet vastgepind" NMAX Figuur 2: Geschaalde rekentijden voor het CSM8-model (Triwaq, 2 lagen) bij variatie van NMAX. Eerste serie experimenten, zonder harde mapping van berekeningen naar cores.

7 Memo EV/M versie 0.8, 30 december Om de beloofde performance-winst van het taskset-commando te kunnen bereiken moet daarom een verjnd schema worden uitgewerkt. Daarbij is er een duidelijk onderscheid tussen een lokale PC waarop een som wordt opgestart, en andere PC's die voor een parallelle of domein decompositie berekening worden gebruikt. Op de eerste PC kan een Perl-procedure opvragen hoeveel cores de machine heeft, welke Waqpro-processen er al draaien en welke cores daarbij worden gebruikt. Van de andere PC's kan deze informatie niet worden opgevraagd. Voor het kiezen van cores voor parallelle berekeningen zien we de volgende mogelijkheden: 1. Op clusters waar een batch scheduling systeem wordt gebruikt kunnen de cores van een run uit de toegewezen hosts worden afgeleid. Bij gebruik van PBS gaat dit via de variabele exec host met als waarde bijvoorbeeld wlh23/1+wlh23/ Op andere clusters zou het eerste Waqpro-proces per machine op core 0 kunnen worden gemapped, het tweede op core 1, enz. Zolang er niet meer subdomeinen zijn dan cores en er slechts een parallelle run tegelijk wordt uitgevoerd hoeft hiervoor niets extras te worden gedaan. De gebruiker zou via een argument -exclusive yes kunnen opgeven dat dit het geval is en dat taskset daarom mag worden gebruikt. 3. Als er meer subdomeinen voorkomen dan cores dan moet het aantal cores per machine worden opgegeven. Dit kan via de hostfile kunnen worden gedaan, via het ppnargument per host. 4. Als er meer parallelle runs tegelijk op dezelfde machines kunnen worden uitgevoerd dan zouden de precieze cores door de gebruiker kunnen worden gespeciceerd. Dit zou via het -hostmap argument van waqpro.pl kunnen worden gedaan, op een manier vergelijkbaar met de exec host van PBS. Dit lijkt echter omslachtig: een gebruiker kan beter PBS installeren dan gebruik maken van deze mogelijkheid. 5. Voor sequentiele berekeningen en parallelle runs op een enkele multi-core machine, die niet via PBS zijn opgestart, kan waqpro.pm uitzoeken welke cores er goed kunnen worden gebruikt. 5 Performance-eecten van arraygroottes MMAX en NMAX Tenslotte zijn de performance-eecten van de arraygroottes ARRSIZM en ARRSIZN onderzocht. Voor het CSM8-model met TRIWAQ zijn de resultaten hiervan al gepresenteerd in Figuren 3 en 4. Er zijn ook testen uitgevoerd met het Zeedelta-model met Waqua, zie Figuren 5 en 6, en met het Maas-model, zie Figuren 7 en 8. De guren laten een duidelijke variatie in de rekentijden zien als functie van de arraygroottes MMAX en NMAX. Merk op dat de schaal van de guren wel steeds verschilt; in sommige guren is de variatie in de rekentijden slechts een paar procent (Figuur 7: Maas-model, MMAX, Intel Xeon: 1.5%), in andere gevallen meer dan tien procent (Figuur 5: Zeedelta, MMAX, AMD Opteron: 24%).

8 Memo EV/M versie 0.8, 30 december Rekentijd per gridpunt per tijdstap voor CSM8 model (Triwaq, 2 lagen) "vastgepind" MMAX Figuur 3: Geschaalde rekentijden voor het CSM8-model (Triwaq, 2 lagen) bij variatie van MMAX Rekentijd per gridpunt per tijdstap voor CSM8 model (Triwaq, 2 lagen) "vastgepind" NMAX Figuur 4: Geschaalde rekentijden voor het CSM8-model (Triwaq, 2 lagen) bij variatie van NMAX.

9 Memo EV/M versie 0.8, 30 december Rekentijd per gridpunt per tijdstap voor Zeedelta WQ model MMAX Figuur 5: Geschaalde rekentijden voor het Zeedelta-model (Waqua) bij variatie van MMAX Rekentijd per gridpunt per tijdstap voor Zeedelta WQ model NMAX Figuur 6: Geschaalde rekentijden voor het Zeedelta-model (Waqua) bij variatie van NMAX.

10 Memo EV/M versie 0.8, 30 december Rekentijd per gridpunt per tijdstap voor Maas model MMAX Figuur 7: Geschaalde rekentijden voor het Maas-model (Waqua) bij variatie van MMAX Rekentijd per gridpunt per tijdstap voor Maas model NMAX Figuur 8: Geschaalde rekentijden voor het Maas-model (Waqua) bij variatie van NMAX.

11 Memo EV/M versie 0.8, 30 december rekentijd per roosterpunt per tijdstap [µ s] Simona Zeedelta, Waqua Wasuxc, 2e halve stap subdomein 1 (rivieren) subdomein 2 (zeegebied) afmeting nmax modulo 256 Figuur 9: Gemiddelde rekentijd per roosterpunt voor het oplossen van de impulsvergelijking in subroutine wasuxc, afhankelijk van de afmeting nmax per subdomein. Zeedelta-model, twee subdomeinen. Opvallend is dat het gebruik van veelvouden van vier, acht of zestien in NMAX in veel gevallen voordelig is (Figuren 6 en 8), terwijl van machten van twee juist een nadelig eect werd verwacht. Ter vergelijking toont Figuur 9 de resultaten uit het onderzoek dat is uitgevoerd voor het Havenbedrijf [4]. In deze guur is een extreem sterk cache-eect te zien, waarbij de rekentijd soms meer dan verdubbelt wanneer er een ongunstige array-afmeting wordt gebruikt. Een aantal verschillen met de huidige testen is als volgt: 1. In de huidige testen kijken we naar de totale rekentijd in plaats van de tijd voor een enkele berekening (subroutine wasuxc); 2. we werken met de nieuwste moederversie (december 2008, revisie 2427) in plaats van simona , van voor de uniformering van Waqua en Triwaq; 3. we werken met een vast domein en varieren alleen de arraygroottes mmaxa en nmaxa, in plaats van te varieren met de roosteropdeling, waarbij ook het aantal roosterpunten verandert, het aantal rijen en kolommen, etc.; 4. we hebben de arraygroottes met stapjes van een over een bescheiden range opgehoogd in plaats van grote machten van twee op te zoeken. Voor het Zeedelta-model is 1568 een 32-voud, voor het Maas-model is 6016 een 128-voud.

12 Memo EV/M versie 0.8, 30 december Een andere mogelijke verklaring voor de onduidelijk uitkomsten uit de experimenten is dat de cache-eecten misschien heel gevoelig zijn voor het precieze model dat wordt gebruikt. Ook in Figuur 9 is te zien dat de variatie voor het ene subdomein veel groter is dan voor het andere. Misschien dat dat subdomein net op de grens zit van wat er in het cache-geheugen past, en dat het daardoor zo gevoelig is voor de layout van variabelen in het geheugen. 6 Conclusies en aanbevelingen In dit memo hebben we de invloed van de arraygroottes MMAX en NMAX op de performance van Waqua/Triwaq onderzocht. Hiervoor zijn extra opties toegevoegd aan de beschrijving van een model in de simulatie-invoerle. Ook zijn er uitbreidingen gemaakt aan de rapportage over de rekentijd door het programma Waqpro, en zijn er tijdelijke aanpassingen gemaakt voor het hard toewijzen van rekenprocessen aan verschillende cores van multi-core PC's. De aanleiding voor het huidige onderzoek was een onderzoek dat is uitgevoerd voor het Havenbedrijf Rotterdam, waar er een situatie was opgemerkt waarbij de performance twee keer slechter werd bij bepaalde machten van twee. Dit fenomeen is in het huidige onderzoek niet gereproduceerd. In de huidige testen is de invloed van de arraygroottes op de performance steeds kleiner dan zo'n 5%, behalve in een enkel geval voor het CSM8-model waar de performance plotseling 24% slechter is voor een speciale waarde van MMAX. Verder is opvallend dat machten van twee in het huidige onderzoek vaak juist voordelig in plaats van nadelig zijn. Op basis van de huidige resultaten zien we geen aanleiding om bepaalde arraygroottes te kiezen of juist te vermijden in Waqpre en/of Coppre. We stellen voor dat de opties ARRSIZM en ARRSIZN wel worden opgenomen in de moederversie van de programmatuur. Dat biedt gebruikers de mogelijkheid om te experimenteren met hun model. Ook zou de optie kunnen worden uitgebreid zodat er voor de simulatie van uitsnedes uit een groter model minder geheugen is vereist. Wat ons betreft is het gewenst dat er verder onderzoek wordt gedaan naar de bepalende factoren voor de rekentijd per domein. Ook zou het gebruik van het taskset-commando verder kunnen worden uitgewerkt. Hiermee wordt de performance op Linux PC's verbeterd en beter herhaalbaar gemaakt. Referenties [1] M.R.T. Roest. Parallel TRIWAQ on a Cray T3E and on an IBM SP2. Technical Report TR97-03, VORtech, P.O.Box 260, 2600 AG Delft, the Netherlands, July By order of RIKZ. [2] E.A.H. Vollebregt. Parallel Software Development Techniques for Shallow Water Models. PhD thesis, Delft University of Technology, 1997.

13 Memo EV/M versie 0.8, 30 december [3] E.A.H. Vollebregt. Testen met het Scalwest model op het Linux-cluster van WLH. Memo EV/M04.066, versie 1.0, VORtech, Juli [4] E.A.H. Vollebregt. Onderzoek naar de performance van WAQUA/TRIWAQ op multi-core Opteron-systemen. Memo EV/M07.061, VORtech, Oktober [5] E.A.H. Vollebregt. Performance-testen van de upgrade van het linux-cluster van WLH. Memo EV/M07.009, versie 0.9, VORtech, Februari 2007.