[FFmpeg-devel] [PATCH][RFC] lavu/libm: add exp10 support

[Ganesh Ajjanagadde]

On Tue, Dec 22, 2015 at 8:04 AM, Ganesh Ajjanagadde <gajjanag at mit.edu> wrote:
> On Tue, Dec 22, 2015 at 3:35 AM, Michael Niedermayer
> <michael at niedermayer.cc> wrote:
[...]
>>
>> IMHO a exp10 fallback should be implemented using exp2() if that is faster
>> and available.
>
> I don't know whether the fallback should use exp or exp2, need to
> check which is faster. And if we fallback to exp or exp2, it will turn
> out that the fallback is significantly faster than the actual libm
> function (as demonstrated above, like erf), nothing wrong with that,
> just is somewhat strange.
>
>>
>> Code requiring absolute accuracy must be written using integers as C
>> does not gurantee accuracy for float and double.
>> A single libc or fallback providing more accuracy does not really help
>> as our code must function correctly in the absence of such accuracy
>> also the accuracy difference between exp2() and pow() should be
>> negligible
>
> A lot of our floating point code assumes IEEE-754, which has
> reasonably well defined semantics. Anyway, as a general statement, I
> agree.
>
> For a proper libm, exp2(x) and pow(2, x) should be identical. I guess
> what you are referring to is exp2(log2(10)*x) vs pow(10, x). In this
> case, I don't know how bad the difference is; I suspect it to be more
> than 1 ulp in some cases.

Definitely way more than 1 ulp. Looks like exp2 fallback is the way to go:
1. speed: it is approximately 25% faster on GNU libm, even faster on
BSD/Mac OS X and other libm's due to a table lookup approach.
2. accuracy: it is marginally better. Measurement was via 3e8 points
spaced evenly from -310 to 310, maximum relative error is 1.7e-13 vs
1.8e-13. For values in the 64 bit range (roughly 10^0 to 10^20), error
is around 7.5e-15. Basically errors are amplified at very small and
very large values which is intuitively clear. In fact, that is exactly
what GNU libm does: splits the exponent into a main term and a
correction term, computes exp twice, and then multiplies the two
together.

Really, I guess the question is:
are people ok with this accuracy loss on non GNU/Linux? If yes, then
will post with an exp2 based fallback, if not, will post with a pow
based fallback.
Summary:
Current patch
1. Accuracy: identical to old behavior on all platforms.
2. Speed: improve slightly (~30%) on GNU/Linux, identical to before on
all other platforms.
Thus a Pareto improvement.

exp2 fallback
1. Accuracy: identical on GNU/Linux, regression on all other platforms
(assuming their pow is correct), to the tune of relative error of
1e-13.
2. Speed: improve slightly (~30%) on GNU/Linux, improve drastically on
platforms with exp2 (2-3x).
Trades off significant speed gains for slight reduction in accuracy on
most platforms.

I favor the exp2 fallback, but decision left to others here.

[...]