On Tue, 25 Jan 2011, [email protected] wrote:
Hi Gilles,
----- "Gilles Sadowski" <[email protected]> a écrit :
Hello.
[...]
Note: this appears to be at least as quick as StrictMath on Sun
Java 1.6 in a crude test
The performance comparison for "FastMath" should be against
"Math", as "StrictMath
is expected to be slow(er). [That's why I've added the calls to
"Math" in the
performance unit tests.]
The Javadoc for FastMath says that it is a replacement for
StrictMath,
which is why I tested against that.
Unless I'm missing something, this is a doc mistake then.
"StrictMath"
results are portable (but possibly not accurate?) but the algorithms
are
sometimes "slow". "Math" results possibly change from machine to
machine
but the algorithms are expected to sometimes be faster (thanks to
hardware
implementations?).
I thought that "FastMath" aimed at better performance than "Math",
while
retaining the same (or better) accuracy.
Well, the net result is that FastMath is faster than both Math and StrictMath
and is as accurate
as both. So their is no real reason to argue further on this.
Its more accurate than both. Both Math and StrictMath have accuracy
guarantee, for most functions its +/- 1.0 ULP, however some functions such
as cosh() are only accurate to +/- 2.5 ULP!
FastMath gets close to 0.5 ULP on all methods, certainly under 0.51 ULP.
But it's useful to test against Math as well.
Certainly. E.g. in the code I'm writing, I'm not going to change for
"FastMath" if it is not faster than "Math"!
It is faster. The best gain is on exponential, but cos/sin are also vastly
improved.
Some other functions are simply as fast without much gain, but for consistency
I think it is better to switch for all functions.
Note that a lot of Math methods actually delegate to StrictMath
anyway.
I guess that these are the cases where they are sure that they don't
loose
efficiency at the expense of reproducibility.
The main ones that don't are toRadians/toDegrees and min/max.
Any idea why?
I guess this is because these operations are already really really fast
on all implementations and there is nothing to gain. Just as sqrt could not
be improved and we simply delegate to Math.
By the way, I got different results in Eclipse and when using Java
1.5, so any conclusions we draw from the performance tests need to
document the conditions.
I think I also noticed constrasting results when changing the number
of
runs.
With very small numbers of function calls, the JVM optimizer does not kick off,
so performances should be quite poor. This is fair as it would be pointless
to try to optimize a program that would compute less than several hundreds
of thousands of sines/cosines, i.e. a program that would run for less than one
second or so.
Luc
Best,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
