[FFmpeg-devel] [PATCH 08/11] avfilter/avf_showvolume: use log10 instead of log()/M_LN10

[Ganesh Ajjanagadde]

On Thu, Oct 29, 2015 at 8:22 AM, Paul B Mahol <onemda at gmail.com> wrote:
> On 10/29/15, Ganesh Ajjanagadde <gajjanagadde at gmail.com> wrote:
>> This is likely more precise and conveys the intent better.
>>
>> Signed-off-by: Ganesh Ajjanagadde <gajjanagadde at gmail.com>
>> ---
>>  libavfilter/avf_showvolume.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavfilter/avf_showvolume.c b/libavfilter/avf_showvolume.c
>> index 95b5388..395375a 100644
>> --- a/libavfilter/avf_showvolume.c
>> +++ b/libavfilter/avf_showvolume.c
>> @@ -197,7 +197,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
>> *insamples)
>>              max = FFMAX(max, src[i]);
>>
>>          max = av_clipf(max, 0, 1);
>> -        values[VAR_VOLUME] = 20.0 * log(max) / M_LN10;
>> +        values[VAR_VOLUME] = 20.0 * log10(max);
>>          values[VAR_CHANNEL] = c;
>>          color = av_expr_eval(s->c_expr, values, NULL);
>>
>> --
>> 2.6.2
>
> Have you checked which one is faster?
> I really have no opinion on this but gain is neglible.

No, I have not. I suspect, but have not confirmed that log10 is
slightly slower:
https://stackoverflow.com/questions/10810105/explanation-wanted-log10-faster-than-log-and-log2-but-only-with-o2-and-greater
(janneb's comment). Keep in mind their benchmark did not include the
cost of a division.

I also suspect that this is mostly an artifact of libm, see links:
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/ieee754/dbl-64/e_log10.c;hb=HEAD
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/ieee754/dbl-64/e_log2.c;hb=HEAD
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/ieee754/dbl-64/e_log.c;hb=HEAD

Basically log10 uses _ieee754_log (essentially log) underneath. No one
has taken the trouble of creating a different polynomial, etc for
log10. I strongly suspect this is because most clients of libm anyway
use log instead of log10, which is arguably rarer. Furthermore,
improvements in _ieee754_log are the lowest hanging fruit for them,
since due to the above, any improvements there translate into
improvements in the other log functions.
Lastly, work has been done on optimizing log, and due to the above
architecture, log10 inherently relies on it:
https://developerblog.redhat.com/2015/01/02/improving-math-performance-in-glibc/
I am pretty sure that if the libm people spent the time to optimize
log10 (e.g by creating different polynomial, etc), the gap should
narrow.

> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel