Von fliegenden Partikeln auf verteilten Rechnern

Wer kennt es nicht: Man ist unterwegs, packt sein Smartphone aus und möchte mal schnell eine physikalische Simulation durchführen. Das dauert jedoch etwas länger als sonst, weil man sich die Zeit normalerweise an einem wissenschaftlichen Rechner vertreibt.

Mit diesem Alltagsproblem hat sich mein Forschungspraktikum an der Professur Praktische Informatik im Rahmen des Masterstudiums Informatik befasst. Die Grundidee ist, Teile eines rechenaufwändigen Programms auf einen schnellen Rechner auszulagern. Er übernimmt den schweren Teil und schickt anschließend die Ergebnisse zurück. Da sich dieser Rechner nicht vor Ort befindet, spricht man von einem entfernten oder auf Englisch Remote-Rechner. Jenen Rechner, den man gerade bedient, nennt man entsprechend lokal.
Die Ausgangsbedingung des Praktikums war, dass der lokale Rechner ziemlich langsam und der entfernte Rechner schnell ist. Damit könnte sich eine Auslagerung von Programmteilen lohnen.

Das Programm selbst ist eine Partikelsimulation, die auf Zeitschritten basiert. Mit dieser Art von Thema habe ich ja bereits Erfahrung. In einem dreidimensionalen Raum befinden sich punktförmige Partikel, die sich durch ihre Masse anziehen und somit ihre Flugbahn beeinflussen. Da die Partikelanzahl bis hin zu Millionen oder noch weiter gehen kann, kriegt ein Rechner damit also ziemlich viel zu tun.

Programmiertechnisch ist das ganze hauptsächlich in vier Komponenten aufgeteilt. Das hat gewisse Vorteile: Zum einen lassen sich die Laufzeiten der einzelnen Programmteile so einfacher messen. Dadurch kann man sehen, welche Komponenten viel Zeit beanspruchen und ausgelagert werden sollten. Zum anderen kann man die Komponenten ohne großen Aufwand austauschen; beispielsweise wenn ein anderes Rechenverfahren angewendet werden soll.

Die Komponenten sind die folgenden:

  • Komponente D generiert Anfangsdaten der Partikel oder lädt sie aus einer Datei. Außerdem kann sie Partikeldaten in eine Datei schreiben und daraus lesen.
  • Komponente C berechnet die Anziehungskräfte, die auf die Partikel wirken.
  • Komponente I berechnet aus den Kräften die Beschleunigungen der Partikel, daraus die Geschwindigkeiten und daraus die neuen Positionen.
  • Komponente G ist für die grafische Ausgabe zuständig.

Als Anfangsdaten bieten sich zwei Partikelwolken an, die aufeinander zufliegen. Man kann auch etwas anderes nehmen, aber so ist es ziemlich anschaulich. Zur grafischen Ausgabe der Zeitschritte habe ich das Programm Gnuplot verwendet. Dieses ist eigentlich zum Zeichnen von Graphen gedacht, doch mit etwas Trickserei sieht man quasi bewegte Bilder.

Grafische Ausgabe mittels Gnuplot

Nun stellt sich die Frage, wozu die Berechnungen in zwei Komponenten aufgeteilt sind. Das hat durchaus seinen Grund. Komponente I führt ziemlich einfache Berechnungen durch. Bei den Laufzeitbetrachtungen kann man sie erst einmal beiseitelegen. Komponente C hingegen erzeugt mit dem Ermitteln der Anziehungskräfte den hauptsächlichen Rechenaufwand und sollte daher allein betrachtbar sein können. Das trivialste Verfahren dafür betrachtet alle Partikelpaare und errechnet, wie sehr sie einander anziehen. Das heißt aber, dass man Anzahl mal Anzahl viele Paare betrachtet. Schon wenn wir „nur“ 10000 Partikel verwenden, braucht man keinen Taschenrechner, um zu sehen, dass das Resultat eine Eins mit ziemlich vielen Nullen ist. Ein einzelner Zeitschritt dauert damit schon lange. In der praktischen Anwendung sind es aber wesentlich mehr, z. B. 200. Hat man nur einen langsamen lokalen Rechner zur Hand, dauert es entsprechend, bis man Ergebnisse sieht.

Damit der Rest des Programms gegenüber Komponente C nicht vollends untergeht, verwende ich für diese ein anderes Rechenverfahren, das zwar schneller ist, aber noch immer viel Zeit braucht.

Nach der Programmierung kommen also die Zeitmessungen. Zunächst wird das Programm komplett auf einem langsamen lokalen Rechner – meinem lahmen Netbook – gestartet und die Laufzeiten der Komponenten in Abhängigkeit von der Partikelanzahl aufgezeichnet. Erkennbar ist sofort, dass wie befürchtet Komponente C fast die ganze Rechenzeit einnimmt. Die anderen Komponenten sind vergleichsweise vernachlässigbar. Man beachte, dass die y-Achse im Graphen logarithmisch eingeteilt ist. Ansonsten würde man die Komponenten D, I und G gar nicht mehr ablesen können.

Laufzeiten der lokalen Ausführungsvariante

Es geht nun darum, verschiedene Varianten auszuprobieren, inwieweit man Komponenten auf einen schnellen entfernten Rechner auslagert. Das ist relativ frei wählbar. Nur Komponente G für die grafische Ausgabe muss natürlich auf dem lokalen Rechner laufen. Dort will man ja das Ergebnis auf dem Bildschirm betrachten.

Die folgenden Varianten wurden betrachtet:

  • Variante 0: Alles lokal – Zum Vergleich
  • Variante 1: Komponenten D, C und I ausgelagert – So viel wie möglich
  • Variante 2: Komponente C ausgelagert – Sollte eigentlich reichen
  • Variante 3: Komponenten C und I ausgelagert – Nutzer kann bei sich auf dem lokalen Rechner Daten generieren

Verglichen werden hier nicht mehr die einzelnen Komponenten, sondern die gesamten Laufzeiten jeder Ausführungsvariante. Man erkennt, dass die Auslagerungen wesentlich schneller als die komplett lokale Variante 0 sind. Am besten sind die Varianten 1 und 3. Diese beiden sind sich sehr ähnlich, wie auch deren Rechenzeiten. Etwas schlechter ist Variante 2. Das liegt daran, dass die Komponenten C und I nicht mehr auf demselben Rechner laufen. Da die beiden aber viele Daten untereinander austauschen müssen, muss man in jedem Zeitschritt die Zwischenergebnisse in eine Datei schreiben, verschicken und wieder laden – und das zwei Mal. Das kostet zusätzlich Zeit.

BLA

Als Fazit lässt sich sagen, dass die Auslagerung grundsätzlich etwas bringt. Allerdings muss dazu gesagt werden, dass das Ganze unter günstigen Bedingungen durchgeführt wurde: Der lokale Rechner war ein Netbook im Uninetz und der entfernte Rechner direkt bei der Professur (der übrigens in meinem Botschafter-Foto hinter mir zu sehen ist 😉 ). Das Thema ließe sich nun auf die Alltagssituation mit einem Smartphone übertragen, das mit dem entfernten Rechner über das Internet kommunizieren muss. Gerade hier fällt die Datenübertragungszeit sehr ins Gewicht.

Ich hoffe, dass euch mein etwas ausführlicherer Einblick in diese Lehrveranstaltung gefallen hat und möglichst allgemeinverständlich ausgefallen ist. Wer es noch detaillierter wissen möchte, kann sich gern meine Präsentationsfolien oder gar die Ausarbeitung dazu ansehen. Ebenso ist es ausdrücklich erlaubt, den Programmcode auf GitLab zu bestaunen (URZ-Login erforderlich) und das Programm eventuell selbst auszuprobieren.

Jetzt übrigens verbleibt in meinem Studium nur noch die Masterarbeit, in der ich dieses Thema weiter ausschlachte. 😉

 

Eintrag von Michael, Masterstudium Informatik, 01.03.2018

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

I accept that my given data and my IP address is sent to a server in the USA only for the purpose of spam prevention through the Akismet program.More information on Akismet and GDPR.

Time limit is exhausted. Please reload CAPTCHA.