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

[Michael Niedermayer]

On Mon, Sep 20, 2010 at 02:10:05PM +0100, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > On Fri, Sep 17, 2010 at 07:58:09PM +0100, M?ns Rullg?rd wrote:
> >> Michael Niedermayer <michaelni at gmx.at> writes:
> >> 
> >> > On Fri, Sep 17, 2010 at 06:23:16PM +0100, M?ns Rullg?rd wrote:
> >> >> "Ronald S. Bultje" <rsbultje at gmail.com> writes:
> >> >> 
> >> >> > Hi,
> >> >> >
> >> >> > $subj, fixes a typo and mentions yasm.
> >> >> >
> >> >> > I could word it stronger ("if you write new code, yasm is preferred
> >> >> > for non-inlined functions") if we can agree on that (which I don't
> >> >> > think we do yet).
> >> >> 
> >> >> Does anyone who actually writes any asm nowadays disagree?
> >> >
> >> > i dont know, but the one maintaining the x86 asm does
> >> 
> >> Ronald has done more maintenance there than anyone else recently.
> >
> > it depends on how you define maintaince, ronald did a lot of usefull asm
> > related work recently and maybe recently more than anyone else. But i dont
> > think he has maintained the existing asm.
> 
> He fixed a ton of bugs.  If that is not maintaining the code, I don't
> know what is.

he converted alot of inline to yasm to make it support win64
id say its a new feature


> 
> >> > and the project leader disagrees too
> >> 
> >> What rational arguments do you have in favour of inline asm over yasm?
> >
> > That has been discussed already if iam not mistaken
> > but i can repeat what i remember of it
> > * The call overhead can be avoided
> 
> I am only talking about code which is called through a function
> pointer regardless of the implementation.

but such code could be inlined in theory if its asm(), we did consider
things like this ages ago but noone worked on it.
And in principle a compiler compiling a whole program at a time could
inline function pointer calls if a function pointer is never set to more
than 1 function (or null)


> 
> > * it works on all platforms that have gcc or compatible compilers
> > * it allows mixing in of C code,that is especially when accessing structs
> >   quite nice and leads to more readable code.
> > * The actual existing yasm code is rather unpretty and mixed with
> >   plenty of macros.
> >
> > Also what maybe hasnt been mentioned, i dont know ...
> > The inline vs. external asm (nasm back then) discussion has happened already
> > many years ago and the consensus was that inline was better.
> 
> Do you have a reference for that?  I'd like to see what arguments were
> made that time.

sadly no


> 
> > Now the technology has changed but i dont think it has changed much and also
> > i dont remember anyone arguing along  the line that it was bad in the past
> > but due to feature X it is now good to use external asm.
> 
> One significant change is the widespread adoption of x86_64.  We've
> had many build failures in inline asm caused by mismatched operand
> types.

yes but yasm is not a magic solution here.
if one commits asm and tests it just on 32 or 64 it might not work on the other
if that is inline asm or yasm isnt going to change this in either direction
    

> 
> > What i see is jason and the people surrounding him pushing for yasm.
> > prior to x264 people pushed for inline (and people was not me here when iam
> > remembering correctly)
> 
> I don't remember much pushing taking place.  Some people wrote a bunch
> of code using inline asm, and nobody really questioned it.

i remember somoene (possibly me) suggesting nasm so code could be shard with
other projects (possibly xvid)but its too long ago to remember clearly ...
so i might remember wrong


> 
> > What i really dislike is the switching the preferred asm style every few
> > years depending on the by then more active people.
> > The result is a mix of 2 systems where one has to deal with all issues of
> > both. This is probably not really avoidable now but still...
> 
> The alternative is bitrot, witness libswscale.

reminds me of complexity cancer in the scripts

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

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is 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/20100920/decb001c/attachment.pgp>