commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject [Math] FastMath preset tables (Was: Re: svn commit: r1169437 - [...])
Date Wed, 14 Sep 2011 15:31:05 GMT

People taking part to this discussion[1] seem to have a hard time being
explicit about what they are trying to achieve.

>From information gathered so far, the issue raised seems to have been solved
by taking advantage of the fact that the JVM loads classes at first use (i.e
methods will not be delayed by the loading of tables that they don't use).

At least, this is what I conclude from my tests that compare code with and 
without preset tables (which differ by less than 50 ms). [This has yet to be
confirmed by the initial poster who reported a unexpected difference of 30

A _second_ issue has been bundled in the commits related to the initial
problem described above: Instead of computing the tables contents at
runtime, they are now set from litteral arrays.

In addition to being non-consensual, it is still not clear that this change
is a necessary step to fix the reported problem.

On a PC, comparing the old "FastMath" code (no IOD, no preset) with the
latest version, I get the following timing gain for a single call to
"pow" (i.e. a function that _uses_ the tables):
  130 ms (preset)
   80 ms (no preset)
So, indeed, using preset tables does make the first call run faster.
[On subsequent calls, the difference is less than 1 microseconds (cf.

The issue is: When do we say that initialization time is too long?

On this machine:
  Intel(R) Core(TM)2 Quad CPU @ 2.40GHz
the difference is around 50 ms. Is that too long?
This will most probably be swamped in the execution time of any useful
application and in my opinion does not justify the workaround currently in

The slowliness reported initially (9 seconds to ~1 minute on a "low-end"
device) is indeed excessive.
But can we please draw the line at some meaningful value instead of
prematurely over-optimizing for a one-shot gain?

Can we also lay out rules about what consitutes an acceptable request for a

I don't think that is OK to just say that "FastMath" is too slow. The master
argument here was often that one should provide a (realistic) use case.

I see that a faster startup time would benefit an application required to
be restarted several times per second. But how realistic would that be?
And would "FastMath" be the single bottleneck in such a case?
Moreover, if there was such need to be able to restart the JVM several times
per second, then I'd draw the attention to the fact that "FastMath" is not
the right tool: Indeed, for the first call to "pow", it is still about 150
slower than "Math" or "StrictMath". Does that suggest that we must implement
some way so that users are able to select whether CM will use "Math" or

On Sun, Sep 11, 2011 at 02:51:31PM +0100, sebb wrote:
> [...]
> I don't think minimising the class source file size is nearly as
> important as the startup time.

First, it's not only about source size, but also code versus tables.
The former is self-descriptive.

Second, not only source file is larger, but so is bytecode size.
Without the preset tables, the ".class" file for was 38229 bytes long.
With all the changes to accomodate preset tables, there are now 5 ".class"
files with the following sizes:
  8172  FastMathCalc.class
 34671  FastMath.class
 35252  FastMath$ExpFracTable.class
 49944  FastMath$ExpIntTable.class
 39328  FastMath$lnMant.class

For the same functionality, this results in more than a four-fold increase
in bytecode size.[2]

> [...]


[2] In CM, the average size of a ".class" file is about 5885 bytes.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message