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

Reply via email to