Radiation Hydrodynamics at Scale: Comparing MPI and Asynchronous Many-Task Runtimes with FleCSI

Dit artikel presenteert benchmarks van het FleCSI-framework op tot 1024 knopen, waarbij wordt vastgesteld dat de MPI-backend uitstekende schaalbaarheid biedt, terwijl de HPX-backend in rekenintensieve stralingshydrodynamica-toepassingen op kleinere schaal prestatievoordelen biedt ten opzichte van MPI.

De kern

Stel je voor dat je een gigantisch, ingewikkeld puzzelstuk moet oplossen, zoals het simuleren van hoe licht en gas door de ruimte bewegen (radiatiehydrodynamica). Om dit in een fractie van een seconde te doen, heb je duizenden computers nodig die samenwerken.

Deze paper is als een vergelijkend testrapport van drie verschillende manieren om die duizenden computers te laten samenwerken. De onderzoekers wilden weten: "Is de nieuwe, slimme manier om te werken sneller dan de oude, bewezen manier, of kost die nieuwe manier juist te veel tijd aan 'administratie'?"

Hier is de uitleg in simpele taal, met een paar creatieve vergelijkingen:

1. De Drie Spelers (De "Runtimes")

Stel je voor dat je een bouwproject hebt met duizenden arbeiders. Je hebt drie verschillende manieren om hen aan te sturen:

• MPI (De Oude Meester): Dit is de klassieke aanpak. De bouwmeester (de computer) roept elke arbeider apart op, geeft een opdracht, wacht tot die klaar is, en roept de volgende. Het is heel gestructureerd, maar als je wacht op de volgende opdracht, staan de anderen soms stil. Het is betrouwbaar en snel voor simpele taken.
• Legion (De Strikte Manager): Dit is een modernere aanpak. De manager kijkt naar wie wat nodig heeft en probeert alles te plannen. Maar deze manager is soms een beetje traag in zijn administratie en heeft veel papierwerk nodig voordat hij echt aan het werk kan.
• HPX (De Dynamische Regisseur): Dit is de nieuwste, slimste aanpak. De regisseur laat de arbeiders niet wachten. Zodra een arbeider klaar is met zijn stukje, springt hij direct door naar de volgende taak die beschikbaar is, zelfs als die nog niet helemaal gepland was. Het is als een jazzband die improviseren: niemand wacht, iedereen speelt mee zodra het moment rijp is.

2. De Twee Tests (De "Benchmarks")

De onderzoekers hebben deze drie methoden getest met twee heel verschillende "puzzels":

Test A: De Simpele Muur (De Poisson-oplosser)

Dit is een simpele, repetitieve taak. Stel je voor dat je een muur moet schilderen, maar je mag alleen schilderen als je buurman klaar is met zijn stukje.

• Het Resultaat: Hier bleek dat de oude methode (MPI) het beste was. De "administratie" van de nieuwe managers (Legion en HPX) kostte meer tijd dan het schilderen zelf.
• De les: Voor simpele, gestructureerde taken is de nieuwe, slimme regisseur (HPX) net iets te druk met het plannen van de chaos. De oude, gestructureerde aanpak wint hier.

Test B: De Complexe Storm (HARD - Stralingshydrodynamica)

Dit is een echte, complexe simulatie van een storm of een explosie. Hier zijn duizenden dingen tegelijk aan het gebeuren: drukgolven, licht, hitte. Het is een enorme chaos waar sommige dingen wachten op andere, maar veel dingen kunnen ook terwijl anderen wachten, alvast aan de slag gaan.

• Het Resultaat: Hier kwam de HPX-regisseur sterk naar voren! Omdat hij zo goed kan improviseren en wachten overbodig maakt, was hij tot 1,6 keer sneller dan de oude methode op kleinere schaal.
• De les: Voor complexe, chaotische taken waar veel dingen tegelijk gebeuren, loont het om die slimme, dynamische regisseur in te zetten. Hij kan de "wacht-tijd" van de arbeiders omzetten in productieve tijd.

3. De Grote Ontdekking

De onderzoekers ontdekten twee belangrijke dingen:

1. De "FleCSI" tool werkt: Ze gebruikten een speciaal gereedschap (FleCSI) dat het makkelijk maakt om deze verschillende methoden te gebruiken. Het is alsof ze een universele vertaler hebben die zorgt dat de bouwmeesters (MPI) en de regisseurs (HPX) dezelfde taal spreken. Dit gereedschap kostte nauwelijks tijd, zelfs niet op de grootste schaal (tot 1024 computers!).
2. HPX heeft nog een klein mankement: Hoewel HPX in de complexe test wint, bleek dat op heel grote schaal (duizenden computers) de "collectieve" communicatie van HPX nog niet helemaal geoptimaliseerd is. Het is alsof de regisseur een beetje vastloopt als hij te veel mensen tegelijk moet roepen. Maar voor de meeste complexe taken is hij al een enorme winnaar.

Samenvattend

Stel je voor dat je een restaurant runt:

• Voor een restaurant met alleen maar soep (simpele taak), is het beste om een vaste, strakke lijn te hebben (MPI).
• Voor een restaurant met een complex menu waar chefs tegelijkertijd vlees, vis en groenten bereiden en wachten op elkaar (complexe taak), werkt het veel beter om een regisseur te hebben die de chefs laat improviseren en direct doorsturen zodra een pan leeg is (HPX).

Conclusie: De nieuwe technologie (HPX) is niet perfect voor elke situatie, maar voor de echt moeilijke, wetenschappelijke problemen (zoals het simuleren van sterrenstelsels of stormen) kan hij de snelheid aanzienlijk verhogen door slim te plannen en niet te laten wachten.

Technische samenvatting

Hier is een gedetailleerde technische samenvatting van het paper "Radiation Hydrodynamics at Scale: Comparing MPI and Asynchronous Many-Task Runtimes with FleCSI", geschreven in het Nederlands.

Probleemstelling

Het schrijven van efficiënte gedistribueerde code voor wetenschappelijk rekenen blijft een arbeidsintensieve en complexe taak. Programmeerders moeten vaak vertrouwd zijn met geavanceerde parallelisatietools zoals MPI, CUDA en Kokkos om moderne, many-core architecturen te benutten. Hoewel frameworks zoals FleCSI (Flexible Computational Science Infrastructure) een hoog niveau van abstractie bieden om de ontwikkeling te vereenvoudigen en asynchrone parallelisatie mogelijk te maken via runtimes zoals Legion en HPX, is de exacte impact van deze abstracties op de prestaties onduidelijk.

De kernvraag is: wat zijn de kosten (overhead) van het gebruik van Asynchronous Many-Task Runtimes (AMTRs) ten opzichte van geoptimaliseerde, synchrone MPI-implementaties, en kunnen deze AMTRs in complexe werklasten de prestaties daadwerkelijk verbeteren door asynchrone parallelisatie? Bestaande benchmarks focussen vaak op werklasten waar AMTRs van nature uitblinken, waardoor de pure overhead van de abstractie-laag moeilijk te kwantificeren is.

Methodologie

De auteurs evalueren FleCSI op schaal (tot 1024 nodes) op de Chicoma supercomputer (LANL) door twee verschillende toepassingen te benchmarken met drie verschillende backends:

1. MPI (synchroon).
2. Legion (asynchroon).
3. HPX (asynchroon).

De gebruikte hardware bestaat uit AMD EPYC 7H12 CPU's (64 cores per socket, 2 sockets per node). De configuraties variëren van pure MPI (128 processen/node) tot hybride instellingen met Kokkos voor gedeeld geheugen (bijv. 8 processen/16 threads).

De twee benchmark-toepassingen:

1. Poisson-oplosser (Communicatie-gericht): Een eenvoudige red-black Gauss-Seidel solver voor de Poisson-vergelijking. Deze toepassing is computatieweinig en communicatie-intensief, wat ideaal is om de overhead van de AMTR-runtimes en de abstractie-laag van FleCSI bloot te leggen. De auteurs hebben een nieuwe "benchmark mode" ontwikkeld die asynchrone timing mogelijk maakt om kunstmatige synchronisatiebarrières te vermijden.
2. HARD (Berekening-gericht): Een complexe code voor stralingshydrodynamica (Radiation Hydrodynamics) die compressibele hydrodynamica koppelt aan radiatieve diffusie. Deze toepassing gebruikt geavanceerde numerieke methoden (zoals WENO5-Z en operator splitting) en vormt een complexe taakgrafiek, wat ideaal is om de voordelen van asynchrone planning te testen.

Experimenteel ontwerp:
Er werden zowel strong scaling (vaste probleemgrootte, meer resources) als weak scaling (probleemgrootte per node constant, meer resources) tests uitgevoerd. Voor de vergelijking van MPI en HPX werd de MPI-parcelport van HPX gebruikt om te garanderen dat communicatie-overhead identiek was, zodat verschillen puur toe te schrijven waren aan de runtime-planning.

Belangrijkste Bijdragen

1. Eerste grootschalige evaluatie: Dit is de eerste evaluatie van het FleCSI-framework op grote schaal (tot 131.072 cores) over alle beschikbare backends (MPI, Legion, HPX) met meerdere applicaties.
2. Vergelijkende analyse: Een directe vergelijking van MPI, Legion en HPX die exact dezelfde C++-code uitvoeren, wat een eerlijke basis biedt voor het meten van runtime-overhead.
3. Nieuwe benchmark-methode: De ontwikkeling van een asynchrone timing-modus voor de FleCSI Poisson-voorbeeldcode, waardoor nauwkeurige prestatievergelijkingen mogelijk zijn zonder de timing te verstoren door synchronisatiebarrières.

Resultaten

1. Poisson-oplosser (Communicatie-gericht):

• MPI: Bereikte een parallelle efficiëntie van meer dan 97% bij weak scaling op 1024 nodes (131.072 cores), wat aangeeft dat de abstractie-laag van FleCSI minimaal overhead introduceert voor synchrone werklasten.
• HPX: Toonde een vergelijkbare prestatie als MPI+Kokkos, maar met beperkte schaalbaarheid boven de 64 nodes. De daling in prestaties werd veroorzaakt door inefficiënte implementaties van collectieve operaties in HPX (geen boom-gebaseerde algoritmen, maar een bottleneck via één host-proces).
• Legion: Vertoonde aanzienlijke overhead en schaalbeperkingen. De oorzaak hiervan (hoog geheugengebruik en runtime-overhead) kon niet direct worden geïdentificeerd, maar de prestaties waren duidelijk inferieur aan MPI.

2. HARD (Berekening-gericht):

• In deze complexere, rekenintensieve toepassing verdween de prestatiekloof tussen MPI en HPX.
• HPX presteerde beter: Op minder dan 64 nodes overtrof de HPX-backend MPI+Kokkos.
  • Weak scaling: Gemiddelde snelheidswinst van 1.31x ten opzichte van MPI+Kokkos.
  • Strong scaling (Hydrodynamica-only): Snelheidswinsten van tot 1.64x ten opzichte van MPI+Kokkos en 1.20x ten opzichte van pure MPI.
• De asynchrone planning van HPX kon de planning van berekeningen en communicatie beter overlappen, wat leidde tot betere resourcebenutting in deze complexe werklast.

Betekenis en Conclusie

Het paper levert twee cruciale inzichten:

1. Lage overhead van abstractie: FleCSI introduceert slechts minimale overhead ten opzichte van geoptimaliseerde MPI, zelfs bij zeer grote schalen (100.000+ cores), wat het framework betrouwbaar maakt voor traditionele wetenschappelijke toepassingen.
2. Potentieel van AMTRs: Hoewel AMTRs (zoals HPX) in eenvoudige, communicatie-georiënteerde taken overhead introduceren, tonen ze in complexe, asynchrone werklasten (zoals stralingshydrodynamica) een duidelijk voordeel. Ze kunnen de prestaties verbeteren door asynchrone planning en het overlappen van taken.

Toekomstperspectief:
De auteurs wijzen op de noodzaak om de HPX-collectieve operaties te optimaliseren om de schaalbaarheid verder te verbeteren. Daarnaast is er plannen om de benchmarks uit te breiden naar heterogene architecturen (met GPU's), waarbij AMTRs mogelijk nog grotere voordelen bieden door het overlappen van CPU-GPU data-transfers met berekeningen. De Legion-backend vereist verdere profilering om de oorzaken van de hoge overhead te begrijpen.

Kortom, dit werk valideert FleCSI als een krachtig framework dat zowel de stabiliteit van MPI als het potentieel van moderne asynchrone runtimes kan bieden, afhankelijk van de aard van de wetenschappelijke werklast.