HPC Java

Wed Feb 9 07:45:00 GMT 2005

Hi Terry,
> >>Why is Java desirable as a HPC language?
> >
> >> - Stricter semantics should offer higher performance than C++.
> >
> > Stricter semantics generally restrict opportunities for compiler
> > optimizations. For example, Java's exception semantics need a runtime
> > to throw a (sycnhronous) exception just in the timing and this
> > semantics obstruct code motion for optimizations.
> >
> > On the other hand stricter semantics support reproducibility of
> > calculation and program execution. It is true even for distributed
> > computation heterogeneous computers if the program does not involve
> > non-deterministic properties.
>> It can work either way. Fortran's stricter semantics (regarding lack of
> pointer aliasing) have often been cited as a reason that Fortran is
> inherently more optimizable than C(++). If you look at IBM's work on
> high-performance Java matrix libraries
> (http://www.research.ibm.com/ninja/) they cite similar issues.

I understood and second it (working either way).
Several years ago, I've read a Jose Moreira's paper about
the multidimentional array library.
> >>What keeps Java (SE) from being a world-class HPC language?
> >
> > It is very interesting that C# language/runtime has solutions for the
> > following Java's properties:
> >
> >> - No support for immortal (truly static) allocation. GC overhead
> >> considered excessive. Desirable if GC subsystem not present if all
> >> allocation is immortal.
>> C# has a mode that completely eliminates the GC from the runtime? I 
> wasn't aware of that...please provide a reference.

I meant that C# has value types (e.g. struct) and the feature can
reduce memory management overhead.
I am not sure MS .NET Framework provides such a function.
I found a method named System.GC.KeepAlive(object obj) which prevents
GC from collecting the specified object in a code region. It can be
used to prohibit GC from investigating a complicated graph of objects.
> >> - Lack of flat multidimensional arrays (Fortran style).
>> As was pointed out by Per Bothner, this is not too hard to overcome. 
> Combined with operator overloading and generics, it could be made 
> convenient.
>> DoubleMatrix dm = DoubleMatrixFactory(1000, 1000, 1000);
> double d = dm[0, 100, 500];

Once, such a library has been proposed as a JSR:
 JSR 83: Multiarray package
 http://jcp.org/en/jsr/detail?id=83
But, it looks suspended and does not include the syntax sugar (a[x,y]).
 Kazuyuki Shudo	shudo@computer.org	http://www.shudo.net/