[FFmpeg-devel] FASTDIV macro

Michael Niedermayer michaelni
Sun Nov 23 19:39:51 CET 2008


On Sun, Nov 23, 2008 at 06:15:53PM +0000, M?ns Rullg?rd wrote:
> 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.

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.
> 
> That should be as simple as adding a third argument for the shift
> amount.

exactly

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081123/99e59a06/attachment.pgp>



More information about the ffmpeg-devel mailing list