Boxing function types

[Reinier Zwitserloot]

co- and contravariance is an intrinsic complexity inherent in the concept of
generics. Generics without variance is not a good idea.

If my memory serves, BGGA and the new CFJ offshoot of that will actually
generate the appropriate type, including with non-boxing primitives, on the
fly, so an #(int, int)int becomes a FunctionIII, not a Function<Integer,
Integer, Integer>. PA's API will still need to deal with the explosion of
types caused by primitives, so exactly how much of a benefit this really is,
is debatable.

If you have the time, a test to compare the speed of late
unboxed->boxed->unboxed conversion (which would closely parallel what PA
would do if its closures are parameterized instead of using direct types
like FunctionIII) against straight passing with PA would be interesting.
Brian Goetz' theory on where CPUs are headed (devoxx talk) suggests that the
penalty of unboxing->boxing->unboxing is statistically insignificant, as its
entirely limited to a single core, and is unlikely to cause cache misses. It
would be nice if we had practical proof of whether it does, or doesn't,
matter. Technically, if it does, it may still be turned into a
(performance-wise) inconsequential waste of cycles with some JDK
optimizations.

--Reinier Zwitserloot



On Mon, Nov 23, 2009 at 11:16 AM, Howard Lovatt <howard.lovatt at iee.org>wrote:

> I was a little surprised to see ParallelArray used as the poster child for
> function types (structural typing). Having used the library a little I can't
> see that function types would make much of a difference (note I am not
> saying that shorter inner class/closure syntax wouldn't make a difference).
> Having the JavaDoc for the different op types is useful and it also helps
> the IDE. Also I don't think you will be able to replace the primitive
> versions with generic versions, hence the saving of interface number will
> not be that dramatic. The primitive version, ParallelDoubleArray, is
> struggling already to show speedup on the code I am trying, so I find it
> hard to imagine that the boxing version will fair well.
>
> Why not introduce something close to CISE and see if we really need all the
> extra stuff. I think the big drive is for shorter syntax for inner classes
> and for some internal iterators on lists, perhaps write access to captured
> variables. So long as we don't preclude adding the other stuff at a latter
> date; I think it is best to be cautious. Generics were basically a good idea
> that got out of hand and made too radical a change (variance) - lets not
> make the same mistake again.
>
> As an aside. The code I am porting is a reasonably standard parallel
> benchmark used in weather prediction/climate modeling circles for selecting
> parallel Fortran compilers and parallel hardware. The code is a finite
> difference calculation, a common calculation type for weather/climate. This
> benchmark, amongst others, was used by the company I work for to buy a share
> in new supercomputer recently (they chose a Sun machine -
> http://www.smh.com.au/technology/sci-tech/australias-new-supercomputer-outflops-the-lot-20091116-ihew.html).
> I was not part of the decision process, which was joint across a number of
> organizations, so I can't say how influential the benchmark was, other than
> it is one that the selection group within my company quite like.
>
>  -- Howard.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20091123/02e7d362/attachment.html