Hi, On Wed, Nov 25, 2015 at 5:17 PM, Ganesh Ajjanagadde <gajjanaga...@gmail.com> wrote:
> On systems having cbrt, there is no reason to use the slow pow function. > > Sample benchmark (x86-64, Haswell, GNU/Linux): > new: > 5124920 decicycles in cbrt_tableinit, 1 runs, 0 skips > > old: > 12321680 decicycles in cbrt_tableinit, 1 runs, 0 skips > > Signed-off-by: Ganesh Ajjanagadde <gajjanaga...@gmail.com> > > ------------------------------------------------------------------------------- > What I wonder about is why --enable-hardcoded-tables is not the default for > FFmpeg. Unless I am missing something, static storage is anyway allocated > even > if hardcoded tables are not used, and the cost is deferred to runtime > instead of > build time. Thus binary size should not be affected, but users burn cycles > unnecessarily for every codec having these kinds of tables. I have these > patches, > simply because at the moment users are paying a price for the typical > default. > --- > libavcodec/cbrt_tablegen.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) This has been discussed extensively in the past... As for the patch, don't forget that tablegen runs on the host (build), not target (runtime), whereas libm.h is for target (runtime) and may not be compatible. I believe that's why we don't use libm.h in tablegen files. It's fine to use pow or a compat wrapper, but then you need a build/host libm.h instead of using the target/runtime one. Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
