Hi, On Thu, Mar 10, 2016 at 2:28 PM, Reimar Döffinger <reimar.doeffin...@gmx.de> wrote:
> On 10.03.2016, at 12:01, Ismail Donmez <ism...@i10z.com> wrote: > > > On Thu, Mar 10, 2016 at 12:04 PM, wm4 <nfx...@googlemail.com> wrote: > >> On Thu, 10 Mar 2016 16:53:12 +0700 > >> Muhammad Faiz <mfc...@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. Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
