[FFmpeg-devel] [flamefest-start] A little something on MMX/SSE intrinsics
Thu Feb 28 00:27:09 CET 2008
On Wed, Feb 27, 2008 at 10:59:52PM +0000, M?ns Rullg?rd wrote:
> >> >> I guess you can always try, though, but don't do anything to
> >> >> discourage people who know altivec from adding more. There's still a
> >> >> lot missing from H.264.
> >> >
> >> > Code is either well written or should be rejected.
> >> > Intrinsics != well written.
> >> That's where you're wrong. Code using intrinsics can be well-written.
> > If the compiler generated optimal code to begin with there would be
> > no need for asm/intrinsics. OTOH if it does not, using intrinsics is
> > not that smart.
> As long as we're using the C language, expressing algorithms in a way
> that give a compiler even a remote chance to identify possibilities
> for SIMD optimisation is next to impossible. If we entertain the
I disagree here, a compiler can convert C code to SIMD in principle.
As example take, lets say motion compensation, a 8x8 block a loop iterating
over lines and columns. The compiler just has to unroll it 8 times proof
that the loop iterations cannot interfere with each other (&a != &a
then proof that the read 8 bit values fit in 8bit and "vectorize" it to
SIMD. It also has to recognize the (a+b+1)>>1 pavgb, but thats something gcc
can do already, ive seen it recognize loops and convert them to bsf/bsr.
Another approch would be to start at a given value of an array and loop
and ask the question if the next 1 or 3 or 7 values are handled identically
if so it can be possibly changed to SIMD.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel