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

[Måns Rullgård]

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.

>> > * 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?

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

-- 
M?ns Rullg?rd
mans at mansr.com