On Fri, Mar 11, 2016 at 2:52 AM, Ronald S. Bultje <rsbul...@gmail.com> wrote: > 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. >
OK, I will follow. Thank's _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
