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

[Ronald S. Bultje]

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.

So for the cases where I converted to yasm, I think there was a good
reason. I won't rewrite every single inline asm instruction into yasm,
don't worry, and I intend for the overall quality of FFmpeg
(portability, speed, ...) to improve as I change things. I won't
change just "so it is in yasm".

> 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.
> 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.
> 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)
>
> 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...

I don't think the mix is bad. Like I said, I won't rewrite more of
what's there right now, unless I intend to continue improving on it in
the future. As long as the overall quality of FFmpeg (speed,
portability, ...) improves, I see no problem.

Ronald