HPC Java

Terry Sikes tlsikes@yahoo.com
Mon Feb 7 12:24:00 GMT 2005


shudo@computer.org wrote:
> From: Terry Sikes <tlsikes@yahoo.com>
>>>Hi all. I've been pondering the issue below for a while, and thought
>>I'd jot down some thoughts. I'd appreciate your feedback, especially
>>if I missed anything in the Java drawbacks section.
>> Thanks for this informative list.

You're welcome, though I'm sure it's not exhaustive.
>>Thoughts on High Performance Computing (HPC), Java and gcj
>>==========================================================
>>>>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.
>>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.
>> - No support for lightweight types (Fortran style complex for
>> example). Compiler should allow definition of new lightweight
>> types, even if arduous.

Yes. This should be addressed in Java.
>> - 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];
For instance (without generics).
>> - No operator overloading. (Solvable with preprocessor - high
>> efficiency.)

This isn't adequately addressed in C#. C# uses only builtin operators, 
and suffers from same temporary variable problems as C++. Something much 
more expressive and efficient is needed, IMO.
Terry


More information about the Java mailing list

AltStyle によって変換されたページ (->オリジナル) /