[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