commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Rossi <>
Subject Re: [Math] FastMath Performance
Date Tue, 25 Jan 2011 17:53:08 GMT

On Tue, 25 Jan 2011, wrote:

> Hi Gilles,
> ----- "Gilles Sadowski" <> 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:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message