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

Måns Rullgård mans
Thu Oct 15 12:45:31 CEST 2009


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.

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

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



More information about the ffmpeg-devel mailing list