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