On 8 March 2016 at 03:48, Ganesh Ajjanagadde <gajja...@gmail.com> wrote:
> This is ~2x faster for y not an integer on Haswell+GCC, and should > generally be faster due to the fact that anyway powf essentially does > this under the hood. > > Note that there are some accuracy differences, that should generally be > negligible. In particular, FATE still passes on this platform. > > Results in ~ 7% speedup in aac encoding with -march=native, Haswell+GCC. > before: > ffmpeg -i sin.flac -acodec aac -y sin_new.aac 6.05s user 0.06s system > 104% cpu 5.821 total > > after: > ffmpeg -i sin.flac -acodec aac -y sin_new.aac 5.67s user 0.03s system > 105% cpu 5.416 total > > This is also faster than an alternative approach that pulls in powf, gets > rid of > the crufty NaN checks and other special cases, exploits knowledge about > the intervals, etc. > This of course does not exclude smarter approaches; just suggests that > there would need to be significant work on this front of lower utility than > searches for hotspots elsewhere. LGTM, thanks _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
