Die Kunst des Hochleistungsrechnens

 (theartofhpc.com)
3 Punkte von GN⁺ 2023-12-31 | 1 Kommentare | Auf WhatsApp teilen
  • The Art of HPC ist eine von Victor Eijkhout vom TACC erstellte Lehrbuchreihe zum Hochleistungsrechnen, die von den Grundlagen des wissenschaftlichen Rechnens bis zu paralleler Programmierung und Entwicklungswerkzeugen alles in einem durchgehenden Zusammenhang bündelt
  • Der erste Band ist ein Hintergrundband zum wissenschaftlichen Rechnen, der behandelt, wie Computerarchitektur, Arithmetik, lineare Algebra und ODE/PDE bei groß angelegten Berechnungen zusammenspielen
  • Der zweite Band erklärt MPI und OpenMP als Kern der parallelen Programmierung und enthält außerdem kurze Abschnitte zu PETSc, Kokkos, Sycl und Co-array Fortran
  • Der dritte Band behandelt C++17 und Fortran2008, wie sie in der wissenschaftlichen und technischen Programmierung verwendet werden, und kann sowohl von Einsteigern als auch von C-Programmierern gelesen werden
  • Der vierte Band stellt Werkzeuge für den Entwicklungs-Workflow vor, die für die praktische HPC-Arbeit nötig sind, etwa Compiler, Build-Systeme und Quellcodeverwaltung

Aufbau der Lehrbuchreihe The Art of HPC

  • The Art of HPC ist eine von Victor Eijkhout vom TACC erstellte Lehrbuchreihe zum Hochleistungsrechnen
  • Die Reihe behandelt bandweise den Hintergrund des wissenschaftlichen Rechnens, parallele Programmierung, wissenschaftliche Programmiersprachen und das HPC-Entwicklungsökosystem

Umfang der einzelnen Bände

  • Volume 1: The Science of Computing

    • Behandelt das allgemeine Hintergrundwissen, das zum Verständnis des wissenschaftlichen Rechnens nötig ist
    • Enthalten sind Computerarchitektur, parallele Computerarchitektur, Computerarithmetik, lineare Algebra und ODE/PDE
    • Es wird erklärt, wie sich diese Elemente bei groß angelegten Berechnungen verbinden; zusammen mit Volume 2 bildet dies das „Was/Warum“ und das „Wie“ von HPC

  • Volume 2: Parallel Programming for Science and Engineering

    • Dieser Band behandelt die für das wissenschaftliche Rechnen wichtige parallele Programmierung
    • Im Mittelpunkt stehen moderne Versionen von MPI und OpenMP
    • Enthalten sind auch kurze Abschnitte zu PETSc, Kokkos, Sycl und Co-array Fortran
    • MPI und OpenMP werden für C, Fortran und C++ behandelt; bei MPI kommt auch Python hinzu

  • Volume 3: Introduction to Scientific Programming

    • Vor dem Hintergrund von C/C++ und Fortran, die in der wissenschaftlichen und technischen Programmierung häufig verwendet werden, lehrt der Band modernes C++17 und Fortran2008
    • Der Ansatz gibt C++17 gegenüber C den Vorzug
    • Das Buch kann sowohl als Einführung in die wissenschaftliche Programmierung von Grund auf als auch als C++-Lernbuch für C-Programmierer gelesen werden
    • Es enthält mehrere umfangreiche Programmierprojekte

  • Volume 4: HPC Carpentry

    • Der Band legt den Fokus darauf, dass das Ökosystem des wissenschaftlichen Rechnens nicht nur aus Programmiersprachen und Systemen für parallele Programmierung besteht
    • Er stellt Elemente vor, die für wissenschaftliche Workflows nötig sind, darunter Compiler, Build-Systeme und Quellcodeverwaltung
    • Es handelt sich weniger um ein allumfassendes Nachschlagewerk als vielmehr um eine einführende Sammlung, zugeschnitten auf wissenschaftliche Workflows

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-12-31
Hacker-News-Kommentare

  • Die Hardware-/Datacenter-Seite dieses Themas ist genauso spannend.
    Früher habe ich bei AWS im Bereich Software/Services gearbeitet und bin gelegentlich heimlich zu Präsentationen des Datacenter-Teams gegangen.
    Die größte Erkenntnis war, dass das Erhöhen der Rechenleistung in einem Datacenter eher ein thermodynamisches Problem ist als eigentliches Computing. Die Knotendichte ist so stark gestiegen, dass es extrem schwierig ist, Strom hineinzubringen und Wärme abzuführen – und dazu noch allerlei Redundanzen einzubauen. Selbst wenn man Ineffizienzen findet, kann man sie nicht einfach wie mit einem Software-Update beheben.
    Das ist etwa zehn Jahre her, daher mag sich inzwischen manches geändert haben, aber es ist erstaunlich, dass Amazon, das als Online-Buchhandlung begann, heute an vorderster Front bei der Lösung thermodynamischer Probleme steht.

    • Seymour Cray sagte schon in den 1970er-Jahren, das größte Problem sei die Wärmeabfuhr.
      Beim Cray-2 wählte man einen noch extremeren Ansatz: eine Kühlkonstruktion, bei der dicht gepackte Stapel von Leiterplatten in eine spezielle, nicht leitende Flüssigkeit namens Fluorinert™ getaucht wurden: „The Cray-2's unusual cooling scheme immersed dense stacks of circuit boards in a special non-conductive liquid called Fluorinert™“
    • Ich habe mich immer gefragt, warum Flüssigkühlung in Datacentern nicht weiter verbreitet ist.
      Wasser hat eine sehr hohe Wärmekapazität und kann große Mengen schnell auf die optimale Temperatur herunterkühlen. Lüfter und Klimaanlagen braucht man weiterhin, um die Wärme von Komponenten abzuführen, die sich nicht per Flüssigkeit kühlen lassen, aber bei großen Stromverbrauchern wie CPUs oder GPUs/Rechen-Engines könnte man enorme Wärmemengen schnell und direkt abführen.
      Die Komplexität und das Risiko von Lecks sind natürlich ein Problem, aber bei Datacentern in der Größenordnung von Amazon scheint mir das keine allzu große Sorge zu sein.
    • Gibt es gute Daten oder Visualisierungen, die die Größenordnung dieses Problems zeigen?
      Ich frage mich, wie modernste Kühltechnologie heute aussieht.

  • Interessant ist, dass HPC manchmal ziemlich stark von der Hardware abstrahiert wirkt
    Bücher scheinen viel über SPMD-Programmierung, Algorithmen und Datenstrukturen, Task-Parallelität, Synchronisierung usw. zu behandeln, aber Details der Computerarchitektur wie Speicher-Subsysteme von Supercomputern, High-Bandwidth-Interconnects wie CXL oder GPU-Architekturen scheinen seltener vorzukommen
    Ich frage mich, ob Abstraktionen und Tools inzwischen gut genug sind, dass man sich um solche Details nicht kümmern muss, oder ob HPC-Praktiker doch viele Blackbox-Regler drehen, um Performance herauszuholen

    • In den meisten HPC-Umgebungen lassen sich Parallelität und Durchsatz nicht maximieren, ohne Hardwarearchitektur und -verhalten tief zu verstehen
      Als allgemeines Prinzip gilt: Für optimale Skalierbarkeit sollte die Topologie der Software so weit wie möglich zur Topologie der Hardware passen. Effiziente HPC-Software wird stark von den Hardwareeigenschaften beeinflusst
      Wenn ich für neue HPC-Hardware Code schrieb und nicht nach Programmierdokumentation, sondern nach Systemhardware- und Architekturdokumenten fragte, waren die Leute immer überrascht. Verstand man das Hardwaredesign, wurde aus First Principles klar, wie man darauf Software entwerfen sollte. In der Programmierdokumentation standen ziemlich viele Halbwahrheiten, die Entwicklern die Sache einfacher erscheinen lassen sollten, als sie tatsächlich war
      Manche HPC-Plattformen haben, um „einfach zu benutzen“ zu wirken, beharrlich falsch vermittelt, was Entwickler tun müssen, um maximale Performance zu erreichen. Schrieb man Software so, wie es das Marketing nahelegte, verfehlte man die Leistung, zu der das Silizium fähig war, teils deutlich
      Man kann HPC-Code über Abstraktionen schreiben, und viele tun das auch, aber die Verluste bei Performance und Skalierbarkeit liegen oft bei unvermeidbaren ganzzahligen Faktoren. Wie bei anderer Software wurden solche Verluste oft akzeptiert, wenn dadurch weniger erfahrene Entwickler den Code entwerfen konnten
      Bei HPC ist es wie bei anderer Software: Viele Menschen, die dem Titel nach professionelle Entwickler sind, tun sich schwer, konstant gute Ergebnisse zu liefern. Ein erheblicher Teil der teuren Hardware, die in HPC eingesetzt wird, existiert, um Performanceverluste durch schlechtes Softwaredesign abzumildern
      Wer maximale Performance will, hat keine Abkürzung daran vorbei, wirklich zu verstehen, wie die Hardware funktioniert. Das ist nicht anders als bei gewöhnlicher Software; bei HPC sind die Hardwaresysteme nur größer und komplexer
    • Ich habe vor etwa zwei Jahren in einem Cluster mit rund 500 Nodes bei einem Fortune-100-Unternehmen mit HPC-Arbeit angefangen. Eigentlich suchte ich eine Stelle, die zu 100 % Linux ist, und bisher macht es Spaß
      Es war aber anders als erwartet. Ich dachte, ich würde mehr performanceorientierte Arbeit machen, Zahlen analysieren und die letzte Leistung aus dem Cluster herausquetschen. Ehrlich gesagt gab es am Anfang nicht einmal Monitoring. Ich habe es selbst aufgebaut, aber es wird kaum genutzt. Ab und zu fragt das Management, etwa zur Budgetrechtfertigung, „wie ausgelastet der Cluster ist“
      Der Großteil der „Optimierung“ besteht darin, zu prüfen, dass Leute nicht 384 CPUs anfordern, obwohl ihr Skript nur 16 CPUs nutzt, oder zu testen, bis zu wie vielen CPUs eine bestimmte Software ohne Performanceeinbruch läuft. Den Intel Profiler habe ich genau zweimal geöffnet
      Der größte Teil der Arbeit besteht eher darin, Forschenden bei ihren Jobs zu helfen. Meist führen wir kommerzielle oder Open-Source-Programme aus und beheben Probleme, oder wir nehmen Code, den ein anderes Team auf einem anderen Cluster geschrieben hat, und bringen ihn dazu, auf unserem Cluster zu bauen und zu laufen. Ich wühle mich durch miserablen Python-Code und versuche, C++-Projekte aus moderneren Clustern für eine CentOS-7-Umgebung zu bauen
      Auf seine Art macht es Spaß. Da ich mit mehreren Sprachen gearbeitet habe, mag ich es, Dinge zum Laufen zu bringen und Crashes und Stacktraces nachzugehen. Wenn man mit großer Hardware arbeitet, verschiebt sich der Normalmaßstab, wenn man einen Server sieht, der „nur“ 128 GB RAM oder 20 TB Plattenplatz hat
      Beängstigend ist, dass diese Ergebnisse in der realen Welt genutzt werden, während die Leute, die die Simulationen laufen lassen, es manchmal nicht richtig machen. Ich habe falschen Code, durcheinandergewürfelten Quellcode, die Verwendung anderer Daten als der, von denen sie dachten, sie würden sie nutzen, und einen riesigen Bug gefunden, der drei Jahre lang existiert hatte. Dann fragt man sich, ob damit nicht die gesamte Arbeit zu diesem Thema ungültig wird
      Der Nachteil ist, dass viele HPC-Jobs, obwohl sie nur Clusterbetrieb sind, einen Masterabschluss verlangen. Das verstehe ich nicht. Ich schreibe nicht die Software, die ich ausführe, und betreibe auch keinen aktuellen TOP500-Cluster. Es geht nur darum, mehrere Maschinen zu vernetzen und Code darauf laufen zu lassen
    • Es gibt viele Abstraktionen, aber um zu wissen, welche Abstraktion man verwenden sollte, muss man immer noch viel über die Hardware wissen
      Aus meiner Erfahrung mit CUDA-Entwicklern: Um Performance herauszuholen, dreht man an vielen Reglern. Ein Shmoo Plot (https://en.wikipedia.org/wiki/Shmoo_plot, in manchen Branchen auch „wedge“ genannt) ist eines der zentralen Werkzeuge der alltäglichen Optimierung
      Ob ich das allerdings als Blackbox bezeichnen würde, weiß ich nicht. Am Ende kann es ähnlich sein. Selbst wenn man weiß, was die Regler tun und wie sie funktionieren, und begründete Vermutungen anstellt, erlebt man bei Messungen häufig große Überraschungen. Die erste Regel der Optimierung lautet: messen
      Mir fällt dabei immer das erste Kapitel „The Best Optimizer is Between Your Ears“ aus Michael Abrashs „Black Book“ ein: http://twimgs.com/ddj/abrashblackbook/gpbb1.pdf. Es geht zwar eher um PC-Spiele als um moderne HPC, ist aber ein hervorragender Text, der die Philosophie hoher Performance gut zeigt
      In Bezug auf Abstraktionen sollte man das schwerste Regler-Tuning am besten am Ende des Optimierungsprozesses machen. Denn wenn man refaktoriert oder etwas ändert, muss man das Tuning der Regler erneut durchführen. Schon kleine Änderungen bei Register-Spills oder Cache-Zugriffsmustern können feines Tuning wie Thread-Konfiguration, Cache und Größe des Shared Memory komplett zurücksetzen
      Trotzdem ist zwischendurch ein angemessenes Maß an Regler-Tuning nötig: als Check and Balance und um Intuition für den Performance-Raum rund um den Code zu gewinnen
    • Als HPC-Administrator unterstütze ich üblicherweise Forschende aus dem „Long Tail der Wissenschaft“
      Auf heutiger x86_64-Hardware gibt es so etwas wie ein Speicher-Subsystem eines Supercomputers nicht. Es ist einfach ein schickes NUMA-System, und das größte Problem besteht darin, Speicher nahe an den Cores zu halten, also Daten lokal innerhalb des jeweiligen NUMA-Nodes zu halten, um Latenz zu reduzieren
      Die Ressourcenzuordnung übernimmt der Scheduler. Der Scheduler kennt die Hardware, erstellt eine cgroup, die die Anforderungen erfüllt und so weit wie möglich optimiert ist, und setzt die Anwendung zur Ausführung in diese cgroup

Der aktuelle König der Hochleistungs-Interconnects ist InfiniBand; es beschleunigt MPI auf Fabric-Ebene. Nachrichtenübertragung, Broadcasts und Reduktion von Ergebnissen lassen sich damit extrem schnell durchführen. Wenn eine Nachricht ankommt, ist sie bereits reduziert, und beim Broadcast muss man nur eine einzige Nachricht senden, die dann auf der Fabric-Schicht verbreitet wird. Multi-Context-IB-Karten haben viele Queues, sodass auf einem Node/einer Karte mehrere MPI-Jobs mit Queue-/Context-Isolation laufen können
Wenn man für GPU-Workloads ein Framework verwendet, werden Struktur und Optimierung normalerweise auf dieser Ebene automatisch erledigt. Die harte Arbeit machen meist die Framework-Entwickler. Auch der NVIDIA-Treiber ist reine schwarze Magie und übernimmt einen Teil der Optimierung. Die Verbindungen zwischen GPUs werden vom physischen Fabric bereitgestellt und vom Treiber sowie einem eigenen Daemon verwaltet
Wenn die CPU der Flaschenhals ist, sind die Bibliotheken in der Regel vom Anbieter von Hand getunt. Beispiele sind Intel MKL, BLAS, Eigen usw.; Eigen, das ich persönlich verwendet habe, enthielt prozessorspezifische Hints und Optimierungen
Worauf man achten muss, ist, den Code für die richtige Architektur zu kompilieren und sicherzustellen, dass die Hardware, auf der er läuft, die Anforderungen erfüllen kann. Zum Beispiel sollte man nicht zu viele zufällige Speicherzugriffe machen, Prefetcher und Branch Predictor gut treffen, wenn man auf dem Node „so schnell wie möglich“ sein will, und Disk-Zugriffe nicht missbrauchen
Bei numerischen Berechnungen ist entscheidend, die Arbeit unabhängig zu halten, damit Parallelität auf Instruktionsebene/Vektorisierung möglich ist, keine unnötigen Berechnungen auszuführen und MPI nicht zu überstrapazieren – also die Kommunikation zwischen Nodes auf das unbedingt nötige Maß zu reduzieren
Das ist leichter gesagt als getan, aber wenn man sich daran gewöhnt hat, wird es zur zweiten Natur, über solche Dinge nachzudenken. Vorausgesetzt, diese Art von Arbeit entspricht dem eigenen Geschmack

  • Teils ja, teils nein
    MPI und OpenMP sind in HPC die wichtigsten Mittel, um Hardware zu abstrahieren. MPI ist die Abstraktion für paralleles Rechnen mit verteiltem Speicher, OpenMP die Abstraktion für paralleles Rechnen mit gemeinsamem Speicher. Viele Forschende schreiben ihren Code nur mit diesen beiden, und oft werden beide im selben Code verwendet. Wenn man sie nutzt, muss man sich meist nicht um Details der Architektur kümmern
    Forschende, die gerne weiter optimieren, drehen dennoch an vielen kleinen architekturellen Details, um noch mehr Leistung herauszuholen. Zum Beispiel ist Loop Unrolling recht verbreitet, und ich persönlich finde, dass es ziemlich verwirrend sein kann. Ich erinnere mich vage an Aussagen, dass man wegen einer bestimmten CPU-Architektur Additionen gegenüber Multiplikationen bevorzugt, um Operationen zu vektorisieren, habe das aber nie selbst gesehen
    Cache Misses zu verhindern ist ebenfalls ein großes Thema. Manche Codes sind so geschrieben, dass die wichtigsten Informationen im CPU-Cache liegen statt im Hauptspeicher. Die meisten Codes behandeln das nur so weit, dass sie in Fortran bei Array-Operationen spaltenweise Iteration und in C zeilenweise Iteration sicherstellen, aber das Konzept lässt sich weiter ausbauen. Wenn man die Cache-Größe des Prozessors kennt, kann man bestimmte Operationen so optimieren, dass alle benötigten Informationen im Cache bleiben und Cache Misses minimiert werden. Ich habe das in der Praxis nie gesehen, aber in einem Kurs zu wissenschaftlichem Rechnen, den ich 2013 gehört habe, wurde es intensiv behandelt
    Ob man eine bestimmte GPU nutzt, hängt stark vom zu lösenden Problem ab. Manche Probleme laufen hervorragend auf GPUs, andere sind zu schwierig. Darüber weiß ich leider nicht besonders viel

  • Ich bin beeindruckt, dass Victor so hervorragendes Material zusammengetragen hat.
    Ich kenne ihn nicht persönlich, aber ich habe in den 1990er-Jahren an der UT Austin promoviert und meine Forschung mit Ressourcen abgeschlossen, die vom TACC verwaltet wurden (Cray Y-MP, IBM SP/2 Winterhawk und Lonestar, damals der Hostname für die Cray T3E). Eine Person aus meinem Promotionskomitee ist immer noch dort. Wenn ich mich richtig erinnere, hieß TACC damals HPCC oder CHPC.
    Damals mussten Programmierer ihren Code selbst parallelisieren; in meinem Fall nutzte ich MPI auf der Cray T3E unter UNICOS. Da das Feld noch jung war, brauchte man auch ein gewisses Verständnis der Hardware. Ich löste Probleme, indem ich die grauen Cray-Ringordner und das Buch von Gropp et al. las, das ich zur Hand hatte; natürlich war auch der oben erwähnte sachkundige Kontakt eine große Hilfe.

    • Lonestar5 war wieder eine Cray. Die aktuelle Lonestar6 ist ein ölgekühlter AMD-Milan-Cluster mit A100-GPUs.
      Die Zeit bleibt nie stehen.
    • Ich habe mit ihm zusammengearbeitet, als ich über TACC große Simulationen durchführte, und aus Dankbarkeit für seine Hilfe habe ich den ersten Band dieser Reihe als gedrucktes Buch gekauft.
      Es liegt etwas außerhalb meines Fachgebiets, war aber sehr interessant. Ich werde mir auch den Rest ansehen und empfehle allen Interessierten, einen Blick darauf zu werfen.

  • Ich interessiere mich für die Hardwareverwaltung im HPC-Bereich.
    Mich interessiert, wie Probleme erkannt und diagnostiziert werden und wie sie auf Maßnahmen wie Neustart, Neuinstallation oder Reparatur abgebildet werden, wie solche Arbeiten geplant und optimiert werden, um das bestmögliche Serviceniveau zu bieten.
    Außerdem interessiert mich, wie man vorgeht, wenn es mehrere Ziele gibt, die gleichzeitig optimiert werden müssen, etwa Node-Verfügbarkeit und Gesamtdurchsatz; wie sich verschiedene Topologien darauf auswirken; welchen Einfluss andere Einschränkungen haben; und ganz allgemein, wie man solche Probleme aus Sicht der Systemdynamik behandelt.
    Ich habe nicht viele gute Ressourcen gefunden, die diese Informationen abdecken. Wenn jemand Material kennt, würde ich mich über Hinweise freuen.

    • Wenn du über ein typisches non-blocking folded-Clos-Netzwerk oder Little’s Law hinaus eine stärker ingenieurwissenschaftliche Perspektive willst, solltest du dich in Warteschlangentheorie vertiefen.
      Warteschlangentheorie wirkt beim ersten Lernen trivial und einfach, hat aber viele offene Probleme.
      Zum Beispiel sind Performance-Metriken für ein System mit zufälligen Ankunftszeiten, unabhängigen Servicezeiten und k Servern (M/G/k) immer noch ein offenes Problem.
      https://www.sciencedirect.com/science/article/pii/S0895717704905341
      Entgegen der Erwartung gibt es in der Warteschlangentheorie wirklich viele offene Probleme.
    • Als ich vor ein paar Monaten Interviews bei Meta und nVidia hatte, schien das ein großes Thema zu sein.
      Meta hatte einige gute YouTube-Videos, die die Probleme beim Umgang mit GPUs in dieser Größenordnung erklärten.
    • Mark Russinovich hält fast jedes Jahr gute Vorträge über das Innenleben von Azure und die Systeme, die es antreiben. [1] ist ein Beispiel, und auch die Vorträge aus anderen Jahren sind einen Blick wert.
      Meta veröffentlicht auf seiner Engineering-Website ebenfalls viele Papers, Blogposts und Open-Source-Projekte. [2]
      James Hamilton von AWS hält ebenfalls fast jedes Jahr Vorträge über Infrastruktur. Es lohnt sich, die Vorträge aus mehreren Jahren anzusehen. [3]
      [1] https://youtu.be/69PrhWQorEM?si=u7vh_Um6SQNoyeFH
      [2] https://engineering.fb.com/category/data-center-engineering/
      [3] https://youtu.be/AyOAjFNPAbA?si=nFRJVcQI4EiamC-O
    • Dieses Paper von Microsoft [1] war das Coolste, was ich in diesem Bereich gesehen habe.
      Im Grunde optimiert es auf Ebene der Workloads, hier Deep-Learning-Jobs, und ermöglicht so Größenanpassung und Preemption von Jobs.
      [1] https://arxiv.org/pdf/2202.07848.pdf
    • Schau dir das openbmc-Projekt und die DMTF-Organisation an.

  • 2013 habe ich einen Kurs in Scientific Computing belegt.
    Es war ein Kurs, der sowohl in Informatik als auch in angewandter Mathematik angeboten wurde. Das Problem war, dass das Feld insgesamt so breit ist, dass viele Themen, darunter HPC und Parallelprogrammierung, nur sehr oberflächlich behandelt wurden. Ich bereue nicht, ihn belegt zu haben, aber für die Anwendungen, die ich verfolgte, war er zu breit.
    Ich habe seit Jahren nicht mehr nachgesehen, welche Kurse angeboten werden, aber als ich Doktorand war, wäre ein eigener Kurs, der ein ganzes Semester lang paralleles Rechnen behandelt, wirklich hilfreich gewesen. Besonders nötig gewesen wäre ein Kurs, der bestimmte Algorithmen und Datenstrukturen für paralleles und verteiltes Rechnen vertieft.
    In dem Scientific-Computing-Kurs, den ich besucht habe, wurden diese Inhalte viel zu grob behandelt, fast so, als könne man schon beim ersten Versuch genau wissen, wie man etwas korrekt parallelisiert. Später habe ich, wie viele HPC-Leute, über Jahre hinweg viel allein und von Kolleginnen und Kollegen gelernt, aber solche Bücher wären als Teil eines dedizierten Semesterkurses sehr wertvoll gewesen.

  • Es ist erstaunlich, dass der Autor so umfassende Bücher erstellt und kostenlos geteilt hat, die sogar Schulungen zu C++ und Unix-Tools enthalten.
    Auch wenn sie nicht ausschließlich HPC-spezifisch sind, kann jede Programmiererin und jeder Programmierer daraus etwas lernen.
    Als verwandtes Material gibt es auch Jorg Arndts Buch „Matters Computational“ und die FXT-Bibliothek: https://www.jjj.de/fxt/

  • Mich würde interessieren, wie ihr die hier verwendete C++-Lehrmethode einschätzt. Gibt es besondere Nachteile?
    Ich nutze Python schon sehr lange, beschäftige mich auch etwas mit C, C++ und CUDA und arbeite in einer HPC-Umgebung an anwendungsnaher Forschung (ML/DL). Ich möchte meine C++-Kenntnisse verbessern, und nachdem ich die drei Bände überflogen habe, scheinen sie genau zu meinem Niveau zu passen. Es geht nicht zu langsam voran und zielt nicht auf Vollständigkeit ab, sondern vermittelt die vom Autor empfohlenen Best Practices.

    • Aus Sicht eines C++-Programmierers und Lehrenden sind diese drei Bände gut strukturierte Lehrmaterialien für Einsteiger. Das meiste davon kennst du vermutlich schon.
      Ich habe nach range-based for loops, std::array und std::span gesucht, und erfreulicherweise sind sie alle enthalten.
      Da das Buch einen Bezug zu HPC hat, würde ich gern noch ein paar Dinge ergänzen: Return Value Optimization, Move-Semantik und im Abschnitt zu rekursiven Funktionen eine Erklärung zur Tail-Call-Optimierung.
      Als Einsteigermaterial kann ich es sehr empfehlen.
    • Auffällig ist, dass Band 2 von „The Art of HPC“, „Parallel Programming for Science Engineering“, C, Fortran, C++ und im Fall von MPI auch MPI und OpenMP in Python behandelt: https://theartofhpc.com/pcse/index.html
      Zur Einordnung: MPI ist nur eine Möglichkeit, HPC mit Python zu betreiben.
      Wenn ich mich richtig erinnere, kann ipyparallel MPI-Jobs über einen selbst aufgebauten Tunnel ausführen.
      Kapitel zu dask-scheduler, CuDF, CuGraph (NetworkX), DaskML, CuPy und dask-labextension würden das Ganze aktueller machen.
      Dask übernimmt die Datenspeicherung nicht für einen; es liegt also in der Verantwortung der Nutzer, sicherzustellen, dass der Datenspeicher vor jeder Barriere nicht zum Performance-Flaschenhals wird.
      High Performance Computers in der Dask-Dokumentation: https://docs.dask.org/en/stable/deploying-hpc.html
      Auch die Zufallsquelle kann ein Flaschenhals sein. Das weiß man erst, wenn man die Arbeit über den gesamten Cluster hinweg profiliert.
      Zu eBPF-basierten Tracing-Tools: https://news.ycombinator.com/item?id=31688180
      Danach wären auch Themen wie GitOps und ChatOps, Code-Reviews und Revisionen sowie Projekt-Ressourcenkontingente wünschenswert.

  • Vor zehn Jahren wurde ich gefragt, ob ich mir die Rolle als Teaching Assistant für einen HPC-Graduiertenkurs teilen wollte, aber ich habe abgelehnt.
    Nach einem groben Überfliegen kann ich ehrlich sagen: Wenn es dieses Buch damals gegeben hätte, hätte ich die Gelegenheit ergriffen.
    Die offenbar Knuth-artige Rahmung als Kunst, die Perspektive mit der Analogie zum Tischlerhandwerk und die Notwendigkeit, ein besserer DevOps-Mensch zu werden als der eigene DevOps-Verantwortliche, ergeben zusammen ein überzeugendes Bild.
    Ich applaudiere der Leistung des Autors. UT Austin scheint in der Informatik etwas Ähnliches geschafft zu haben wie North Texas State in der Musik.

  • UT Austin ist bei HPC und numerischen Methoden wirklich eine hervorragende Institution.

    • Fast jede BLAS-Implementierung, die man verwenden möchte, ist in irgendeiner Weise mit TACC der UT Austin verbunden.

  • Als ich zu einer kleinen Firma stieß, die HPC-Ingenieure eines großen Automobilherstellers unterstützte, war ich überrascht, wie viele intern entwickelte Skripte es rund um den Scheduler LSF gab.
    Viel später, als ich auf einem persönlichen Mini-Cluster mit SLURM herumprobierte, stellte ich fest, dass verschiedene Versionen der Scheduler-Software weitgehend nicht miteinander kompatibel sind. Man konnte also nicht innerhalb des Clusters eine Version und auf externen Client-Maschinen eine andere verwenden.
    Deshalb brauchte man Glue-Software, um von außen Jobs beim Scheduler einzureichen und später die Ergebnisse abzuholen. Persönlich finde ich, dass das den Wert des Schedulers mindert.
    Ich hätte gedacht, dass nach rund 30 Jahren High-Performance Distributed Computing die Anforderungen gut bekannt sind und zumindest die Protokolle für Befehls- und Datenaustausch feststehen. Offenbar ist dem nicht so.

    • Cluster-Authentifizierung ist tatsächlich weiterhin bei jeder Interaktion ein Ärgernis. Der kleinste gemeinsame Nenner ist auf den meisten Systemen, ob man per SSH auf einen Login-Node kommt. Ab diesem Punkt sind die wichtigsten Job-Kommandos wie sbatch/squeue ziemlich stabil.
      Es gab auch früher Versuche, grundlegende Job-Management-APIs zu standardisieren; DRMAA ist ein bemerkenswertes Beispiel. DRMAA v2 wurde allerdings nur von Grid Engine implementiert und war im Grunde eine leicht abstrahierte Version der internen API, sodass es bei Slurm/PBS/LSF keine erstklassige Unterstützung bekam.
      Bei Slurm gilt die REST API als der Weg nach vorn. Das Authentifizierungsproblem wird über einen Apache/NGINX-Proxy an jede beliebige Methode delegiert, die der Administrator anbinden möchte. Die grundlegenden APIs für Job-Einreichung und Status sind inzwischen so stabil, dass künftig fast jede Version einer Client-Anwendung sie konsumieren können sollte.