Triwaq

VORtech Computing

Experts in Technisch Rekenwerk Postbus 260 2600 AG DELFT

MEMO Datum Auteur(s) Onderwerp

EV/M08.093 30 december 2008 Edwin Vollebregt

tel. 015-285 0125 fax. 015-285 0126 [email protected]

Onderzoek van cache-eecten in de performance van Waqua/Triwaq

Documentinformatie Versie Auteur

Datum

Opmerkingen

0.8 EV Bestandslokatie:

30-12-2008 Eerste verslag van bevindingen /v3/E05q bo simona/c85904-perform-cache/report

Review JD

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 ver jning 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

VORtech Computing Memo EV/M08.093

versie 0.8, 30 december 2008

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 m349839 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 sequentiele sommen worden onderzocht. Er zijn twee nieuwe keywords gede nieerd voor de simulatie-invoer le: 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-invoer le, en

2



2. 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 gespeci ceerd,

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 roosterpun-

ten worden verwacht als de gebruiker geen grootte voor een box speci ceert,

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 c84131. 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.

3



3 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. 2.800 sec/Ggpstp voor het maasdemo-model via 19.400 voor een subdomein van het czuno.0kalman-model tot 2.222.222 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.

4



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 gra eken 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 speci eke 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 vol-

ledig in de weg.

5



Rekentijd per gridpunt per tijdstap voor CSM8, Triwaq, 2 lagen 5200

Time [sec/Ggpstp]

5150

"niet vastgepind"

5100 5050 5000 4950

Vortech25 − AMD Opteron 2216 2.4GHz

4900 200

204

208

212

216

220

216

220

Time [sec/Ggpstp]

4100

3900

3700 Vortech32 − Intel Xeon E5420 2.5GHz 3500 200

Figuur 1:

204

208

212 MMAX

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 5700

Time [sec/Ggpstp]

5600 5500

"niet vastgepind"

5400 5300 5200 5100


5000 4900 176

184

192

200

208

216

176

184

192

200 NMAX

208

216

4400 Time [sec/Ggpstp]

4300 4200 4100 4000 3900 3800 3700

Figuur 2:


NMAX. Eerste serie experimenten, zonder harde mapping van berekeningen naar cores.

6



Om de beloofde performance-winst van het taskset-commando te kunnen bereiken moet daarom een ver jnd 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/0+.... 2. 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 gespeci ceerd. 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%).

7



Rekentijd per gridpunt per tijdstap voor CSM8−model (Triwaq, 2 lagen)

Time [sec/Ggpstp]

5300 5200 "vastgepind"


5100 5000 4900 200

204

208

212

216

220

212 MMAX

216

220

Time [sec/Ggpstp]

4150 Vortech32 − Intel Xeon E5420 2.5GHz 4100

4050

4000 200

Figuur 3:

204

208


MMAX. Rekentijd per gridpunt per tijdstap voor CSM8−model (Triwaq, 2 lagen) 5400 "vastgepind"

Time [sec/Ggpstp]

5300 5200 5100 5000


4900 176

184

192

200

208

216

208

216

Time [sec/Ggpstp]

4200 4150 4100 4050 Vortech32 − Intel Xeon E5420 2.5GHz

4000 176

Figuur 4: NMAX.

184

192

200 NMAX


8



9

Rekentijd per gridpunt per tijdstap voor Zeedelta−WQ−model

Time [sec/Ggpstp]

6600 Vortech25 − AMD Opteron 2216 2.4GHz 6200

5800

5400 502

504

506

508

510

512

514

516

518

514

516

518

Time [sec/Ggpstp]

4400 Vortech32 − Intel Xeon E5420 2.5GHz

4300

4200 502

Figuur 5:

504

506

508

510 MMAX

512

Geschaalde rekentijden voor het Zeedelta-model (Waqua) bij variatie van MMAX.

Rekentijd per gridpunt per tijdstap voor Zeedelta−WQ−model

Time [sec/Ggpstp]

5700 5600


5500 5400 5300 1544

1552

1560

1568

1576

1568

1576

Time [sec/Ggpstp]

4400 4350

Vortech32 − Intel Xeon E5420 2.5GHz

4300 4250 4200 4150 4100

Figuur 6:

1544

1552

1560 NMAX

Geschaalde rekentijden voor het Zeedelta-model (Waqua) bij variatie van NMAX.



10

Rekentijd per gridpunt per tijdstap voor Maas−model

Time [sec/Ggpstp]

3350 3300 3250 3200 Vortech25 − AMD Opteron 2216 2.4GHz 3150

188

192

196

200

196

200

Time [sec/Ggpstp]

2780

2760

2740

2720 Vortech32 − Intel Xeon E5420 2.5GHz 2700

188

192 MMAX

Figuur 7:

Geschaalde rekentijden voor het Maas-model (Waqua) bij variatie van MMAX.

Rekentijd per gridpunt per tijdstap voor Maas−model 3450

Time [sec/Ggpstp]

3400 3350


3300 3250 3200 3150 3100 3050

6008

6016

6024

6032

6040

6048

6032

6040

6048

Time [sec/Ggpstp]

2800

2750

2700

2650

Vortech32 − Intel Xeon E5420 2.5GHz 6008

Figuur 8:

6016

6024 NMAX

Geschaalde rekentijden voor het Maas-model (Waqua) bij variatie van NMAX.



11

0.1 subdomein 1 (rivieren) subdomein 2 (zeegebied) 0.09 Simona2007−01

rekentijd per roosterpunt per tijdstap [µ s]

0.08

Zeedelta, Waqua Wasuxc, 2e halve stap

0.07

0.06

0.05

0.04

0.03

0.02

0.01

0

Figuur 9:

0

32

64

96 128 160 afmeting nmax modulo 256

192

224

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 simona2007-01, 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

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-invoer le. 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 1997. By order of RIKZ. [2] E.A.H. Vollebregt. Parallel Software Development PhD thesis, Delft University of Technology, 1997.

Techniques for Shallow Water Models.



13

[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 2004. [4] E.A.H. Vollebregt. Onderzoek naar de performance van WAQUA/TRIWAQ op multi-core Opteron-systemen. Memo EV/M07.061, VORtech, Oktober 2007. [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.

Triwaq

Recommend Documents