Vor kurzem habe ich meine Bachelorarbeit mit dem Titel „Übertragbarkeit von Benchmarkergebnissen auf reale wissenschaftliche Anwendungen” beendet. In diesem Beitrag möchte ich die wichtigsten Ergebnisse teilen. Ich hatte das Privileg, für meine Arbeit nicht nur auf die Ressourcen der Universität, sondern auch auf die meines Arbeitgebers zuzugreifen. Das brachte verschiedene Vorteile mit sich. Beispielsweise konnte ich Expertise von sowohl der Universität als auch meines Arbeitgebers nutzen. Außerdem hatte ich drei verschiedene HPC-Cluster zur Verfügung, auf denen ich meine Tests ausführen konnte. Zugriff auf 3 HPC-Cluster ist selten, insbesondere im Rahmen einer Bachelorarbeit. Daher bin ich den Beteiligten zu tiefem Dank verpflichtet. Jedoch hat das alles auch einen Nachteil: Ich kann nicht frei Daten direkt aus meiner Bachelorarbeit verwenden. Weder die Universität noch mein Arbeitgeber wären glücklich, wenn ich die genauen Fähigkeiten ihrer Cluster in die Welt posaunen würde. Zusammen mit meinem Wunsch, ein bisschen Anonymität zu bewahren, führt dies dazu, dass ich in diesem Blogpost nur die wichtigsten Lehren zusammenfassen und meine Bachelorarbeit paraphrasieren werde.

Einleitung

Benchmarks sind ein weit verbreitetes Werkzeug, um die Leistung von Computern einzuschätzen. Das trifft sowohl auf gebräuchliche Laptops als auch auf große HPC-Cluster zu. Eine genaue Einschätzung der Leistung ist beispielsweise relevant, wenn Hersteller neue Technologien erproben oder potentielle Käufer die Leistung ebendieser abschätzen wollen. Allerdings sind weit verbreitete Benchmarks nicht unumstritten. Insbesondere der HPL Benchmark, welcher die Grundlage für die viel beachtete Top500 Liste der stärksten Supercomputer weltweit ist, wird häufig wegen seiner geringen Aussagekraft kritisiert. Der HPL Benchmark versucht mit allen Mitteln, möglichst viele FLOP/s zu erreichen. Dafür minimiert er die Kommunikation zwischen den Prozessen sowie die Anzahl der Speicherzugriffe, um die CPU so gut wie möglich auszulasten. Beides ist nicht repräsentativ für reale wissenschaftliche Anwendungen (im Nachfolgenden nur noch Anwendungen genannt). Das hat zur Folge, dass HPL deutlich höhere FLOP/s erreicht als Anwendungen und deutlich besser auf vielen Knoten skaliert.
Um die Probleme mit HPL und ähnlichen Benchmarks auszugleichen, wurde eine Reihe von sogenannten anwendungsnahen Benchmarks entwickelt. Im Allgemeinen werden dafür Codes, wie sie in der Wissenschaft verwendet werden, in einen Benchmark verpackt. Damit sollen die Anforderungen realer Anwendungen angemessen dargestellt werden. Ein Beispiel für anwendungsnahe Benchmarks sind die NAS Parallel Benchmarks, kurz NPB, entwickelt von der NASA Advanced Supercomputing Division. Obwohl sie darauf ausgelegt sind, reale Anwendungen abzubilden, sind die Benchmarks sehr auf ihr spezielles Problem optimiert. Daher ist es fraglich, wie gut sie sich wirklich eignen, um die Rechenleistung von Clustern auf Anwendungen vorherzusagen.

Durchführung

Die Tests wurden mit vier Benchmarks und zwei Anwendungen durchgeführt. Um das Scalingverhalten untersuchen zu können, wurden die Tests in vier Szenarien durchgeführt:

1. Auf einem Knoten mit einer CPU, um nur Kommunikation auf einer CPU zu haben.
2. Auf einem Knoten mit beiden CPUs, um außerdem Kommunikation auf dem CPU-Interconnect zu haben,
3. Auf vier Knoten mit insgesamt acht CPUs (2 pro Knoten), um das Knoten-Interconnect außerdem zu verwenden.
4. Auf 64 Knoten mit 128 CPUs, um das Verhalten in massiv parallelen Umgebungen zu testen, in denen Kommunikation und Parallelizierbarkeit eine sehr wichtige Rolle spielen.

Die Ergebnisse der vier Benchmarks wurden verwendet, um Vorhersagen für die Rechenleistung auf den beiden Anwendungen zu machen. Außerdem offenbarten die Benchmarkergebnisse selbst interessante Details über die verwendete Hardware.

Benchmarks und Anwendungen

Es wurden drei synthetische Benchmarks verwendet: HPL, STREAM und vier Benchmarks aus der OSU-Microbenchmark Suite: allreduce, alltoall, bibw und latency. Allreduce und Alltoall sind MPI Routinen. Die Benchmarks messen die benötigte Zeit, um sie auszuführen. Bibw und Latency nutzen MPI-Routinen, um die bidirektionale Bandbreite beziehungsweise die Latenz zwischen zwei Knoten zu messen. STREAM ist ein Benchmark, welcher die Bandbreite des RAMs testet. Auf modernen Clustern ist der entscheidende Faktor für die Laufzeit eines Programms nicht mehr die Leistung der CPU, sondern wie schnell Daten zu der CPU gelangen können. Caches sind zwar eine sehr wichtige Technologie, aber letztendlich passen die wenigsten Probleme in den Cache einer Anwendung. Daher ist die Bandbreite des RAMs von zunehmender Bedeutung. Der vierte verwendete Benchmark ist die NPB Suite. Wie auch bei den OSU-Microbenchmarks wurden mehrere Benchmarks aus der Sammlung verwendet, und zwar die Conjugate Gradient (CG), Multigrid (MG) und Fourier Transformation (FT) Benchmarks. Conjugate Gradient und Multigrid sind beides Methoden zur Lösung linearer Gleichungssysteme, wobei Multigrid-Methoden häufig eine Conjugate-Gradient Methode anwenden.
Für die Anwendungen wurde NWChem ausgewählt, ein OpenSource Chemie-Projekt. Die andere Anwendung ist intern von meinem Arbeitgeber, sodass ich hier kein weiteres Wort über sie verlieren kann. Mit NWChem wurde eine DFT-Analyse des C28 Moleküls durchgeführt. DFT berechnet die Verteilung der Elektronen in einem Molekül. C28 ist das Molekül, welches entsteht, wenn 28 Kohlenstoffatome eine Bindung eingehen. Eine Einschränkung von NWChem ist, dass die DFT Analyse mithilfe von Gaußschen Basissätzen berechnet wird, welche schlechter parallelisierbar sind als andere.

Ergebnisse

Die Tests haben gezeigt, dass die Rechenleistung in Anwendungen nur eingeschränkt durch Benchmarkergebnisse vorherzusagen ist. Insbesondere reicht ein Benchmark alleine nicht aus, es müssen mehrere verwendet werden. Welche Kombination der Benchmarks die aussagekräftigsten Ergebnisse erzielt, hängt von der Anwendung ab, deren Rechenleistung vorhergesagt werden soll. Für CPU-intensive Anwendungen ist das Ergebnis in STREAM beispielsweise weniger relevant als für Anwendungen, welche große Mengen Daten verarbeiten müssen. Außerdem zeigte sich, dass insbesondere der HPL-Benchmark, trotz seiner immensen Verbreitung, wenig geeignet ist, um die Rechenleistung von Clustern unter realen Bedingungen abzuschätzen. HPL erreicht um ein Vielfaches höhere FLOP/s und skaliert insbesondere auf vielen Knoten viel besser als Anwendungen. Außerdem spiegeln die relativen Abstände zwischen Clustern bei HPL nicht unbedingt die relativen Abstände bei realen Anwendungen wieder, die Abstände bei HPL sind mitunter deutlich geringer. Dies ist darauf zurückzuführen, dass der meiste technologische Fortschritt bei CPUs nicht in der rohen Rechenleistung ihrer Kerne, sondern in der Größe und Geschwindigkeit des Caches liegt, welche von HPL kaum in Betracht gezogen werden.
Des Weiteren zeigen die Tests, dass selbst die anwendungsnahen Benchmarks der NBP Suite deutlich besser optimiert sind als die zur Verfügung stehenden Anwendungen. Auf einem Cluster konnte auf 8 CPUs sogar ein 22-facher Speedup erzielt werden. Die Anwendungen waren weit davon entfernt, wobei unter gewissen Umständen auch bei ihnen ein kleiner, superlinearer Speedup beobachtet werden konnte. Somit ist klar, dass Benchmarkergebnisse nur eingeschränkt übertragbar auf reale wissenschaftliche Anwendungen sind.