This is the mail archive of the mailing list for the Java project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: HPC Java

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

>>   - 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

> I implemented general arrays in Kawa:

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):

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...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]