Wenn das so weitergeht, werde ich in diesem Sommer keine Sandalen ohne Socken tragen können: Bei jeder Installation unsinniger und übelst zusammen gestückelter Software (Teil meines Jobs), kräuseln sich meine Fußnägel. Irgendwann wird es zu viel sein. Bei dieser Arbeit mache ich mir manchmal schon Gedanken, wie viel Energie als Resultat der Anwendung solcher Software verschwendet wird. Meine Vermutung ist: Sehr viel im globalen Maßstab. Da kommt mir ein Artikel, wie der, den ich heute mal beschreiben mag, gerade recht. Aber Vorsicht, bei Messungen, die zeigen, was man sehen möchte!
Ganz zu Anfang dieses Blogs gab es einen – zugegeben eher oberflächlichen – Vergleich von Programmiersprachen. Das geht auch sehr viel fokussierter und eine Gruppe aus Portugal hat sich angeschaut, wie es um den Energieverbrauch bei Ausführung einer Reihe von Standardalgorithmen der Informatik bestellt ist[Pereira et al., 2021]. Hierzu wurden 10 gute Implementierungen verschiedener Algorithmen des Computer Language Benchmarks Games – eines Dauerwettbewerbs zum Vergleich von Programmiersprachen “laufen gelassen”, die Laufzeit und der Energieverbrauch gemessen. Die Autoren merken zurecht an, dass die Annahme der Energieverbrauch von Software wäre
, also das ein schneller laufender Code auch weniger Energie verbraucht, etwas naiv ist. Also haben sie direkt gemessen und das finde ich gut. Ein Problem der Autoren war, dass für einige Algorithmen noch nicht genügend viele Einsendungen gab, die den Qualitätskriterien entsprechen, weshalb beispielsweise Julia, eine Programmiersprache, die im wissenschaftlichen Programmieren immer mehr Boden gewinnt, nicht aufgezählt ist. Weniger gut finde ich für eine Publikation, die im Mai 2021 (also gewissermaßen jetzt) erschienen ist, dass nicht auf einem aktuellen System gemessen wurde:
All studies were conducted on a desktop with the following specifications: Linux Ubuntu Server 16.10 operating system, kernel version 4.8.0-22-generic,with 16GB of RAM, a Haswell Intel(R) Core(TM) i5-4460 CPU @ 3.20GHz.
Der fragliche Prozessor wird nicht mehr vertrieben, sein Befehlssatz ist nicht auf dem aktuellen Stand (was vielleicht daran liegt, dass die Ergebnisse älter sind als die Veröffentlichung). Damit werden sich die Energiewerte zu aktuellen Systemen unterscheiden, aber dies tut unter dem Strich den Aussagen der Veröffentlichung keinen Abbruch. Ich erspare hier die technischen Details und zeige mal das Gesamtergebnis:
Eigene Darstellung der normalisieren Resultate (mit “C” wurden die niedrigsten Verbrauchswerte gemessen (der Wert für C ist 1), alle anderen Resultate beziehen sich darauf und benötigen n-mal mehr als C) aus der oben genannten Veröffentlichung. Bitte beachtet die logarithmische Auftragung (Implementierungen mit Java benötigen im Mittel doppelt soviel Engergie wie solche, die in C geschrieben wurden. Lösungen mit Python oder Perl etwa 80 mal mehr.). Lizenz: CC-BY SA 4.0
Deutlich zu erkennen ist, dass Lösungen welche C, eine sehr systemnahe Sprache in der beispielsweise das Linux-Betriebssystem geschrieben ist, verwenden im Mittel die besten, also niedrigsten Energieverbrauchswerte aufweisen.
Wer schon mal etwas von Programmiersprachen gehört, dem fällt noch Etwas auf: Diese Liste führt einige auf, die man vielleicht gar nicht auf dem Schirm hatte. Andere fehlen vielleicht. Und in der Tat: Sie deckt sich nur teilweise mit den populärsten Sprachen (wie beispielsweise durch den Tiobe-Index ermittelt). Die wesentlichere Fragestellung sollte sein: Wie unterscheiden sich die Sprachen bezüglich ihres Energieverbrauchs bei den Aufgaben, zu denen tatsächlich eingesetzt werden? Gibt es in den Aufgabengruppen Alternativen, die man gut vergleichen kann? Denn klar: Man kann mit PHP, einer Skriptsprache für dynamische Webseiten, dazu nutzen randomisierte genetische Sequenzen auszuschreiben (einer der Tests) – in der Praxis wird das keine Aufgabe sein, der sich PHP-EntwicklerInnen gegenüber sehen. Und auch die “algorithmischen” Details der Aufgaben sind nicht, was üblicherweise die Laufzeit von PHP-Umgebungen dominiert. Ähnliches ließe sich über manch andere Kombination von Sprache und Testalgorithmus sagen.
Wir wissen, dass unsere Mobiltelefone eine gigantische Menge Strom verbrauchen und das Internet sowieso. Und so können wir zu der Frage kommen: Können wir substantiell Strom sparen, in dem wir bessere Software einsetzen, effizientere Bibliotheken, ggf. sogar in anderen Sprachen neu geschrieben? Mein Verdacht ist: Ja. Aber solch eine Arbeit ist allenfalls ein mittelgutes Indiz, da die ausgewählten Test wenig praxisrelevant sind – es ist ein Vergleich von Äpfeln und Birnen. Insofern verstehe ich den Mini-Hype, der sich u. a. auf jene Veröffentlichung beruft nicht.
Blick zu Scientific Computing
Nun, dies ist ein Wissenschaftsblog und der Energieverbrauch beim wissenschaftlichen Rechnen ist global schwer zu beziffern. Aber vielleicht können wir dennoch was aus der Veröffentlichung lernen. Denn eine große Universität kann hierzulande schon mal 1 Millionen Euro für Strom im Jahr allein für das wissenschaftliche Rechnen ausgeben – natürlich nicht bezogen von einem Ökostromanbieter zur Förderung der Energiewende. Hierbei könnte viel durch Einsatz wissenschaftlicher Großrechner gespart werden – anstelle der immer noch vorherrschenden arbeitsgruppeneigenen Server.
Nun gut, schauen wir uns die Sprachen an, die im wissenschaftlichen Rechnen verwendet werden (nein, liebe Computer-WissenschaftlerInnen, hier sind nicht die Sprachen gemeint, die ihr wissenschaftlich interessant findet, sondern die Sprachen, die – ohne das an dieser Stelle näher quantifizieren zu können – die meisten CPU-Stunden fressen im Einsatz bei den Naturwissenschaften):
Eigene Darstellung der aus der oben genannten Veröffentlichung. Herausgegriffen sind diejenigen Sprachen, welche am häufigsten verwendet dazu werden (natur-)wissenschaftliche Softwareprojekte zu realisieren – nach Einschätzung des Blogautors (hierbei ist Rust noch eher selten anzutreffen, gewinnt aber in den letzten Jahren an Boden). Lizenz: CC-BY SA 4.0
So, und jetzt sollen alle umweltbewussten WissenschaftlerInnen bitteschön nur noch C schreiben? Natürlich nicht! Die Forderung wäre naiv. Einige der Tests besitzen, wie gesagt, keinerlei praktische Relevanz und die aktuellen Entwicklungen bei Sprachen wie C++, Rust oder Julia sind performancemäßig atemberaubend. Vor allem aber: Wenn man das Paper aufmerksam liest, stellt mach auch fest, dass es für einige der Algorithmen keine Implementierung in C gibt. Das hat seinen Grund: C ist vielleicht eine Sprache, die verspricht sehr effiziente Programme schreiben zu können – potentiell … möglicherweise. Aber auch eine Sprache in der die Umsetzung mancher Vorhaben einfach aufwendiger ist als bei anderen Sprachen. Außerdem kann man mit jeder Sprache auch langsamen Code schreiben. Hier, liebe mitlesenden InformatikerInnen geht es um ein Erwartungsmittel und da zeigt sich, dass die gewählten Sprachen bzgl. ihrer Geschwindigkeit in erster Näherung doch zu verhalten wie bzgl. ihrer hier gezeigten Effizienz[Prechelt, 2020]. Jede Programmiersprache hat bevorzugte Einsatzgebiete.
Andererseits hilft Nachdenken vor Beginn eines wissenschaftlichen Softwareprojektes weiter und dazu zählen auch Überlegungen wie die Folgende: Mit vielen Programmiersprachen kann man Numerik betreiben, aber Python ist beliebt und zugleich ist die Gefahr groß lahme Skripte zu schreiben, beispielsweise wird
for i in range(zillion): result = pi/2 * ...
von Python auch eine “zillion”-Mal pi/2 berechnet (so gesehen mehrere Male, wobei die “Zillionen” irgendwo zwischen einer Millionen und Milliarden von Schleifendurchgängen ist). Besser wäre bei allen Skalaren, nicht nur Vielfachen von Pi, diese Division aus der Schleife heraus zu ziehen:
pi_2 = pi * 0.5 for i in range(zillion): result = pi_2 * ...
. Dieser “Trick” wird ganz zu Anfang gelehrt, wenn man sich je mit Programmierung beschäftigt, ist völlig trivial und der Fehler wird doch immer wieder gemacht. Wir können uns also gut vorstellen, dass man langsame und ineffiziente Lösungen entwickeln kann. Bei anderen Sprachen sorgt möglicherweise der Compiler für Effizienz, weil er bemerkt, dass es sich da um eine quasi-Konstante handelt (obwohl der kleine Trick der Auslagerung auch bei anderen Sprachen gewiss nicht schadet). Und ja, man kann mit Cython von Python zu C übersetzen. Damit ist oft viel gewonnen, ohne großen Aufwand. Das übrige Buzzwordbingo rund um Bibliotheken, die das Eisen aus dem Feuer holen, sparen wir uns mal … Punkt ist: Augen auf bei der Sprachwahl, sonst ist die Wahrscheinlichkeit für die große und vergessliche Wissenschaftsmüllhalde zu schreiben sehr groß.
Mancher Mensch fühlt sich nach Kauf eines SUV gut. Andere überzeugen eine Arbeitsgruppe für ein zusammengepatchtes, überfrachtetes, speicherhungriges Java-Programm einen Serverboliden anzuschaffen – beides sind in gewissen Kreisen bedeutende Statussymbole. Man kann aber auch Freude daran finden, kleine schlanke Programme zu schreiben, die überall und ohne großen Aufwand zu installieren sind und ihre Arbeit zuverlässig erledigen.
Deshalb finde ich das zweite zitierte Paper wesentlich aussagekräftiger: Hier wurden insg. 80 Implentierungen für zwei Probleme verglichen für die Sprachen C, C++, Java, Python, Perl, Rexx (was nun wirklich kein Schwein mehr nutzt, oder?) und Tcl. Und wenn auch hier die Zahlenwerte durch alte Compiler, Pythonversionen etc. bereits Makulatur sind, obwohl die Veröffentlichung im letzten Jahr erschien, gibt es durch die Erfassung von Programm- bzw. Scriptlänge und Aufwand einige weitergehende Schlussfolgerungen:
- Ein Programm in Perl, Python, Rexx oder Tcl zu schreiben braucht nicht halb soviel Zeit wie für die Alternative in C, C++ oder auch Java – und diese Programme sind auch nur halb so lang.
- Ein typisches Scriptprogramm braucht etwa doppelt so viel Speicher wie ein C oder C++-Programm und mit Java sind es gleich 3-4 mal mehr Speicherbedarf.
- Bei allen getesteten Programmen ist die Variabilität innerhalb der Lösungen mit einer Sprache größer als die Variabilität zwischen den Sprachen.
Also: Würde mehr Zeit in gute Programme investiert, könnten vielfach bessere, schnellere und sparsame wissenschaftliche Programme vorliegen – klingt trivial, aber ob das Bewusstsein dafür vorhanden ist? Davon abgesehen überlasse ich Lutz Prechelt, Autor des zweiten hier zitierten Papers das letzte Wort (Hervorhebung durch mich):
I advocate that more and larger studies are conducted along the lines of the one described here. Such work is necessary if we are to disperse the fog of vendor hype and programmers advocacy so that we can see each language’s strenghts, weaknesses, and pecularities more clearly. Acquiring such knowledge will help advance the state of software development overall.
Kommentare (48)