commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles (JIRA)" <>
Subject [jira] [Commented] (MATH-579) FastMath.pow much slower than Math.pow
Date Wed, 18 May 2011 09:53:47 GMT


Gilles commented on MATH-579:

In the end, it is the _absolute_ running time that counts. If you call "pow" _once_ in an
application, why would it matter that it takes 100 ms or 1 ms?

Could it be that the "Math" class is already loaded (as part of the JVM initialization), so
that "FastMath" is at a disadvantage in your benchmark (because it still needs to be loaded
at the first call to "pow")?

I maintain that such a disclaimer ("large scale usage") provides more confusion that it clears:
What is large-scale? People who are worried will profile their (complete) application and
can decide which implementation (of any interface) to use, based on realistic timings, not
on a micro-benchmark (which can provide contradictory results).

What we could do is add a link to the performance test class.

> FastMath.pow much slower than Math.pow
> --------------------------------------
>                 Key: MATH-579
>                 URL:
>             Project: Commons Math
>          Issue Type: Bug
>    Affects Versions: 3.0
>         Environment: java version "1.6.0_22"
> OpenJDK Runtime Environment (IcedTea6 1.10.1) (6b22-1.10.1-0ubuntu1)
> OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
> java version "1.6.0_24"
> Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
> Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
>            Reporter: Arne Plöse
>             Fix For: 3.0
> calculating FastMath.pow(10, 0.1 / 20) is approximately 65 times slower as the Math.pow()
> Ether this is a bug or a javadoc comment is missing.

This message is automatically generated by JIRA.
For more information on JIRA, see:

View raw message