Es ist schließlich egal, ob ein Problem in 2 Sekunden oder 2 Stunden gelöst wird. Ja, das ist für die meisten Probleme wirklich völlig gleichgültig. Und C oder C++ stellen die meisten BioinformatikerInnen vor große Hürden. Warum das so ist, weiß ich nicht. Aber da ist es naheliegend, zu Skriptsprachen wie Python oder R zu greifen. Zu einem echten Problem wird das erst bei richtig großen Datenmengen, wenn also eine Rechnung nicht ein paar Mal, sondern Millionen Male durchgeführt werden muss:
Meine “Motivationsfolie” zum Hochleistungsrechnen. Bild: gemeinfrei, Idee: Lennart Martens
Zum Problem werden interpretierte Sprachen auch, wenn Sie Lösungen verhindern, z. B. weil bereits eine “Lösung” vorliegt, die zwar langsam ist und nur proof-of-concept, also nicht mit allen Eigenschaften (features) versehen, die man braucht. Eine neue, bessere Implementierung wird selten finanziert. Und so vertrete ich die Auffassung, dass vor Start eines Programmierprojektes u. a. überlegt werden sollte:
- Soll mein Programm einmal von Dritten genutzt werden? Nein? Dann sind viele weitere Entscheidungen “Privatsache”. Ja? Dann gilt es sorgfältiger zu überlegen. Nicht vergessen: Der Fokus hier ist wissenschaftliche Software, die veröffentlicht werden soll. Eigentlich selbstverständlich wird aber oft vergessen.
- Wer entwickelt eigentlich? Ich im stillen Kämmerlein? Meine Kollegen mit mir? Eine große Gruppe (mich eingeschlossen) über Gebäude, Länder, vielleicht Kontinente verteilt? Das hat zumindest Einfluss auf die Erwartungshaltung, aber auch auf die Codestruktur.
- Wer soll meine Software wie nutzen? Eine Webanwendung unterliegt anderen Kriterien als eine graphische Benutzeroberfläche, als Programme, die auf der Kommandozeile zu nutzen sind.
- Auf welchen Datenmengen soll meine Software arbeiten? Eine kleine Tabelle oder möglicherweise Terabyte von Rohdaten?
- Und weiter: Welche Algorithmen liegen vielleicht schon optimiert vor? Wie kann ich die mit welcher Sprache nutzen? Welche Parallelisierungsstrategien kann ich damit verfolgen?
Die Liste ließe sich lange fortsetzen. Aber vielleicht dämmert es Euch schon, warum meine Kollegen und ich die Auffassung vertreten:
- Interpretierte Sprachen sind toll, man kann damit viel machen. Insbesondere kann man langsamen und schnellen Code schreiben. Schnellen Code zu schreiben ist ähnlich aufwendig, wie gleich schnellen, zu kompilierenden Code zu schreiben (oft auch unmöglich). Insbesondere leiden Parallelisierungsstrategien in interpretierten Sprachen an ihren engen Grenzen.***
- Daher sollten interpretierte Sprachen für Aufgaben genutzt werden wie Schnittstellen (Wrapper) zu anderen Programmen bereitstellen, Daten graphisch aufzubereiten (zum Plotten), einen Workflow zu skripten, etc..
Persönlich bin ich kein Anhänger des “interpretierte Sprachen haben im Hochleistungsrechnen nichts zu suchen”, aber ihr habt hoffentlich heraus gelesen, dass ich für Sorgfalt in der Wahl der Mittel plädiere.
Meine Schlußfolgerung
Tatsache ist, dass sehr viel Bioinformatiksoftware auf der Grundlage von interpretierten Sprachen publiziert wird (Zwischenstand meiner Erhebung: 80-90 %). Und ist eine Lösung einmal da, wird sie auch genutzt. Auch wenn sie langsam, schwer zu installieren ist und noch andere Probleme mit sich bringt. Man kommt halt schwer zu besseren Alternativen. Und das ist ein Problem, weil langsame Lösungen, die millionenfach Verwendung finden auch viel Strom und Zeit der Anwender und Geld für zusätzliche Hardware verbrauchen – unnötig.
Ganz übel ist die Situation dennoch nicht, denn Qualität setzt sich durch. Die in der bioinformatischen Datenanalyse meist verwendeten Programme (in Bezug auf Rechenzeit) sind in C oder C++ geschrieben oder auch R (mit C oder C++ im Hintergrund). Außerdem spielt Python auch eine große Rolle im maschinellen Lernen – auch hier wieder als “Wrapper” um kompilierten Code, teils sogar für Graphikkarten.
Lösung für Interpreter gibt es häufiger – aber die damit “verschwendete Rechenzeit” hält sich in Grenzen, da diese Lösungen dennoch kurze Laufzeiten aufweisen (z. B. für einen kleinen Plot). Und wichtiger als Grundsatzdebatten ist die Möglichkeit wissenschaftliche Erkenntnisse zu gewinnen. Da spielt REPL eine Trumpfkarte: Die Entwicklung von komplexer Software in kompilierten Sprachen kostet weitaus mehr Zeit als vergleichbare Lösungen in interpretierten Sprachen. Die Überlegung “zu welchem Werkzeug greife ich?” ist eine große Herausforderung. Zumindest – und DAS zeigen solche Vergleiche, sollte man sich nicht nur von Moden leiten lassen.
Kommentare (50)