6

I am trying to compare performance of pow(x,2.0) and pow(x,2.0000001) and I though that 2.0 would be much faster, but they are at the same speed. I even removed JIT optimizations by running jar with -Xint parameter.

Any idea why is that, please? Thanks a lot!

Vladimir Vagaytsev
  • 2,871
  • 9
  • 33
  • 36
Tomáš Mocek
  • 398
  • 3
  • 14
  • 1
    The implementation is free to spend a conditional branch to test for special case or to implement all cases with the same code. All that matters is the result. There are no guarantees on the execution time. (Not that, if you are not careful, you would see them even if they are there). – Pascal Cuoq Mar 23 '15 at 19:57
  • Why do you expect a performance boost? The type of both parameters is `double`. – Rollen Mar 23 '15 at 19:57
  • Because it's just using one magical implementation that's specialized to all doubles; it's not using any special magic for integer powers. If you just use multiplication directly (`x * x`) you'll get better results. – Louis Wasserman Mar 23 '15 at 19:57
  • 1
    I am expecting better results because source code for Math.pow(x,y) has return condition for y==2, as you can see here http://developer.classpath.org/doc/java/lang/StrictMath-source.html – Tomáš Mocek Mar 23 '15 at 20:02
  • 1
    @TomášMocek, perhaps Math.pow (as opposed to StrictMath.pow, which you reference) does not differentiate between exponents? – s.bandara Mar 23 '15 at 20:18
  • That source code is for GNU Classpath. Are you running with GNU Classpath? What does `java -version` print? – VGR Mar 23 '15 at 20:18
  • thanks for answers guys, java -version prints 1.7.0_51, Java SE Runtime Environment etc, so i guess u are right with GNU Classpath, right? also, thank you s.bandara, when i tried StrictMath.pow() instead of Math.pow(), the result was as expected – Tomáš Mocek Mar 23 '15 at 22:05
  • The optimization is again broken in JDK9: https://bugs.openjdk.java.net/browse/JDK-8190869 – ZhekaKozlov Nov 09 '17 at 04:20

1 Answers1

11

In spite of unfair downvotes, the question makes much sense, since it reveals the real JVM bug.

When you run Oracle JDK the performance of Math.pow(x, 2.0) highly varies between JVM versions.

  • Before JDK 7u40 Math.pow used software implementation, i.e. it simply called __ieee754_pow function that emulates the operation in software. It was rather slow, but it did have a special case for y == 2.
  • Since JDK 7u40 Math.pow became a JVM intrinsic that was translated into FPU instructions by the JIT. However, with this optimization the special case has been lost, resulting in a performance regression for y == 2, see bug JDK-8029302.
  • This performance regression has been fixed in JDK 8u25 and upcoming 7u80. Since JDK 8u25 Math.pow works fast enough for all values, but extremely fast for y == 2. See the related question.

P.S. The approximate times in seconds for 100M invocations of Math.pow on my machine with different versions of JDK.

             Math.pow(x, 2.0)    Math.pow(x, 2.0000001)
JDK 7u25            3.0                30.4
JDK 7u40           11.1                11.1
JDK 8u40            0.1                11.1
Community
  • 1
  • 1
apangin
  • 92,924
  • 10
  • 193
  • 247
  • 1
    When you say "Java implementation", you actually mean a native method, correct? – Marko Topolnik Aug 04 '15 at 11:35
  • 1
    Quote from the linked JDK bug: `Using "-XX:+UnlockDiagnosticVMOptions -XX:+PrintIntrinsics" shows the intrinsic implementation is used in both cases.` So the actual change was only in the intrinsic itself, not in the fact that an intrinsic was introduced. – Marko Topolnik Aug 04 '15 at 12:12
  • 2
    @MarkoTopolnik Well, it was a rather stupid intrinsic. I mean it didn't crawl through all [JNI stuff](http://stackoverflow.com/a/24747484/3448419) (in this sense it was an *"intrinsic"*), but it still had to make a native call to the emulation function. In JDK7u40 it became a *"real intrinsic"*, i.e. the implementation was written in assembly and was inlined into the caller. I've updated the answer to be more precise. Thanks for reviewing :) – apangin Aug 04 '15 at 14:06