[FFmpeg-devel] FASTDIV macro

Måns Rullgård mans
Sun Nov 23 19:15:53 CET 2008


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

Of the benchmarks we've seen so far (ARM, PPC, x86), all have
benefited significantly from the table method, although only PPC is
lacking an asm version.  IMHO we should enable CONFIG_FASTDIV by
default (possibly dependent on !CONFIG_SMALL), and deal with anything
where it is slower if we ever find such a machine.

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

Uoti reckons this might penalise code using it from lavc...

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

That should be as simple as adding a third argument for the shift
amount.

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




More information about the ffmpeg-devel mailing list