[concurrency-interest] jsr166y.forkjoin API comments

jason marshall jdmarshall at gmail.com
Fri Feb 1 19:46:39 EST 2008

I thought there was a relaxation in one of the more recent JDKs that allowed
you to say, "just use the hardware FP for this operation".

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.  If you can't support hardware accelleration, then the
implementation should merely be clear and concise, because getting a 4-fold
or 10-fold improvement in throughput will mean nothing if JNI offers a
100-fold improvement.

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, and it
would generate specializations of all of the methods that are reversed from
whatever the person implemented (switch to Integer from int, or vice
versa).  The tricky bit would be that the new methods would have to be added
without colliding with the namespace that already exists.  I suspect that
could be quite a pain for debuggers, profilers, and stack traces.

Besides computational overhead, the only thing that separates Integer from
int or Float from float is:

1) Nullability (this one is tough, since Java can't easily determine that a
reference can never be null)
2) Identity
3) convenience methods

If you could tell that all 3 don't happen (and on numerical code, none of
those had better be happening), and that the computation would benefit from
being transformed into using primitives, then ParallelArray wouldn't need
specialization at the API level, because the VM could make the same


On Jan 26, 2008 2:49 AM, Mark Thornton <mthornton at optrak.co.uk> wrote:

> jason marshall wrote:
> >
> > For floats, the prevailing winds suggest you're going to use GPGPU for
> > SIMD.  IEEE incompatibilities notwithstanding.
> The IEEE incompatibilities may make that a non starter for Java.
> Currently Java can't even use instructions like the fused Multiply
> Accumulate present on some processors. JSR-84 was withdrawn.
> Mark Thornton

- Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20080201/aadd3e0d/attachment.html 

More information about the Concurrency-interest mailing list