[FFmpeg-devel] [RFC] remove table_4_3_value with CONFIG_SMALL

[Reimar Döffinger]

On Thu, Oct 15, 2009 at 11:45:31AM +0100, M?ns Rullg?rd wrote:
> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> > On Thu, Oct 15, 2009 at 11:19:05AM +0100, M?ns Rullg?rd wrote:
> >> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> >> > On Thu, Oct 15, 2009 at 09:59:33AM +0100, M?ns Rullg?rd wrote:
> >> >> It will totally murder performance on anything without an FPU.  Those
> >> >> are also the systems most likely to need CONFIG_SMALL, so this is not
> >> >> acceptable.
> >> >
> >> > Actually the only system that currently _needs_ CONFIG_SMALL is IA64.
> >> 
> >> IA64 builds with a plain ./configure over here.  It's --enable-shared
> >> that's breaking it.
> >
> > Well, then IA64 with --enable-shared is the only system that definitely
> > needs it (though I hope that if I move the ff_sin tables to .rodata as well
> > hardcoded-tables will fix it).
> 
> You're forgetting all the RAM-constrained systems we don't test on.

Well, do you have any hard information on? I only seem to remember that
e.g. rockbox used hardcoded-tables, but not small.

> >> > Also, this is nearly the largest table in all of FFmpeg, so I very much
> >> > think it should be under CONFIG_SMALL.
> >> 
> >> I repeat, there is a large overlap between systems with limited RAM
> >> and those without FPU.  We don't want to make CONFIG_SMALL useless on
> >> those.  Didn't you have a different idea without floating-point too?
> >
> > No, I only had a suggestion that avoids exp2f, it still needs cbrtf and
> > float multiplication.
> > It probably should be investigated more, the current form of the patch
> > probably is nonsense. I still don't think that it's a sensible approach
> > to have CONFIG_SMALL assume a slow/inexistent FPU.
> 
> It is at least as nonsensical to have CONFIG_SMALL assume a blazingly
> fast FPU is available.

Yes, to a degree (though that might need further investigation with
someone who actually uses --enable-small), though you could just as well
say that those device with little memory are likely to have even slower
CPUs, thus (almost) all those CONFIG_SMALL optimizations are nonsensical (yes, it
is an exaggeration, but maybe you get the idea).
If someone uses --enable-small in real-world use, comments are welcome.