|
Division is expensive, so replace it with multiplication instead. But
don't multiply by 0.1 (inexact in floating point), multiply by 10 and
then do one division at the end.
Make sure the final division is at the very end, so that the result
isn't immediately used. That allow the division to overlap with the
function return overhead, hiding it further.
This is silly, but while thinking about different file formats and doing
profiling of loading big files, it turned out that "strtod_flags()"
actually showed up in profiles. Not very high, but at more than 1%.
This makes the common case (no exponent) use only addition and
multiplication until the very end, and makes the division be the very last
thing it does, which minimizes the data dependencies on the division.
For my stupid test-case, it cut the cost of strtod_flags() in half
according to the profile. The half a percent speedup on loading time isn't
really noticeable or even measurable outside of profiling startup costs,
but rather than carry this along in my tree or just throw it away, I'm
sending it out to see if anybody cares.
Note that we could avoid the final division by instead multiplying
"decimal" with 0.1 rather than multiplying by 10 (and switching the sign
test over), but that's a fundamentally inexact operation in binary floatig
point, so doing the "multiply by tens for decimals" ends up keeping
everything exact as long as possible.
For our use, we probably really don't care, but whatever. End result: this
should not only speed things up immeasurably, it *might* also make things
more precise at a level that we really don't care about :^p
I'm really selling this piece of crap, aren't I?
[Dirk Hohndel: sorry - had to pull the full email into the commit message
this is so good, you couldn't make it up]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
Dirk Hohndel
Linus Torvalds