[FFmpeg-devel] [PATCH] ppc: replace vec_ld(0), vec_ld(1) by VEC_LD2() which has fewer loads

[Michael Niedermayer]

On Fri, Nov 14, 2014 at 09:00:31PM -0700, Pavel Koshevoy wrote:
> On 11/14/14 07:34, Michael Niedermayer wrote:
> >On Fri, Nov 14, 2014 at 06:45:55AM -0700, Pavel Koshevoy wrote:
> >>On Nov 13, 2014 4:15 PM, "Michael Niedermayer" <michaelni at gmx.at> wrote:
> >>>On Fri, Nov 07, 2014 at 03:12:19PM +0100, Michael Niedermayer wrote:
> >>>>This needs to be benchmarked, i do not have ppc hw
> >>>>This is on big endian more similar to how the code was before
> >>79e0255956bc8fcdb143f39b2e45db77144ac017
> >>>>Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
> >>>ping
> >>>
> >>>can someone with a altivec PPC please benchmark this
> >>>or do all the ppc people want code to be slow and unoptimized ?
> >>>iam also happy to benchmark it myself if someone provides a ppc or
> >>>account on a altivec ppc that is reasonable idle so benchmarking is
> >>>possible with some accuracy
> >>>
> >>I can do it over the weekend, I have a ppc G4 800MHz iMac.  I'll need
> >>instructions on what to do for benchmarking.
> >patch that adds benchmarking is below
> >that and trying to decode some mpeg2 like with
> >  -v 99 -i matrixbench_mpeg2.mpg -f null -
> >
> >should result in some timing values
> >i cant say for sure though, as this does not work under qemu
> >under qemu i just get 0
> >
> >
> >diff --git a/libavcodec/mpegvideo_motion.c b/libavcodec/mpegvideo_motion.c
> >index e7a585d..94b140d 100644
> >--- a/libavcodec/mpegvideo_motion.c
> >+++ b/libavcodec/mpegvideo_motion.c
> >@@ -976,6 +976,7 @@ void ff_mpv_motion(MpegEncContext *s,
> >                     op_pixels_func (*pix_op)[4],
> >                     qpel_mc_func (*qpix_op)[16])
> >  {
> >+    START_TIMER
> >  #if !CONFIG_SMALL
> >      if (s->out_format == FMT_MPEG1)
> >          mpv_motion_internal(s, dest_y, dest_cb, dest_cr, dir,
> >@@ -984,4 +985,5 @@ void ff_mpv_motion(MpegEncContext *s,
> >  #endif
> >          mpv_motion_internal(s, dest_y, dest_cb, dest_cr, dir,
> >                              ref_picture, pix_op, qpix_op, 0);
> >+    STOP_TIMER("MC")
> >  }
> >
> >
> 
> git am wouldn't apply the patches for me (I just saved the message
> from Thunderbird to .eml file and tried to feed that to git am). So,
> I had to trim them and use patch -p1 to apply manually.  The patch
> for util_altivec.h wouldn't apply so I patched manually.
> 

> I ran both builds twice and captured the output from the second run
> of each build, it's in the attachment.  By the looks of it there is
> no difference in performance.

to compare START/STOP_TIMER data its generally best to run the
test a few times (like 3) and compare the values from each that
have some specific number or runs, like

> 681 UNITS in MC, 4192359 runs, 1945 skips0:01:40.88 bitrate=N/A
vs.
> 668 UNITS in MC, 4192326 runs, 1978 skips0:01:40.16 bitrate=N/A

but from these 2 tests it seems you are correct and theres no
significant difference so theres probably not much point in doing
further tests

Thanks!

PS: if the tests take too long, a shorter video can be used or the
duration can be limited


> 
> If you'd like me to try something else -- I can try again tomorrow.
> 
>     Pavel.
> 

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20141115/3e4a4acf/attachment.asc>