[FFmpeg-devel] [PATCH] swresample/resample: improve bessel function accuracy

Clément Bœsch u at pkh.me
Tue Nov 3 08:17:46 CET 2015


On Mon, Nov 02, 2015 at 10:10:33PM -0500, Ganesh Ajjanagadde wrote:
> On Mon, Nov 2, 2015 at 9:32 PM, Ganesh Ajjanagadde <gajjanag at mit.edu> wrote:
> > On Mon, Nov 2, 2015 at 6:49 PM, Ganesh Ajjanagadde <gajjanag at mit.edu> wrote:
> >> On Mon, Nov 2, 2015 at 6:37 PM, wm4 <nfxjfg at googlemail.com> wrote:
> >>> On Mon,  2 Nov 2015 14:49:54 -0500
> >>> Ganesh Ajjanagadde <gajjanagadde at gmail.com> wrote:
> >>>
> >>>> This improves accuracy for the bessel function, and this in turn should
> >>>> improve the quality of the Kaiser window.
> >>>
> >>>
> >>> "Should"? Does it or does it not? If you don't know, why the patch?
> >>
> >> It improves the window in the sense of mathematically matching the
> >> Kaiser window expression due to the improved bessel function accuracy.
> >> That claim I have verified and placed in the commit message with
> >> evidence.
> >>
> >> What that translates into in terms of resampling accuracy, I don't
> >> know. Normally, such things do help reduce the noise floor, but I
> >> don't know an easy way to test via FATE or associated tools. I put
> >> that caveat in the bottom lines of the patch.
> >
> > Turns out the init speed is definitely improved as well (~20% boost
> > with default settings).
> > I did a cheap trick of calling build filter 1000 times to get a large
> > number of runs.
> > Results (x86-64, Haswell, GNU/Linux):
> >
> > test: fate-swr-resample-dblp-44100-2626
> >
> > new:
> > 995894468 decicycles in build_filter(loop 1000),     256 runs,      0 skips
> > 1029719302 decicycles in build_filter(loop 1000),     512 runs,      0 skips
> > 984101131 decicycles in build_filter(loop 1000),    1024 runs,      0 skips
> >
> > old:
> > 1250020763 decicycles in build_filter(loop 1000),     256 runs,      0 skips
> > 1246353282 decicycles in build_filter(loop 1000),     512 runs,      0 skips
> > 1220017565 decicycles in build_filter(loop 1000),    1024 runs,      0 skips
> >
> > Thus, this patch has both things going for it luckily. Will leave to
> > the maintainer (Michael I believe) to give details of accuracy
> > benefits as translated to the actual resampling if easily testable,
> > and I will add the perf numbers to the message.
> 
> One last comment on performance (this is something I have discussed
> with Timothy privately), if one removes the crippling
> -fno-tree-vectorize, FATE still passes on my GCC 5.2 setup, and one
> gets further ~5 % perf improvement here:
> 949318408 decicycles in build_filter(loop 1000),     256 runs,      0 skips
> 948795082 decicycles in build_filter(loop 1000),     512 runs,      0 skips
> 928925076 decicycles in build_filter(loop 1000),    1024 runs,      0 skips
> 
> I am sure a lot of other places may benefit.

It's been a while I want to remove -fno-tree-vectorize. We've already
observed relatively small performance improvements in various places. If
it's still buggy, compilers need to be fixed anyway.

--extra-cflags=-fno-tree-vectorize is a good enough workaround if some
people explicitly want to disable it.

About the bessel patch itself, I'm happy that you benched it, because its
performance are actually relevant: last time I tried to replace the
current unrolled loop with a real loop (trying to match libavresample
code), I observed a noticeable overall slow down while resampling (the
init is very slow). Yes, no number, sorry :)

[...]

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20151103/dd2f0873/attachment.sig>


More information about the ffmpeg-devel mailing list