Freitag, 26. Februar 2016

Die Swiss Ephemeris im Google Portable Native Client (PNaCl)

Rechenintensive Programme in einer öffentlichen Web-Anwendung anzubietet, bringt logischerweise eine erhöhte CPU-Last auf dem Server mit sich, die von der Zahl der Benutzer abhängt, die die Anwendung gerade nutzen. Das bringt auch eine Verlangsamung für alle anderen Anfragen, die der Server beantworten muss.

Es geht also beispielsweise in der Astrologie nicht um astrologische Standard-Webauftritte, in denen ein oder zwei Horoskopdaten berechnet werden, um dem Benutzer sein Geburtshoroskop und seine laufenden Transite zu präsentieren, sondern um Hochlastanwendungen mit tausenden von Planetenberechnungen. Mir fallen auf Anhieb zwei Arten astrologischer Anwendungen ein, die als Webanwendung eine zeitweise erhöhte Rechenlast auf dem Server bringen können:

  • Statistische Signifikanztests, bei denen man nach der Monte-Carlo-Methode sehr viele Pseudo-Stichproben mit zufälligen Geburtszeiten und -orten erzeugt, die man in Hinsicht auf eine bestimmte Kennzahl gegen die reale Stichprobe antreten lässt, um einen Schätzwert für die Irrtumswahrscheinlichkeit zu ermitteln. Mit diesem Ziel hatte ich 2014 das Projekt astrotest begonnen.
  • Orakelmaschinen, die versuchen, aus einer gegebenen Sammlung von Horoskopen in regelmässigen Zeitabständen die astrologische Wetterlage zu ermitteln und Trends für einzelne Personen, Nationen, Wirtschaftszweige usw. zu ermitteln. Auch dies wird sehr rechenintensiv, vor allem wenn die ganze von der klassischen Astrologie beschriebene Serie von Hilfshoroskopen zu Rate gezogen wird (Solarhoroskop, Lunarhoroskop, Transite, wiederkehrende Konstellationen, Sonnenaufgangshoroskop, Augenblickshoroskop, sowie Relokationen von Horoskopen auf eine grosse Menge von Erdorten).

In solchen Fällen stellt sich die Frage nach Alternativen zur Webanwendung. Man könnte auf die klassische Desktopanwendung zurückgreifen. Dann wälzt man zwar richtig die Rechenlast vom Server auf den Rechner des Anwenders, wo sie hingehört, aber man handelt sich wieder die klassischen Probleme der Desktopanwendungen ein: Die Installation ist oft kein einfacher Vorgang; es gibt Abhängigkeiten von der Systemumgebung; das ausgelieferte Binary muss in der (möglichst frei wählbaren) Zielarchitektur des Rechnermodells ausführbar sein, das sich der Anwender ausgesucht hat. Eine Java Runtime würde das Problem der Plattformabhängigkeit lösen, aber in der Wartung bleibt das Problem der Softwareverteilung und der verschiedenen Versionen des installierten Programms auf verschiedenen Rechnermodellen bestehen.

Eine schöne Alternative stellt Googles Portable Native Client (PNaCl) dar, der in den Kern des Chrome-Browsers integriert ist (keine Erweiterung! Keine spezielle Installation nötig!) Ähnlich einem Applet (aber ohne UI) ist ein PNaCl-Modul ein Stück Binärcode, das mit der Umgebung der einbettenden Webseite kommunizieren kann. Der Binärcode ist portabel und wird unmittelbar nach dem Laden in Maschinencode und (erlaubte) Betriebssystemaufrufe der Zielarchitektur übertragen, was in der Ausführung laut Google einen Überhang von etwa fünf Prozent im Vergleich zu rein nativem Code bedeutet. Wie beim Applet, ist sein Binärcode also plattformübergreifend.

Ob ein solches Konzept Erfolg hat, hängt davon ab, ob es eine gute Toolunterstützung gibt. Da C/C++ immer noch in den obersten Rängen der Verbreitung von Programmiersprachen rangiert, hat Google sich dafür entschieden, eine Build-Toolkette zu bauen, die sehr nahe an der von C/C++ Compilern orientiert ist. Insbesondere sind C und C++ die beiden bislang unterstützten Sprachen für den Quellcode.

Auch die nützlichen und verbreiteten C-Bibliotheken wie <pthread.h> für die POSIX-Mehrfädigkeit und <stdio.h> für die I/O-Funktionen werden unterstützt. Letztere arbeitet sehr gut mit verschiedenen Filesystem-Konzepten auf dem Browser zusammen. So kann man ein HTML5-Filesystem auf dem Browser "mounten", um danach mit den Standardfunktionen wie fopen(), fread(), fwrite() usw. auf bestehende Dateien zuzugreifen oder neue zu erstellen.

Bei der Entwicklung der Swiss Ephemeris wurden die Abhängigkeiten zu anderen Bibliotheken bewusst schmal gehalten, es wird nur eine Auswahl von Standardbibliotheken vorausgesetzt, insbesondere natürlich auch das Standard-I/O. Es war daher zu erwarten, dass man sie mit relativ wenig Aufwand dem PNaCl-Build-Prozess unterziehen kann - und so war es auch, wie sich herausstellte.

Wärend andere, um neue Technologien zu erforschen, "Hallo Welt"-Anwendungen schreiben, schreibe ich "Hallo SwissEph"-Anwendungen: Ich habe eine Test-Anwendung erstellt, die im Web in einem Chrome-Browser der Version 47 oder höher lauffähig ist und einen Aufruf der Funktion swe_calc_ut mit variablen, in der Webseite angebbaren Parametern durchführt. Dabei werden einige Ephemeridenfiles (sepl_18.se1, semo_18.se1, seas_18.se1) beim Starten der Applikation in das lokale HTML5-Filesystem des Browsers eingelesen.

Man kann sich diese kleine Machbarkeitsstudie live auf meinem Rechner ansehen. Wer Interesse an den Details hat, liest meine Notizen auf dem Weg dahin.

Den Test hat PNaCl bestanden. Ich überlege, das Projekt astrotest vollständig auf diese Technologie umzustellen, nicht zuletzt weil die aktuell verwendete UI-Technik von astrotest - ein Internet Explorer als Benutzeroberfläche, der via Active X Dateien liest und ausführt - ein aussterbendes Modell ist. Wer die doch recht spezialisierten Berechnungen, die astrotest anbietet, ausführen möchte, ist sicher gerne bereit, einen gängigen Browser in der neuesten Version zu installieren und darin einen Link aufzurufen.

Keine Kommentare :