[FFmpeg-devel] [PATCH] avfilter, swresample, swscale: use fabs, fabsf instead of FFABS
gajjanag at mit.edu
Wed Oct 14 13:53:02 CEST 2015
On Wed, Oct 14, 2015 at 6:49 AM, 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).
Usually yes, but for such a small function, even the low runs should
Explain to me why I get consistently lower numbers with the new code
(on low runs) - if you are inclined to believe that they are
irrelevant, then why do I see a consistent trend there and not simply
>> 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!
I already have with my random number benchmark. The original glibc
link I posted (which you essentially dismissed as irrelevant) also
shows why they switched away from their macros to fabs, fabsf, etc.
> Carl Eugen
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel