HPC Java

Sun Feb 13 01:10:00 GMT 2005

Terry> Hi all. I've been pondering the issue below for a while, and thought
Terry> I'd jot down some thoughts. I'd appreciate your feedback, especially
Terry> if I missed anything in the Java drawbacks section.
Terry> Why is Java desirable as a HPC language?
Terry> - Extremely large standard library and available software selection.
Terry> - GUI and graphics support.
Terry> - Large developer following.
Terry> - Highly portable.
Terry> - JDK 1.5 fixed some issues (generics, static import).
Other people have covered a lot of ground here, I'll try to avoid
repeating anything.
One minor detail: 1.5-style generics won't really help the way you
might like. In java a generic type can only be parameterized with a
reference type, not a primitive type. So, you can't have
MyArray<int>, only MyArray<Integer> -- i.e., everything is boxed.
This is basically anti-HPC; the .NET folks usually hold this up as one
of the big advantages of .NET.
One nice thing about java is that there are a lot of tools out there.
But, if you change the language, then unfortunately you either have to
modify all the tools (e.g., Eclipse has a built in compiler... so you
would want to change it), or do without -- losing an important
advantage of java. So, that's one consideration.
If you're willing to lock in to gcj, then you do have a lot more
flexibility. Well, depending on the amount of work you want to do.
For instance, you could start with gcj (or gcjx :-), add whatever
language features you want, and explicitly *not* allow compiling to
bytecode. Just go fully native. One drawback here is that the bar
for getting changes like this back into the GCC tree will be quite
high. But, this approach gives a lot more latitude for implementing
things like value types, operator overloading, multi-dimensional
arrays, etc, as efficiently as possible.
Tom