Green Coding: Wie „grün“ der Programmcode ist, lässt sich messen
Green Coding ist nur eine der 23 Disziplinen unseres Referenzmodells für eine grünere IT („MMIGIT“), aber eine sehr wichtige. So wichtig, dass wir dafür mit unserem Green Coding Measurement Lab eine Vielzahl belastbarer Messwerte ermittelt haben und weiter ermitteln. Was genau messen wir, und was finden wir dabei heraus? An dieser Stelle wollen wir einen kleinen Einblick geben.
Das Thema Green Coding und seine Bedeutung für einen möglichst geringen „ökologischen Fußabdruck“ der IT haben wir bereits in einem vorhergehenden Beitrag näher beleuchtet. Erwähnt haben wir dort auch, dass wir unseren Kunden umfassende „Green Coding Guidelines“ zur Verfügung stellen. Diese Guidelines enthalten nicht nur konkrete Hinweise, wie sich der Programmcode schneller und weniger ressourcenintensiv gestalten lässt, sondern geben auch nachvollziehbare Erläuterungen in Form von konkreten Messergebnissen wieder.
Die unterschiedlichen Gestaltungsmöglichkeiten – sprich: Datentypen und -strukturen sowie Codestrukturen – zu messen und zu vergleichen, ist die Aufgabe des Green Coding Measurement Lab, kurz GCML. Es verwendet dafür eine standardisierte VM (Standard B1s) mit x64-Architektur sowie einem Gigabyte RAM und 1 vCPU unter Ubuntu 20.4. Sie läuft in der Azure-Cloud von Microsoft. Die Ergebnisse für Java liegen final vor in der „Java Edition 2.0“, während die Experimente für die Programmiersprachen Typescript, Javascript und C# derzeit aufgesetzt werden.
Vergleich sorgfältig ausgewählter Konstrukte
Innerhalb der festgelegten Testumgebung entwerfen die Mitarbeitenden des GCML verschiedene Programmkonstrukte, die sich für den Vergleich unterschiedlicher Datentypen, Datenstrukturen und Codestrukturen eignen. Zudem identifizieren sie die „Aufgaben“, die der Code lösen soll. Dabei achten sie auf unbedingte Vergleichbarkeit der Ergebnisse. Das heißt: Die Implementierung bleibt stets dieselbe – abgesehen von den wechselnden Programmkonstrukten.
In den nun folgenden „Experimenten“ geht es darum, mit Hilfe eines verlässlichen Monitoring-Tools zu messen, wie lang das Programm für einen Durchlauf benötigt und wieviel CPU-Ressourcen – in Prozent der Gesamtleistung – es durch das jeweilige Programmkonstrukt verbraucht. Das Experiment wird für jedes Konstrukt zehnmal wiederholt und dann der Mittelwert berechnet. Außer Acht bleiben allerdings Mehrverbräuche durch zusätzliche Services oder die Hardwarekühlung.
Die Messergebnisse werden in Wattstunden angegeben. Gebildet wird das Resultat aus dem Produkt von Thermal Design Power (tdp), Laufzeit und CPU-Nutzung. Der besseren Übersicht wegen lassen sich die Einzelergebnisse visuell darstellen. Sind mehr als zwei Möglichkeiten miteinander zu vergleichen, werden die jeweiligen Energieeinsparungen als positive Abweichung zum schlechtesten gemessenen Wert dargestellt.
Zwei beispielhafte Experimente
Ein simples Beispiel für ein GCML-Experiment ist der Vergleich zwischen den Datentypen „float“ und „double“. Wie nicht anders zu erwarten, schneidet das Konstrukt mit dem Float-Typ in Bezug auf die CPU-Auslastung etwas besser ab. Das Plus an CPU-Verbrauch beim Double-Typ ist wohl dem größeren Speicherbedarf geschuldet, der sich wiederum auf die höhere Detailgenauigkeit zurückführen lässt.
Ein anderes Beispiel, diesmal aus dem Bereich der Codestrukturen, betrifft die Klassenabstraktion in objektorientierten Systemen. Hier konkurrieren zwei Strukturen miteinander: Interface und Vererbung über eine nicht als Objekt instanziierbare („abstrakte“) Klasse. Oft wird in der Entwicklung die letztere bevorzugt – wegen ihrer größeren Flexibilität und Erweiterbarkeit. Hinsichtlich der Energieeffizienz schneidet das Interface jedoch eindeutig besser ab.
Der Kunde setzt die Priorität
Diese beiden Beispiele belegen auch: Nicht in jedem Fall ist die energiesparendste Programmierung die für das jeweilige Unternehmen optimale Lösung. So sind die feineren Abstufungen bei float für die eine oder andere Anwendungen möglicherweise unabdingbar. Oder die Verwendung von Interfaces statt abstrakter Klassen würde die Entwicklungsarbeiten verkomplizieren und über Gebühr in die Länge ziehen. Hier stehen die Green Coding Guidelines in Konkurrenz zu anderen Kriterien – und das Team muss abwägen, worauf es am meisten Wert legt.
Nicht von ungefähr existiert neben den Green Coding Guidelines eine Vielzahl von Entwicklungs-Richtlinien, die andere Aspekte in den Vordergrund stellen, beispielsweise die Entwicklungskosten oder die Wartbarkeit der Software. Die Unternehmen selbst müssen entscheiden, wo sie ihre Prioritäten setzen.
Die von uns erarbeiteten Verbesserungsvorschläge orientieren sich am metafinanz Maturity Model Integrated Green IT (MMIGIT) und zielen auf einen möglichst effizienten Umgang mit den Energieressourcen ab. Wir empfehlen sie allen Unternehmen, die diesen Gesichtspunkt als besonders wichtig einstufen.
Lesen Sie unsere weiteren Artikel und erhalten Sie ausführlichere Informationen zu MMIGIT!
#1 Enterprise-IT nachhaltiger entwickeln
#2 Mit dem MMIGIT Schritt für Schritt zu einer grüneren IT
#3 MMIGIT in der Praxis: Der Sparplan für das Energiekonto Ihrer IT im Schnelldurchlauf
#4 MMIGIT: Wie sich die Reifestufen des Green Coding leichter erklimmen lassen
Alle Informationen zu unserem MMIGIT – Maturity Model Integrated Green IT
Quelle Titelbild: zhihao/Getty Images
