On Thu, 22 Jan 2015 16:59:24 -0300 James Almer <jamr...@gmail.com> wrote:
> On 22/01/15 4:52 PM, wm4 wrote: > > On Thu, 22 Jan 2015 16:43:16 -0300 > > James Almer <jamr...@gmail.com> wrote: > > > >> On 22/01/15 4:27 PM, wm4 wrote: > >>> Then I'd definitely vote for remove. > >>> > >>> The asm probably mattered on ancient CPUs and ancient compilers, but > >>> there's no reason to keep it anymore. > >> > >> No. If the handwritten asm is better than the C code, even if slightly, > >> then > >> it should not be removed. > >> And if someone dislikes its inline asm nature then they are free to port > >> it, > >> like i did with a couple other filters before. > > > > For such a small difference, your statement is ridiculous. > > > > No, really. > > Grab any audio file and try to decode it, manually disabling different audio > dsp > functions it uses from libavcodec/libswresample and recompiling, and see how > much > each of them affect overall decoding speed. > You'll find that many don't even seem to have any effect if you only check > with > time, yet are still 2 to 4 times faster than their C counterparts. > > Do you want to remove them as well? That's hard to tell; if they're not bottlenecks (and can never be), then this asm would have been a case of premature optimization. In this case, it seems unlikely that vf_eq will ever be a bottleneck, or that the asm would help if it was. (You can still add back the asm if this changes... it's part of the git history, and won't run away.) _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
