Download JavaGrande Forum

JavaGrande Forum:
An Overview
Vladimir Getov
University of Westminster
Background Observations

Java thread model is insufficient
 Message Passing model is important to
support
 Performance is critical
– Many applications need “high” performance

Proper numerical computing
– Complex, arrays, performance, reproducibility
Background
main motivation - need to solve bigger
problems with resource requirements beyond
the current limits
 recent advances in computer communications
make it possible to couple geographically
distributed resources - Grid computing
 in contrast with low-level approaches Java can
support a single object-oriented communication
framework for Grande applications

Java Grande Forum (JGF)

Goal: make Java the best ever environment
for grande applications†

Open to all: .com, .edu, .gov

Established March 1998

Conferences, working groups

http://www.javagrande.org/
† e.g.
large-scale, large-distance, resource-”hungry”
Getting Better Performance

native methods (JNI)
stand-alone compliers (.java -> .exe)

modified JVMs

– fused mult-adds, bypass array bounds checks

aggressive bytecode optimization
– JITs, flash compilers, HotSpot

bytecode transformers

parallel Java and concurrency
SciMark Benchmark
http://math.nist.gov/scimark/
 five key numerical kernels
–
–
–
–
–
fast Fourier transform
successive over-relaxation (SOR)
Monte Carlo integration
sparse matrix multiply
dense LU factorization
 two sizes: in cache and out-of-cache

run as applet; Java, C source available

results in Mflop/s; posted on SciMark page
Mflops
SciMark 2.0 By Platform
125
Intel PIII (600 MHz), IBM
1.3, Linux
100
AMD Athlon (750 MHz),
IBM 1.1.8, OS/2
75
50
25
0
Intel Celeron (464 MHz),
MS 1.1.4, Win98
Sun UltraSparc 60, Sun
1.1.3, Sol 2.x
SGI MIPS (195 MHz) Sun
1.2, Unix
Alpha EV6 (525 MHz),
NE 1.1.5, Unix
JVMs Are Improving
SciMark : 333 MHz Sun Ultra 10
35
Mflops
30
25
20
15
10
5
0
1.1.6
1.1.8
1.2.1
JVM Version
1.3
SciMark: C Beats Java
Sun UltraSPARC 60, Sun JDK 1.3 (HotSpot) , javac -0; Sun cc -0; SunOS 5.7
90
80
70
Mflops
60
50
C
Java
40
30
20
10
0
FFT
SOR
MC
Sparse
LU
SciMark: Java Beats C
Intel PIII, 500 MHz, Win98, Sun JDK 1.2, javac -0;
Microsoft VC++ 5.0, cl -0; Win98
120
Mflops
100
80
C
Java
60
40
20
0
FFT
SOR
MC
Sparse
LU
Multidimensional arrays
In Java an “n-dimensional array” is
equivalent to a one-dimensional array of
(n - 1)-dimensional arrays.
 In the proposal, message buffers are
always one-dimensional arrays, but
element type may be an object, which may
have array type - hence multidimensional
arrays can appear as message buffers.

Java multidimensional arrays
A
[
0
]
[
0
]
A
[
0
]
[
1
]
A
[
0
]
[
2
]
A
[
0
]
[
3
]
A
[
0
]
A
[
1
]
[
0
]
A
[
1
]
[
1
]
A
[
1
]
[
2
]
A
[
1
]
[
3
]
Array
A
[
1
]
of
Arrays
A
[
2
]
[
0
]
A
[
2
]
[
1
]
A
[
2
]
[
2
]
A
[
2
]
[
3
]
A
[
2
]
A
[
3
]
[
0
]
A
[
3
]
[
1
]
A
[
3
]
[
2
]
A
[
3
]
[
3
]
A
[
3
]
Java multidimensional arrays
[
0
]
[
0
]
A
[
0
]
[
1
]
A
[
0
]
[
2
]
A
[
0
]
[
3
]
A
[
0
] A
B
[
0
]
[
1
]
[
0
]
A
[
1
]
[
1
]
A
[
1
] A
B
[
1
]
[
2
]
[
0
]
A
[
2
]
[
1
]
A
[
2
]
[
2
]
A
[
2
]
[
3
]
A
[
2
] A
B
[
2
]
[
3
]
[
0
]
B
[
3
]
[
1
]
B
[
3
]
[
2
]
A
[
3
] B
B
[
3
]
Java multidimensional arrays are not indivisible objects: could
have intra-array aliasing and "partial overlaps" with other arrays
Java in Distributed Computing
main motivation - need to solve bigger
problems with resource requirements beyond
the current limits
 recent advances in computer communications
make it possible to couple geographically
distributed resources - Grid computing
 in contrast with low-level approaches Java can
support a single object-oriented communication
framework for Grande applications

Roadmap of Communication
Frameworks
Message Passing - Motivation
The existing communication packages in Java
- RMI, API to BSD sockets - are optimized for
Client/Server programming
 The symmetric model of communication is
captured in the MPI standard - MPI-1 and
MPI-2
 An MPI-like message-passing API
specification is needed to enable the
development of portable JavaGrande
applications

Early MPI-like Efforts - 1

mpiJava -

JavaMPI -

MPIJ -
Modeled after the C++ binding for MPI.
Implementation through JNI wrappers to native MPI
software.
Automatic generation of wrappers to
legacy MPI libraries. C-like implementation based on
the JCI code generator.
Pure Java implementation of MPI closely
based on the C++ binding. A large subset of MPI is
implemented using native marshaling of primitive
Java types.
Early MPI-like Efforts - 2

JMPI -
MPI Soft Tech Inc. have announced a
commercial effort under way to develop a message
passing environment for Java.
Others
 Current ports 
Linux, Solaris (both WS clusters
and SMPs), AIX (both WS clusters and SP2),
Windows NT clusters, Origin-2000, Fujitsu AP3000,
and Hitachi SR2201.

Java + MPI codes full applications
growing variety including
MPJ API Specification





First phase in our work on Message Passing for
Java.
Builds on MPI-1 Specification and the current
Java Specification.
Immediate standardization for common message
passing programs in Java
Basis for conversion between C, C++, Fortran
and Java.
Eventually, support for aspects of MPI-2 as well
as possible improvements to the Java language.
Naming Conventions
All MPI classes belong to the
package mpi.
 Conventions for capitalization, etc, in
class and member names
generally follow the
recommendations of Sun's Java
code conventions
 consistent with the MPI C++ binding

Error codes
Unlike the C and Fortran interfaces,
the Java interfaces to MPI
calls will not return explicit error
codes.
 Instead, the Java exception
mechanism will be used to report
errors

O-O Java-Centric Message
Passing
Current task - to offer a first principles
study of MPI-like services in an upward
compatible fashion
 Goal - performance and portability
 Fundamental look at data marshaling
 Preference for Java-natural mechanisms

MPJ-Related Documents and
URLs

E-discussion - [email protected]
or
e- mail [email protected]

MPJ API Specification http://www.javagrande.org/reports

mpiJava - MPJ reference
implementation
http://mailer.csit.fsu.edu/mailman/listinfo/java-mpi/
Mixed-Language Programming
with Java
Java is a highly-portable language
Java adheres to the “Write once, run anywhere” philosophy
Java has a well-established collection of scientific library bindings
Java’s executional speed is suitable for HPC
C/Fortran are highly-portable languages
C/Fortran adhere to the “Write once, run anywhere” philosophy
C/Fortran have well-established scientific libraries
C/Fortran executional speeds are suitable for HPC
So, What Language to Use?
Java is a highly-portable language
Java adheres to the “Write once, run anywhere” philosophy
C/Fortran have well-established scientific library bindings
C/Fortran executional speeds are suitable for HPC
Utilize Java for its portability and standardization,
but focus on using Java as a wrapper for porting
of native code in the form of shared libraries. This
involves the least amount of work and guarantees
maximum performance on different platforms.
JCI Block Diagram
Legacy libraries bound to Java
so far
Library
Lang. Func.
MPI
C
128
BLACS
C
76
BLAS
F77
21
PBLAS
C
22
PB-BLAS
F77
30
LAPACK
F77
14
ScaLAPACK F77
38
C
Java
4434 439
5702 489
2095 169
2567 127
4973 241
765
65
5373 293
Mixed-language programming
based on JVM
Ping-Pong Timings
Execution time (sec)
1e-2
Java/LAM-MPI
C/LAM-MPI
C/IBM-MPI
1e-3
1e-4
1e+1
1e+2
1e+3
1e+4
Message length (bytes)
1e+5
1e+6
Stand-alone IBM compiler
W
C
o
d
e
J
a
v
a
s
o
u
r
c
e
B
y
t
e
c
o
d
e
W
C
o
d
e
j
a
v
a
c
H
P
C
J
o
t
h
e
r
W
C
o
d
e
s
o
u
r
c
e
F
o
r
t
r
a
n
/
C
f
r
o
n
t
e
n
d
P
o
w
e
r
P
C
c
o
d
e
T
O
B
E
Y
b
a
c
k
e
n
d
T
o
r
o
n
t
o
P
o
r
t
a
b
l
e
O
p
t
i
m
i
z
e
r
o
t
h
e
r
b
a
c
k
e
n
d
s
NPB IS kernel on IBM SP2
Fast RMI - Motivation

Serialization and RMI are too slow for
Grande Applications:
Improvements are needed in three areas:
– Faster serialization for Java
– Faster RMI for Java
– Use of non-TCP/IP networks with RMI
 JavaParty project works on all three areas

Faster Serialization: UKA-Serialization




Drop-in replacement (plus class file retrofitter)
Save 76%-96% of the time needed for serialization
Minor incompatibilities:
– targeted towards fast communication, not made
for persistent objects (store objects now and
reload them in x years with some future release
of Java)
– not yet: remote loading of byte code
Some impact on Sun
Faster RMI: KaRMI





Drop-in replacement with almost the same API
Can exploit non-TCP/IP networks
Saves up to 96% of the time needed for a
remote method invocation (including UKA
serialization): 80ms on Digital Alphas connected
by Myrinet
Minor incompatibilities:
– no sockets & ports at user-level
– no support of undocumented RMI classes
Some impact on Sun
Benchmark Results
Programming Models

SPMD
– mutithreading on SMPs or clusters (fat JVMs)
– symmetric message passing on clusters

Client-Server
– RMI
– JINI

Peer-to-Peer
– JXTA and others
Mobile agents
 Components
