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. > 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"! > 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? > > 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. Best, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
