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
.

Relevant Pages

  • Re: Java ready for number crunching?
    ... I don't like boxing and unboxing primitives as there is a space and speed penality (or is there? ... There is generally little to no "penalty" for boxing and unboxing. ... Please let Sun, IBM, NIST, the academy, or any authors of java numerical software know of your insight. ... 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. ...
    (comp.lang.java.programmer)
  • Re: Java ready for number crunching?
    ... I don't like boxing and unboxing primitives as there is a space and speed penality (or is there? ... There is generally little to no "penalty" for boxing and unboxing. ... Please let Sun, IBM, NIST, the academy, or any authors of java numerical software know of your insight. ... 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. ...
    (comp.lang.java.programmer)
  • Re: Extending Arrays
    ... From the JVM point of view, it does not have a field called length, there is actually a special op-code to access the array length... ... From a Java standpoint, a Java array is an instance of a class. ... and you should avoid using them in all but the lowest-level abstractions (such as Collection API implementations). ... Anything else should use abstractions in place of these primitives. ...
    (comp.lang.java.programmer)
  • Re: Removing Array Elements
    ... So yes both Array and ArrayList are data structures, ... The Java class is called ArrayList because its objects use Java Arrays ... >stores all elements as objects (no primitives) and ii) it dynamically ... John Harris ...
    (comp.lang.javascript)
  • Re: Tcl Threads
    ... The next stage is concurrency. ... but mostly to the problem with Java threads. ... The problem with Java is that the real primitives were hidden behind ... mutex/condition vars ...
    (comp.lang.tcl)