Java zerstört Weltklima!
Jetzt haben wir C-Programmierer endlich mal wieder ein gutes Argument gegen die Programmiersprache Java: sie schädigt das Weltklima! Erlebt die Sprache C nun ihre Renaissance? Oder ist der Gerhards jetzt nur endgültig verrückt geworden?
Wie komme ich denn nun zu diesem "irrsinnigen" Gedanken? Im Blog gleich nebenan sinniert Gunter Dueck über "Green Programming". Er stellt dort die Frage, ob effiziente Programmierung nicht tatsächlich einen erheblichen Beitrag zum Schutz des Weltklimas leisten kann.
Seine Argumente sind gut und durchaus nachvollziehbar. Unsere IT-Infrastruktur benötigt immer mehr Strom. Wenn Programme nun effzienter arbeiten, dann wird weniger Rechenleistung benötigt, folglich in der Summe weniger Rechner und damit weniger Strom verbraucht. In der Fernwirkung hilft das effiziente Programm also dem Weltklima.
Tatsächlich kann, und sollte, man diese Meinung vertreten. Man muss allerdings beachten, dass "Effizienz" ein sehr vielschichtiger Begriff ist. Es gibt viele Aspekte, die den Energieverbrauch eines Programmes beeinflussen. Im Rahmen meines rsyslog-Projekts hatte ich Mitte 2008 beispielsweise in meinem Blog-Post "Coding to save the environment" darüber nachgedacht, wie man durch Vermeidung althergebrachter Programmierverfahren Strom sparen kann. Die Lösung liess sich mit relativ wenig Aufwand implementieren, und ich konnte forthin rsyslog als "grünen Protokolldaemon" anpreisen...
Aber bleiben wir einmal bei der reinen Laufzeiteffizienz. Die Wahl der Programmiersprache, so scheint es, hat manchmal schon fast etwas Religiöses. So schwelt seit Jahren ein Streit zwischen der C/C++ Fraktion auf der einen und der Java/.NET Fraktion auf der anderen Seite. C ist effzienter (obwohl Java hier stark aufgeholt hat!), verlangt vom Programmierer aber auch grössere Sorgfalt. Und da auch die sorgfältigsten Menschen Fehler machen, ist die Wahrscheinlichkeit, in einem gut geschriebenen C-Programm Fehler zu finden, höher als bei einem ebenso gut geschriebenen Java-Programm.
Auf der "religiösen" Ebene diffamiert man sich dann schon einmal gerne gegenseitig, so von wegen "man muss nur richtig programmieren können" vs. "in C kann man keine funktionierenden Programme schreiben".
Verlassen wir diese Ebene einmal und schauen auf die Fakten, dann gehört Java zu einer Sprachfamilie, die keinen direkten Maschinencode erzeugt. Um ein Java Programm auszuführen, wird also eine Art Interpreter benötigt, der das Java Programm in ein real auf der Hardware ausführbares Programm umwandelt. Das geschieht zur Laufzeit, und kostet daher zusätzlich Rechenzeit. In den Anfangstagen von Java hat das in der Tat zu quälend langsamen Programmen geführt. Mittlerweile ist die Technik dieser Interpreter aber weit fortgeschritten, der Overhead stark minimiert wurden.
Fakt ist und bleibt aber, dass ein gewisser Overhead existiert (was wohl auch der Grund sein dürfte, warum Betriebssysteme wie Linux oder Windows nicht in Java geschrieben sind). Ein Java Programm wird also üblicherweise etwas langsamer sein als ein vergleichbares C Programm.
Nun lacht sich der C-Programmierer ins Fäustchen: also braucht ich für Java mehr Rechenzeit, also mehr Rechner, also mehr Strom - und Ergo ist Java schädlich für's Weltklima. Wusste ich es doch!
Aber, gemach, gemach... Wie steht es denn mit der Zuverlässigkeit der Programme? Darf ich C-Programme (deren Zuverlässigkeit, das sagt der hartgesottene C-Programmierer, tatsächlich schwerer zu erreichen ist), wirklich überall einsetzen? Oder gibt es nicht Bereiche, in denen die Zuverlässigkeit wichtiger ist als die eigentliche Effizienz? Oder, ganz böse ausgedrückt: was nützt mir z.B. eine effziente Steuerungssoftware, die aufgrund eines Programmfehlers versagt und als Nebeneffekt z.B. Stromverbraucher zu lange angeschaltet lässt? Und dann kommen die Betriebswirte: Java-Programme sind in der Regel mit geringerem Aufwand zu Entwickeln als C-Programme (schon alleine, weil die Qualitätssicherungskosten niedriger sind). Wenn ich nun den Resourcenaufwand während der Entwicklung 'mal in die Ökobilanz eingehen lasse - ist ein C-Programm dann wirklich noch besser für das Weltklima? Zu guter Letzt kann ich auch von der hardcore IT-Franktion noch einwerfen: Ist denn wirklich die Wahl der Programmiersprache so entscheidend? Ist nicht die Wahl der Algorithmen viel wichtiger? Und die geschickte Anwendung der Werkzeuge? Sicher, ein exzellenter Programmierer wird wahrscheinlich in C effzientere Programme schreiben können als ein ebenso exzellenter Java-Programmierer. Aber was ist mit dem normal begabten Programmierer? Ist der Unterschied wirklich so entscheidend? Kann nicht eine Sprache wie Java unter Umständen sogar Fehler/Ineffizienzen des weniger guten Programmierers beseitigen?
Mhhh... Schade! Auch hier scheinen sich keine einfachen Antworten zu finden. Wie so oft im Leben ist die Wahrheit kompliziert und es bestehen viele Zusammenhänge.
Aber: von der provokativen Frage C vs. Java einmal abgesehen, so gibt es in der Tat Vieles, was Programmierer zum Schutz des Weltklimas beitragen können. Die Wahl der Programmiersprache sollte sich wohl eher nach anderen Kriterien richten. Aber ein effizienter Algorithmus, gutes Verständnis für die Maschine sowie der "Blick über den Tellerrand" helfen, Energieeffzienz auch als eine Aufgabe der Software-Entwickler zu sehen. Und, um im Beispiel zu bleiben: gerade wer die Java-Systemsoftware selbst entwickelt, hat natürlich gewaltiges Wirkpotential. Effzientere Implementierungen im Laufzeitsystem können in der Tat ungeahnte Folgen haben. Gleiches gilt für Betriebssystementwickler sowie all' diejenigen, die häufig eingesetzte Komponenten erstellen.
Leider findet sich das Thema "Energieeffzienz" noch in so gut wie keinen Software-Pflichtenheften. Entsprechend vernachlässigt wird es auch in der Ausbildung. Die IT wird erwachsen - leider sehr langsam. Wir sind immer noch damit beschäftigt, den Entwicklern Sensibilität für Security zu vermitteln. Und dort ist der Bedarf offensichtlich erkennbar. Ich befürchte, Energieeffizienz wird noch auf mittlere Sicht als eher exotisches Thema gehandelt werden. Um so schöner, hier in diesem Forum darauf hinweisen zu können.
Über Kommentare freue ich mich wie immer sehr!
Ähnliche Artikel:
Na ja, eine Interpreterverfahren hat mit Fehlervermeidung erstmal grundsätzlich nichts zu tun, es ist einfach 4..10mal langsamer als compilierter Code. Das Ziel von modernen SW-Verfahren ist es die Entwicklungskosten zusenken und die Qualität zu verbessern. Das geht of auf Kosten der Geschwindigkeit weil nicht immer die Auswirkungen solcher Maßnahmen im Entwurfstadium transparent sind und die Hoffnung besteht, dass sich das Problem durch schnellere HW von selbst erledigt.
So gesehen sollten wir erstmal die ganzen Microsoft-Produkte entsorgen. Was die an Ärger und dadurch Bruttosozialprodukt kosten, Umweltbelastung durch zusätzlich benötigten Speicher und Rechenleistung produzieren... von deren Ineffizienz wollen wir mal ganz absehen.
wie wäre es mal einen Blick auf die zur verfügung stehende Hardware zu machen. Serverräume sind heiss, brauchen eigene Klimaanlagen weil der TDP der Prozessoren zu hoch anliegen. Die effizienz der Hardware halte ich für viel wichtiger als die Effizienz der Software. Wir leben nicht mehr in den 70er, 80er Jahren, wo Varibalenlängen deklariert werden mussten, weil der Speicher rar war. Heute hben wir Arbeitspeicher zu hauf, Mehrkernprozessoren für wenig Geld, mit viel Leistung, jedoch wird die Leistung mit Stromverschwendung erkauft und mit hohen Verlustleistungen. Da fände ich es viel wichtiger anzusetzen.
Ganz klar: an der Hardwarefront muss sich etwas tun. Aber ich meine, man darf die Bedeutung der Software nicht aus den Augen lassen. Ein Beispiel: moderne CPUs haben schon einige Energiesparmodi (vor allem die in Notebooks). Um die zu nutzen, muss das Betriebssystem die CPU aber hinreichend lange in diese Modi versetzen können. Wenn nun eine Anwendung (oder das Betriebssystem selbst!) periodisch Aktivitäten ausführt, so kann der Energiesparmodus nicht, nicht lange oder nicht tief genug erreicht werden. Es ist also auch an den Software-Entwicklern, hier einen Beitrag zu leisten.
Da das wenige beachtet wird und energiesparende Programmierung oft umdenken erfordert, tut sich in diesem Bereich leider relativ wenig. Die Hardware-Designer müssen es dann (mal wieder) ausbaden, machen das auch gewohntermassen gut - finden aber nun einmal eben doch ihre Grenzen.
Energiesparmodie bringen uns garnichts, da sie nur genutzt werden wenn der Prozessor keine Last hat. Wenn der Prozessor last hat, frisst er wieder enorm. Die Architektur muss verändert werden. Wir haben mittlerweile Multicore CPUs mit annährnd 1 Mrd. Transistoren (Core i7) jeder bekommt ca. 1,2 Volt. Ein paar Elektronen brauchen wa da auch, also gibts ne gewisse Stromstärke. Das da über 100 Watt Leistungsaufnahme aufkommen is klar ersichtlich.
Hallo,
natürlich, wenn der Prozessor unter Vollast läuft, dann braucht er auch entsprechend Strom. Prinzipiell ist sicherlich - die Notebook-Prozessoren machen es vor - auch noch Einspaarpotential im Design der Prozessoren gegeben. ABER: wenn viel gerechnet werden muss, dann braucht das auch - leider - viel Strom. Früher ist das teilweise auch daher gar nicht aufgefallen, weil eben entsprechend weniger gerechnet wurde. Wer hat denn auf einem 286er schon einen Film dekodiert...?
Aber ich habe das Gefühl, ich verstehe Ihren Standpunkt nicht ganz. Worauf möchten Sie denn hinaus: darauf, dass die Prozessoren insgesamt weniger Stromaufnahmen haben sollten? Oder möchten Sie keine Multicore-Maschinen sehen? Oder geht die Kritik in Richtung "unnötiges Rechnen" (z.B. Warum werden überhaupt Computerspiele gespielt), d.h. generelle Reduzierung der Computeranwendung?
Viele Grüße,
Rainer Gerhards
Sorry, ganz vergessen: im Endeffekt müssen wir eigentlich erst einmal unterscheiden, welches Szenario wir betrachten: um nur zwei Beispiele zu nennen: den "normalen Desktop-PC" oder einen Rechner, der für technisch-wissenschaftliche Berechnungen eingesetzt wird. Bei ersterem bringen Energiesparmodi durchaus einiges. Die CPU "langweilt" sich ja über weiter Strecken der Laufzeit, z.B. während ich hier tippe. Da kann die Leistung (und damit der Verbrauch) gut runtergeschaltet werden.
Anders sieht es aus, wenn ich eine umfangreiche Berechnung, stundenlang, durchführen lasse. Da läuft der Rechner immer auf Hochtouren.
Auch andere Szenarien sind denkbar, und je nach Szenario gibt es auch das passende "Sparmodell". Vielleicht sollten wir uns also zunächst einmal auf ein paar Szenarien festlegen.
Schauen wir uns mal die neue GPU generation von AMD/ATI und NVIDIA an.
Bspw. der RV770 mit 800 ALUs diese nur dann stom ziehen wenn sie auch wirklich genutzt werden. Das sind 800 REcheneinheiten die Fließkomma berechnungen enstellen können. auf pcgh.de Werden mittlerweile Grafikkarten dank eines Moduls auf ihren Stromverbrauch getestet. Aber das Problem liegt nicht nur an der Abschaltung von Prozessorbereichen bei Nichtnutzung, sondern eine neue Technologie muss her. Schauen sie heutige Prozessoren können 2 - 3 Mrd. Rechenoperationen Pro Sekunde erledigen ob da nun ein algorithmus 50 Schleifen durchläuft oder 500 interessiert die Rechenzeit nicht viel. Das Problem ist doch das Diese Hundertmillionen Transitoren nicht nur 1 Elektron an Strom zum schalten verbrauchen, sondern tausende und mehr. Meine Gedanken klingen jetzt zwar wie zukunftsmusik, aber ich glaube das ein Prozessor mit Lichttechnik effiztienter arbeitet, wir haben mittlerweile licht emittierende Tranistoren und licht aufnehmen. wenn man diese vereint und die schaltung im prozessor lichtgesteuert gestaltet wird er nicht nur durch die lichtgeschwindigkeit schneller sondern auch stromsparender da ein photn zu erzeugen weniger energie benötigt wird als ein herkömmlicher transistor zum schalten benötigt.
entschuldigen sie meine kleinschreibung.
Also ganz prinzipiell würde ich eine ganz neue, schnellere und dabei Strom sparende Technologie natürlich auch begrüssen. Ich stecke bei weitem nicht genügend in den Hardware-Details um hier eine realistische Abschätzung zu geben. Aber sei die Hardware noch so effizient: auch die Software darf nicht verschwenderisch mit den Resourcen umgehen...
Nochmal zur heutigen Technologie: da steckt durchaus noch Potential drin. Wenn Sie die heutige (primär) CMOS-Technik betrachten, dann wird Strom im Regelfall dann verbraucht, wenn die Komponenten schalten müssen (besser gesagt beim Ladungstransport). Heute ist natürlich auch der Leerlaufstrom ein Problem, vor allem, wenn die CPUs sehr warm werden. Aber ignorieren wir das einmal.
Nach Ihrem Beispiel gehe ich nun eher von einem Desktop-Szenario aus, es wird also nur gelegentlich volle Rechenleistung benötigt, meist weniger. Eine Teilabschaltung von Komponenten, gar ganzen Cores, kann da durchaus Strom sparen. Denn wenn ich auf einem 4-Kern Prozessor drei der Kerne abschalte (vom Takt trenne), dann schalten die nicht und verbrauchen Ergo auch keinen Strom. Klar, nun ist immer noch die Infrastruktur da, Caches etc. Nun kann ich aber auch noch Takt und Betriebsspannung reduzieren, und kann weiter Strom sparen. Vieles davon passiert mittlerweile ja auch. Als Benutzer merkt man das gut an den unterschiedlich schnell laufenden Lüftern, je nach Betriebssituation.
Damit all' das funktioniert, muss aber auch die Software "mitspielen", d.h. insbesondere keine Algorithmen verwenden, die solche Sparmechanismen erschweren.
"Ein Java Programm wird also üblicherweise etwas langsamer sein als ein vergleichbares C Programm."
Sobald ein C-Progamm nichttrivale Speicherverwaltung betreibt, ist es in der Regel der Garbage-Collection moderner JVMs unterlegen, denn es ist ein Mythos, dass malloc/free schnell sind. Insofern ist die Aussage oben allenfalls noch für Trivalsoftware zutreffend.
Wenn man jetzt noch anfängt die Energie einzurechnen, die Entwickler im gut geheizten oder klimatisierten Büro verschwenden um in C-Programmen Fehler zu finden, die so in einem Java-Programm schon garnicht passieren können, ist die Energiebilanz für C ziemlich schlecht.
"... gehört Java zu einer Sprachfamilie, die keinen direkten Maschinencode erzeugt."
Das stimmt so auch nicht. Während ein C-Progamm immer komplett übersetzt wird, compiliert der Just-In-Time-Compiler einer modernen Java Virtual Machine die zeitkritischen Codeanteile sehr wohl in Maschinencode.
Hallo Herr Kirsch,
freut micht, dass die Java Gemeinde so langsam Notiz nimmt. Ich hatte mich ehrlich gesagt schon gewundert. Der Titel ist bewusst provokativ gewählt. Ich möchte insgesamt auf das Thema "Energieeffiziente Programmierung" hinweisen.
Java ist sicherlich nicht wirklich klimaschädlich. Ich kann Ihren Argumenten durchaus weitgehend zustimmen, ähnliche Argumentationen führe ich ja zum Ende des Blogposts selbst an (in dem Abschnitt über "Mhhh... Schade! Auch hier scheinen sich keine einfachen Antworten zu finden.").
Ein paar Anmerkungen dennoch: was die Effizienz der Speicherzuordnung angeht, dann darf man natürlich nicht eine hochoptimierte Java VM Implementierung mit einer schlecht optimierten C-Laufzeitbibliothek vergleichen. Wenn, dann müsste man also zwei von der Qualität identische Implementierungen vergleichen. Da dürfte dann C allerdings immer noch ein kleines bisschen "die Nase vorn" haben. Aber, wie geschrieben: das sollte üblicherweise keineswegs einen relevanten Unterschied ausmachen.
Anders sieht die Sache aber bei hochoptimierten Sequenzen gerade in den Laufzeitbibliotheken (respektive VM) aus: da wird ja teilweise durchaus noch Assembler programmiert (an wenigen aber entscheidenden Stellen). Hier genau zeigt sich meiner Meinung nach die Notwendigkeit zu überlegen, wann man optimiert. Das ist natürlich keine neue Frage, sondern eine, die man sich immer schon gestellt hat. Bei Code, der besonders häufig ausgeführt wird (Herr Dueck hatte da ja ein sehr gute Beispiel in seinem Blog), lohnt sich die Hand-Optimierung eben doch. Von der Gesamt-Codemenge her gesehen gilt das aber eben nur für einen verschwindend geringen Teil. Die Identifikation der entscheidenden Stellen ist wichtig.
Was den Just in Time Compiler angeht: den hatte ich ja auch schon im Blog ein wenig angesprochen, und der verbessert das Laufzeitverhalten natürlich dramatisch. Ich habe dazu auch eine sehr schöne Mail erhalten, werde beim Autor 'mal nachfragen, ob ich sie als Kommentar posten kann.
Wichtig ist mir aber: Ob Java, C oder was auch immer: die Art und Weise der Progammierung kann durchaus Auswirkungen auf den Energiebedarf haben. Und darauf sollte meines Erachtens stärker hingewiesen werden. Natürlich gibt es Sachen mit grösseren Auswirkungen. Wenn nun aber jeder sagt "mich muss das nicht kümmern, die anderen können mehr tun", dann brauchen wir uns nicht zu wundern, wenn letztlich gar nichts passiert. Meiner Meinung nach kann und sollte man durchaus im Kleinen anfangen - sei es hier bei Programmieren oder auch mit der Ausstattung seiner Wohnung mit energiesparender Beleuchtung...
Vielen Dank nochmals für die Kommentare, ich freue mich sehr darüber!
Rainer Gerhards
Der große Vorteil von Java als es aufkam, war doch gerade der Bytecode. Ein Programmierer schrieb ein Programm, egal ob auf Windows oder Linux und kompilierte den Bytecode und dieser konnte dann egal ob auf Linux oder Windows interpretiert werden (hat nicht ganz geklappt, aber immerhin). C hingegen muß immer passend zum Betriebssystem kompiliert werden. Wird die Plattformunabhängigkeit von Java überhaupt noch genutzt? Wenn nicht, weshalb ist Java nun so weit verbreitet, wenn es auf die Plattformunabhängikeit nicht ankommt und C das gleiche zu leisten im Stande ist und dann auch noch energieschonender? Die Garbage-Collection und das fehlen von Zeigern bei C++? Wenn dem so ist, warum wird Java nicht eine vollends kompilierte Sprache?
O wei o wei ........
Es ist schon interessant, mit wie wenig Zeichen man viel sagen kann. Daher auch eine Antwort: ich empfehle, meinen Post einmal wirklich zu lesen. Er trägt nämlich einen bewusst provokativen Titel, folgt dann aber Ihrer eigenen Argumentation.