[FFmpeg-devel] [PATCH] avcodec/cbrt_tablegen: avoid pow and speed up cbrt_tableinit
jamrial at gmail.com
Thu Nov 26 00:49:10 CET 2015
On 11/25/2015 8:32 PM, Ganesh Ajjanagadde wrote:
> On Wed, Nov 25, 2015 at 6:19 PM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
>> On Wed, Nov 25, 2015 at 5:17 PM, Ganesh Ajjanagadde <gajjanagadde at gmail.com>
>>> On systems having cbrt, there is no reason to use the slow pow function.
>>> Sample benchmark (x86-64, Haswell, GNU/Linux):
>>> 5124920 decicycles in cbrt_tableinit, 1 runs, 0 skips
>>> 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
>>> FFmpeg. Unless I am missing something, static storage is anyway allocated
>>> 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
>>> simply because at the moment users are paying a price for the typical
>>> 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?
libavutil/libm.h uses defines from config.h, which are based on the tests run
by configure for the target, and not the host where compilation takes place.
The tablegen applications all run at compile time. What is available on the
target may not be on the host.
>> 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.
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel