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

Carl Eugen Hoyos cehoyos at ag.or.at
Tue Oct 13 06:44:37 CEST 2015


Ganesh Ajjanagadde <gajjanag <at> mit.edu> writes:
> On Tue, Oct 13, 2015 at 12:16 AM, Carl Eugen Hoyos wrote:
> > Ganesh Ajjanagadde <gajjanag <at> mit.edu> writes:
> >
> >> Bench from libavfilter/astats on a 15 min clip.
> >
> > I believe that your test would indicate that the
> > old variant is faster or that no result can be
> > given which is what my tests show.
> 
> Look at the bench and the numbers again, I have 
> provided it above.

Ok:
old:
    389 decicycles in abs,      64 runs,      0 skips
    350 decicycles in abs,     128 runs,      0 skips
    331 decicycles in abs,     256 runs,      0 skips
    321 decicycles in abs,     512 runs,      0 skips
    319 decicycles in abs,    1024 runs,      0 skips
    318 decicycles in abs,    2048 runs,      0 skips
    315 decicycles in abs,    4096 runs,      0 skips
    317 decicycles in abs,    8192 runs,      0 skips
    335 decicycles in abs,   16384 runs,      0 skips
    335 decicycles in abs,   32768 runs,      0 skips

mew:
    382 decicycles in abs,      64 runs,      0 skips
    361 decicycles in abs,     128 runs,      0 skips
    356 decicycles in abs,     256 runs,      0 skips
    334 decicycles in abs,     512 runs,      0 skips
    322 decicycles in abs,    1024 runs,      0 skips
    317 decicycles in abs,    2048 runs,      0 skips
    315 decicycles in abs,    4096 runs,      0 skips
    341 decicycles in abs,    8192 runs,      0 skips
    363 decicycles in abs,   16383 runs,      1 skips
    342 decicycles in abs,   32767 runs,      1 skips
Numbers with high skips or low runs are not so 
relevant afaik.

> They are essentially identical in the best case 
> (most number of runs), the new variant is faster in 
> the worst case.

I would say the opposite is true but we can certainly 
agree that there is no proof that one is faster.

> You have not provided a bench proving otherwise.

old:
user    0m20.338s
user    0m20.408s
user    0m20.287s
user    0m20.365s
user    0m20.208s
new:
user    0m20.197s
user    0m20.577s
user    0m20.434s
user    0m20.322s
user    0m20.356s

> > I am not sure if it makes sense to apply a patch
> > that is meant to improve speed if this improvement
> > can't be shown.
> 
> I believe I have shown it above clearly.

Imo, you have shown clearly that neither variant can 
be shown to be faster.

Carl Eugen



More information about the ffmpeg-devel mailing list