Multi-GPU Hybrid Particle-in-Cell Monte Carlo Simulations for Exascale Computing Systems

Diese Arbeit stellt eine portable, multi-GPU-fähige Hybrid-Implementierung des PIC-Monte-Carlo-Codes BIT1 vor, die durch OpenMP-Zielaufgaben, optimierte Speicherlayouts und effiziente I/O-Verfahren auf heterogenen Exascale-Systemen wie Frontier eine signifikante Verbesserung von Skalierbarkeit und Ressourcennutzung ermöglicht.

Das Wesentliche

🚀 Der große Plasma-Rennwagen: Wie man Supercomputer für die Zukunft rüstet

Stellen Sie sich vor, Sie wollen das Verhalten von Plasma simulieren – jener heißen, elektrisch geladenen Materie, die in Sternen glüht oder in zukünftigen Fusionsreaktoren (wie einem extrem großen, kontrollierten Sonnenkern) genutzt wird, um saubere Energie zu erzeugen.

Um das zu tun, nutzen Wissenschaftler ein Programm namens BIT1. Es ist wie ein riesiger, digitaler Zoo, in dem Milliarden von winzigen Teilchen (wie Elektronen und Ionen) herumfliegen, kollidieren und sich gegenseitig beeinflussen.

Das Problem? Diese Simulationen sind so rechenintensiv, dass sie selbst die stärksten heutigen Computer an ihre Grenzen bringen. Besonders auf den neuen, riesigen Supercomputern (den sogenannten "Exascale"-Systemen), die Tausende von Grafikkarten (GPUs) gleichzeitig nutzen, gab es bisher ein großes Chaos.

Hier ist die Geschichte, wie die Forscher dieses Chaos in einen gut organisierten Rennwagen verwandelt haben.

1. Das Problem: Der Stau im Daten-Autobahn

Stellen Sie sich den Supercomputer als eine riesige Autobahn vor.

• Die alten Methoden: Früher mussten die Daten (die Positionen der Teilchen) bei jedem Schritt vom "Chef" (der CPU) zu den "Arbeitern" (den GPUs) und wieder zurück geschleppt werden. Das war wie ein Lieferwagen, der ständig anhalten muss, um Pakete zu entladen und neu zu laden.
• Das Ergebnis: Die Autobahn war verstopft. Die GPUs warteten nur darauf, dass die Daten ankommen, anstatt zu rechnen. Das war extrem ineffizient und langsam.

2. Die Lösung: Ein neues Team-System (Hybrid MPI + OpenMP)

Die Forscher haben BIT1 neu programmiert, damit es auf diesen neuen Maschinen läuft. Sie haben drei geniale Tricks angewendet:

Trick A: Der "Wohnwagen" statt des täglichen Pendelns (Persistenter Speicher)

• Vorher: Bei jedem Rechenschritt wurden die Daten vom Computer-Hauptspeicher in die Grafikkarte geschickt, dort verarbeitet und wieder zurückgeschickt.
• Jetzt: Die Daten bleiben einfach auf der Grafikkarte wohnen. Man baut einen "Wohnwagen" (persistenten Speicher) direkt auf der GPU. Die Teilchen müssen nicht mehr pendeln; sie bleiben dort, wo die Arbeit stattfindet. Das spart enorm viel Zeit und Nerven.

Trick B: Die flache Straße statt der Treppen (1D-Datenlayout)

• Vorher: Die Daten waren in komplexen 3D-Strukturen gespeichert (wie ein mehrstöckiges Parkhaus). Um ein Teilchen zu finden, musste der Computer Treppen steigen und Gassen suchen.
• Jetzt: Die Forscher haben alles in eine lange, flache Straße (eindimensionale Liste) umgewandelt. Die GPUs können jetzt wie ein Hochgeschwindigkeitszug einfach geradeaus fahren, ohne abbiegen oder Treppen steigen zu müssen. Das macht den Zugriff blitzschnell.

Trick C: Die asynchrone Orchestrierung (OpenMP Target Tasks)

• Vorher: Alle mussten warten, bis der nächste Befehl kam. Wenn eine Grafikkarte fertig war, musste sie auf die andere warten (Synchronisation).
• Jetzt: Es ist wie ein gut geöltes Orchester. Ein Dirigent (der Code) gibt den Musikern (den GPUs) Anweisungen, aber sie spielen gleichzeitig und unabhängig. Während eine Grafikkarte rechnet, kann eine andere schon Daten für den nächsten Schritt vorbereiten oder Daten auf die Festplatte schreiben. Niemand steht untätig herum.

3. Die Werkzeuge: Ein universeller Schlüsselkasten

Ein großes Problem bei Supercomputern ist, dass sie unterschiedliche Hardware nutzen (manche haben Nvidia-Karten, andere AMD). Früher musste man für jede Marke einen anderen Schlüssel benutzen.

• Die Lösung: Die Forscher haben OpenMP genutzt. Das ist wie ein universeller Schlüsselkasten. Mit ein paar einfachen Befehlen funktioniert der Code sowohl auf Nvidia- als auch auf AMD-Karten, ohne dass man den ganzen Code neu schreiben muss. Das macht das Programm "portabel" – es läuft überall.

4. Das Ergebnis: Ein Weltrekord auf der Frontier

Die Forscher haben ihr neues System auf dem Frontier, dem derzeit schnellsten Supercomputer der Welt (in den USA), getestet.

• Das Ergebnis: Sie konnten die Simulation mit bis zu 16.000 Grafikkarten gleichzeitig laufen lassen.
• Der Vergleich: Das alte System wäre bei dieser Größe zusammengebrochen oder extrem langsam gewesen. Das neue System läuft so schnell, dass es fast linear skaliert: Wenn man mehr Computer hinzufügt, wird es fast genau so viel schneller.
• Die I/O-Probleme: Selbst wenn sie extrem viele Daten schreiben mussten (wie ein Kamera-Team, das 24/7 filmt), lief das System stabil. Dank neuer Dateisysteme (openPMD und ADIOS2) wurden die Daten so effizient abgelegt, dass sie die Rechenleistung nicht blockierten.

🌟 Fazit in einem Satz

Die Forscher haben einen alten, holprigen Rennwagen (das alte Programm) in einen hochmodernen, fliegenden Zug verwandelt, der auf jeder Art von Schiene (Nvidia oder AMD) fährt, bei dem die Passagiere (die Daten) nicht mehr aussteigen müssen, um umzusteigen, und der dank perfekter Koordination Tausende von Wagen gleichzeitig ziehen kann.

Dies ist ein wichtiger Schritt, um in Zukunft saubere Energie durch Fusionsreaktoren zu verstehen und zu bauen.

Technische Zusammenfassung

1. Problemstellung

Partikel-in-Zelle (PIC) Monte-Carlo (MC) Simulationen sind ein Kernbestandteil der Plasmaphysik, insbesondere für die Modellierung von Plasma-Material-Wechselwirkungen und Tokamak-Divertoren. Auf herkömmlichen CPU-Clustern zeigten diese Simulationen zwar gute Skalierbarkeit, stießen jedoch auf heterogenen High-Performance-Computing (HPC)-Systemen (Pre-Exascale und Exascale) auf erhebliche Herausforderungen:

• Ineffiziente Datentransfers: Zu viel Datenbewegung zwischen Host (CPU) und Device (GPU) sowie zwischen GPUs.
• Synchronisations-Overhead: Hohe Wartezeiten durch Synchronisation über viele Beschleuniger hinweg.
• Ressourcennutzung: Ineffiziente Auslastung multipler GPUs innerhalb eines Knotens.
• Portabilität: Schwierigkeiten, Code sowohl auf Nvidia- als auch auf AMD-Architekturen effizient und ohne vendor-spezifischen Code auszuführen.

Das Ziel war es, den Code BIT1 (Berkeley Innsbruck Tbilisi 1D3V) so zu optimieren, dass er auf zukünftigen Exascale-Systemen (wie Frontier) mit bis zu 16.000 GPUs effizient läuft.

2. Methodik

Die Autoren entwickelten eine portable, hybride MPI + OpenMP-Implementierung von BIT1, die speziell für heterogene GPU-Architekturen (Nvidia und AMD) konzipiert wurde. Die zentralen technischen Ansätze umfassen:

• Hybrides Parallelisierungsmodell: Kombination von MPI für die Domain-Zerlegung über Knoten hinweg und OpenMP für die Shared-Memory-Parallelisierung innerhalb eines Knotens.
• OpenMP Target Tasks mit Abhängigkeiten: Nutzung von #pragma omp target mit nowait und depend-Klauseln, um Berechnung und Kommunikation asynchron zu überlappen. Dies ermöglicht eine feingranulare Steuerung der GPU-Kernels ohne blockierende Synchronisation.
• Persistente Device-Resident Memory: Statt Daten jeden Zeitschritt neu zu transferieren, werden große Arrays (z. B. Partikelpositionen und -geschwindigkeiten) persistent im GPU-Speicher gehalten. Dies wird durch #pragma omp target enter/exit data Regionen realisiert.
• Optimierte Datenlayouts:
  • Umstellung von nicht-kontinuierlichen 3D-Arrays (x[species][cell][particle]) auf kontinuierliche 1D-Arrays. Dies verbessert den Speicherzugriff und die Bandbreite auf GPUs erheblich.
• Speichermanagement (Pinned Memory):
  • Wechsel von Unified Memory (UM) zu Pinned Host Memory (PinM) für große Datenarrays.
  • Auf Nvidia-GPUs wird PinM zur Compile-Zeit ausgewählt.
  • Auf AMD-GPUs (wo Compile-Time-Pinning nicht verfügbar ist) werden OpenMP Memory Allocators (omp_high_bw_mem_alloc mit pinned=true) verwendet, um die Platzierung explizit zu steuern. Dies ermöglicht hohe Durchsatzraten und niedrige Latenz bei asynchronen Transfers und GPU-DMA.
• GPU-Runtime-Interoperabilität: Nutzung von use_device_ptr und is_device_ptr, um direkten Zugriff auf Device-Pointer zu ermöglichen, ohne zusätzliche Mapping-Operationen. Dies unterstützt die Laufzeit-Interoperabilität zwischen CUDA, HIP und OpenMP.
• Standardisiertes I/O: Integration von openPMD und ADIOS2 (mit BP4 und SST-Backends) für hochperformantes Datei-I/O, In-Memory-Streaming und In-Situ-Analyse/Visualisierung, ohne den Simulationslauf zu unterbrechen.

3. Wichtige Beiträge

1. Hybride MPI+OpenMP-Versionen: Entwicklung von BIT1-Versionen, die Lastungleichgewichte durch task-basierte Ansätze mindern und die Ressourcennutzung auf einzelnen Knoten sowie in Strong- und Weak-Scaling-Tests optimieren.
2. Portabler GPU-Offloading: Erweiterung des OpenMP-Offloadings auf Nvidia und AMD GPUs durch Nutzung von Target Tasks, Persistenz im GPU-Speicher und PinM, was eine vendor-unabhängige Portabilität sicherstellt.
3. Vendor-spezifische Optimierungen: Implementierung von PinM-Strategien (Compile-Time bei Nvidia, Allocator-basiert bei AMD) zur Minimierung von Host-zu-Device-Overhead.
4. Skalierbares I/O: Integration von openPMD/ADIOS2, um I/O-Engpässe zu vermeiden und In-Situ-Analysen auf Exascale-Systemen zu ermöglichen.

4. Ergebnisse

Die Leistung wurde auf vier HPC-Systemen getestet, darunter Frontier (OLCF-5, Exascale), LUMI, MareNostrum 5 und Dardel.

• Performance-Steigerung (Single Node):

  • Auf einem MN5-Knoten (4 GPUs) reduzierte die vollständig optimierte Version (persistenter Speicher, asynchrone Ausführung, 1D-Layout, PinM) die Simulationszeit von ca. 1919 s (Original) auf ca. 113 s.
  • Dies entspricht einer 17,04-fachen Beschleunigung gegenüber der ursprünglichen BIT1-Version mit 3D-Layout und Unified Memory.
  • Der Partikelbeweger (Mover) wurde durch asynchrone Ausführung fast auf null reduziert (~0,06 s).

• Strong Scaling (bis 16.000 GPUs):

  • Auf Frontier (bis 2.000 Knoten / 16.000 GPUs) für eine Schicht-Simulation mit schwerem I/O:
    • Die OpenPMD-Implementierung mit ADIOS2 (SST-Backend) erreichte eine 5,25-fache Beschleunigung beim Skalieren von 50 auf 2.000 Knoten.
    • Die parallele I/O-Lösung (SST) zeigte die beste Skalierbarkeit unter hohem I/O-Druck.

• Weak Scaling (bis 800 GPUs):

  • Bei proportionaler Vergrößerung der Problemgröße mit der Knotenanzahl blieben die Ausführungszeiten auf Frontier nahezu konstant.
  • Die parallele Effizienz (PE) lag bei 97,0 % bis 98,0 % für minimale I/O-Lasten.
  • Selbst unter schwerer I/O-Last (häufige Checkpoints) blieb die PE bei 72,0 % bis 73,6 %, was deutlich besser ist als bei der ursprünglichen Implementierung.

• I/O-Overhead: Die Integration von openPMD/ADIOS2 verursachte nur einen marginalen Overhead und ermöglichte gleichzeitig In-Situ-Visualisierung, was die Nachbearbeitungszeit eliminiert.

5. Bedeutung und Ausblick

Dieses Werk demonstriert, dass PIC-MC-Simulationen durch eine sorgfältige Kombination aus persistentem GPU-Speicher, optimierten Datenlayouts und asynchroner OpenMP-Target-Parallelisierung effizient auf Exascale-Systemen skaliert werden können.

• Portabilität: Der Ansatz funktioniert erfolgreich auf beiden großen GPU-Architekturen (Nvidia und AMD) ohne vendor-spezifischen Code.
• Exascale-Bereitschaft: Die Ergebnisse auf Frontier belegen, dass BIT1 bereit für den Einsatz auf zukünftigen Exascale-Systemen ist, selbst unter extremen Bedingungen mit massivem I/O und vielen tausend GPUs.
• Zukunft: Die Autoren planen die Erweiterung auf Intel-GPU-Plattformen (Aurora, JUPITER) und die Integration von KI-Methoden für adaptive Steuerung und Echtzeitanalyse. Zudem sollen vertiefte Profiling-Analysen mit Tools wie TAU, Nsight Systems und ROC-Profiler durchgeführt werden.

Zusammenfassend liefert das Paper einen robusten, portablen und hochskalierbaren Weg für die nächste Generation von Plasmaphysik-Simulationen auf heterogenen Supercomputern.