[FFmpeg-devel] [PATCH] avcodec/cbrt_tablegen: avoid pow and speed up cbrt_tableinit

Ganesh Ajjanagadde gajjanagadde at gmail.com
Thu Nov 26 00:32:23 CET 2015

On Wed, Nov 25, 2015 at 6:19 PM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> Hi,
> On Wed, Nov 25, 2015 at 5:17 PM, Ganesh Ajjanagadde <gajjanagadde at 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 <gajjanagadde at 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...

Can you please give a link and/or timeframe to search for?

> 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.

I don't understand this, it seems to me like any other code (at least
in the default configure), it gets called, and like all other such
things, we use libavutil/libm for hackery. This host/target business
affects other things as well. What is the issue?

> 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

More information about the ffmpeg-devel mailing list