Java im Bauwesen – Performance

Werbung
Java im Bauwesen – Performance-Untersuchung
einer agentenbasierten Tragwerksberechnung
Jochen Bilek
Ruhr-Universität Bochum
Zusammenfassung
Im Januar 1996 wurde die objektorientierte Programmiersprache Java offiziell eingeführt. Seitdem hat Java eine rasante Entwicklung durchgemacht und wird zunehmend auch
in der Ingenieurinformatik eingesetzt. In diesem Beitrag wird die Performance von Java
für Anwendungen im Bauwesen beispielhaft anhand einer agentenbasierten Tragwerksberechnung empirisch untersucht. Die Tragwerksberechnung wurde auf mehreren Rechnern
und Betriebssystemen mit verschiedenen Java-Versionen durchgeführt. Zur automatisierten Durchführung der Untersuchung wurde ein mobiler Software-Agent realisiert, der die
Tragwerksberechnungen autonom auf den einzelnen Rechnern durchführte. Anhand der
Auswertung der ermittelten Rechenzeiten konnten qualitative Aussagen über die Performance von Java auf verschiedenen Betriebssystemen gemacht werden.
1 Einleitung
Im Januar 1996 präsentierte Sun Microsystems der Öffentlichkeit die erste offizielle Version der
völlig neu entwickelten, streng objektorientierten Programmiersprache Java. In den folgenden
Jahren nahm die Verbreitung, Bedeutung und Anwendungsbasis – besonders bei serverseitigen
Applikationen – von Java stetig zu: Java ist zur Zeit die Programmiersprache mit den höchsten Wachstumsraten. Die Gründe hierfür sind vielfältig: Java ist das Ergebnis mehrjähiger
Forschungsarbeit, bei der von Anfang an besonderer Wert auf die Unterstützung von InternetAnwendungen gelegt wurde und zudem konsequent viele Fehler und Schwächen anderer Programmiersprachen ausgemerzt wurden. Zu den größten Vorteilen von Java zählen neben der
strengen Objektorientierung, die Compilierung von Java-Quellcode in maschinenunabhängigen
Bytecode (Plattformunabhängigkeit), die leichte Erlernbarkeit, ein ausgefeiltes Sicherheitskonzept, die automatische Speicherverwaltung, die Unterstützung von Nebenläufigkeit (Multithreading), eine hochentwickelte Fehlerbehandlung, die Unterstützung graphischer Oberflächen und
nicht zuletzt die zahlreichen und umfangreichen Klassenbibliotheken. Aufgrund der Plattformunabhängigkeit wird Java aber auch nachgesagt, relativ „langsam“ zu sein. Durch die Entwicklung ausgefeilter Compiler-Techniken (Just-in-Time (JIT) Compilierung von Java Bytecode,
vgl. Kap. 2.1) konnte die Ausführungsgeschwindigkeit von Java-Programmen stark gesteigert
werden: im Vergleich zu C# oder C++ ergeben sich nur marginale Unterschiede [?]. Bei den rein
prozeduralen Programmiersprachen wie Fortran oder C spricht man dagegen noch von einem
Faktor bis zu zwei.
Im Software-Entwicklungsprozess ist jedoch oft nicht die reine Rechenzeit einer Anwendung
entscheidend: vielmehr sind Entwicklungs-, Wartungs- und Fehlersuchzeiten von größerer Bedeutung. Studien haben gezeigt, dass Java-Projekte nur halb so viel Zeit für Fehlersuche in
Anspruch nehmen wie vergleichbare C- oder C++-Projekte [?].
1
Auch im Bereich des Bauwesens ist eine ständige Zunahme von in Java implementierter Ingenieursoftware zu beobachten. Die Gründe hierfür liegen zum einen in den bereits geschilderten,
konzeptionellen Vorteilen von Java, zum anderen ist die Planung von Bauwerken zunehmend
durch verteilt ablaufende Planungsprozesse geprägt: dies erfordert auch im Bauwesen den zunehmenden Einsatz internetbasierter Technologien, die häufig auf Java beruhen. Aber auch bei
den klassischen, rechenintensiven Verfahren aus dem Bereich der Finite-Element-Berechnung
können mittlerweile mit Java gute Ergebnisse erzielt werden [?].
Aus den oben genannten Gründen wurde daher die Lehrveranstaltung Grundlagen der Ingenieurinformatik des Lehrstuhls für Ingenieurinformatik im Bauwesen der Ruhr-Universität Bochum
schon früh (April 1998) auf Java umgestellt. In der Folgezeit wurden zahlreiche Forschungsprojekte am Lehrstuhl mit Hilfe Java-basierter Technologien erfolgreich realisiert oder sind gerade aktuelles Forschungsgebiet: Optimierung von Tragwerken, Verkehrsimulation, TalsperrenMonitoring, Einsatz der Agententechnogie in der vernetzt-kooperativen Tragwerksplanung [?],
Objektorientierte Modellierung in Planung und Konstruktion, u.a. Überdies wurde im März
2003 die gesamte Web-Präsentation des Lehrstuhls umgestaltet und auf eine innovative, auf
Java- und XML-basierende technologische Grundlage gestellt.
Zusammenfassend kann festgestellt werden, dass auch am Lehrstuhl für Ingenieurinformatik
die Bedeutung der Programmiersprache Java und der Einsatz Java-basierter Technologien stark
zugenommen haben und nunmehr von großer Bedeutung sind.
Dies wurde zum Anlass genommen, eine Untersuchung der Performance, Entwicklung und Leistungsfähigkeit von Java im Bereich des Bauwesens – und hier besonders im Bereich der Tragwerksplanung – vorzunehmen. Ziel dabei war es, im heterogenen Netzwerk des Lehrstuhls auf
verschiedenen Rechnerarchitekturen unter Einbeziehung verschiedener Java-Versionen Tragwerksberechnungen ablaufen zu lassen, die Ergebnisse der Berechnungen (besonders die Rechenzeiten) zu sammeln und dann auszuwerten. Zur Unterstützung der Datenbeschaffung wurde
eine autonome Software-Komponente in Form eines mobilen Software-Agenten („BenchmarkAgent“) realisiert. Dieser Agent ist in der Lage, selbständig durch das Netzwerk des Lehrstuhls
zu migrieren, auf den einzelnen Rechnern die strukturanalytischen Berechnungen (nach Theorie
I. Ordnung) durchzuführen und am Ende mit den Ergebnissen zum Ursprungsrechner zurückzukehren.
2 Konzept und Aufbau der Untersuchung
Bei der Konzeption der Untersuchung waren zunächst die folgenden vier Teilaspekte vorab zu
bedenken: 1) die Festlegung der Java-Versionen, mit denen die Berechnung durchgeführt werden sollten, 2) die Wahl der eingesetzten Rechner und Betriebssysteme, 3) die Wahl einer geeigneten Beispiel-Tragstruktur, deren Diskretisierung und die Festlegung auf ein Berechnungsverfahren und zuletzt 4) die Entwicklung einer Software zur automatisierten Durchführung der
Untersuchung.
2.1
Eingesetzte Java-Versionen
Der plattformunabhängige Java Bytecode wird von einer sog. Java Virtual Machine (JVM) interpretiert und ausgeführt. Eine JVM ist eine Spezifikationen, die beschreibt, wie ein Java Bytecode Interpreter aufgebaut sein muss bzw. welchen Rahmenbedingungen er genügen muss.
Prinzipiell kann jede Firma oder Privatperson eine eigene JVM entwickeln. Die Referenzimplementierung einer JVM wird zu jedem neuen Release regelmäßig von Sun Microsystems, dem
2
„Erfinder“ von Java, geliefert. Neben der Referenzimplementierung von Sun existieren noch
weitere JVM’s, z.B. von IBM [?] oder die KAFFE JVM [?]. Der überwältigende Teil der JavaEntwickler arbeitet jedoch mit der Sun-Referenzimplementierung, dem Sun JDK (=Java Development Kit) bzw. dem Sun J2SDK (=Java 2 Standard Development Kit). Im Volano-Report [?],
der die Ausführungsgeschwindigkeit der JVM’s verschiedener Hersteller untersucht und verglichen hat, schnitten die JVM von Sun und IBM am besten ab. Im Rahmen der Untersuchung
wurden nur die Java-Versionen von Sun getestet.
Folgende Java-Versionen hat Sun Microsystems bisher zum Download zur Verfügung gestellt:
• JDK 1.0: Das JDK 1.0 ist das erste Release von Java (Januar 1996). Das JDK 1.0 ist
allerdings von von Sun als EOL (End of Life) gekennzeichnet, d.h. der Vertrieb wurde
eingestellt. Da im JDK 1.0 grundlegende Eigenschaften und Mechanismen wie Serialisierung noch nicht berücksichtigt sind, konnte das JDK 1.0 nicht in die Untersuchung
einbezogen werden.
• JDK 1.1: Im Februar 1997 stand die erste Beta-Version des neuen JDK 1.1 zum Download bereit. Mit dem JDK 1.1 wurde eine Reihe von Bugs der Vorgänger-Version behoben
und zusätzliche Funktionalitäten angeboten. Die Version 1.1.6 für Windows wurde zum
ersten Mal mit einem Just-in-Time-Compiler (der Firma Symantec) ausgeliefert, der die
Ausführungsgeschwindigkeit deutlich erhöhte.
• J2SDK 1.2: Ab dem Release J2SDK 1.2 (Frühjahr 1998) spricht man von der Java 2
Plattform. Gegenüber dem JDK 1.1 gab es zahlreiche Neuerungen und Verbesserungen.
So wurden die Java Foundation Classes (JFC) mit dem Swing-Toolset, die Java 2D API 1 ,
die Collection API, die Drag-and-Drop API und andere Erweiterungen eingeführt. Bei
der Entwicklung des J2SDK standen Stabilität, Performance und Qualitätssicherung im
Vordergrund. Ab März 1999 wurde dann der lang angekündigte Java Hotspot-Compiler
ausgeliefert.
• J2SDK 1.3: Das J2SDK 1.3 wurde im August 1999 ausgeliefert und verbesserte die Performance der Swing-Anwendungen deutlich. Dies lag zum großen Teil an dem völlig neu
entwickelten Garbage-Collector, einem neuen Speichermanagement und einem komplett
überarbeiteten Hotspot-Compiler.
• J2SDK 1.4: Die seit Februar 2002 veröffentlichte offizielle Version des J2SDK 1.4 brachte erhöhte Datensicherheit durch neue SSI- und Kryptographiebibliotheken mit sich. Ebenso wurden die graphischen API-Klassen verbessert und um neue Funktionen wie Webservices erweitert. Mit dem J2SDK 1.4 wurde auch ein neuer Hotspot-Compiler ausgeliefert.
Bei der Entwicklung der Performance von Java spielen die Just-in-Time-Compiler (JIT) eine
wichtige Rolle. Ein JIT-Compiler ist ein Programm, das den Bytecode während der Ausführung in Maschinencode der aktuellen Plattform übersetzt und so beim nächsten Mal wesentlich
schneller ausführen kann. Vorteilhaft dabei ist, dass der Bytecode plattformunabhängig bleibt
und lediglich der Just-in-Time-Compiler plattformspezifisch an ein bestimmtes Betriebssystem
gebunden ist. Ein JIT-Compiler ist in der Lage, bestimmte Codeteile so stark zu beschleunigen,
dass ihre Ablaufgeschwindigkeit der von kompilierten C-Code nahe kommt. Dies muss aber
aber längst nicht für alle Teile eines Programms gelten.
Die JIT-Compiler von Sun werden ab dem J2SDK 1.2 Hotspot-Compiler genannt. Ab dem
J2SDK 1.3 hat man die Möglichkeit, die JVM mit einem der folgenden zwei JIT-Compiler zu
starten:
1 Application
Programming Interface
3
1. Server: längere Compilezeit als bei Hotspot, optimiert die Ausführungsgeschwindigkeit,
jedoch längere Startzeiten (Startup Time), konzipiert für lang laufende Applikationen,
2. Hotspot (Client): schnelle Start- und Ausführungszeiten von kurzlebigen, interaktiven
GUI-Applikationen, verbesserte Laufzeit Performance für Applikationen und Applets,
weniger Optimierungen als bei Server, daher weniger Zeit für die Analyse und weniger
Compilezeit.
Für die Untersuchung werden alle zuvor aufgezählten Java-Versionen mit und ohne Just-inTime-Compiler eingesetzt.
2.2 Eingesetzte Hardware und Betriebssysteme
Die Entwicklung der Hardware schreitet bekanntlich rasant voran. Bereits 1965 hat Gordon
Moore postuliert, dass sich die Leistung der Computerchips alle 2 Jahre verdoppeln würde. Sind
nun Vorhersagen im Allgemeinen schon schwierig genug, so scheint es in der schnelllebigen
Halbleiter-Branche geradezu ausgeschlossen, auch nur halbwegs treffende Prognosen für die
Zukunft abzugeben. Gerade deshalb ist es besonders bemerkenswert, dass sich nun schon seit
knapp 40 Jahren die Moore’sche Zukunftsformel sehr präzise bewährt hat.
Das Moore’sche Gesetz trifft in etwa auch für die Hardwareausstattung des Lehrstuhls für Ingenieurinformatik zu: anfangs (1998) wurde Java noch auf Pentium I Rechnern (133 MHz) eingesetzt; mittlerweile - 6 Jahre später - sind 800-1600 MHz Rechner Standard. Um der Schnelllebigkeit in der Hardware-Entwicklung einigermaßen Rechnung zu tragen, wurden für die Untersuchung ältere Rechner reaktiviert und mit Java ausgestattet und zudem neuere Rechner und
Notebooks sowie ein PDA2 (Mobile Computing) für die Untersuchung eingesetzt. Einziges Kriterium bei der Auswahl der Hardware war, dass auf den Rechnern Java installiert werden konnte
und ein Netzwerkanschluss vorhanden war. Bei dem ältesten Rechner handelt es sich um einen
386er PC mit 25MHz und 10MB Arbeitsspeicher, auf dem noch das JDK 1.1.8 installiert werden konnte. Der aktuellste eingesetzte Rechner war ein Intel Pentium 4 mit 2.53 GHz und 256
MB RAM. Ein Übersicht über die eingesetzte Hardware liefert Tabelle 1.
Auf der eingesetzten Hardware war zudem ein breites Spektrum an Betriebssystemen installiert:
nahezu alle Windows-Versionen, ebenso Linux und ein PDA-Betriebssystem. Prinzipiell wäre
es auch möglich gewesen, javafähige Mobilfunkgeräte (Handys) mit Fließkommazahlunterstützung miteinzubeziehen: jedoch wäre der Aufwand hierfür im Rahmen dieser Untersuchung zu
groß gewesen.
2.3 Wahl der Beispiel-Tragstruktur und Implementierung des
Berechnungsverfahrens
Als Beispiel-Tragstruktur wurde eine Fußgänger-Bogenbrücke aus Stahl (ST 37-2) gewählt.
Bild 1 zeigt das vereinfachte statische System der Brücke. Die 80m lange Fahrbahn ist über sieben Zugstangen an den Bogenträger angehängt. Als Profile wurden für den Bogen ein Rohrprofil
(610x16), für die 2,5m breite Fahrbahn vereinfachend ein Rechteck-Hohlprofil (2500x1000x20)
und für die Zugstangen ein Vollrohr-Querschnitt (Durchmesser 30mm) angenommen. Als Belastung wurde eine gleichmäßig verteilte Flächenlast von 6 KN/m2 (entspricht einer Streckenlast
von 15 KN/m) angesetzt.
2 Portable
Digital Assistant
4
Tabelle 1: Eingesetzte Hardware
Rechnername
turbo386
speedy486
racer586
tau
dell a
winner
Typ
CPU [MHz]
PC
PC
PC
PC
PDA
PC
psi
PC
AMD Athlon 800
256
stan
xp
CIP
PC
PC
PC
AMD Athlon 800
AMD Athlon XP 1600+
AMD Athlon XP 1600+
256
512
256
dihart
biber
smarlsly
NBd
NB
NB
Mobile Intel P4 1700
Mobile AMD XP 2400+
Mobile Intel P4 2530
512
512
265
Intel 25
Intel 486DX2 66
Cyrix 6x86 166+
AMD K6 350
Intel@XScale 400
Intel 2x400
RAM
[MB]
10
8
72
64
64
1024
Betriebssystem
Windows 95
Windows 95
Windows 98
Suse Linux 2.4.10
MS-Pocket PC 2003
Windows NT 4.0
Server
Windows 2000
Windows 98
Suse Linux 2.4.10
Windows XP
Suse Linux 2.4.10
Windows 2000
Windows XP
Windows XP
Windows 2000
1.1.8
x
x
x
x
xb
x
x
x
x
x
x
x
x
x
x
Java-Version
1.2.2 1.3.1
–
–
x
x
x
x
x
x
–
–
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
1.4.2
–
–
x
x
–
xc
x
x
x
x
x
x
x
x
x
a Dell
Axim X5 Pocket PC
JVM der Firma EsmerTec; auf dem Pocket PC kann keine andere JVM installiert werden
c J2SDK 1.4.1
d NB=Notebook
b Jeode,
Bild 1: Vereinfachtes statisches System der Bogenbrücke
Zur Berechnung der Verschiebung der einzelnen Knoten (nach Theorie I. Ordnung) wurde das
Weggrößenverfahren gewählt. Der Vorteil des Weggrößenverfahrens liegt darin, dass sich das
statische System in ein lineares Gleichungssystem überführen lässt, welches dann mit einem
geeigneten linearen Gleichungslöser gelöst werden kann. Im Weggrößenverfahren wird aus den
Steifigkeitsmatrizen der einzelnen Stäbe eine Gesamtsteifigkeitsmatrix (K) erzeugt. Es lässt sich
zeigen, dass die Gesamtsteifigkeitsmatrix K multipliziert mit dem Verschiebungsvektor v der
einzelnen Knoten, addiert mit dem Lastvektor p gerade den Nullvektor ergeben muss:
K̃ · ṽ + p̃ = 0̃.
(1)
Aus den Steifigkeitsmatrizen der einzelnen Stäbe, dem Lastvektor und dem errechneten, globalen Verschiebungsvektor können über eine Rückrechnung die Schnittgrößen der einzelnen
Stäbe bestimmt werden. Zur Erstellung der Gesamtsteifigkeitsmatrix kann das statische System
beliebig fein diskretisiert werden; jedoch erhöht sich dadurch auch die Anzahl der Freiheitsgrade.
Für die Diskretisierung der Bogenbrücke musste bedacht werden, dass die Berechnung auch
auf älteren Rechnern in vertretbarer Zeit durchführbar sein musste. Da die Prozessorleistung
5
Bild 2: Klassendiagramm zur Berechnung der Tragstruktur
des neuesten Rechners (smarsly, 2.53 GHz) ca. um den Faktor 100 größer ist als bei dem ältesten (turbo386, 25 MHz), war zu erwarten, dass der älteste Rechner eine mindestens um den
Faktor 100 längere Berechnungszeit benötigen würde. Daher konnte bei der Diskretisierung der
Tragstruktur keine allzu große Steifigkeitsmatrix aufgestellt werden. Als praktikabel hat sich
eine Gesamtsteifigkeitsmatrix mit insgesamt 69 Freiheitsgraden erwiesen.
Zur Lösung des linearen Gleichungssystems wurde das Gauss-Eliminations-Verfahren mit Pivotisierung gewählt. Der Gauss-Algorithmus ist zwar nicht der effizienteste GleichungslösungsAlgorithmus, jedoch relativ schnell zu programmieren. Für den Vergleich der Rechenzeit auf
den einzelnen Rechnern ist die Wahl des Lösungsalgorithmus ohnehin nicht relevant. Vergleichsbasis der Untersuchung ist die Rechenzeit, die der implementierte Gauss-Algorithmus
für die Lösung des Gleichungssystems auf den einzelnen Rechnern benötigt.
Die Implementierung des Gleichungssystems sowie des Gauss-Gleichungslösers wurde mit vier
Java-Klassen umgesetzt (Bild 2). Benötigt wurden zunächst eine Klasse Matrix für die Steifigkeitsmatrix und hiervon abgeleitet eine Klasse Vector für den Verschiebungs- und Lastvektor.
Ein Vector stellt eine Spezialisierung einer n × m−Matrix dar (Vector = n × 1−Matrix). Die
Werte einer Matrix werden innerhalb der Klassen Matrix bzw. Vector in einem 2-dimensionalen
Double-Array vorgehalten. Weiterhin wurde eine abstrakte Oberklasse EquationSolver eingeführt, die je eine Referenz auf eine Steifigkeitsmatrix, einen Lastvektor und einen Verschiebungsvektor besitzt. Für die Untersuchung wurde nun die Klasse GaussEquationSolver implementiert. Prinzipiell können auch andere Gleichungslöser implementiert werden (z.B. CholewskiEquationSolver).
Es wurde bewusst darauf verzichtet, bereits vorhandene, in Java implementierte MathematikPakete zu verwenden, um die Berechnung leicht nachvollziehen und evtl. an die Untersuchung
anpassen zu können und das Programm nicht unnötig aufzublähen.
2.4
Automatisierung der Durchführung
Aus Tabelle 1 ergibt sich, dass insgesamt 13 Rechner mit 15 installierten Betriebssystemen an
der Untersuchung beteiligt waren. Die einzelnen Java Virtual Machines können mit verschiedenen Optionen gestartet werden:
• die JVM 1.1 und 1.2 können im Interpreter-Modus und im JIT-Compiler Modus betrieben
werden,
6
• die JVM 1.3 und 1.4 unterscheiden beim Einsatz des JIT-Compilers noch zwischen Clientund Server-Modus.
Installiert man alle vier Java-Versionen (1.1.8, 1.2.2, 1.3.1, 1.4.2) auf einem Rechner, so ergeben sich insgesamt 10 Möglichkeiten, Java zu starten. Rechnet man nun sämtliche Kombinationen aus JVM, Rechner und Betriebssystem (s. Tabelle 1) zusammen, so müssen im Laufe der
Untersuchung 130 verschiedenen Java Virtual Machines gestartet werden. Demzufolge wird
die Tragwerksberechnung bei fünf geplanten Durchläufen insgesamt 650 (130x5) mal durchgeführt. Der Aufwand zur manuellen Durchführung der Untersuchung wäre also beträchtlich
gewesen. Hinzu kommt, dass die einzelnen Rechner sich in verschiedenen Räumen innerhalb
des Lehrstuhls befinden.
3 Automatisierung mit Hilfe des mobilen Benchmark-Agenten
Um den zuvor geschilderten Aufwand zu verringern, wurde die Agententechnologie eingesetzt. Ein Software-Agent ist eine gekapselte Software-Einheit, die im Auftrag eines Auftraggebers proaktiv die ihm mitgegebenen Aufgaben selbständig erfüllt. Ein mobiler Software-Agent
kann dabei auf andere Rechner migrieren, um seine Aufgaben zu erledigen. Software-Agenten
benötigen eine spezielle Ausführungsumgebung (Agentenlaufzeitumgebung), auf der sie existieren können. Mehrere, miteinander verbundene Agentenlaufzeitumgebungen mit den darauf
existierenden Agenten werden als Multiagentensystem bezeichnet.
Zur Unterstützung der Tragwerksberechnungen auf den einzelnen Rechnern wurde ein mobiler Software-Agent („Benchmark-Agent“) konzipiert, der folgende Funktionalitäten besitzen
musste:
• Fähigkeit, mitsamt der Berechnungsdaten und des Berechnungs-Algorithmus (s. Kapitel 2.3) auf andere Agentenlaufzeitumgebungen zu migrieren, dort die Berechnung durchzuführen und die Berechnungszeit sowie weitere wichtige Angaben wie Java-Version,
Rechnername, usw. zu protokollieren,
• Verwaltung und Abarbeitung einer Liste von Agentenlaufzeitumgebungen („Rechnerliste“), auf denen die Berechnungen durchgeführt werden sollten,
• Bereitstellung eines graphischen Frontends zur Eingabe der Berechnungsdaten, der Rechnerliste und zur Darstellung der Ergebnisse auf dem Leitrechner,
• Optionale Bereitstellung eines Info-Dialogfensters mit Angaben zum Berechnungsstatus,
zur Berechnungsdauer sowie weiterer Informationen (Java-Version, Betriebssystem, etc.)
bei Ankunft des Benchmark-Agenten auf einer neuen Agentenlaufzeitumgebung, um die
Funktionsweise des Agenten überprüfen und kontrollieren zu können.
Die Implementierung des Benchmark-Agenten musste mit dem JDK1.1.8 erfolgen, um der Abwärtskompatibilität von Java gerecht zu werden. Hieraus ergaben sich zunächst zwei Konsequenzen: 1) es musste eine auf Java 1.1.x basierende Agentenlaufzeitumgebung mit Unterstützung von Migration und mobilen Endgeräten eingesetzt werden und 2) das graphische Frontend
musste mit dem Abstract Windowing Toolkit (AWT) von Java, welches auf Java 1.1.x basiert,
implementiert werden (Bild 3).
7
Bild 3: Graphisches Frontend des Benchmark-Agenten (ResultPanel), links; Info-Dialog (InfoFrame)
des Benchmark-Agenten auf dem PDA, rechts
Bild 4: Vereinfachte Architektur des Benchmark-Agenten
Zur Implementierung des Benchmark-Agenten wurde das Java-basierte Agentensystem JADE
(Java Agent Development Environment [?]) mit einem speziellen Aufsatz für mobile Endgeräte (LEAP = Lightweight Extensible Agent Platform) eingesetzt. JADE-LEAP basiert auf Java
1.1.x, unterstützt Migration und erfüllt somit alle zuvor gestellten Forderungen.
Die Implementierung des Benchmark-Agenten erfolgte mit 13 Klassen. Die eigentliche Agentenklasse BenchmarkAgent erbt direkt von jade.core.Agent, der Superklasse aller Agenten,
die mit dem Agentensystem JADE-LEAP realisiert werden. Die Klasse BenchmarkAgent besitzt eine Referenz auf die eigentliche Agenten-Oberfläche (eine Instanz der Klasse BenchmarkUI). Die Oberfläche stellt entsprechend den Funktionalitäten des Benchmark-Agenten drei
unterschiedliche Eingabemasken zur Verfügung: 1) eine Instanz der Klasse ResultPanel zur
Darstellung der Ergebnisse, 2) eine Instanz der Klasse InputPanel zur Eingabe des Gleichungssystems und 3) eine Instanz der Klasse LocationPanel zur Verwaltung der Rechnerliste. Die
Speicherung der Daten aus den einzelnen Eingabemasken erfolgt in der Agentenklasse BenchmarkAgent. Dies sind im wesentlichen die Rechnerliste, die Eingabematrix, der Lastvektor,
das Berechnungsverfahren sowie einer Liste von Computation-Objekten. Ein Objekt der Klasse Computation enthält sämtliche Informationen über eine Berechnung auf einer bestimmten
Agentenlaufzeitumgebung. Die zuvor erwähnte Klasse ResultPanel stellt die Daten aller Computation-Objekte nach der Ankunft des Benchmark-Agenten auf dem Leitrechner (vgl. Kap. 4)
graphisch dar. Weiterhin kann der BenchmarkAgent auf jeder besuchten Agentenlaufzeitum8
Bild 5: Automatisierte Tragwerksberechnung mit Hilfe des mobilen Benchmark-Agenten
gebung eine Instanz der Klasse InfoFrame hinterlassen, die dem letzten Punkt der geforderten Funktionalitäten (Optionale Bereitstellung eines Info-Dialogfensters) Rechnung trägt und
Informationen über den aktuellen Stand der Berechnung auf einer Agentenlaufzeitumgebung
anzeigt. Die wichtigsten Klassen sind in Bild 4 dargestellt.
4 Durchführung und Ergebnisse der PerformanceUntersuchung
Zunächst mussten alle Rechner für die automatisierte Untersuchung vorbereitet werden; insbesondere mussten die verschiedenen Java-Versionen installiert werden. Stellte dies unter den
Windows-Betriebssystemen kein Problem dar (lediglich auf dem 386er und 486er konnten nicht
mehr alle Java-Versionen installiert werden), war dies auf den Linux-Rechnern schon aufwendiger. Leider funktionierte auf den Linux-Rechnern der von Sun mitgelieferte JIT-Compiler unter
Java 1.1.8 und 1.2.2 nicht: daher wurde ersatzweise der ShuJIT-Compiler verwendet [[?]].
Der Ablauf der Untersuchung sah nun folgendermaßen aus: zunächst wurde auf einem Leitrechner eine Agentenlaufzeitumgebung mit dem Benchmark-Agenten gestartet. Danach wurden auf
den Test-Rechnern jeweils bis zu 10 Agentenlaufzeitumgebungen (mit jeweils einer bestimmten JVM) mit Hilfe eines Startskripts automatisch gestartet und mit dem Leitrechner verbunden.
Das Multiagentensystem war nun einsatzbereit. Als nächstes wurden dem Benchmark-Agenten
über das graphische Frontend die Berechnungsdaten und die anzusteuernden Agentenlaufzeitumgebungen mitgegeben. Nach Betätigen eines Startschalters beendete der Benchmark-Agent
seine Oberfläche, migrierte dann nacheinander auf die einzelnen Agentenlaufzeitumgebungen
und führte dort die Berechnungen durch. Nachdem die Rechnerliste abgearbeitet war, kehrte er
zur Ursprungsumgebung auf dem Leitrechner zurück und reinitialisierte sein graphisches Frontend, auf dem nun die Rechenzeiten abgelesen werden konnten. Dieser Ablauf ist in Bild 5
dargestellt.
Der Benchmark-Agent migrierte ingesamt 5 mal auf jede Agentenlaufzeitumgebung, um dort
das Tragsystem je 5 mal unabhängig voneinander berechnen zu lassen. Zur Zeit der Untersuchung waren alle beteiligten Rechner im Ruhezustand, d.h. der Benchmark-Agenten konnte
die jeweiligen Prozessoren der verschiedenen Rechner voll ausnutzen. Aus den 5 gesammelten
Werten je Agentenlaufzeitumgebung wurde jeweils der Mittelwert gebildet.
Eine Aufstellung der Ergebnisse ist im Anhang in Tabelle 2 gegeben. Jede Zelle der Tabelle
9
Bild 6: Abhängigkeit der Rechenzeit von der Prozessorleistung
entspricht einer Agentenlaufzeitumgebung, die auf dem in der Zeile angegebenen Rechner mit
der aus der zugehörigen Spalte ablesbaren JVM gestartet worden ist. Offensichtliche Ausreißer
wurden bei der Bildung der Mittelwerte nicht berücksichtigt.
Die Gesamtzeit aller Berechnungen betrug mehrere Stunden. Allein der älteste Rechner benötigte für nur einen Berechnungslauf ohne JIT-Compiler mit Migration ca. 35 Minuten und mit
JIT-Compiler ca. 25 Minuten je Lauf (für 5 Durchläufe also ca. 5 Stunden).
5 Auswertung der Ergebnisse
Die Untersuchung hatte nicht das Ziel, einen allgemeinen Benchmark-Test für Java zu ersetzen.
Bei der Bewertung der Ergebnisse ging es vorwiegend darum, qualitative Aussagen zum einen
über die Performance von Java im Allgemeinen und zum anderen über den sinnvollen Einsatz
von Java im Bauwesen zu treffen.
Die Unterschiede in den Ergebnissen der Tragwerksberechnung sind gravierend. Die schnellste
Berechnung (130 ms) und die langsamste (ca. 32 Min.) unterscheiden sich ca. um den Faktor
15000. Der Vergleich absoluter Zahlen ist jedoch wenig aussagekräftig: es war zu erwarten,
dass sich der rasante Anstieg der Rechenleistung der letzten Jahre auch in dieser Untersuchung
widerspiegeln würde. Besonders deutlich wird dies in Bild 6: trägt man Rechenzeit und Prozessorleistung gegeneinander auf, so ergibt sich eine stark monoton fallende Kurve. Die Leistungssteigerung ist so enorm, dass der Wert des langsamsten Rechners im Diagramm nicht
mehr sinnvoll dargestellt werden kann.
Will man dagegen Erkenntnisse über die Performance der verschiedenen Java-Versionen erhalten, die nicht ursächlich auf eine Hardwaresteigerung zurückzuführen sind, muss man die
absoluten Berechnungszeiten relativieren. Es ergeben sich dann folgende Ergebnisse aus der
Untersuchung:
• Der JIT-Compiler des JDK 1.1.8 in der Windows-Version von Symantec ist sehr schnell.
Ab dem J2SDK 1.2.2 stellt Sun einen eigenen JIT-Compiler zur Verfügung. Dieser ist aber
erst unter dem J2SDK 1.4.2 mit Server-Option so schnell wie der JIT-Compiler des JDK
1.1.8. Es gilt bei dieser Aussage allerdings zu bedenken, dass dieser Sachverhalt bei der
intensiven Nutzung anderer Java-Klassen anders aussehen kann. Zudem gibt es im JDK
10
1.1.8 deutlich weniger Klassen als bei der Java2 Platform (z.B. keine resourcenhungrigen
Swing-Klassen).
• In allen Java Virtual Machines ist der Einsatz des Interpreter-Modus nicht sinnvoll. Die
Ausführungszeiten sind mit dem Interpreter deutlich langsamer als mit einem JIT-Compiler
(bis zu Faktor 15).
• Bei der Berechnung der Tragstruktur ist der Server-Modus mit Java 1.3 und 1.4 in der
Regel schneller als der Client-JIT-Modus (Ausnahme: ältere Rechner und Rechner Stan
unter Linux). Dies entspricht den Angaben von Sun, wonach der JIT-Compiler den Bytecode besser optimiert als der Client-JIT-Compiler. Dies kann jedoch bei Anwendungen
mit graphischer Oberfläche, die nicht so sehr auf rechenintensive Algorithmen aufsetzen,
anders aussehen. Auffällig ist zudem, dass beim erstmaligen Durchlauf der Berechnung
der Server-Modus deutlich langsamer war als bspw. der Client-Modus. Erst ab dem zweiten Durchlauf erreichte der Server-Modus dann eine deutlich höhere Rechengeschwindigkeit. Offensichtlich wird beim ersten Durchlauf im JIT-Compiler die Optimierung
durchgeführt und steht dann ab dem zweiten Durchlauf zur Verfügung. Die gemittelten
Werte im Server-Modus enthalten daher nicht den langsamen Wert des ersten Durchlaufs.
Für rechenintensive Berechnungen im Bauwesen ist offensichtlich der Server-Modus dem
Client-Modus vorzuziehen. Dies sollte jedoch jeweils im Einzelfall überprüft werden, da
Ausnahmen möglich sind. Diese Aussage ist insofern wichtig, da die JVM 1.3 und 1.4
standardmäßig im Client-Modus gestartet wird und der Anwender sich hierüber i.d.R.
keine Gedanken macht.
• Beim mobilen Intel Pentium 4 Prozessor (Rechner Smarsly und Dihart) scheint die JVM
mit Client-JIT-Compiler in den Java-Versionen 1.3.1 und 1.4.2 noch nicht optimal zu
funktionieren: die Ausführungszeiten sind hier überdurchschnittlich langsam. Der erste
der 5 Rechenläufe war bei den P4-Rechnern fast doppelt so schnell wie alle nachfolgenden; offensichtlich trat hier ein umgekehrter Effekt ein wie beim Server-Modus: die
Optimierung, die der JIT-Compiler beim ersten Durchlauf durchführt, ist sehr schlecht
und wird trotzdem in den folgenden Durchläufen verwendet.
• Zwischen den einzelnen Betriebssystemen sind keine gravierenden Geschwindigkeitsunterschiede feststellbar. Lediglich im JDK 1.1 und 1.2 unter Linux macht sich der ersatzweise eingesetzte JIT-Compiler von Shu bemerkbar: er ist deutlich langsamer als der
unter Windows mitgelieferte JIT-Compiler. Dies lässt den Schluss zu, dass der Wahl des
JIT-Compilers bei Java zentrale Bedeutung zukommt: die Geschwindigkeitsunterschiede
verschiedener JIT-Compiler können sehr hoch sein.
• Die Rechenzeit auf dem PDA lag im Bereich vergleichbarer Rechner: intern lief der PDA
im Test mit 200 MHz und liegt mit 5005 Millisekunden genau zwischen den vergleichbaren Werten der Rechner Tau (350MHz, 4064 ms) und Racer586 (166MHz, 5338 ms).
Einfache Berechnungen können also problemlos auch auf mobilen Endgeräten durchgeführt werden.
• Der Benchmark-Agent konnte mit allen Java-Versionen problemlos gestartet bzw. ohne
Fehler auf sämtliche Agentenlaufzeitumgebungen migrieren. Die Abwärtskompatibilität
und Plattformunabhängigkeit von Java waren also zu 100% gewährleistet.
• Die Abweichungen der Rechenzeiten auf den einzelnen Rechnern betrugen mit den verschiedenen JIT-Compilern (Java 1.1-1.4, Linux und Windows) bis zu 150%. Bei rechen11
intensiven oder zeitkritischen Anwendungen ist daher die Wahl der JVM bzw. des JITCompilers von großer Bedeutung.
Abschließend lässt sich festhalten, dass die Rechenzeit stark von der Wahl der Java-Version
und des JIT-Compilers abhängen kann. Im Einzelfall hilft hier oft nur das Prinzip „Trial and
error“. Der Performancegewinn, der sich jedoch möglicherweise erzielen lässt, kann beträchtlich sein und rechtfertigt den zusätzlichen Aufwand in jedem Fall. Gerade bei rechenintensiven
Anwendungen in der Tragwerksplanung kann so wertvolle Zeit gespart werden.
6 Fazit
Aus der Untersuchung können mehrere, allgemeine Schlussfolgerungen für den Einsatz von
Java im Bauwesen gezogen werden.
Die Untersuchung hat zunächst einmal gezeigt, dass Java universell einsetzbar ist. Bei der
Planung von Bauwerken sind in der Regel viele Fachplaner und Fachplanungsbüros beteiligt,
die im Normalfall sehr heterogene Ingenieursoftware verwenden. Häufig ist es nicht oder nur
schwer möglich, Ingenieursoftware, die für ein spezielles Betriebssystem entwickelt wurde, auf
ein anderes Betriebssystem zu portieren. Die Untersuchung hat gezeigt, dass in Java implementierter Code tatsächlich problemlos auf verschiedene Rechner und Betriebssysteme portiert und
dort ausgeführt werden kann.
Die Ausführungsgeschwindigkeit von Java hat sich im Lauf der Jahre insbesondere durch verbesserte Just-in-Time-Compiler so stark verbessert, dass ein durchgängiger Einsatz von Java
auch im Bauwesen nicht mehr von vornherein ausgeschlossen werden sollte. Mittlerweile können selbst rechenintensive numerische Berechnungen mit Java in vertretbarer Zeit durchgeführt
werden.
Bei der Planung von Bauwerken schließen sich mehrerer Planungsbüros für einen begrenzten
Zeitraum zu einer Projektgemeinschaft zusammen. Für eine relativ kurze Zeit wird dann eine
häufig sehr heterogene und dynamische Netzwerkumgebung geschaffen, in der die einzelnen
beteiligten Fachplaner zusammenarbeiten. Java hier bietet ein Vielzahl an Technologien und
Mechanismen an, mit der die Koordination, Kommunikation und Kooperation der Fachplaner
untereinander spürbar verbessert werden kann. Als Beispiel sei hier die in der Untersuchung
eingesetzte Agententechnologie genannt. Der in Java implementierte Benchmark-Agent hat gezeigt, dass Verarbeitungsmethoden und Daten mobil gemacht werden können: der BenchmarkAgent kann zu Rechnern im einem dynamischen Netzwerk migrieren und dort seine Daten verarbeiten. Das Netzwerk ist dabei nicht nur auf Arbeitsplatzrechner und Server beschränkt: es ist
möglich, javafähige mobile Endgeräte (PDA’s oder Mobilfunkgeräte) in das Planungsnetzwerk
zu integrieren.
Beispielsweise könnte ein Ingenieur auf der Baustelle über sein PDA einen Agenten beauftragen, auf einen FE-Server zu migrieren, dort eine Aufgabe (z.B. eine schwierige, offensichtlich
fehlerhafte FE-Berechnung) nochmals durchzuführen und dann zurückzukehren. In einem weiteren Szenario kann man sich vorstellen, für aufwendige FE-Berechnungen nicht unbedingt
die neueste und beste Rechenmaschine anzuschaffen, sondern stattdessen eine Berechnung auf
bereits vorhandene Rechner mit Hilfe mobiler Software-Agenten dynamisch zu verteilen und
somit insgesamt kostengünstiger zu fahren.
Die Untersuchung hat weiterhin gezeigt, dass sich Java in relativ kurzer Zeit stark weiterentwickelt hat. Jedes neue Release bringt Verbesserungen in der Performance und neue, anwendungsfreundliche Klassenbibliotheken. Für Ende 2003 ist bereits das nächste Release von Java
(J2SDK 1.5, Codename Tiger) mit zahlreichen Neuerungen geplant [?].
12
13
dihart
biber
smarsly
Tabelle 2: Mittelwerte der Tragstrukturberechnungen (in Millisekunden)
JDK 1.1.8
J2SDK 1.2.2
J2SDK 1.3.1
ohne
mit
ohne
mit
ohne
JIT
JIT
JIT
JIT
JIT
JIT
JIT
Client Server
a
b
1915290
1267310
–
–
–
–
–
138130
17335
118792 24204 159844 26232 21542
43978
5338
39888
7088
48632 10294 8390
c
c
15432
4064
17339 4339
17247
2233
1815
–
5005
–
–
–
–
–
9297
859
9712
1109
8359
984
668
6632
509
6373
629
5859
645
478
5866
460
6308
638
6086
604
483
4452
1722c
4601
1544c
4393
490
729
2925
218
2976
298
2838
324
238
c
c
2838
895
3196
954
2801
368
226
2880
222
3030
304
2759
304
267
2960
200
2713
328
2137
1222
266
2526
170
2327
228
2133
248
170
1865
134
1677
214
1404
814
165
b entspricht
ca. 32 Minuten
ca. 21 Minuten
c mit JIT shuJIT 0.7.12 (http://www.shudo.net/jit/) – im JDK 1.1.8/1.2.2 für Linux war der SUN JIT nicht funktionsfähig
d lief intern mit 200 MHz
a entspricht
Intel 25
Intel 66
Cyrix 166
AMD 350
Intel 400d
Intel 2x400
AMD Win2k
800 Win98
900 AMD
AMD 1600
AMD Linux
1600 Win2K
Intel 1700
AMD 2400
Intel 2530
turbo386
speedy486
racer586
tau
dell PDA
winner
psi
stan
xp
CIP
CPU [MHz]
Rechner
Anhang
J2SDK 1.4.2
ohne
JIT
JIT
JIT
Client Server
–
–
–
–
–
–
57943 9710 11243
23942 2096
2365
–
–
–
10406
875
687
7130
493
451
6964
472
440
6096
388
633
3342
236
210
3894
231
199
3328
232
201
2615
730
221
2580
185
160
1682
481
135
Herunterladen