Antragssteller
Prof. Dr. Hans-Joachim Bungartz
Scientific Computing
TU München
Projektübersicht
Traditionell steht im Höchstleistungsrechnen (HPC) die Hardware im Vordergrund: Das Mooresche Gesetz gibt den Takt der Integrationsdichte von Transistoren bzw. der Leistungssteigerung von Prozessoren vor, die Top500-Liste weist die 500 weltweit stärksten Supercomputer aus, und die „Liga“, in der ein Standort spielt (die Ebene im Jargon der Pyramidenstruktur in Deutschland) , definiert sich i.W. über die Größe des vor Ort verfügbaren Systems. Seit geraumer Zeit ist jedoch unbestritten, dass ein mindestens ebenso kritischer Faktor auf dem Weg zu neuer Erkenntnis oder zu optimierten Produkten im Bereich der Software liegt. Denn was hilft der leistungsfähigste Rechner, wenn Anwendungscodes auf ihm nicht effizient zum Laufen gebracht werden? Der Tianhe-2- Rechner in China ist hierfür ein Beispiel: beeindruckende Peak-Performance, beeindruckende Linpack-Performance, jedoch lange Zeit nur wenige echte Anwendungen. Insofern benötigt ein leistungsfähiges HPC-Ökosystem „Racks & Brains“, also Rechner und erfahrene Experten in Software-Entwicklung und Hardware-naher Programmierung.
Hier liegt jedoch ein großes Problem – woher nehmen? Die Fördermittel, aus denen die Rechner finanziert werden, sind typischerweise reine Investitionsmittel; die Fördermittel, die z.B. die DFG für HPC-Projekte vergibt, werden typischerweise für neue mathematische Modelle, neue Algorithmen oder neue Parallelisierungsstrategien vergeben, aber nicht für die „bloße“ Verbesserung der Effizienz von Simulationscodes. Eine gewisse Abhilfe haben in jüngster Zeit Förderprogramme wie das DFG-Schwerpunktprogramm SPPEXA oder das HPC-Software-Programm des BMBF geschaffen. Dort stehen jedoch jeweils einzelne Codes im Fokus – aufgrund der selektiven Projektauswahl bevorzugt solche mit bereits sehr guter Performance und Skalierbarkeit. Damit können vor allem im obersten Leistungssegment punktuelle Verbesserungen für einzelne Codes und damit auch für die jeweiligen Fachcommunities erreicht werden. Das strukturelle Problem, dass ein Großteil der auf den mittelgroßen und z.T. auch auf den großen Systemen laufenden Codes deren Leistungsfähigkeit derzeit nicht im Ansatz nutzen kann, bleibt bestehen. Auch die Weiterentwicklung dieser Codes in Richtung Verwendung größerer Rechner wird nicht unterstützt. In mehreren Positionspapieren und zuletzt der Empfehlung zum Aufbau einer Koordinationsstruktur „Nationales Hoch- und Höchstleistungsrechnen“ (NHR) hat der Wissenschaftsrat diese Problematik adressiert und eine ganzheitlichere Sehweise des HPC – Hardware und Software und Algorithmik – angemahnt.
Vor diesem Hintergrund hat die DFG im vergangenen Jahr das Programm „Performance Engineering für wissenschaftliche Software“ aufgelegt. Das Programm zielt ab auf „Konzepte für das Performance Engineering wissenschaftlicher Software“ – also nicht punktuelle Verbesserungen einzelner Software-Pakete, sondern auf innovative Maßnahmen, um die Situation in der Landschaft nachhaltig zu verbessern, mit klaren Vorgehensmustern, wie man im Sinne eines Engineering-Prozesses der unbefriedigenden Leistungsfähigkeit von Codes Herr werden kann. Eine zentrale Aussage im Ausschreibungstext der DFG lautet „In der jetzigen Situation werden […] oft wesentlich zu große Rechnerressourcen verbraucht …“: Eine bessere Nutzung der vorhandenen Rechenleistung ist nicht nur ökonomisch angezeigt, sondern erhöht auch direkt den wissenschaftlichen „Output“, da größere Probleme angegangen werden können.
Woran liegt es nun, dass die teure Hardware nicht angemessen genutzt wird? Eine schlechte Nutzung von Rechnerressourcen kann im Extremfall zunächst auch an unglücklich gewählten Modellen liegen, im Allgemeinen sind jedoch erstens suboptimal gewählte (numerische) Algorithmen und Datenstrukturen und zweitens suboptimale Implementierungen selbiger verantwortlich. Der Call der DFG wie auch das Projekt ProPE adressieren primär die zweite Ursache. Aus Sicht der Rechenzentren ist dies naheliegend: Einerseits liegen hier typischerweise Kernkompetenzen der HPC-Spezialisten in den Zentren, andererseits fallen Algorithmen oft unter die „Hoheit der Anwender“, werden folglich, wie die Modelle, bei der Code-Optimierung bzw. beim klassischen Performance Engineering gar nicht mehr hinterfragt. Es herrscht jedoch Konsens, dass für eine nachhaltig verbesserte Situation an beiden Hebeln angesetzt werden muss: Weder „der beste Algorithmus lausig programmiert“ (z.B. ein kompliziertes Mehrgitterverfahren „einfach drauf los parallelisiert“) noch „ein alter Hut auf 80% Peak Performance getrimmt“ (z.B. eine Jacobi-Iteration hocheffizient parallel implementiert) sind per se vernünftig; beide taugen nicht als Optimierungsziel (obwohl in vielen Statistiken von Rechenzentren Kenngrößen wie „X% unserer Anwendungen laufen mit Y% der Peak Performance“ sehr wohl als Qualitätsmaß hergenommen werden). Man muss vielmehr die besten verfügbaren Algorithmen nehmen, und diese dann bestmöglich implementieren. Das heißt, die vereinfachend oftmals aufscheinende Interaktion von „HPC-Anwendung“ und „HPC-System“ (oder das Rechenzentrum und seine Kunden), das „Co-Design von Systemen und Anwendungen“, muss um eine algorithmische Perspektive ergänzt werden, die oftmals weder der Anwender noch der HPC-Experte allein beisteuern können.
Für die Ziele der DFG-Ausschreibung bedeutet dies, dass Mechanismen zu finden und Strukturen zu schaffen sind, die bei den Anwendern Awareness und Kompetenz für beides zu erhöhen gestatten, die algorithmische Effizienz und die Implementierungseffizienz. In der Anwendungssoftware sind somit Performance-Patterns im Hinblick auf sowohl die eingesetzten Algorithmen als auch die Implementierung zu identifizieren und dann die angezeigten Verbesserungsmaßnahmen umzusetzen Das hier beantragte Begleit- oder Ergänzungsprojekt ProPE-AL zum DFG-Projekt ProPE schafft die Möglichkeit, beide oben genannten „Performance-Bremsen“ in einem konzertierten Vorhaben anzugehen.
Die Bestandsaufnahme aus dem ProPE-Antrag für den Bereich des Performance Engineering trifft sicher auch für das Algorithm Engineering zu, ja wahrscheinlich ist hier die Situation noch weniger zufrieden stellend. Denn schlechte FLOP/s-Werte sind zumindest für jedermann sichtbar und offensichtlich; ein schlechter Algorithmus ist demgegenüber viel verborgener, und seine mangelnde Effizienz kann durch eine kunstvolle Implementierung noch mehr verborgen werden. Dennoch gibt es Beispiele, wo eben der Eingriff in die Algorithmik zu signifikanten Fortschritten geführt hat. Im nachfolgenden Abschnitt Vorarbeiten sind solche Beispiele aus der Arbeit der Antragsteller gelistet. Ein weiteres aktuelles Beispiel liefert der SFB/TR 55 (Lattice-QCD, Wuppertal & Regensburg): Ein (immerhin eine Science-Titelseite werter) Durchbruch konnte hier durch den Einbau eines (i.W. bekannten) Mehrgitterlösers in einen bestehenden und etablierten Code erzielt werden. Das heißt, es gibt auch hier wiederkehrende Patterns – im Sinne von Fallen, in die man unbedarft tappen kann, aber auch im Sinne von Vorgehensempfehlungen, die auch dem Nicht-Experten Schritte in die richtige Richtung erlauben. Insofern ist das übergeordnete Ziel des ProPE-Vorhabens auch das zentrale Ziel im Begleitprojekt ProPE-AL: raus aus der unsystematischen Einzelfallbehandlung und rein in einen systematischen und fundierten Optimierungsprozess!