[FFmpeg-devel] [PATCH] update doc/optimization.txt

[Michael Niedermayer]

On Mon, Sep 20, 2010 at 03:51:23PM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Mon, Sep 20, 2010 at 1:20 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Mon, Sep 20, 2010 at 09:58:53AM -0400, Ronald S. Bultje wrote:
> >> Again, of course I
> >> could arguably have done that in inline asm as well. But I did the
> >> work and I didn't.
> >
> > yes, and what irks me a bit is that if an outsider does that we point him
> > to /dev/null
> > Like hey you fixed a bug but unneccesarily rewrote the whole code in differnt
> > "style" but people with commit access just do it and dont feel anything wrong.
> > as leader i see this harsh difference and i do not like it nor does it feel
> > being fair at all.
> >
> > I dont mind at all if code is changed to yasm if it is faster or if it is
> > neccessary and the only known clean way to solve a bug.
> > i dont even mind if code is yasm instead of asm() to begin with
> > but changing the code just because someone decided to make a usefull change
> > on top of the yasm code instead of in inline, i really dont like this and i
> > wouldnt like the other way around either, rewriting yasm to inline for no
> > good reason
> 
> I think it did solve bugs. E.g. in h264_idct*() I've described (in my
> emails) several cases where the gcc+inline asm combination resulted in
> incredibly weird assembly that had a _very_ negative effect on
> performance because of weird jumping behaviour. The worst case is
> intra16 (mmx, I believe), where my new code was 50% (!!) faster
> (probably ~0.25%-0.5% overall) because of this weird way of compiling
> for (i=0;i<n;i++) { if (a || b) do_something }. I believe that's a
> proper reason to rewrite the if() in asm instead of in C.

yes 


> 
> inlineasm->yasm could be considered questionable. In my defense, I
> don't regularly write inline asm and it would likely have taken me
> twice as long. I still don't know quite what +, r, m, memory and so on
> mean.

+ is input+output
m is memory
r register

"memory" means that the asm block can modify memory that is not one of its
output operands, this is often not needed/forgotten in practice as there are
rarely opertunities for gcc to cache values from the written to arrays over
the asm


> 
> For things like h264_deblock.asm, I simply synced to latest trunk of
> x264, which is in yasm as well. I hope at least that one is OK with
> you.

of course


[...]
-- 
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: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100920/9b5316a6/attachment.pgp>