Re: Java ready for number crunching?
On Fri, 16 May 2008, Mark Thornton wrote:
Tom Anderson wrote:
It's garbage collection, isn't it? My code was never creating new wrapper
objects, but yours does, and then puts them in an array. It creates huge
amounts of garbage. That's what slows things down. -server does seem to be
altering the way memory is managed, though, since it's not only a lot
faster than the client VM, but avoids having the occasional massive time.
I believe this is still optimisable, at least in this microbenchmark; a bit
of escape analysis would let the compiler rewrite the Double[] as a
double[]. In the more complex real-world case, though, it might not.
I suspect it will be rather hard to optimise Double[] to double[] in
useful cases. Nulls and equals versus == are a particular problem as
they allow the object behaviour of Double to be seen.
Yes, absolutely. Basically, you need to do escape analysis to find all the
places where the Doubles can be seen, so you can determine if it's safe to
do the unboxing. Escape analysis is notoriously hard in real programs.
Still, encapsulation means this might not be as bad as you might think. If
i have a private Double[] in my class, and i never pass objects from it to
methods of other classes (and possibly if the class is final), the escape
analysis is pretty trivial. It's only when i start doing things like
having globally visible arrays or passing values out to other bits of code
it goes wrong.
tom
--
I didn't think, "I'm going to change the world." No, I'm just going to
build the best machines I can build that I would want to use in my own
life. -- Woz