Java für das Hochleistungsrechnen

Java für das Hochleistungsrechnen
[Special Section, Comm. of the ACM, Okt. 2001]
Entwicklung:
1998: Gründung des Java Grande Forums
Mai 2000: Spezialausgabe der Zeitschrift
Concurrency: Practice & Experience
Okt. 2001: Spezialsektion in der Zeitschrift
Communications of the ACM
Java Grande Forum: Aufgaben
Evaluierung der Sprache Java und ihres Laufzeitsystems für
Grand Challenge Anwendungen
Fokussierung der Java Grande Gemeinde (jährliche Konferenz)
Erstellung von Benchmarks, APIs, Verbesserungsempfehlungen, etc.
Warum Java für HPC?
um die Fülle der Java-Programmierer zu erreichen (Bibliotheksfundus)
um Geldgeber zu erreichen
für Dinge, die sich nicht ohne Weiteres mit Fortran und C tun lassen
.
1/14
Wie mit Java umgehen?
Kurzfristig: Kopieren gängiger HPC-Technologie nach Java
SPMD-Parallelität (PVM, MPI)
Kommunikation zwischen JVMs
“sofort” umsetzbar
im Wettbewerb mit Fortran und C
Längerfristig: Entwicklung neuer HPC-Technologie für Java
Vorteile von Java gegenüber Fortran und C:
Portierbarkeit des Bytecodes
Objektorientierung
Fadenparallelität
dynamische Parallelität (echtes MIMD)
irreguläre Parallelität
Optimierungen während der Laufzeit (JIT)
Java anpassen
Sich an Java anpassen
+ fokussierte Entwicklung
neuer Technologie
– Sprachlimitierungen bestimmen
die Entwicklung
– Akzeptanzrisiko
+ große Benutzergemeinde
.
2/14
Was spricht gegen Java für HPC?
Java ist interpretiert
+ schneller Vertrieb
+ hohe Sicherheit
+ einfacher, universaler Compiler
– langsame Ausführung (bis zu Hunderte mal langsamer als C,
aber heute im HPC-Bereich schon kompetitiv [Boisvert et al. 2001])
+ Dos&Don’ts-Liste für HPC-Programmierung in Java [Boisvert et al. 2001]
Java ist eine “große” Sprache
kleine Sprachen sind effizienter implementierbar:
statischer Speicher (klassisches Fortran)
schneller als per Hand verwalteter dynamischer Speicher (C)
schneller als automatisch verwalteter dynamischer Speicher (Java)
Fallstudie: klassisches Fortran fünfmal schneller als C,
da Compiler keinen Code für Aliastests einfügen muss
Java ist nicht auf HPC ausgerichtet
Websprache
Betonung auf Sicherheit, Portablilität, Objektorientierung, Verteiltheit
Effizienz zweit- oder drittrangig
.
3/14
Java und Numerik
Sprachänderungen: von Java Grande instigiert
strictfp:
Methodenattribut zur Einhaltung bitreproduzierbarer, standardisierter
Gleitpunktarithmetik – auf allen Zwischenresultaten
aufgenommen in Java 1.2 mittels eines Java Special Request
im vorherigen Java-Standard war Bitreproduzierbarkeit zwingend
Bitreproduzierbarkeit verbietet Optimierungen unter Ausnutzung
von Assoziativität, Kommutativität, etc.
fastfp:
Methodenattribut zur Benutzung maschinenspezifischer Hardware
Beispiel: float-multiply-add (FMA) zur Vektormultiplikation
Java Special Request versandet
Weiteres Problem: unpassende Datentypen für komplexe Zahlen und Arrays
beides sind Objekte:
umständliche Syntax von Operationen (Methodenaufrufe)
Referenz- statt Wertsemantik
Effizienzverluste (dynamische Speicherverwaltung)
Java-Arrays haben zusätzliche, schlechte Eigenschaften
sie müssen nicht rechteckig sein
es kann Aliasing zwischen Elementen bestehen
.
4/14
Modellierung komplexer Zahlen für HPC in Java
[IEEE CSE Papier von Boisvert et al. 2001]
Komplexe Zahlen sind Objekte:
Complex a = new Complex(5,2);
Complex b = a.plus(a);
Complex c = b;
Nachteile:
umständliche Syntax
unnötige Dynamik der Speicherverwaltung
Behandlung inkonsistent mit anderen Basistypen
(Referenzgleichheit, nicht Wertgleichheit)
Lösungsansatz:
zusätzlicher Basistyp complex
complex ist Wertepaar von Doubles
complex ist Obertyp von double
Präprozessor transformiert syntaktisch gezuckerte Operationen auf
complex-Werten in Operationen auf double-Paaren
.
5/14
Modellierung von Arrays für HPC in Java (1)
[Comm.ACM(CACM)- und JavaGrande(JG)-Papier von Moreira et al. 2001]
Array-Problem im Bild (CACM: Abb. 1)
Fallstudie: BLAS-Programme
dgemv (JG: Abb. 2)
dgemm (JG: Abb. 3)
Option 1: mit einem Klassenpaket
eine Klasse pro Dimensionalität und Elementtyp (CACM: Abb. 5)
Beispiel: intarray3D = new intArray3D(m,n,p)
Compiler kann wegen Rechteckigkeit traditionell optimieren
Layout nicht festgelegt
Operationen auf Elementen und Arraysektionen (à la HPF)
Vor-und Nachteile:
+ JVM kann unverändert bleiben (Portabilität)
– zur Optimierung einfache, lokale Änderungen der JVM nötig
– Dimensionalität begrenzt (im vorgestellten Paket: 7)
– bequeme Syntax für Methodenaufrufe notwendig
.
6/14
Modellierung von Arrays für HPC in Java (2)
Probleme mit der bequemen Syntax für Methodenaufrufe:
Darstellung:
Sequenz von punktweisen Operationen (JG: Abb. 4, 5(a))
· Updates und Nebenwirkungen greifen für jedes
Array-Element separat
eine aggregierte Operation, d.h. multiple Zuweisung
aller Array-Elemente (JG: Abb. 5(b), 5(c))
· Sonderfälle für das ganze Array greifen vor dem
Update des ersten Array-Elementes
· Updates aller Array-Elemente erfolgen nach der
Auswertung aller Array-Elemente
Achtung: punktweise und aggregierte Updates können zu
unterschiedlichen Resultaten und Sonderfallverhalten führen
Implementierungsoptionen:
führe Overloading arithmetischer Operatoren ein
+ Arraypackage muss nur installiert sein, wo man es braucht
– große Sprachänderung (Java hat kein Overloading)
erweitere die Syntax der Kernsprache
– Arraypackage ist Teil der allgemeinen Installation (Standard!)
+ geringere Auswirkung auf die Sprachdefinition von Java
.
7/14
Modellierung von Arrays für HPC in Java (3)
Option 2: mit einer neuen JVM
Shape-Analyse von Arrays (im Speziellen einfach, generell schwierig)
Speicheranalyse zur Zeit der Allokation und bei jedem Arrayzugriff
(Dichtheitsanalyse)
Beispiel: double[][] A = new double[m+1][n+1] (JC: Abb. 6)
anfangs: Dichtheitsmarke gesetzt
Änderung der Arraysstruktur ⇒ Löschen der Dichtheitsmarke
Beispiele: A[i] = new double[2*n]
A[i] = B[i]
Vor-und Nachteile:
+ keine Sprachänderung
– Rechteckigkeit manchmal schwer zu erkennen:
double[][] a = new [double[m][];
for (int i=0; i<m; i++)
a[i] = new double[n];
– schwerwiegende JVM-Erweiterungen
– keine arrayspezifischen neuen Operatoren (z.B. Sektionierung)
.
8/14
Modellierung von Arrays für HPC in Java (4)
Option 3: mit neuen Sprachkonstrukten
Beispiel: float [*,*] Y = new float [n,m]
Zugriff mit normaler Indizierungsnotation (JG: Abb. 7-8)
Sektionen in jeder Dimension möglich
Transformationen in eindimensionale Arrays auf Java-Ebene
(JG: Abb. 9-10)
Vor-und Nachteile:
+ Bytecode und JVM unverändert
+ unbeschränkte Dimensionalität
– starke Sprachänderungen
– einige Komplikationen
(z.B. nicht als Rückgabewert benutzbar, da Menge von Variablen;
man kann aber einen Resultparameter vorbereiten)
.
9/14
Das Java Sonderfallmodell
[Comm.ACM-Papier von Moreira et al. 2001]
Java Standard:
alle Zeiger auf Null prüfen (positiv ⇒ Sonderfall)
alle Arrayzugriffe auf Grenzverletzung prüfen (positiv ⇒ Sonderfall)
präzises Sonderfallmodell:
alle Effekte vor dem Sonderfall sichtbar
alle Effekte nach dem Sonderfall nicht sichtbar
Problem: Komplikationen entstehen durch
Umordnung von Operationen
spekulative Ausführung
Lösungsansatz:
Versionierung von Schleifensätzen (CACM: Abb. 2)
.
10/14
Verteilte Parallelität in Java (1)
Java RMI: (Remote Method Invocation)
im Paket java.rmi, über das Java Native Interface (JNI) implementiert
(C-Aufrufe aus dem Bytecode heraus)
im Gegensatz zu RPC: (Remote Procedure Call)
volle Integration in die Sprache
uneingeschränkte Argumenttypisierung
verteilte Speicherbereinigung
Polymorphie und dynamisches Klassenladen über Rechnergrenzen
Methoden können parallel sein
Remote Object: Klasseninstanz mit Interface Remote
Entfernte Objekte werden in einer zentralen Liste (Registry )
verwaltet und über diese angesteuert
Zugriff auf die Registry generiert eine lokale Notiz (Stub),
die die Verbindung zum entfernten Objekt herstellt
RMI ist nicht transparent: der Programmierer muss
Kommunikationssonderfälle abfangen
entfernte Parameterübergabe ist generell per Wert
Objektparameter müssen das Interface Serializable implementieren
Effizientere Alternativen: Manta, JavaParty, Hyperion/DSM-MP2
.
11/14
Verteilte Parallelität in Java (2)
[Comm.ACM-Papier von Kielmann et al. 2001]
Manta:
Erweiterung von Javas RMI
explizite Auszeichnung von entfernten Objekten
Verbesserung der Datenlokalität durch Angabe von Objektreplikationen
Maschinencode-Compiler für RMI (sogar schneller als JavaParty)
neues, leichtgewichtiges Protokoll in C minimiert Kosten von
· Fadenwechsel
· Pufferverwaltung
· Datenkonversionen
· Kopieraktionen
Objektserialisierung ohne Laufzeittypchecks
effiziente Kommunikationssoftware (Panda-Bibliothek)
Kompatibilität mit Standard Java:
Manta kann Bytecode kompilieren
Manta kann Bytecode generieren
Replizierte Objekte mit RepRMI: (Replicated Method Invocation)
lokale Kopie für read-only Methoden
Schreiben per Update-Protokoll (Orca-System)
.
12/14
Verteilte Parallelität in Java (3)
[Comm.ACM-Papier von Kielmann et al. 2001]
Hyperion:
Verteiltheit völlig transparent: Modell eines gemeinsamen Speichers
Basis: Distributed Shared Memory System DSM-PM2
hohe Portabilität: DSM-PM2 gibt es für
· viele Architekturen: SCI, Myrinet, Gigabit-Ethernet...
· viele Kommunikationsschnittstellen: TCP, MPI, VIA,...
hohe Effizienz: DSM-PM2 hat
· leichtgewichtige Fäden
· Hochleistungskommunikation
· page-based distributed shared memory
Zweiphasenkompilation:
1. Phase: Bytecode −→ C (plattformunabhängig)
2. Phase: C −→ optimiertes C (plattformabhängig)
Was kann Hyperion (noch) nicht?
einige standard Java-Bibliotheken unterstützen
dynamische Kompilation (d.h. auch dynamisches Klassenladen)
dynamisches Linken
JavaParty: extra Foliensatz
.
13/14
Grid Computing
[Comm.ACM-Papier von Getov et al. 2001]
Idee:
nutze die freien Reserven des Internets zur Beschleunigung
einer Berechnung:
ungenutzte CPU Zyklen
ungenutzten Speicher
ungenutzte Spezialhardware (z.B. Parallelrechner)
Seminale Literatur:
Foster: The Grid: Blueprint for a New Computing Infrastructure
es gibt zwei Ausgaben: Grid (1999) und Grid 2 (2004)
Hype:
sehr, sehr viel Geld verfügbar
viele Konferenzen und Workshops zum Thema Grid
viele der Gridarbeiten sind seichte Entwicklungen
Herausforderungen:
Heterogenität der Ressourcen im Grid
dynamische Verfügbarkeit der Ressourcen im Grid
i.d.R. zu wenig Information für eine verläßliche Vorhersagbarkeit
.
14/14