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

Michael Niedermayer michaelni
Mon Sep 20 15:57:12 CEST 2010


On Mon, Sep 20, 2010 at 02:41:23PM +0100, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > 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
> 
> It also fixed a number of failures with suncc on Linux.
> 
> >> >> > 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)
> 
> We should optimise for reality, not some hypothetical ideal situation.

well, avoiding call overhead is working in reality in swscale and libpostproc
for swscale there is probably no point in that desigb though


> 
> >> > * 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
> 
> Do you remember which mailing list?

ffmpeg or mplayer, dev or cvslog i suspect but i do not know



> 
> >> > 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
> 
> Yasm seems to provide better features for abstracting the differences
> with macros.

yes but this is a 2 sided sword, the macros it supports can become quite
obfuscated and complex


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

> ... defining _GNU_SOURCE...
For the love of all that is holy, and some that is not, don't do that.
-- Luca & Mans
-------------- 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/c1edf035/attachment.pgp>



More information about the ffmpeg-devel mailing list