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

[Michael Niedermayer]

On Mon, Sep 20, 2010 at 11:41:35PM +0100, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > On Mon, Sep 20, 2010 at 02:13:56PM -0700, Alex Converse wrote:
> >> On Mon, Sep 20, 2010 at 10:20 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> >> >
> >> >
> >> > 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
> >> > thats just besides that it totally fucks up svn blame and even git blame
> >> >
> >> 
> >> Besides the bugs Ronald mentioned, we were using split asm sections
> >> and counted on them preserving values between the sections which is
> >> undefined behavior.
> >
> > its no bit better if these where split yasm function calls
> > the problem is the split not the inline vs yasm
> 
> The two asm blocks were obviously moved to yasm as a single function.

merging 2 blocks and converting to yasm in one patch does not make
"converting to yasm" fix the issue that was fixed by "merging the blocks"


> 
> >> Both of these situations are possible to fix with inline asm (yasm
> >> loops and manually stacking variables things) but these mistakes
> >> are much harder to make in yasm in the first place.
> >
> > i dont really agree that such mistakes are harder to make in yasm
> > also depending on mmx/sse registers being preserved was likely done
> > conciously.
> 
> Consciously or not, it was done in error.

i would say it less strong like it was dirty way of handling things
but yes in principle i agree
though again this isnt a yasm vs. inline issue, its a "too lazy/hard to
convert the C in between to asm" issue


[...]

> 
> > With yasm the only reason not to do split asm is that yasm has more
> > overhead namely for each call
> 
> The function call overhead is exactly the same with yasm or C,
> assuming the C compiler doesn't generate ridiculous prologues and
> epilogues.  Please stop claiming anything else.  Nobody is talking
> about asm that actually gets inlined.

thats not true, the split asm cases surely where inlined and a 1:1 conversion
to yasm would have had additional call overhead.


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Thouse who are best at talking, realize last or never when they are wrong.
-------------- 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/20100921/5656b55d/attachment.pgp>