[FFmpeg-devel] [RFC] remove table_4_3_value with CONFIG_SMALL
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.
mans at mansr.com
More information about the ffmpeg-devel