Aufgabenbasierte Parallelbibliotheken mit gemeinsamem Speicher in Scientific Computing

In den letzten Jahren sind mehrere Bibliotheken / Softwareprojekte erschienen, die die eine oder andere Form der datengesteuerten Parallelität für gemeinsam genutzten Speicher für allgemeine Zwecke bieten.

Die Hauptidee ist, dass Programmierer ihre Algorithmen nicht als explizit getunten Code schreiben, sondern als voneinander abhängige Aufgaben implementieren, die dann von einer Allzweck-Middleware auf einem Shared-Memory-Computer dynamisch geplant werden.

Beispiele für solche Bibliotheken sind:

• QUARK : Ursprünglich für die MAGMA- Bibliothek für parallele lineare Algebra entwickelt, scheint sie auch für eine parallele schnelle Multipolmethode verwendet worden zu sein.

• Cilk : Ursprünglich ein MIT-basiertes Projekt, die jetzt von Intel unterstützt, implementiert als Sprache / Compiler Erweiterungen C, in der verwendeten Cilkchess Computer Schach - Software und experimentell in FFTW .

• SMP-Superskalar : Entwickelt im Barcelona Supercomputing Center, ähnlich wie Cilk in vielerlei Hinsicht, basierend auf #pragmaErweiterungen.

• StarPU : Ähnliche bibliotheksbasierte "Codelets", die für verschiedene Architekturen, einschließlich GPUs, kompiliert und geplant werden können.

• OpenMP-Tasks: Ab Version 3.0 hat OpenMP "Tasks" eingeführt, die asynchron geplant werden können (siehe Abschnitt 2.7 der Spezifikation).

• Intels Threading-Bausteine : Verwendet C ++ - Klassen zum Erstellen und Starten asynchroner Aufgaben (siehe Abschnitt 11 des Lernprogramms).

• OpenCL : Unterstützt aufgabenbasierte Parallelität auf mehreren Kernen.

Obwohl es eine Menge Literatur gibt, die das Innenleben dieser Bibliotheken / Spracherweiterungen und ihre Anwendung auf bestimmte Probleme beschreibt, bin ich nur auf sehr wenige Beispiele gestoßen, die in der Praxis in wissenschaftlichen Computeranwendungen verwendet werden.

Hier ist also die Frage: Kennt jemand wissenschaftliche Computercodes, die eine dieser Bibliotheken / Spracherweiterungen oder ähnliches für die Parallelität von gemeinsamem Speicher verwenden?

deal.II verwendet die Threading-Bausteine ​​in der gesamten Bibliothek und im Großen und Ganzen sind wir ziemlich zufrieden damit. Wir haben uns einige Alternativen angesehen, insbesondere OpenMP, da jeder diese für einfachere Codes zu verwenden scheint, aber festgestellt hat, dass sie fehlen. Insbesondere hat OpenMP den großen Nachteil, dass das Aufgabenmodell es Ihnen nicht ermöglicht, ein Handle für eine gestartete Aufgabe zu erhalten, und folglich ist es schwierig, auf den Status einer Aufgabe zuzugreifen (z. B. auf deren Abschluss zu warten) oder Werte von zurückzugeben Funktionen, die Sie für eine separate Aufgabe ausführen. OpenMP eignet sich in erster Linie für die Parallelisierung der innersten Schleifen. Sie erzielen jedoch eine parallele Effizienz, indem Sie die äußersten , komplexen Schleifen parallelisieren. OpenMP ist nicht das Werkzeug dafür, während die TBB dafür einigermaßen gut geeignet sind.

Meiner Meinung nach waren diese Systeme vor allem aus folgenden Gründen relativ erfolglos.

• Die naive Perspektive der parallelen Berechnung besteht darin, die Berechnung (z. B. Flops) mehr zu parallelisieren als die Speicherlokalität freizulegen und Synchronisationspunkte zu entfernen. Obwohl einige Probleme, wie z. B. Dichtematrix-Algorithmen, immer noch FP-begrenzt sind, tritt dies nur nach sorgfältiger Prüfung des Speichersubsystems auf, und die meisten Rechenkerne (insbesondere in der PDE-Welt) sind speicherempfindlicher. Arbeitswarteschlangen tendieren dazu, die Speicherlokalität gegen ein besseres naives Gleichgewicht von Flops und atomarere Speicheroperationen auszutauschen (aufgrund der Synchronisation durch die Warteschlange).
• Verlassen Sie sich auf eine Überzerlegung für einen dynamischen Lastausgleich auf Kosten einer starken Skalierbarkeit. Aufgaben haben im Allgemeinen überlappende Datenabhängigkeiten (Geisterwerte). Wenn die Größe des Innenraums kleiner wird, nimmt das Verhältnis von Geist zu Innenraum zu. Selbst wenn dies keine redundante Arbeit impliziert, impliziert dies eine erhöhte Speicherbewegung. Erhebliche Reduzierungen der Speicherbandbreitenanforderungen können durch Ansätze wie das kooperative Prefetch erzielt werden, bei dem mehrere Threads einen L1- oder L2-Cache gemeinsam nutzen, indem sie für ihren Nachbarn Software-Prefetching durchführen (wodurch die Gruppe von Threads implizit ungefähr kohärent bleibt). Dies ist genau das Gegenteil von Überzersetzung.
• Unvorhersehbare Leistung, hauptsächlich aufgrund der oben genannten Speicherprobleme.
• Mangel an bibliotheksfreundlichen Komponenten. Dies kann fast so zusammengefasst werden, dass es kein Analogon von a gibt, MPI_Commdas es verschiedenen Bibliotheken ermöglicht, umfangreiche Operationen ohne Kollision auszuführen sowie den Kontext zwischen Bibliotheken zu übergeben und die erforderlichen Attribute wiederherzustellen. Die vom "Kommunikator" bereitgestellte Abstraktion ist wichtig für die Bibliothekszusammensetzung, unabhängig davon, ob gemeinsamer oder verteilter Speicher verwendet wird.