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

Michael Niedermayer michaelni
Mon Sep 20 19:20:39 CEST 2010


On Mon, Sep 20, 2010 at 09:58:53AM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Mon, Sep 20, 2010 at 8:55 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > 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.
> > And i dont consider rewriting inline to yasm when it can be avoided maintaince
> > For the next bugfix someone could rewrite yasm to inline again thats not
> > maintaince either
> >
> >
> >>
> >> > 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
> > * 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.
> 
> I'll openly admit that in some situations, inline asm is better. I
> would argue that in others, yasm is better.
> 
> For code that exists, is stable, won't be touched much and shows no
> bugs, I don't see why I would change to one or the other, _unless_
> there is a clear advantage of moving from one to the other. For the
> win64 bugfix/"feature", there was a clear advantage. There are other
> approaches, but I did the work and decided to do it this way. For the
> rest of the h264 code that I converted, I sent some patches afterwards
> where I can enhance the speed quite a lot (1.25% overall together is
> not too bad, and I've more work lying around here).


> 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
thats just besides that it totally fucks up svn blame and even git blame

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

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- 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/925d8710/attachment.pgp>



More information about the ffmpeg-devel mailing list