Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

13.12.2007 - 

Open Source

Offene Software ist grüner

Kurt Garloff 
Welchen Einfluss hat die Software auf den Energiebedarf eines Computersystems? Anhand von Programmen aus dem Bereich Linux und Open Source lassen sich Spareffekte besonders gut nachvollziehen.
Der Doppelkerner Pentium D840 zeigt sich im Vergleich sowohl unter Last als auch im Leerlaufmodus am hungrigsten.
Der Doppelkerner Pentium D840 zeigt sich im Vergleich sowohl unter Last als auch im Leerlaufmodus am hungrigsten.

Virtualisierung ist wahrscheinlich die effizienteste Methode, den Bedarf an Rechenkraft zu verringern. Viele Server sind heute schlecht ausgelastet, da sie für die Lastspitzen dimensioniert werden; das führt zu Auslastungen im Bereich von fünf bis 20 Prozent. Konsolidiert man zehn dieser Rechner in Form von virtuellen Maschinen auf einen großen Server, dann wird man die Reserve für Lastspitzen (80 bis 95 Prozent) nicht zehnmal einplanen, außer die Spitzen hängen miteinander zusammen. Ein doppelt so starker Rechner nimmt zehn virtuelle Maschinen mit typischerweise zehn Prozent Auslastung auf und verbessert somit die Auslastung auf 50 Prozent.

Regeln für stromsparenden Code

Benutze Standardbibliotheken und Standarddienste.

Performanter, wartbarer Code ist stromsparender Code.

Vermeide unnötige Komplexität und Abstraktion.

Vermeide Polling, benutze Event-Notification.

Multiplexen und Dispatchen von Diensten nur bei Bedarf spart Ressourcen.

Mit Hilfe von Live-Migration lassen sich die virtuellen Maschinen unterbrechungsfrei zwischen den Servern hin- und herschieben. Falls also am Wochenende die Auslastung geringer ist, konsolidiert man die virtuellen Maschinen auf wenigen Servern und schaltet die nicht benötigten ab. Die Stromersparnis ist hier offensichtlich.

Aber auch ohne Virtualisierung kommt man zur Abarbeitung mehrerer Applikationen mit nur einem Rechner aus. Voraussetzung dafür ist ein Multitaskingfähiges Betriebssystem wie Unix oder Linux. Der Betriebssystem-Kern schirmt dabei die Anwendungen voneinander ab. Leider sind Anwendungen häufig so programmiert, dass sie spezielle Versionen von Systemdiensten brauchen und sich dann gegenseitig behindern. Deshalb sollten Anwendungen die mit dem System gelieferten Dienste und Bibliotheken benutzen, die dann auch nur einmal in den Arbeitsspeicher geladen werden müssen.

Desktop-Rechner und Laptops werden oft im Dauerbetrieb genutzt, damit sie kurzfristig zur Verfügung stehen. Eigentlich ist das unnötig, denn moderne Desktop-Betriebssysteme wie MacOS, Linux und Windows unterstützen die "Suspend"-Funktion. Sie versetzt den Computer in einen Schlafmodus, aus dem er bei Bedarf in wenigen Sekunden aufwacht.

Moderne Prozesse sind energieeffizient

Eine typische Server-CPU benötigt unter Volllast bis zu 100 Watt an elektrischer Energie. Glücklicherweise haben auch die Prozessorhersteller die Notwendigkeit zum Stromsparen erkannt. Beliebt sind seit längerem Tests, die die Rechenleistung pro Watt vergleichen. Moderne CPUs werden nicht nur unter Last effizienter, sie unterstützen auch diverse Stromsparmodi: bei geringer Last kann die Frequenz und die Versorgungsspannung sinken, was den Stromverbrauch mehr als halbiert. Der Linux-Betriebssystem-Kern beispielsweise versetzt die CPU immer dann in einen Schlafmodus, wenn die Anwendungen und Komponenten keine Rechenkraft benötigen. Der Stromverbrauch geht so auf weniger als zehn Prozent zurück. Auf schwach ausgelasteten Systemen bestimmt sich der Stromverbrauch dann im Wesentlichen durch die Häufigkeit des Aufwachens.

Der Kernel weckt die CPU nur noch bei Ereignissen

Früher "erwachte" der Linux-Betriebssystem-Kern häufig (250-mal pro Sekunde), um regelmäßige Verwaltungsaufgaben zu erledigen. Heute ist das nicht mehr notwendig. Der Kernel weckt die CPU nur noch, wenn eine Anwendung abläuft oder ein externes Ereignis auftritt, etwa das Eintreffen eines Netzwerkpakets. Für den Stromverbrauch eines wenig belasteten Systems sind deshalb mittlerweile vor allem die Anwendungen verantwortlich.

Die Aussage ist trivial: Programme, die nicht laufen, führen auch zu keinem Stromverbrauch. Anwendungen oder Dienste, die man nicht benötigt, startet man am besten gar nicht. Häufig wird diese Erkenntnis aber nicht berücksichtigt. So wird oft ein Dienstprogramm gestartet, das dann auf Netzverbindungen warten muss, statt zuerst einen Multiplexer auf die notwendigen Verbindungen warten zu lassen und das Programm erst bei Bedarf zu starten. Unter den Betriebssystemen Unix und Linux sorgen die Funktionen "inted" und "xinted" genau dafür.

Bei den Anwendungen haben die Architektur und die Umsetzung einen großen Einfluss auf den Stromverbrauch. Es ist der Ressourcenverbrauch jeglicher Art (CPU, Arbeitsspeicher, Ein-/Ausgabe-Operationen), der das System belastet und damit auch den Stromverbrauch verursacht. Eine Festplatte braucht mehr Energie, wenn sich der Schreib-Lese-Kopf bewegt, um die Daten auf der Festplatte zu schreiben oder zu lesen. Am größten ist aber der Einfluss einer Anwendung auf den Stromverbrauch der CPU. Zwei Faktoren spielen hier eine Rolle:

1. Wie viel CPU-Rechen-Power benötigt die Anwendung?

2. Wie häufig weckt die Anwendung unnötigerweise die CPU aus ihrem Stromsparmodus auf?

Die gute Nachricht: Das meiste, was eine Anwendung performanter und effizienter ablaufen lässt, macht sie auch stromsparender. Dabei hat auch die Wiederverwendung von Komponenten einen positiven Einfluss auf den Energiehunger. Die Formel ist einfach: Weniger Rechenzyklen der CPU bedeuten auch einen geringeren Stromverbrauch. Einen Teil der Arbeit erledigt dabei ein optimierender Compiler, dem ein guter und klar strukturierter Code dabei hilft. Noch wichtiger ist die Wahl der richtigen Architektur und der wichtigen Algorithmen.

Leider gibt es Ausnahmen von der schönen Regel: Nicht immer geht eine Leistungsoptimierung Hand in Hand mit dem geringsten Verbrauch von CPU-Zyklen. Die Leistung wird manchmal unter Inkaufnahme von vielen Rechenzyklen erreicht. So rechnen Programme "auf Verdacht" im Hintergrund schon mal Ergebnisse aus, obwohl nicht alle Eingabedaten bekannt sind und gar nicht klar ist, ob die Ergebnisse gebraucht werden. Das verschwendet dann Strom. Oder man parallelisiert ein Programm, damit viele CPU-Kerne benutzt werden. Der Aufwand für die Synchronisierung und die Kommunikation kann aber diesen Vorteil leicht zunichte machen, was sich dann auch in der schlechten Skalierbarkeit des parallelisierten Programms zeigt. Als Daumenregel für das Stromsparen gilt: Nicht mehr Prozesse oder Threads benutzen, als diese noch fast linear skalieren.

Großer Hauptspeicher mit Vor- und Nachteilen

Der Einfluss des Hauptspeichers auf den Energiebedarf ist weniger offensichtlich: Speicher-Controller benötigen zwar derzeit eine recht konstante Menge an Strom, unabhängig davon, wie viele Zugriffe stattfinden. Dafür hilft ein großer Speicher aber, Festplattenzugriffe des Betriebssystems zu vermeiden, indem der Inhalt zwischengespeichert (gecachet) wird.

Eine Optimierung, die massiv die Codegröße erhöht - etwa ein hemmungsloses "Inlinen" von Subroutinen oder ein übertriebenes Ausrollen von Schleifen oder das Aufbauen von riesigen Indextabellen - kann den Speicherbedarf so weit erhöhen, dass die minimal bessere Codeeffizienz damit erkauft wird, dass weniger Anwendungen gleichzeitig in den Speicher passen und sich so der Strombedarf doch erhöht.

Programmierer haben Effizienz oft nicht im Blick

Von solchen Ausnahmen abgesehen, tritt in der Praxis viel häufiger der Fall auf, dass der Programmierer die Effizienz gar nicht im Blickfeld hat: Da wird ein Feld linear durchsucht, statt es sortiert zu halten und es binär durchsuchen zu können oder mit einer Hash-Tabelle zu indizieren. Statt eine gut optimierte Routine aus einer Standardbibliothek zu benutzen, wird eine schlechtere Variante selbst programmiert. Oder man baut ein unnötig kompliziertes Framework, obwohl das Problem einfach zu lösen ist. Da wird eine Java Virtual Machine gestartet, wenn eine einfache Scriptsprache oder ein kleines C/C++-Programm den Job tun würden. Deshalb der Tipp: Keep it simple! So sind Standardroutinen meist in Form von Bibliotheken verfügbar. Diese sind in der Regel besser getestet und besser optimiert. Es gibt aber noch einen weiteren Vorteil: Wenn mehrere Anwendungen dieselbe Bibliothek benutzen, muss die nur einmal in den Speicher geladen werden. Und weniger Speicherverbrauch ist gut.

Die "Schlafstörer" sind entlarvt

Der Chiphersteller Intel hat die Initiative "lesswatts.org" gestartet, welche mittlerweile von vielen Hard- und Softwareherstellern unterstützt wird. Hervorgegangen ist daraus das Programm "powertop", welches unter Linux anzeigen kann, welche Anwendungen für das Aufwachen der Prozessoren aus dem Schlafmodus verantwortlich sind. Das hat sogleich einige Programme als regelmäßige "Schlafstörer" entlarvt. Da gibt es zum Beispiel ein Mixer-Applet auf dem Desktop, welches mehrmals in der Sekunde weckte, um nachzuschauen, ob die Lautstärke nicht von einem anderen Programm verändert wurde.

Regelmäßiges Nachschauen (Polling) ist immer ungünstig, denn eigentlich sollte das Applet gezielt nur dann benachrichtigt werden, wenn wirklich etwas ansteht. Eine ereignisgesteuerte Architektur arbeitet so. Moderne Systeme bieten dafür viele Mechanismen. So kann ein Programm sich zum Beispiel nur dann benachrichtigen lassen, wenn sich eine Datei oder ein Verzeichnis verändert.

Viele Tools helfen bei der Codeoptimierung

Zahlreiche Werkzeuge helfen bei der Codeoptimierung. So erledigt der Compiler zwar viele Dinge automatisch, aber es gibt auch eine Reihe von Analyse-Tools für das Profiling. Unter Linux sind das Programme wie "oprofile", "valgrind", "gprof"und "gcov". Mit "powertop" lassen sich unnötige Weckvorgänge aufdecken. Die Tools können allerdings nicht die Programmarchitektur verbessern oder den Entwickler über die Existenz von Standardbibliotheken aufklären. Dazu muss der Entwickler sorgfältig recherchieren, wozu aber allzu häufig die Disziplin oder die Zeit fehlen.

Deshalb wird effektiver und zuverlässiger programmiert, wenn viele Augen die Architektur und die Implementierung prüfen. Am stärksten ausgeprägt ist das Prinzip des Reviews in der Open- Source-Community, denn hier gehen Ideen und Code über eine öffentliche Mailing-Liste, bevor sie Teil eines Projekts werden. Und häufig genug wird hinterfragt, warum denn das Rad neu erfunden wird, statt bewährte und effiziente Routinen aus einer Bibliothek zu benutzen. Das Gute ist bei Open Source ja, dass dies ohne lizenzrechtliche Probleme möglich ist. Entwicklungsteams, die nicht das Privileg haben, an Open-Source-Projekten zu arbeiten, sollten intern viel diskutieren, Ideen und Code immer wieder untersuchen und so eine kleine interne Community schaffen, die ähnlich wie Open Source funktioniert. Das führt nicht nur zu besserer Qualität, sondern auch zu mehr Energieeffizienz.