Boxing function types

[Howard Lovatt]

Answers inline below

2009/11/23 Reinier Zwitserloot <reinier at zwitserloot.com>

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


I would prefer the functionality of arrays only, i.e. no wild-cards just
co-variant generic arguments (see
http://www.artima.com/weblogs/viewpost.jsp?thread=222021).

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

There is also a proposal to allow auto boxing as part of BGGA (suggest in
this thread first - I think).

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

I did a quick conversion and compared ParallelDoubleArray to
ParallelArray<Double> and found I lost around 40% of the speed. Brian Goetz
could be right though, despite this result, that in the future this gap will
narrow. Also the ParallelDoubleArray version is slow to begin with; much
slower, factor of 10 slower than single-threaded code on a two core machine!
It is therefore difficult to say how useful ParallelDoubleArray is compared
with ParallelArray<Double>, since I wouldn't use either!

The best solution I have found using ParallelArray is a single
ParallelArray<Rows>, where Rows is a data structure containing the rows from
all the matrices (so that a single ParallelArray contains all the matrices
in the problem). This still isn't that great though, about 5% quicker than
single-threaded code on a two core machine. So currently I have reservations
about the whole of the ParallelArray package. At the moment I am seeing if I
can hand code something using Thread directly that is quicker, if I can do
so then I can't see much point in the whole package. At the moment this is
still preliminary and I am still hopeful that I can get ParallelArray
working better, however I am currently disappointed because a parallel
Fortran compiler does a good job on the benchmark.

 -- Howard.

>
> --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.
>>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>



-- 
 -- Howard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20091123/75c49a52/attachment.html