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

[Ronald S. Bultje]

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.

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.

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.

> thats just besides that it totally fucks up svn blame and even git blame

That one I know and I'm sorry for. :-(.

Ronald