On Tue, Oct 13, 2015 at 12:26 AM, Ganesh Ajjanagadde <gajja...@mit.edu> wrote: > On Tue, Oct 13, 2015 at 12:16 AM, Carl Eugen Hoyos <ceho...@ag.or.at> wrote: >> Ganesh Ajjanagadde <gajjanag <at> mit.edu> writes: >> >>> Bench from libavfilter/astats on a 15 min clip. >> >> I believe that your test would indicate that the >> old variant is faster or that no result can be >> given which is what my tests show.
Also, how you can possibly believe that the old variant is faster is beyond me given the astonishing amount of work by Intel, Red Hat, and others to create the absolutely best performing libc. Just have a look at https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/ieee754/dbl-64/s_sin.c;hb=HEAD#l281, it gives an idea of the extreme lengths they go to. > > Look at the bench and the numbers again, I have provided it above. > They are essentially identical in the best case (most number of runs), > the new variant is faster in the worst case. You have not provided a > bench proving otherwise. > >> >> I am not sure if it makes sense to apply a patch >> that is meant to improve speed if this improvement >> can't be shown. > > I believe I have shown it above clearly. > >> >> Carl Eugen >> >> _______________________________________________ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
