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

[Måns Rullgård]

Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:

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

My Blackfin struggles even with CONFIG_SMALL, which is why it isn't
yet on FATE.

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

No, I do not get the idea.  Making the code orders of magnitude slower
to save a few kB is not acceptable.  Period.

-- 
M?ns Rullg?rd
mans at mansr.com