Re: [Mjpeg-users] -M 2/3 on SMP is slower than -M 0

[Andrew S. <and...@mn...>]

> In floating point, all you have to do is flip a sign bit.  But with
> integers, it's not so easy.  There is no instruction for absolute value in
> MMX, you have to use a four instruction sequence and two registers.  Slower
> than squaring a value, which only takes two instructions.

> I finally found a mmx2 reference, and you're right about that.  MMX2 added
> psadbw, packed sum of absolute differences.  If you have 8-bit unsigned
> data it makes computing SAD pretty darn easy, you can find the SAD of 8
> pixels in one instruction.

There are really very very few MMX-only current CPUs.   Basically everything 
after K6 with MMX supports the psadbw instruction.

> Though why did mpeg2enc use variance in the first place?  Maybe it's a
> better estimator than SAD for motion compensation fit?

Its just not that simple.  It uses SAD for 'coarse' motion estimation and 
switches to variance for the final selection of the particular motion 
estimation mode.  This combination provides a good speed/quality trade-off.
Experiments with 'only variance' were unimpressive in their quality 
improvements and 'only SAD' costs quite a lot of quality for modest speed 
gain.   All the 'low hanging fruit' in the current motion estimation 
algorithm has long since been picked...

> The level of altivec optimizations ffmpeg vs mpeg2 is probably an important
> factor in any speed difference, and one that wouldn't matter for other
> CPUs, which the level of MMX/MMX2/SSE optimizations makes a large
> difference.

You have to be very careful to compare like coding profiles, motion search 
radii and suchlike too.  

Its easy to be twice as fast if your simply trying half as hard to find a good 
encoding.   However, there *are* bottlenecks in mpeg2enc.   For a real speedy 
mode predictive motion estimation algorithms would need to be used.

	Andrew