HPC Java

Mon Feb 7 13:48:00 GMT 2005

Per Bothner wrote:
 > Terry Sikes wrote:
 >
 >> - No support for lightweight types (Fortran style complex for
 >> example). Compiler should allow definition of new lightweight
 >> types, even if arduous.
 >
 >
 > About two years ago I wrote up idea for "immediate classes".
 > These would be final classes with final fields, so they could
 > be treated as value types. A compiler could treat such a class
 > as a "struct" - i.e. stack-allocated or the fields "inlined" in
 > other classes. With appropriate conventions (perhaps implementing
 > a magic interface) an implementation would use "value semantics"
 > as part of the ABI for those classes (allowing separate compilation
 > as opposed to whole-program optimization), while code that uses these
 > classes would still be pure portable Java, which would also run (if
 > less efficiently) on other implementations.
This sounds ideal. What are the obstacles to implementing this as a gcj
extension?
 >> - Lack of flat multidimensional arrays (Fortran style).
 >
 >
 > That's primarily a syntax and data structure issue. It is
 > easy enough to define a multi-dimensional Array class that
 > is basically a linear (actually affine, I believe) mapping down
 > to a regular Java one-dimensional array. I don't know if it
 > is possible to define a *generic* class; in any case you'd
 > probably need intArray, floatArray etc classes, which is
 > annoying. Ditto if you have to have different classes for
 > different rank: intArray1, intArray2, intArray3 - at least
 > as an optimization or performance hack.
Couldn't this be solved using generics?
 > And Array operations have to be done with method call syntax, rather
 > than array operations. But I don't think that's too bad.
A good operator overloading scheme should solve this, if the user so
desires.
 > I implemented general arrays in Kawa:
 > http://www.gnu.org/software/kawa/api/gnu/lists/Array.html
 > http://www.gnu.org/software/kawa/api/gnu/lists/GeneralArray.html
I'll take a look at this.
 >> - "Everything is an object" loses efficiency of first class
 >> functions. (?)
 >
 > First class functions are also objects. I have a lot of experience
 > implementing functional languages (especially Scheme):
 > http://www.gnu.org/software/kawa/internals.html#Procedures
I was concerned with the efficiency of calling straight mathematical
functions, which looks to be a non-issue. Interesting link though!
Thanks for your feedback! It is much appreciated...
Terry