Reif für die Insel?
Wie weit ist Java?

Franz Franchetti, Christoph Ortner, Christoph Überhuber

Längst hat Java den Ruf verloren, langsam zu sein [13]. Ob es jedoch bereits für das numerische Rechnen im Bereich technisch-naturwissenschaftlicher Anwendungen geeignet ist, wurde am Institut für Angewandte und Numerische Mathematik der TU Wien untersucht [6, 7]. Als Basis dieser Studien dienten sowohl selbst geschriebene numerische Programme als auch fertige numerische Software. In beiden Fällen wurden die Java-und C-Varianten hinsichtlich ihrer Gleitpunktleistung (Performance) untersucht. Die Ergebnisse haben sich als vielversprechend, wenn auch nicht als spektakulär erwiesen.

Warum Java?

Java war ursprünglich für die Software-Entwicklung im Bereich elektronischer Geräte gedacht und sollte negative Eigenschaften von C bzw. C++ vermeiden. Die primären Ziele waren Plattformunabhängigkeit, einfache Anwendbarkeit und Zuverlässigkeit.

Besonders die Eigenschaft der Plattformunabhängigkeit macht Java zu einem sehr interessanten Werkzeug für viele Anwendungen, allerdings erfordert dies die Verwendung von potentiell langsamen Virtual Machines (VMs). Spezielle VM-Technologien wie Just-in-Time- (JIT) Übersetzung ermöglichen es, Java-Programme zu schreiben, die fast so schnell sind wie C-Programme.

Weitere Vorteile von Java sind beispielsweise die automatische Garbage Collection (erleichtert die Speicherverwaltung), in die Sprache integriertes Exception-handling, integriertes Multi-threading und -ebenfalls von enormer Bedeutung für das numerische Rechnen -Netzwerksicherheit und umfangreiche standardisierte Kommunikationsbibliotheken. Diese Eigenschaften machen Java zu einem vielversprechenden Werkzeug für Parallelrechner und verteilte Systeme.

Warum nicht Java?

Als relativ junge Programmiersprache hat Java noch einige Schwächen, die erst behoben werden müssen, bevor es in echte Konkurrenz zu C/C++ und Fortran treten kann. Das größte Hindernis für den Einsatz im technisch-naturwissenschaftlichen Bereich ist die bisher unbefriedigende Performance (Gleitpunktleistung) von Java-Programmen, die bis zu einem Faktor 100 langsamer sein konnten als äquivalente C-Programme. Die Just-in-Time-Compiler verringerten diesen Rückstand beträchtlich, aber Java-Programme erreichen noch immer nicht die Leistung von C- oder Fortran-Programmen. Einige der Gründe dafür werden in der folgenden Aufstellung kurz angesprochen.

Das Java-Klassenmodell, das ein grundlegender Bestandteil des "Java-Konzepts" ist, verursacht einen relativ hohen Overhead. In vielen Situationen würden "abgespeckte Klassen", so genannte "Lightweight-Klassen" benötigt, die diesen Overhead verringern und damit eine bedeutend höhere Gleitpunktleistung ermöglichen.
Das Fehlen des Datentyps complex in der Sprachdefinition von Java ist für viele technisch-naturwissenschaftliche Anwendungen ein wesentlicher Mangel. Um das Fehlen dieses Datentyps zu kompensieren, gibt es in Java entweder die Möglichkeit, eine Klasse Complex selbst zu definieren, das führt aber zu Ineffizienzen (siehe vorhergehender Punkt), oder die komplexen Rechnungen vollständig in reeller Arithmetik zu implementieren, was zu einem signifikant gesteigerten Programmieraufwand und zu fehleranfälligen, schlecht lesbaren und schlecht wartbaren Programmen führt.
Java verbietet die Verwendung leistungssteigernder Features moderner Gleitpunkt-Hardware wie Fused-multiply-add- (FMA) Instruktionen oder (SIMD-) Vektoroperationen. Der Grund dafür liegt in der Java-Spezifikation, die eine exakte Reproduzierbarkeit der Rechenergebnisse verlangt. Das heißt, auf jedem System muss man bei Durchführung bestimmter Rechenabläufe jederzeit exakt dasselbe numerische Ergebnis erhalten. Diese Forderung verhindert Leistungssteigerungen um signifikante Faktoren.

An der Behebung der meisten dieser negativen Eigenschaften von Java wird bereits intensiv gearbeitet. Beispielsweise wird nach Möglichkeiten gesucht, die Java-Spezifikation um eine Bibliothek für Methoden der Numerischen Linearen Algebra zu erweitern. Eine andere wichtige, bereits geplante Änderung wurde vorübergehend leider gestoppt -die Einführung des Schlüsselworts fastfp, welches für die Verwendung beliebiger numerischer Hardware gedacht war.

Wie bereits erwähnt, enthält diese Liste nur Kritikpunkte an Java, die für die Gleitpunktleistung technisch-naturwissenschaftlicher Programme relevant sind. Detaillierte Informationen findet man z.B. in [2, 4, 5, 9, 10, 11, 12].

Java vs. C -FFT-Algorithmen

Dass Java-Programme nicht mehr langsam sind sieht man deutlich in Abb. 1, wo Java im In-cache-Fall bis zu 75 % der Leistung von C erreicht. Den Leistungskurven dieser Abbildung liegt ein Experiment zugrunde, wo (im Gegensatz zum Experiment des folgenden Abschnitts) die Gleitpunktleistung völlig äquivalenter Radix-4-FFT-Codes (siehe Van Loan [15]) gemessen wurde. Getestet wurde mit Virtual Machines von Sun und IBM sowie mit dem Visual C-Compiler von Microsoft auf einem PC mit Pentium-4-Prozessor (1800 MHz) und 256MB RD-RAM.

Abbildung 1: Gleitpunktleistung einer einfachen Radix-4-FFT-Routine in C und unter verschiedenen Java-Plattformen (alle unter Windows 2000) auf einem PC mit Pentium-4-Prozessor (1800 MHz) und 256MB RD-RAM.

Bei diesem FFT-Leistungstest erreichte die Virtual Machine von IBM [8] fast durchwegs 75 % der Leistung von C. Auch die Virtual Machines von Sun [14] und Microsoft lieferten eine durchaus zufriedenstellende Gleitpunktleistung. Interessanterweise scheint der Excelsior Jet Compiler, der (ohne eine Virtual Machine zu verwenden) ausführbare Dateien erstellt, keinen Vorteil gegenüber den anderen Systemen zu bieten. Besonders auffallend ist die Tatsache, dass im Out-of-cache-Bereich alle Java-Plattformen sehr nahe an die Leistung des C-Vergleichsprogramms herankommen. Dieses Bild ist typisch für Vergleiche von Java und C auf Prozessoren der Pentium-4-Familie.

Bei Verwendung eines anderen Speicher-Layouts (split statt interleaved) ist es sogar möglich, dass Java-Programme im Out-of-cache-Fall um 10 % schneller sind als das entsprechende C-Programm.

Die Ergebnisse auf einem PC mit Athlon XP-Prozessor (der ein anderes Speicher-Subsystem als der Pentium 4 besitzt) fielen weniger vorteilhaft für Java aus, waren aber noch akzeptabel. Die Gleitpunktleistung der Virtual Machine von IBM liefert dort etwa die halbe Gleitpunktleistung des entsprechenden C-Programms.

Java vs. C -Algorithmen der Linearen
Algebra

Im Rahmen eines anderen numerischen Experiments wurden existierende Java-Software-Pakete aus dem Bereich der Numerischen Linearen Algebra verglichen [7]. Als Basis des Vergleichs dienten CLAPACK [1] und CATLAS [3].

Hier ergab sich ein anderes Bild als bei dem FFT-Experiment. Java-Software erreichte auch hier etwa die Hälfte der Gleitpunktleistung des "Standardpakets" CLAPACK, allerdings existiert mit CATLAS die Möglichkeit, noch deutlich höhere Leistungswerte zu erzielen, die derzeit mit Java nicht annähernd erreichbar sind. Dies liegt daran, dass CATLAS spezielle maschinenspezifische Optimierungen durchführt, die es weder bei CLAPACK noch bei den verschiedenen Java-Versionen gibt.

Getestet wurde mit Programmen für die Matrizenmultiplikation, LU- und Cholesky-Faktorisierung, sowohl in reeller als auch in komplexer Arithmetik. Die verwendete Virtual Machine war auch hier JDK 1.2.2 von IBM unter Windows, der C-Code wurde unter Linux mit dem GNU C-Compiler kompiliert. Das Testsystem war ein PC mit einem Prozessor vom Typ AthlonXP 1800+ (1533 MHz) und 768 MB DDR-SDRAM.

Die Java-Leistung für die komplexen Berechnungen mit CLAPACK ist konsistent mit den Resultaten der FFT-Studie: JAMPACK konnte bei der Matrizenmultiplikation 80 % der Leistung von CLAPACK erreichen. Auch bei der LU- und der Cholesky-Faktorisierung konnten ähnlich gute und teilweise sogar noch bessere Ergebnisse erzielt werden.

Abbildung 2: Gleitpunktleistung der LU-Faktorisierung mit verschiedenen Java-Programmpaketen (IBM Jdk 1.2.2, WindowsXP) und C (gcc, Linux) auf einem PC mit AthlonXP 1800+ (1533 MHz) und 768MB RAM.

Der Umfang jener Java-Programmbibliotheken, die vertretbare Performance liefern, erreicht derzeit noch nicht den Umfang von LAPACK. Das einzige Java-Paket, welches alle einschlägigen Routinen enthält, liefert eine so schlechte Gleitpunktleistung, dass es bei den Tests ausgeklammert wurde [7].

Folgerungen

Die Frage, ob Java für die Entwicklung technisch-naturwissenschaftlicher Software verwendet werden soll, ist im Augenblick eher noch zu verneinen. Allerdings entwickelt sich Java äußerst schnell und wird vermutlich bald in direkte Konkurrenz zu C und Fortran treten können. Mit dem Erscheinen neuer, Java-spezifischer, effizienter numerischer Software wird sich schon bald eine Situation ergeben, wo Java eine ernst zu nehmende Alternative zu Fortran und C darstellt.

Der Hauptvorteil von Java gegenüber anderen Sprachen -eine nahezu vollständige Plattformunabhängigkeit -garantiert, dass es spätestens nach dem Beseitigen noch vorhandener Schwächen eine attraktive Programmiersprache für technisch-naturwissenschaftliche Problemlösungen darstellen wird.

Literatur

[1] E. Anderson, Z. Bai, C. Bischof, J. Demmel, J.J. Dongarra, J. Du Croz, S. Hammarling, A. McKenney, S. Ostrouchov, D.C. Sorensen: LAPACK User's Guide. SIAM Press, Philadelphia, 3rd ed., 1999.

[2] P.V. Artigas, M. Gupta, R.D. Lawrence, S.P. Midkiff, J.E. Moreira, M. Snir: Java Programming for High-performance Numerical Computing. IBM System Journal, 39(1): pp. 21–56, 2000. http://www.research.ibm.com/journal/sj/391/moreira.html

[3] ATLAS. http://math-atlas.sourceforge.net/

[4] J. D. Darcy, W. Kahan: How Java's Floating-Point Hurts Everyone Everywhere. http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf

[5] J. D. Darcy, W. Kahan: Analysis of Proposal for Extension to Java Floating-Point Semantics, Revision 1. http://www.sonic.net/~jddarcy/Research/jgrande.pdf

[6] F. Franchetti, C. Ortner, C. W. Ueberhuber: Java vs. C -A Performance Assessment Based on FFT Algorithms. Technical Report AURORA TR2001-20, Institute for Applied Mathematics and Numerical Analysis, Vienna University of Technology, 2001. ftp://ftp.par.univie.ac.at/projects/aurora/reports/auroratr2001-20.ps.gz

[7] F. Franchetti, C. Ortner, C. W. Ueberhuber: Performance of Linear Algebra Routines in Java and C. Technical Report AURORA TR2002-06, Institute for Applied Mathematics and Numerical Analysis, Vienna University of Technology, 2002. ftp://ftp.par.univie.ac.at/projects/aurora/reports/auroratr2002-06.ps.gz

[8] IBM Developer Works. http://www-106.ibm.com/developerworks/

[9] Java Grande Forum. http://www.javagrande.org/

[10] Java Numerics. http://math.nist.gov/javanumerics/

[11] B. Joy: The Design of the Java Language: Towards a Science of Reliable Programming, 1999. www.cs.ucsb.edu/conferences/java99/slides/81-joy.ppt

[12] S. Midkiff, J. Moreira: A Comparison of Java, C/C++, and Fortran for Numerical Computing. IEEE Antennas and Propagation Magazine, 40(5): pp. 102–105, 1998.

[13] J. Moreira, S. Midkiff, M. Gupta: From Flop to Megaflops: Java for Technical Computing. ACM Transactions on Programming Languages and Systems, 22(2): pp. 265–295, 2000.

[14] Sun's Java Homepage. http://java.sun.com/

[15] C.F. Van Loan: Computational Frameworks for the Fast Fourier Transform. SIAM Press, Philadelphia, 1992.

Seitenanfang | ZIDline 7 - Oktober 2002 | ZID | TU Wien

Reif für die Insel? Wie weit ist Java?