Es ist zwar schon ein paar Wochen her, aber die Beschäftigung mit wissenschaftlichen Rechenmethoden hat im Nachhinein so einige Grundsteine für später gelegt.
Da gab es Vorlesungen über neuronale Netze, 25 Jahre bevor Bankvorstände über KI philosophieren – Nvidia war gerade gegründet worden und machte zunächst recht erfolglos einfach Grafikkarten. Und es wurde massiv parallele Programmierung gelehrt und angewendet, lange bevor man einen Teil davon MapReduce nannte. Vieles davon hilft mir heute auf die eine oder andere Weise – nicht nur auf der technischen Ebene, sondern auch was Arbeitsweisen betrifft.
Massiv paralleles Rechnen
Und natürlich musste man mangels unbegrenzter Cloud Ressourcen sehen, woher man seine Rechenkapazität bekam. So wurden dann zunächst die lokalen Workstations zu verteilten Rechnerarchitekturen vernetzt.
Das ermöglichte, ihre Kapazitäten Tag und Nacht auszunutzen – für die Lösung großer Optimierungsprobleme, physikalische Fragestellungen zur selbstorganisierten Strukturbildung und für statistische Grundlagenprobleme.
Höhepunkt war die Errichtung und Nutzung eines eigens entwickelten Beowulf-Clusters, welcher die Kapazitäten noch einmal beträchtlich erhöhte. Dieser war für die damalige Zeit beachtlich leistungsfähig und zudem außerordentlich kostengünstig, da er komplett aus Standard-PC-Technik bestand.
Spieltheorie-Server
Aber nicht bei allen Themen ging es um die Schaffung und effiziente Nutzung großer Compute-Ressourcen.
Beispielsweise hatte ich im Rahmen eines Seminars über Spieltheorie die Gelegenheit, eine spezielle Webanwendung umzusetzen. Teilnehmer des Seminars sollten die Effizienz aus der Literatur bekannter sowie neu entwickelter Spielstrategien gegeneinander testen.
Heute würde man sagen, dass so ein Webportal keine große Sache ist. Allerdings haben die heute gängigen Frameworks für webgestützte Anwendungen noch gar nicht existiert, und so mussten die notwendigen Komponenten selbst entwickelt haben. Das mittel der Wahl war übrigens die Sprache perl.
Und so wurde eine rudimentäre Beschreibungssprache für Spielstrategien entwickelt, mittels derer die Teilnehmenden ihre Ideen formulieren und auf den Server laden konnten. Zudem entstanden Funktionalitäten für den Upload der entsprechenden Skripte, für den semantischen Test der Strategien, für die eigentliche Durchführung sowie für die Ablage und Rückgabe der Ergebnisse.
Take-aways (as we call them)
Fragt man sich, was die generellen Erkenntnisse aus jener Zeit sind, dann sicherlich vor allem diese: Wenn ich ein System zu schaffen habe, mit dem Anwender ein Problem bewältigen sollen, dann muss ich sowohl das Problem als auch die Denkweise der Anwender hinreichend gut verstehen.
Und das bedeutet, auf keinen Fall das vorliegende Problem direkt in IT-Sprache zu übersetzen und drauf los zu programmieren. Viel mehr muss man zunächst vom konkreten Auftrag so weit abstrahieren, dass man, so weit es irgendwie geht, alle Varianten voraussieht, die aus der Problemstellung hervor gehen können. Während man die Nutzerführung eher stringent gestaltet, um Lernaufwand und Fehleranfälligkeit in Grenzen zu halten, muss die Datenarchitektur dahinter so flexibel wie möglich sein, und möglichst auch Performance-Bottlenecks bereits im Design antizipieren und vermeiden.
Ob dann wiederum alles auch so wie gedacht funktioniert, sollte man dabei immer wieder oft überprüfen. Sowohl, was das Funktionieren neuer Bestandteile der Lösung an sich betrifft als auch die Rezeption durch die zukünftigen Nutzer. Viel später habe ich dafür dann übrigens die Begriffe agiles Vorgehen und Akzeptanztests kennen gelernt.