[quote]You did not give the version of the JVM though (upgrading could help improve the score).
[/quote]
Look again it says 1.4.1_01
[quote]Okay, just had to give it a try on my work machine:
P3 1Ghz
512MB mem
WinNT
java 1.4.1_01 -client
…
Looks like under WinNT the SSE instructions aren’t being used? Float math is horrible! Maybe that’s why some of the demo games run very slow and jerky on my system. Hopefully we’re upgrading to WinXP by the end of the year!
[/quote]
The use of SSE is new in 1.4.2 beta and even then only in the server version.
only in the server version
Fools. Java gaming once again takes a poke in the eye.
Cas 
One serious problem with this benchmark is that the floating point calculation overflows (and then becomes NaN). The processor timing for the subsequent operations may not be very representative of normal calculation.
I’ve now changed the constants slightly and found that on my P2/400 the floating point time changes from 155 seconds down to 13 seconds.
Curiously that 155 second time for the original benchmark is almost the same as for the 3.06GHz P4 I have at work when SSE is not used. Evidently the SSE path is much faster at hanldling NaN values than the ordinary case, but this doesn’t tell us much about real life floating point speed.
And with benchmarks, ALWAYS check the results when you compare the timing! http://developer.java.sun.com/developer/bugParade/bugs/4860749.html is my experience with JDK 1.4.2Beta… :o
Though speedy, the double calculations were sometimes wrong on the Windows platform… 
[quote]> only in the server version
Fools. Java gaming once again takes a poke in the eye.
Cas
[/quote]
The standard fp performance is reasonable provided that you avoid the NaN case. Of course the -server version is faster (wouldn’t be much point otherwise), but that is also true of the integer results.
So perhaps we should look for a benchmark which does something realistic with the values finite and preferably non zero. My slight variation in this benchmark results in the values converging to zero which isn’t ideal either (too easy). In this case on my P4 the floating point calculation is faster than the integer method.
Any suggestions for a relevant calculation which has both integer and fp forms.
Mandelbrot?
And of course, vertex transformation is where it’s at these days. And the reason why the client FP performance isn’t reasonable at all, just slow :-[
Cas 
[quote]Mandelbrot?
And of course, vertex transformation is where it’s at these days.
[/quote]
Probably a bad example as you would really like the transformations to be done by all those transform pipelines on the graphics card.
I wonder if the graphics card FP could usefully be used for general purpose fp — I seem to recall that the Sony game systems being hooked up as a ‘supercomputer’ were doing something like that.
Coincidentally, there was a thread about that a couple of days ago!
The conclusion was “technically yes, but getting the results out again is too slow”, I believe.
The problem with Microbenchmarks is that you really need to understand what it is yo uare measuring.
As someone has already pointed out, the latest Sun VM does SIMD in the compiler. So if it sees a set of bytecodes that can be folded down to SIMD the result will be much faster then if it doesnt and does them with discrete operations.
In english, this means that doing things like matrix multiplys are MUCH faster then doing the same numebr of unrelated mults.
Jeff