Hi, On Wed, Nov 25, 2015 at 7:36 PM, Ganesh Ajjanagadde <gajja...@mit.edu> wrote:
> On Wed, Nov 25, 2015 at 6:49 PM, James Almer <jamr...@gmail.com> wrote: > > On 11/25/2015 8:32 PM, Ganesh Ajjanagadde wrote: > >> On Wed, Nov 25, 2015 at 6:19 PM, Ronald S. Bultje <rsbul...@gmail.com> > wrote: > >>> 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... > >> > >> 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. > > Ok. So I would like an answer to two simple questions that are outside > my knowledge or interest. > > Is it possible with some hackery to get this change through, or not? > If so, what is it? You need to understand the issue before you can evaluate hacks. The issue is: - I'm using a linux x86-64 machine using gcc as a compiler, with libc=glibc 2.18 (A); - to build a binary that will run on a Windows Mobile ARMv7 machine, with libC=something-from-Microsoft (B). tablegen runs on A, but ffmpeg.exe runs on B. libavutil/libm.h only works for B. If you want a version of libm.h on A, you need to generate a version of libm.h that works on A. There is no relationship between A and B, and thus there can not possibly ever be any relationship between A's libm.h and B's libavutil/libm.h. It's probably possible to generate a version of libm.h for A, but that's not so much a coding issue, as it is an issue of understanding the build system and including detection for stuff on machine A, as opposed to machine B (which is what most of configure does). Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
