[FFmpeg-devel] [PATCH 0/3] showcqt x86 optimization using intrinsic

[Muhammad Faiz]

On Fri, Mar 11, 2016 at 2:52 AM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> Hi,
>
> On Thu, Mar 10, 2016 at 2:28 PM, Reimar Döffinger <Reimar.Doeffinger at gmx.de>
> wrote:
>
>> On 10.03.2016, at 12:01, Ismail Donmez <ismail at i10z.com> wrote:
>>
>> > On Thu, Mar 10, 2016 at 12:04 PM, wm4 <nfxjfg at googlemail.com> wrote:
>> >> On Thu, 10 Mar 2016 16:53:12 +0700
>> >> Muhammad Faiz <mfcc64 at gmail.com> wrote:
>> >>
>> >>> I use intrinsic because writing asm using nasm or inline asm
>> >>> is difficult task for me.
>> >>>
>> >>> [PATCH 1/3] configure: add x86 intrinsic support
>> >>> [PATCH 2/3] avfilter/avf_showcqt: cqt_calc x86 optimization
>> >>> [PATCH 3/3] avfilter/avf_showcqt: draw_bar x86 optimization
>> >>>
>> >>> Thank's
>> >>
>> >> We generally don't accept intrinsic in ffmpeg.
>> >
>> > Given this policy has roots from gcc 2.x times, it might be a good
>> > idea to discuss it again in the context of gcc5 and clang 3.8 and
>> > later.
>>
>> I think last time I tried it on some gcc 4.x the intrinsics generated code
>> significantly slower than the non-SIMD code (asm was about 4x faster, and
>> it was a trivial raw audio format conversion loop).
>> So from my point of view I still think with intrinsics you have to expect
>> a > 4x performance variation, which for me is "it might be better to just
>> not optimize at all" level.
>> Maybe in another 5 years... But honestly it seems to me autovectorization
>> might get there before intrinsics...
>
>
> There's also compiler variation and the sad thing is that we'll always be
> judged by our worst. If it works fine on gcc 6.x and clang 12.x but Chrome
> compiles with MSVC 2008 (windows) or VLC compiles with clang 3.x (osx) and
> that sucks, they'll say ffmpeg sucks and stop using it.
>
> It's better to have guaranteed performance, i.e. hand-written asm, as we've
> always done.
>

OK, I will follow.

Thank's