commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From luc.maison...@free.fr
Subject Re: [Math] FastMath Performance
Date Tue, 25 Jan 2011 15:46:56 GMT
Hi Gilles,

----- "Gilles Sadowski" <gilles@harfang.homelinux.org> 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.

> 
> > 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message