HPC Java

[shudo@computer.org]

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/