Software-In-Effizienz - Java
Zumindest große oder oft genutzte Applikationen sollten nicht in Java geschrieben werden.
Grund:
Java-Anwendungen werden einmal kompiliert. Das Kompilat ist aber nicht ausführbarer Maschinencode für die entsprechende
Zielplattform, sondern s.g. ByteCode für eine "virtuelle Maschine", die Java Virtual Machine (JVM).
Diese ist wiederum selbst ein "normal kompilierte" (C/C++)-Applikation die den ByteCode interpretiert; d.h. dass der Geschwindigkeitsverlust dort "passiert" und
abhängig ist vom Betriebssystem, bzw. von der Prozessorarchitektur.
Benchmark-Test: ein Primzahlenprogramm läuft z.B.
auf Sun-Solaris mit JVM-V1.4? nur 3.5-mal langsamer als das C-Programm.
Auf Intel-Architekturen ist es 10-mal langsamer.
Eine JVM gibt es für alle möglichen Zielplattformen (OS/2, Windows,
Unix, OS/390 ...).
Mit Java wird man also plattformunabhängig und die JVM ist im allgemeinen frei verfügbar.
Aber diese Plattform-Unabhängikeit hat trotzdem ihren Preis:
Hoher Ressourcenverbrauch und Performanzeinbußen. Außerdem wird die
Plattformunabhänigkeit eingetauscht in die Versionsabhängigheit der JVM.
Es laufen aber oft verschiedene Version auf einem Rechner, je nachdem,
welche Version eine Anwendung benötigt. Das ist auch nicht gerade
ressourcensparend.
Der Kostenvorteil der schnelleren Entwicklung mit Java, wird von den Kosten
im Betrieb mehr als aufgehoben.
Z.B.: bei der Batch-Verarbeitung in Rechenzentren nachts, wenn die Ergebnisse am nächsten Tag vorliegen müssen,
dann müssen mehrere Rechner parallel eingesetzt werden.
Damit steigen natürlich die Betriebskosten, vor allem der Stromverbrauch im RZ.
Es ist zwar sehr löblich, daß die Hardware-Hersteller jetzt immer mehr
auf den Energieverbrauch ihrer Produkte achten (s.a. Thema auf der Cebit 2008).
Für die Software-Firmen ist das aber wohl noch kein Thema.
Der Gipfel: ! Die Umstellung einer konventionell kompilierten Applikation nach
Java (z.B. zwecks kürzerer Produktzyklen) macht u.U. alle Energieeffizienz-Anstrengungen
der HW-Produzenten zunichte.
aktuell: 2008-03-26 (Erfahrungsbericht CER)