Are you using JRE 1.4.1 with JIT???
looks like the Math.sqrt() is being compiled to some fancy-dan hardware sqrt operation on newer processors.
It’s nice to know that the JVM does this where it can, but also a pain in the arse if you want top performance across a wide range of target hardware.
At last! My methodology of coding to the api, and avoiding nasty hacks, in the slim hope that Sun would someday optimise it for me, is vindicated:D. Sort of :-/.
Yes, I used JRE with JIT…
Actually there are lot of C++ optimization tricks, which don’t work in Java (didn’t at all or did work prior to some “point”)…
I believe that JVM has special path for some of java.lang.Math methods as well as for other java.* ones, so it effectively inlines them in the final native code. In this case making your own implementation of a standard method (sqrt(), for instance) doesn’t make sence especially in a long run. So you can think about java.* classes as they have superior performance already! ;D
So my opinion is that the only optimization at algorithm level is fully under your control and low-level tricks are… for JVM! ;D
OR
You can keep Java code at high-level (object-level) part and C++ code at low-level (polygon-level, drawing) part of your game (engine) with all of the tricks, etc. I think that this is the optimal way for “hard-core” Java gaming at the moment! 8)
The new computers (I think it was included with MMX) have pipeline slot for straight repeated arithmetic calculations(exponent, sqrt, pi, and whatnot), but it doesn’t make sense the jump is involved with 600mhz pentium to 1.4ghz, since technically they both be MMX. Does anyone know whether the new media processors have sqrt slot built into the cycle?
I have over 514% difference here in the sqrt calculations, so it must mean that the JIT really is doing its work, which is always good to know. However, the speed could be increased.
But still, integer 9^(1/2) is faster than (int)Math.sqrt(9)
Has anyone tested this with older versions of Java?
I don’t hope you litterally mean “9^(1/2)”, because ^ is xor in java, not a power function.
- elias
[quote]The new computers (I think it was included with MMX) have pipeline slot for straight repeated arithmetic calculations(exponent, sqrt, pi, and whatnot), but it doesn’t make sense the jump is involved with 600mhz pentium to 1.4ghz, since technically they both be MMX. Does anyone know whether the new media processors have sqrt slot built into the cycle?
[/quote]
Perhaps there is something in SSE2, which is included in the P4 but not the P3?
Well I do mean that, because I tested it and it was about 1000 ms faster. I bet you can test that your self easily as well. However, whatever your result might be I’m 100% sure that it is faster.
I could and would, if only ^ were the power operator, but it isn’t. ^ in java is the boolean xor operator. Take this example:
public class Test {
public static void main(String[] args) {
float wrong_sqrt = 9^(2);
float real_sqrt = 9*9;
System.out.println(wrong_sqrt + " != " + real_sqrt);
}
}
gives me:
[elias@ip172 snot]$ javac Test.java && java Test
11.0 != 81.0
see http://java.sun.com/docs/books/jls/second_edition/html/expressions.doc.html#5233 for more information
- elias
OK, thank god it came clear now, I have always been under impression that ^is truly ^
The difference between the speed of the Math.sqrt on a P4 and P3 is probably due to the difference in the way the fsqrt opcode is implemented on the processors.
On the P4, the fsqrt instruction takes 38 clock ticks to complete while on the P3, it takes 57(!!) clock ticks. That would explain why you see much better results with Math.sqrt on a P4.
My guess is that the JVM emits an fsqrt instruction for each call to Math.sqrt. More information about the performance of these floating point instructions on various processors can be found at http://www.aceshardware.com/Spades/read.php?article_id=25000194