[FFmpeg-cvslog] r14897 - trunk/libavcodec/acelp_filters.c

[Michael Niedermayer]

On Fri, Aug 22, 2008 at 02:13:23PM +0100, M?ns Rullg?rd wrote:
> 
> Michael Niedermayer wrote:
> > On Fri, Aug 22, 2008 at 12:42:04AM +0100, M?ns Rullg?rd wrote:
> >> michael <subversion at mplayerhq.hu> writes:
> >>
> >> > Author: michael
> >> > Date: Fri Aug 22 01:25:41 2008
> >> > New Revision: 14897
> >> >
> >> > Log:
> >> > Remove mathops.h dependancy.
> >>
> >> The purpose of mathops.h is to allow CPU-specific instructions to be
> >> used for common operations.  Not using it when possible is similar to
> >> not using dsputil.  Is there a specific reason the optimised macros
> >> are unsuitable in this file?
> >
> > Several points
> >   the first line can be simplified to
> >   tmp = (hpf_f[0]* 3959LL)>>11;
> >   but the shift is fixed per file when mathops.h is used
> 
> We could easily add a shift argument to the macro.

Yes i definitly agree with this ...
the way MULL is currently with the shift at the top of the file is not
particularely readable ...


> 
> >   vladimirs comments indicated that the hpf variables need 26 bits
> >   in which case the code can be simplified to
> >   tmp  = ( 31*hpf_f[0] + ((hpf_f[0]*-9)>>7))>>4
> >   tmp += (-15*hpf_f[1] + ((hpf_f[1]*13)>>9))>>4;
> >   which avoids the 64bit ops ...
> 
> Is it faster though?  It still has multiplications.

faster on "what" ?

on normal desktop systems i suspect the whole would be fastest when
done in floats.
On non desktop hardware the 64 bit multiply and shift likely will be
expensive. also *31, *15 and *9 are just 1 shift and 1 add/sub each and
at least on x86 gcc is pretty good at spliting such multiplies into
shift/add sequences.


anyway, i dont mind at all to revert my commit and put the MULL back.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored awnser#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
-------------- 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-cvslog/attachments/20080822/a6ee8b00/attachment.pgp>