Exascale Computing-Projekt: Pagoda aktualisiert die PGAS-Programmierung mit skalierbaren Datenstrukturen und aggressiver asynchroner Kommunikation

31. August 2023

31. August 2023 – Das Pagoda-Projekt erforscht und entwickelt Software, mit der Programmierer Hochleistungsanwendungen mithilfe des Partitioned Global Address Space (PGAS)-Modells implementieren. Das Projekt wird hauptsächlich vom Exascale Computing Project (ECP) finanziert und interagiert mit Partnerprojekten in Industrie, Regierung und Wissenschaft. [1]

PGAS ist ein Programmiermodell, das einen weltweit gemeinsam genutzten Adressraum zur Verbesserung der Produktivität unterstützt und gleichzeitig zwischen lokalen und Remote-Datenzugriffen unterscheidet, um Optimierungsmöglichkeiten zu bieten. Diese Unterscheidung erleichtert den Zugriff auf Daten in einer verteilten heterogenen Computerumgebung und berücksichtigt gleichzeitig das Bewusstsein für uneinheitliche Kommunikationskosten. Für den Programmierer bietet PGAS das Beste aus beiden Welten: Er kann seine Datenstrukturen einfach im Speicher zuweisen und transparent sowohl auf CPU- als auch auf GPU-Geräten verwenden oder die Daten explizit in der Nähe der Rechenhardware platzieren, um kostspielige Datenübertragungen zu vermeiden ( (z. B. erhöhte Laufzeit und Stromverbrauch), was die Leistung und Skalierbarkeit einschränken würde. Dies macht PGAS zu einem hervorragenden Framework für viele Anwendungen, die die Leistung maximieren und die Skalierbarkeit auf großen parallelen Architekturen wie DOE-Exascale-Supercomputern unterstützen müssen.

Der Anwendungstreiber

Viele wissenschaftliche Anwendungen beinhalten asynchrone Aktualisierungen unregelmäßiger Datenstrukturen wie adaptive Netze, spärliche Matrizen, Hash-Tabellen, Histogramme, Diagramme und dynamische Arbeitswarteschlangen.

Manchmal weiß der Programmierer genug über die Datenstruktur, um den effizientesten Weg zur Ausnutzung der Speicherlokalität zu bestimmen. Mit dem PGAS-Modell kann der Programmierer die Platzierung dieser Datenstrukturen explizit verwalten, um die Leistung zu optimieren, beispielsweise im Speicher einer diskreten GPU. Alternativ ist es dem Programmierer möglicherweise auch egal. In diesem Fall geht es ihnen eigentlich darum, auf die Daten zuzugreifen und mit der Berechnung fortzufahren. In diesem Access-and-Proceed-Szenario unterstützt das PGAS-Speichermodell natürlich den bequemen Zugriff auf Daten.

Leider lassen sich nicht alle Speicherzugriffe so einfach kategorisieren. Das PGAS-Modell gibt Programmierern die Werkzeuge an die Hand, die sie benötigen, um komplizierte Datenzugriffsprobleme zu lösen, bei denen die Leistung beim Zugriff auf die Daten wirklich wichtig ist, die Datenbewegung jedoch zu komplex und unregelmäßig ist, um vorhersehbar zu sein.

Technische Einführung

Die zunehmende Verbreitung heterogener Datenverarbeitung und die damit verbundene Komplexität von Hardwareangeboten mehrerer Anbieter führen zu einer kombinatorischen Explosion der Plattformvielfalt. Aus der Sicht des Programmierers sind für jedes Rechenzentrum und jeden Supercomputer möglicherweise sehr spezifische Optimierungen bei der Datenplatzierung erforderlich, um eine hohe Leistung zu erzielen. Um den Programmierer bei der Bewältigung dieser kombinatorischen Portabilitätsherausforderung zu unterstützen, bietet der Pagoda-Software-Stack eine tragbare Kommunikationsschicht, GASNet, sowie die Produktivitätsschichten UPC++ und Berkeley UPC (Abbildung 1).

GASNet-EX

GASNet-EX ist ein Update der 20 Jahre alten GASNet-1 PGAS-Codebasis und des Kommunikationssystems. Im Rahmen dieses Updates wurden die GASNet-Schnittstellen neu gestaltet, um den neuen Anforderungen des Exascale-Supercomputing gerecht zu werden und Kommunikationsdienste für eine Vielzahl von PGAS-Programmiermodellen auf aktuellen und zukünftigen HPC-Architekturen zu unterstützen. Dieser Aufwand umfasst eine Überarbeitung der Implementierung sowie eine umfassende Neugestaltung der Softwareschnittstellen.

Zu den motivierenden Zielen dieser Neugestaltung gehören neben der Abwärtskompatibilität für GASNet-1-Clients:

Kompatibilität ist wichtig, da GASNet von einer Reihe von Projekten übernommen wurde (Abbildung 2). Die enge semantische Anpassung der GASNet-EX-APIs an die Kundenanforderungen und Hardwarefunktionen führt häufig zu einer besseren Leistung als konkurrierende Bibliotheken, da sie direkt über die nativen APIs für Netzwerke implementiert werden, die für HPC von Interesse sind.

Paul Hargrove, Computersystemingenieur 5 in der Abteilung „Applied Mathematics and Computational Research“ (AMCR) am Lawrence Berkeley National Laboratory (Berkeley Lab) und Leiter des ECP Pagoda-Projekts, beobachtete, dass die mit „-EX“ gekennzeichneten Änderungen sich auf die Entwicklung von Anwendungen und HPC auswirken in den letzten 20 Jahren verändert. Speicherarten sind beispielsweise wichtig, um auszudrücken, wie Remote Memory Access (RMA) jetzt Gets und Puts zum/vom GPU-Speicher umfasst.

Organisations- und Programmiereransicht

Das Client-Objekt befindet sich auf der obersten Ebene der GASNet-EX-Objekthierarchie (Abbildung 3). Es umfasst alle Interaktionen zwischen dem Laufzeitsystem eines bestimmten Programmiermodells und GASNet. Der Begriff „Client“ bezieht sich auf die Softwareschicht, die über GASNet sitzt und GASNet-Aufrufe durchführt, die dieses Objekt beim Start erstellt.

Jedes Clientobjekt enthält einen oder mehrere Endpunkte, die als einfacher Kommunikationskontext betrachtet werden können.

Jeder Kommunikationsvorgang ist im Allgemeinen zwei oder mehr Endpunkten zugeordnet. Jeder Endpunkt enthält eine Active Message (AM)-Handlertabelle, die einen aktiven Nachrichtenindex dem entsprechenden lokalen Funktionszeiger zuordnet. Der Endpunkt verfügt außerdem über eine optionale Bindung an ein Segmentobjekt. Ein Segmentobjekt stellt einen zusammenhängenden Bereich des lokalen Speichers dar, der sich im Host-DRAM oder im Speicher eines Geräts wie einer GPU befinden kann.

Endpunkte können zu einem geordneten Satz lokaler und entfernter Endpunkte gruppiert werden, was ein schlankes Analogon eines MPI-Kommunikators darstellt. Diese Gruppe von Endpunkten wird als Teammitglied (TM) bezeichnet und fungiert sowohl als Mechanismus zur globalen Benennung einzelner Endpunkte als auch zur Identifizierung der Teilnehmer an einer kollektiven Operation.

Die meisten Kommunikationsinitiierungsoperationen in GASNet-EX verwenden ein TM-Argument, das implizit den von dieser Operation verwendeten Client, Endpunkt, Handler und Segment angibt.

Hargrove fuhr fort: „GASNet-EX wurde in Anerkennung der Tatsache entwickelt, dass HPC-Systeme und -Anwendungen immer komplizierter geworden sind. Unsere Benutzer haben festgestellt, dass Berechnungen, die zuvor sehr regelmäßig waren, kein so angenehmes Verhalten mehr zeigen. Die Kommunikation GPU-residenter Daten ist für leistungsstarkes heterogenes Supercomputing unerlässlich. Benutzern die Möglichkeit zu geben, Speicher in einem PGAS-Modell an Geräte zu binden, ist wichtig für die Effizienz, um Überschneidungen bei Berechnungen und Kommunikation zu ermöglichen und die Zeit bis zur Lösung zu verkürzen. Asynchrone GPU-Put/Get-Funktionen können im Vergleich zu MPI dazu beitragen, die Kommunikation auf natürlichere Weise zu beschleunigen. Darüber hinaus arbeitet das Team daran, die Skalierung zu erhöhen, Sperren zu beseitigen, Threads zu erstklassigen Entitäten zu machen und die Verwendung von Endpunkten explizit zu machen.

UPC++

UPC++ ist die andere Hälfte der Pagoda-Geschichte, die auf GASNet-EX aufbaut. „Insbesondere“, erklärte Hargrove, „verallgemeinert UPC++ die GASNet-EX-Kommunikationsvorgänge zum Verschieben von Daten zwischen und zu/von Gerätespeichern.“ UPC++ ist eine Abstraktion auf höherer Ebene, die eine effiziente einseitige Kommunikation für Massendaten und umfangreiche C++-Datentypen unterstützt. UPC++ bietet auch die Möglichkeit, Berechnungen einfach auf Daten umzustellen, was für den Programmierer oft natürlicher und/oder recheneffizienter ist. UPC++ ist eine Open-Source-Vorlagenbibliothek, für deren Verwendung lediglich ein C++-Compiler erforderlich ist.

C++-basierte High-Level-Abstraktionen

UPC++ bietet Produktivitätsabstraktionen auf hoher Ebene, die für die Programmierung des Partitioned Global Address Space (PGAS) geeignet sind, wie z. B. Remote Memory Access (RMA), Remote Procedure Call (RPC), Unterstützung für Beschleuniger (z. B. GPUs) und Mechanismen zum Ausblenden aggressiver Asynchronität Kommunikationskosten. UPC++ implementiert die Kommunikation über GASNet-EX. Es ist darauf ausgelegt, hohe Leistung und Portabilität von Laptops bis hin zu Exascale-Supercomputern zu bieten. HPC-Anwendungssoftware mit UPC++ umfasst: MetaHipMer2-Metagenom-Assembler, SIMCoV-Virusausbreitungssimulation, NWChemEx TAMM und Diagrammberechnungskerne von ExaGraph.

Die Designmerkmale von UPC++ konzentrieren sich auf:

Standardmäßig erfolgt die gesamte UPC++-Kommunikation in zwei Phasen und beginnt mit einem Initiierungsvorgang. Dem Programmierer steht es dann frei, alle anderen Arbeiten auszuführen, die während der Datenübertragung ausgeführt werden können. Anschließend wartet er, um sicherzustellen, dass der Datenübertragungsvorgang abgeschlossen ist, bevor er fortfährt (Abbildung 5).

UPC++ nutzt viele Funktionen des modernen C++, um dem Programmierer dabei zu helfen, verständlichen und wartbaren Code zu erstellen. Hargrove betonte: „UPC++ kann in Kombination mit C++-Lambda-Ausdrücken verwendet werden, was viele Programmiervorteile bietet.“ Mit UPC++- und Lambda-Ausdrücken kann der Programmierer seinen Quellcode so organisieren, dass er genau an der Stelle, an der UPC++ benötigt wird, die Operationen angibt, die zum Verschieben von Daten in die Berechnung oder zum Verschieben der Berechnung dorthin, wo sich die Daten befinden, erforderlich sind.“ Diese Lokalität erleichtert es den Benutzern erheblich, die Software zu verstehen und zu warten.

Mit UPC++ kann der Programmierer die leistungsstarken Produktivitätsfunktionen der C++-Standardvorlagenbibliothek nahtlos mit Remote-Prozeduraufrufen zusammenstellen. Abbildung 6 zeigt beispielsweise, wie man leicht eine verteilte Hash-Tabellen-Einfügeoperation implementieren kann, indem man std::unordered_map mit UPC++ RPC erstellt. In diesem Beispiel speichert jeder Prozess seine Partition der verteilten Hash-Tabelle in der Variablen local_map (die Schlüssel- und Werttypen sind zur Veranschaulichung std::string). Der Einfügungsvorgang verwendet einen Hash des Schlüssels, um die diesem Schlüssel entsprechende Partition zu identifizieren, und ein UPC++-Remoteprozeduraufruf wird an den besitzenden Prozess gesendet, um die Einfügung in der entsprechenden Kopie von local_map durchzuführen. Dieser gesamte Vorgang ist natürlich asynchron und gibt einen UPC++-Zukunftstyp zurück, den der Aufrufer später zum Synchronisieren der Fertigstellung verwenden kann.

Die UPC++-Bibliothek ist nicht nur hochproduktiv, sondern kann auch eine robuste Leistungsskalierbarkeit auf modernen Supercomputern bieten. Abbildung 7 zeigt die nahezu lineare schwache Skalierung einer leicht verbesserten Version dieser verteilten Hash-Tabelle auf dem NERSC Cori-Supercomputer. (Weitere Einzelheiten finden Sie unter https://doi.org/10.25344/S4V88H).

Für mehr Informationen

GASNet-EX (https://gasnet.lbl.gov/)

UPC++ (https://upcxx.lbl.gov/)

Leistungsergebnisse 2023

Die Leistungsergebnisse von GASNet-EX werden auf der Leistungsseite von Berkeley Lab GASNet für eine Vielzahl von Maschinen gemeldet.

Aktuelle Frontier-Ergebnisse zur Messung der Leistung von Get- und Put-RMA-Vorgängen im Vergleich zur HPE Cray MPI-Bibliothek zeigen, dass GASNet-EX ab Juni 2023 mit dem schnellsten Supercomputer der Welt eine vergleichbare Bandbreitenleistung liefern kann (Abbildung 8).

Diese „Flood-Bandbreite“-Benchmark-Ergebnisse messen die erreichbare Verbindungsbandbreite für eine bestimmte Übertragungsgröße, indem eine große Anzahl nicht blockierender Übertragungen (z. B. die „Flood“) initiiert und darauf gewartet wird, dass alle vollständig abgeschlossen sind. Die gemeldete Metrik ist das gesamte übertragene Datenvolumen geteilt durch die insgesamt verstrichene Zeit. Der Benchmark meldet unidirektionale (ein Initiator zu einem Ziel) Flutbandbreiten, bei denen das passive Ziel in einem geeigneten Synchronisierungsvorgang wartet.[2]

Die Bandbreite ist nur ein Teil der Wahrheit, da viele HPC-Anwendungen durch die Latenz des Kommunikationsvorgangs eingeschränkt sein können. Abbildung 9 zeigt die durchschnittliche Zeit bis zum vollständigen Abschluss eines einzelnen RMA-Put- oder Get-Vorgangs auf der Frontier Slingshot-11-Verbindung, berechnet durch die Zeitmessung einer langen Sequenz von Blockierungsvorgängen (je niedriger, desto besser). [3]

Die aktuellen Ergebnisse zur GPU-Bandbreite und Latenz auf dem Crusher-Testbed für den Frontier-Supercomputer sind vorläufig und in Arbeit. [4]

Mitentwickelte ECP-Projekte

Hargrove wies darauf hin, dass das Exabiome-Projekt, das für den Gordon Bell Award nominiert wurde, ein in enger Zusammenarbeit mit Pagoda entwickeltes Projekt sei. Weitere Projekte sind ExaGraph, NWChemEx und AMReX (Abbildung 1).

Kathy Yelick, leitende Beraterin für Informatik und Dozentin am Berkeley Lab, Leiterin des Exabiome-Projekts des Exascale Computing Project (ECP) und Vizekanzlerin für Forschung an der UC Berkeley, hob die Vision ihres Teams für das Exabiome-Projekt hervor: „Das Exabiome-Team baut sich auf Ein Toolset zur Arbeit mit Terabytes an Daten (die Billionen Basenpaare enthalten), wobei wir derzeit nicht alle Proteine ​​verstehen, die durch diese Basenpaare kodiert werden. Um zu verstehen, wie Mikrobiome funktionieren, ist es wichtig, die Ähnlichkeiten zwischen Proteinen und ihre Wechselbeziehungen zu verstehen. Dazu sind sehr leistungsfähige Rechenwerkzeuge erforderlich, die in diesen riesigen Datensätzen auf die Funktionen verwandter Proteine ​​schließen können.“ Mikrobiome sind kooperative Gemeinschaften von Mikroben. Diese Organismen und die Organismen in assoziierten Mikrobiomen spielen eine zentrale Rolle beim Klimawandel, der Umweltsanierung, der Lebensmittelproduktion und der menschlichen Gesundheit.[5]

Um den Erfolg ihres Ansatzes zu demonstrieren, nutzte das Exabiome-Team über 20.000 GPUs auf dem Summit-Supercomputer des Oak Ridge National Laboratory (ORNL), um eine Viele-gegen-Viele-Proteinähnlichkeitssuche im größten verfügbaren Proteindatensatz durchzuführen. Die beobachtete Leistung war transformativ, da die Suche innerhalb von Stunden statt in Wochen abgeschlossen wurde.

Um die GPU-Beschleunigung von HipMer und MetaHipMer2 zu erreichen und eine De-novo-Genomassemblierung im extremen Maßstab durchzuführen, war die Verwendung von UPC++ erforderlich. MetaHipMer ist ein Produktions-Metagenom-Assembler, der mit ECP-Finanzierung in UPC++ neu geschrieben wurde. Es ist auf die Metagenomik zugeschnitten und für GPUs optimiert.

Der außergewöhnliche (für den Gordon Bell Award würdige) Leistungsvorteil wurde in der Präsentation „Exabiome: Then and Now“ auf der ECP-Jahrestagung 2023 von Lenny Oliker (geschäftsführender Direktor des Exabiome-Projekts, leitender Wissenschaftler und Gruppenleiter der Leistung des Berkeley Lab AMCR) hervorgehoben und Algorithmengruppe) und Kathy Yelick (leitende Beraterin für Informatik und Fakultätsmitarbeiterin am Berkeley Lab, PI des ECP Exabiome-Projekts und Vizekanzlerin für Forschung an der UC Berkeley) stellen fest, dass „die Beschleunigung von 2016 bis 2021 mehr als 250-fach beträgt algorithmische Verbesserungen, Einsatz von GPUs und UPC++“.[6] In der Präsentation wurde auch die Bedeutung der Flutbandbreitenleistung erörtert (Abbildung 8). Weitere Einzelheiten finden Sie in „GASNet-EX: A High-Performance, Portable Communication Library for Exascale“ und „GASNet-EX RMA Communication Performance on Recent Supercomputing Systems“.

Auf der Exabiome-Website heißt es kurz und bündig: „Die hohe Leistung von MetaHipMer basiert auf mehreren neuartigen algorithmischen Fortschritten, die durch die Nutzung der Effizienz und Programmierbarkeit der einseitigen Kommunikationsfunktionen und RPC-Aufrufe von UPC++ erreicht werden, einschließlich optimierter Hochfrequenz-K-Mer-Analyse und Kommunikationsvermeidung.“ de Bruijn-Graph-Traversal, erweiterte I/O-Optimierung und umfassende Parallelisierung über die zahlreichen und komplexen Anwendungsphasen hinweg.“ [7]

Eine ausführliche Diskussion finden Sie im Artikel „Beschleunigung der De-novo-Metagenomassemblierung in großem Maßstab mithilfe von GPUs“ und im zugehörigen Präsentationsvideo.

Zusammenfassung

Das Community-Modell des Pagoda-Projekts geht auf die Softwareentwicklungsanforderungen von Entwicklern ein, die den weltweit gemeinsam genutzten Adressraum von PGAS nutzen, um die Produktivität zu verbessern und leistungsstarke, skalierbare Modelle zu implementieren. Die GPU-Beschleunigung erhöhte den Wert des PGAS-Modells, indem sie den Zugriff auf Daten in einer verteilten heterogenen Computerumgebung erleichterte und gleichzeitig das Bewusstsein für ungleichmäßige Kommunikationskosten berücksichtigte, was eine Optimierung ermöglichte – selbst wenn das Datenzugriffsverhalten zu komplex und unregelmäßig ist, um vorhersehbar zu sein.

Diese Forschung wurde vom Exascale Computing Project (17-SC-20-SC) unterstützt, einem gemeinsamen Projekt des Office of Science des US-Energieministeriums und der National Nuclear Security Administration, das für die Bereitstellung eines leistungsfähigen Exascale-Ökosystems verantwortlich ist, einschließlich Software, Anwendungen, und Hardwaretechnologie, um die Exascale-Computing-Anforderung des Landes zu unterstützen.

Rob Farber ist ein globaler Technologieberater und Autor mit umfangreichem Hintergrundwissen im Bereich HPC und in der Entwicklung von Technologien für maschinelles Lernen, die er in nationalen Labors und kommerziellen Organisationen anwendet.

Quelle: Rob Farber, ECP