[concurrency-interest] jsr166y.forkjoin API comments

Doug Lea dl at cs.oswego.edu
Sun Feb 3 09:03:50 EST 2008

jason marshall wrote:
> Extremetech's podcast this week talks with someone from the NVidia Cuda 
> group.  I think this stuff is probably closer than I anticipated.  They 
> can do single precision now, and double precision is a priority for 
> them.  If you're going to bend the ParallelArray API enough to compete 
> with other languages on numerical processing, it has to be 'bent' far 
> enough to support this sort of hardware acceleration, otherwise JNI is 
> the correct choice, not ParallelArray. 

Consider what the API would look like for any such JNI facility.
It would almost surely provide a set of structured traversals,
but a more restricted set than Parallel*Array. This still implies
to me that it is preferable to capture this via Parallel*Array,
with the idea of internally using SIMD/GPUs as support becomes

> In an my JVM utopia, the JVM would be able to detect that far too much 
> auto-boxing or auto-unboxing is going on in a particular call graph

You only need such utopian visions to handle cases where
programmers express computations using scalar primitives,
which compilers (like javac) then translate into boxed
mechanics, and then dare the JVM to rediscover the underlying
scalar primitive computation, which even at best it cannot
always do.

Without explicit specializations (like ParallelLongArray),
the current situation in java is not quite that extreme but
can get pretty close to it. In a language with better integration
of objects and value types, you wouldn't get yourself into this
situation to begin with. It is not easy though. Very few languages
get this right. As mentioned in a previous posting, the only
reasonable way to cope is to both help instigate others to
pursue language improvements, while at the same time making
the best API you can for the language you have.

For Parallel*Array, the most important performance issues
surround arrays of boxed vs unboxed primitives, not just
single scalar variables.  Auto-morphing a Long[] to a long[]
is not something I expect to happen anytime soon. Although
I do still encourage you to try working on solutions for
this or related problems that would enable you to program
in a way you like better.


More information about the Concurrency-interest mailing list