[FFmpeg-devel] Proposed patch

[Michael Niedermayer]

Hi

On Sun, Aug 05, 2007 at 11:18:00AM +0300, Ivan Kalvachev wrote:
> 2007/8/4, Michael Niedermayer <michaelni at gmx.at>:
> > Hi
> >
> > On Sat, Aug 04, 2007 at 09:31:35AM +0000, Arpi wrote:
> > > Hi,
> > >
> > > > >   Anyway, if you consider ppc to be a critical one to benchmark on,
> > > > > I would need somebody to do it for me.
> > > >
> > > > well, if noone steps forward to benchmark it on ppc then ill assume that
> > > > there are no ppc users who care about a possible 50% speedloss
> > > > (or speedgain...)
> > >
> > > Darwin g5.local 8.10.0 Darwin Kernel Version 8.10.0: Wed May 23 16:50:59 PDT
> > > 2007; root:xnu-792.21.3~1/RELEASE_PPC Power Macintosh powerpc
> > > 2x2.5ghz G5 cpu...
> > >
> > > gcc version 4.0.1 (Apple Computer, Inc. build 5341)
> > [...]
> > > MPlayer SVN-r24007 (C) 2000-2007 MPlayer Team
> > > -vc ffmpeg12:
> > > BENCHMARKs: VC:   3.138s VO:  13.480s A:   0.000s Sys:   0.487s =   17.104s
> > > BENCHMARK%: VC: 18.3444% VO: 78.8109% A:  0.0000% Sys:  2.8447% = 100.0000%
> > >
> > > SVN-r24007 + the patch:
> > > BENCHMARKs: VC:   3.189s VO:  13.302s A:   0.000s Sys:   0.499s =   16.990s
> > > BENCHMARK%: VC: 18.7674% VO: 78.2959% A:  0.0000% Sys:  2.9367% = 100.0000%
> > >
> > > little slowdown...
> >
> > depends on which number you look at, VC yes, overall no, which is odd as the
> > other parts shouldnt be affected by the patch ...
> > maybe you could run these two benchmarks 3 times?
> >
> > also maybe you want to test the libmpeg2 bitstream reader, i think it hasnt
> > been tested on ppc yet (or i dont remember ...)
> > on x86 (duron 1x0.8 ghz, gcc 4.1.2)
> > with the good old matrixbench mpeg2 its slower:
> >
> > (default)
> > real    0m54.348s
> > user    0m52.692s
> > sys     0m1.349s
> > real    0m54.193s
> > user    0m52.755s
> > sys     0m1.239s
> > real    0m54.249s
> > user    0m52.769s
> > sys     0m1.209
> >
> > #define LIBMPEG2_BITSTREAM_READER in bitstream.h (!this needs svn head due to
> > bugs in mpeg12.c)
> > real    0m55.479s
> > user    0m53.548s
> > sys     0m1.332s
> > real    0m55.097s
> > user    0m53.601s
> > sys     0m1.271s
> > real    0m55.542s
> > user    0m53.628s
> > sys     0m1.232s
> >
> > #define A32_BITSTREAM_READER in bitstream.h
> > real    0m57.933s
> > user    0m56.142s
> > sys     0m1.261s
> > real    0m58.778s
> > user    0m56.474s
> > sys     0m1.455s
> >
> 
> 
> #def CONFIG_ALIGN
> /* avcodec/bitstream.h */
> static inline int unaligned32_be(const void *v){
>         const uint8_t *p=v;
>         return (((p[0]<<8) | p[1])<<16) | (p[2]<<8) | (p[3]);
> }
> 
> /* avutil/intreadwrite.h */
> #define AV_RL32(x) ((((uint8_t*)(x))[3] << 24) | \
>                     (((uint8_t*)(x))[2] << 16) | \
>                     (((uint8_t*)(x))[1] <<  8) | \
>                      ((uint8_t*)(x))[0])
> 
> If the function in bitstream is faster, then I think it would worth to
> replace the AV_RL32 with it.
> I am not familiar with PPC assembler, but if I suppose that it must
> load both shift parameters into registers then using 8 twice would
> explain the speed up. Maybe it worths benchmarking shifting three
> times by 8.
> 
>  (((((x3<<8)|x2)<<8)|x1)<<8)|x0
> 
> (If ppc executes 2+ instructions in parallel/out-of-order, bitstream.h
> version may allow higher parallelization, so it could still be faster.
> )
> 
> Whatever helps, I guess the other functions in avutil could be redone
> in the same manner.

also note that the bitstream reader actually would work with reading just 3
bytes instead of 4 and setting MIN_CACHE_BITS to 17
maybe someone wants to write ALT3_BITSTREAM_READER ?

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

There will always be a question for which you do not know the correct awnser.
-------------- 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/20070805/1821d99c/attachment.pgp>