[FFmpeg-devel] [PATCH] avfilter, swresample, swscale: use fabs, fabsf instead of FFABS

Ganesh Ajjanagadde gajjanag at mit.edu
Thu Oct 15 12:38:10 CEST 2015


On Wed, Oct 14, 2015 at 6:53 AM, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
> On Wed, Oct 14, 2015 at 12:49 PM, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
>> Ganesh Ajjanagadde <gajjanag <at> mit.edu> writes:
>>
>>> What? My numbers actually show that the new code may be faster -
>>
>> No, you are misunderstanding the numbers you posted.
>> (Or I misunderstand them but nobody said so yet.)
>>
>> Highest runs are most relevant, skips have to be
>> avoided (afaik).
>>
>> [...]
>>
>>> If you continue to post such stuff that has no basis, I might actually
>>> get tempted into finding out for which floating point values the new
>>> code is significantly faster, craft a relevant audio file, and post it
>>> showing a huge performance difference - my random numbers benchmark
>>> shows there must exist such values.
>>
>> Please do so!
>>
>>> > The more important question is if you can see the same
>>> > changes in the disassembly of af_astats.o as what
>>> > ubitux posted here for a short test function?
>>>
>>> I do. He uses clang/gcc, so do I.
>>
>> Sorry, my understanding fails here (I am not a native speaker):
>> You did look at the disassembly of af_astats.o and there is
>> inlined code instead of a function call?
>>
>>> The reason (irrelevant) is that both
>>> of us run Arch.
>>>
>>> What is "more relevant" is if _you_ can see the changes
>>> on some non Linux platform.
>>
>> If you could show that it is faster on any platform
>> I would already be happy!
>>
>
> A more important check would be that its not significantly slower on
> any other platform. Just because one compiler/glibc combination
> manages to produce an efficient inlined function doesn't necessarily
> mean that some other compiler or libc couldn't produce a full function
> call with all the overhead that comes with it, becoming significantly
> slower.

As I point out, all a libc implementer needs to do to be on par with
the macro is to add the inline keyword. This was added in c99. If said
libc does not, then it is fundamentally broken from a performance
perspective. A beginning programmer can do that in a couple of
minutes. Fix upstream and complain to them if it does not inline.

You seem to have an alternative platform: you (and others who have
such platforms) are welcome to try and find out, file bugs (if need
be) with Microsoft, etc.

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


More information about the ffmpeg-devel mailing list