[FFmpeg-devel] FASTDIV macro

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> On Sun, Nov 09, 2008 at 01:35:15PM +0000, M?ns Rullg?rd wrote:
>> Michael Niedermayer <michaelni at gmx.at> writes:
>> 
>> > On Sat, Nov 08, 2008 at 09:49:24PM +0000, M?ns Rullg?rd wrote:
>> >> libavutil/internal.h defines a macro, FASTDIV(), for fast 32/16-bit
>> >> division my means of multiplying by a table value.  If the
>> >> architecture is not ARM or x86, which have asm versions, this macro is
>> >> defined as a normal division if CONFIG_FASTDIV is not set.  The odd
>> >> thing is, nothing ever sets CONFIG_FASTDIV.  Something is clearly not
>> >> right here.
>> >> 
>> >> I see these alternatives to fix it:
>> >> 
>> >> 1. Always use the table multiplication.
>> >> 2. Enable CONFIG_FASTDIV by default.
>> >> 3. Disable CONFIG_FASTDIV by default, adding configure option to
>> >>    enable.
>> >> 4. Always use plain division if no asm available.
>> >> 
>> >> Opinions?
>> >
>> > the variant that is faster should be used unless CONFIG_SMALL is enabled
>> > in which case the table should be avoided except when the speed difference
>> > is enourmious.
>> 
>> How do we know which is faster?
>
> benchmark

Calling all people with exotic hardware...

>> >> There is also a question of where this macro belongs.  It uses a table
>> >> defined in lavc, and its only use outside lavc is in ff_sqrt(), which
>> >> is only used in lavc.  Would it make sense to move these to
>> >> lavc/mathops.h, where other similar macros are defined?
>> >> Alternatively, mathops.h could be moved to lavu.  I'd like it to be
>> >> consistent.  The same goes for a number of other macros of this type.
>> >
>> > i think that at least the table should be moved to lavu
>> 
>> What would be a good place?  mathematics.c has some other tables (for
>> ff_sqrt() and av_log2()), so maybe that would be a good place.
>
> ok
>> 
>> What about lavc/mathops.h?
>
> i dont know, but at least the per file FRAC_BITS #define system should be
> replaced by something else first.

Yes, certainly.  I'll take a look, and see what I can think of.

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