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

[Ganesh Ajjanagadde]

On Tue, Nov 3, 2015 at 12:45 AM, Timothy Gu <timothygu99 at gmail.com> wrote:
> On Mon, Nov 2, 2015 at 8:23 PM Rostislav Pehlivanov <atomnuker at gmail.com>
> wrote:
>
>> >if one removes the crippling
>> >-fno-tree-vectorize
>> Yes, I think a config option to turn this flag on (like the unsafe
>> bitstream reader) would be good. Defaulting to off by default if it doesn't
>> break anything for at least a few people (and compilers) who test it. It's
>> not a big performance impact but every little bit counts nowadays.
>>
>
> FWIW, I recently (i.e. 2 days ago) did some tests with auto-vectorization
> and a few compilers. Fortunately, none of the compilers I tested caused any
> miscompilation, when purely measured by FATE:
>
> compiling:
> clang3.7 4m3.034s
> gcc5vectorize 5m50.637s (1.14x gcc5)
> gcc5 5m7.262s
> gcc4.9vectorize 5m29.669s (1.11x gcc4.9)
> gcc4.9 4m54.602s
> gcc4.8vectorize 5m18.848s (1.09x gcc4.8)
> gcc4.8 4m53.940s
>
> FATE:
> clang3.7 3m13.923s
> gcc5vectorize 3m5.988s (0.980x gcc5)
> gcc5 3m9.618s
> gcc4.9vectorize 3m12.880s (0.983x gcc4.9)
> gcc4.9 3m16.563s
> gcc4.8vectorize 3m10.321s (0.993x gcc4.8)
> gcc4.8 3m11.608s
>
> Tested with:
> - Debian jessie/stable/8.2
> - Dual-core Haswell i7 ultra low voltage
> - clang-3.7 3.7.0-svn251177-1~exp1 (from the offical clang apt repo)
> - gcc-5 (Debian 5.2.1-22) 5.2.1 20151010 (Debian testing stock)
> - gcc-4.9 (Debian 4.9.2-10) 4.9.2 (Debian stable stock)
> - gcc-4.8 (Debian 4.8.4-1) 4.8.4 (Debian stable stock)
>
> Note that FATE is probably the worst benchmark one can find, but it does
> show something.
>
> Some observations:
>
> - GCC vectorization slows down compilation A LOT in all versions. The newer
> the worse.

A ~ 20% slowdown on a build for a ~ 20% improvement in an overall FATE
bench - sounds like a win to me especially with ccache. Contrast this
with LTO, which is buggier than vectorization on recent compilers, and
usually at best 5-10% better for a "kitchen sink" bench like the FATE
you described, for a usage of a ton of resources.

> - If you are developing, use clang, and DON'T use GCC 5 with vectorization.

This is an opinion, so I will state mine here: if you are developing
use ccache + GCC > ccache + clang > clang = gcc. Reason for the first
is due to the terrible interaction ccache has with clang. I still will
use GCC 5.2 + ccache (with vectorization) for my builds, and will
inform Arch packagers once we have finalized configure in this respect
:).

> - For release builds, an option to turn it on (or rather to not turn it
> off) would be helpful; but if you really care about performance _that_ much
> then you should probably use some other compilers instead.

No, not true at all. Why do we bother with asm? Many times for such
"last mile" optimizations. A 20% improvement in FATE across board is
nothing to sneeze at given what I have seen in FFmpeg. This one is
virtually free.

Furthermore, barring ICC (for Intel), Clang and GCC are among the best
quality compilers today. I don't know about what "other compilers" you
are referring to.

>
> FYI, as I have told Ganesh so in our private exchanges, I did also test
> vectorization on GCC 4.6 on a Ubuntu 12.04/Precise box, which miscompiled
> the code hilariously, _and_ made the code slower, just as illustrated in
> Mans's commit message.

A good point, but I did comment on this. By "recent compiler" I meant
~ 4.8 and beyond. Or put in other words, I take Debian stable as a
reference.

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