Re: Java ready for number crunching?
On Thu, 15 May 2008, Monty Hall wrote:
Tom Anderson wrote:
On Thu, 15 May 2008, Monty Hall wrote:
Lew wrote:
Monty Hall wrote:
While I can understand why Sun implemented templates as they did, to me
the problem w/ Java templates is that primitives. I don't like boxing
and unboxing primitives as there is a space and speed penality (or is
there? some optimization?)
Study the matter, then make the claim. There is generally little to no
"penalty" for boxing and unboxing.
WOW! Now that's a claim! Please let Sun, IBM, NIST, the academy, or any
authors of java numerical software know of your insight. I know a fair
number of people who would love a generic java numerics library. Little or
no penalty casting to/fro primitive numerical types? What libraries are
you using? Is it open source and where can I get it!
Just for information, looping over an array of ten million ints and adding
them up took me ~30 ms. Doing the same with an array of Integers and using
auto-unboxing took me ~55 ms. So, 25 ms to unbox ten million ints, or 2.5
ns to unbox one.
I also tried with an ArrayList of Integers, and couldn't get below 145 ms.
If we had a 'true' ArrayList<int>, i estimate that it would take 145 - 25 -
120 ms in this test.
Primitives crush Objects - especially on doubles. Floating points would have
to be used for factorizations, etc.. Server option turned on/off, &
I didn't think to try -server! The results are that are interesting: both
the array and all list versions using Integer take 50 ms, and the array
version takes 10 ms. So, the difference between lists and arrays is
eliminated, but the difference between primitives and wrappers is
enhanced. My understanding is that -server applies more compiler
optimisation upfront; that suggests that Sun have done a lot of work on
optimising the object-oriented mucking about (method calls and the like)
involved in a list, but haven't (yet) done anything about eliding boxing.
I would imagine that a year from now, the int vs Integer difference will
be a lot smaller.
I'm on 1.5.0_13, on an intel Mac running OS X 10.4.11, FWIW.
rearranging code object first primitive second and vise-versa - to warm up
the JVM made no difference.
I measured different implementations in separate runs, and just looped the
measurement to warm the JVM up. I didn't notice a significant change in
time due to warming-up, so this probably isn't necessary.
10,000,000 Integers
-------------------
Primitive Object
a[i] += a[i] 57 118
a[i] *= a[i] 67 168
That's consistent with what i measured - you spend about 60 ms on an unbox
and rebox. For some reason, a lot more when multiplying, which is odd.
10,000,000 Doubles
------------------
Primitive Object
a[i] += a[i] 115 2898
a[i] *= a[i] 111 2964
Wow.
Okay, modifying my test to look at longs and doubles, here are all my
results:
Type -server? foo[] Foo[] List<Foo> List<Foo> optimised
int n 30 55 250 145
long n 60 85 270 170
double n 45 60 270 150
int y 10 50 50 50
long y 25 60 50 50
double y 20 50 50 50
I don't see the amazing slowdown with doubles that you do. I see the same
pattern with the big types as with int - lists are much slower than
arrays, -server makes them as fast, and primitives are about twice as fast
as objects.
Hang on, i'll implement your test ...
Aha! With the same inner loop as you:
Type -server? Time
double n 55
double y 55
Double n 1261, 3659, 25530 (!), 1369, 1028
Double y 775, 1378, 1350, 612, 1069, 1071, 612, 1069, 1582
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.
tom
--
The real romance is out ahead and yet to come. The computer revolution
hasn't started yet. -- Alan Kay