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

Måns Rullgård mans
Tue Sep 21 00:41:35 CEST 2010


Michael Niedermayer <michaelni at gmx.at> writes:

> On Mon, Sep 20, 2010 at 02:13:56PM -0700, Alex Converse wrote:
>> On Mon, Sep 20, 2010 at 10:20 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
>> >
>> >
>> > 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
>> >
>> 
>> Besides the bugs Ronald mentioned, we were using split asm sections
>> and counted on them preserving values between the sections which is
>> undefined behavior.
>
> its no bit better if these where split yasm function calls
> the problem is the split not the inline vs yasm

The two asm blocks were obviously moved to yasm as a single function.

>> Both of these situations are possible to fix with inline asm (yasm
>> loops and manually stacking variables things) but these mistakes
>> are much harder to make in yasm in the first place.
>
> i dont really agree that such mistakes are harder to make in yasm
> also depending on mmx/sse registers being preserved was likely done
> conciously.

Consciously or not, it was done in error.

> It was done at a time when it was safe with existing platforms. The problems
> just begun with win64

It also affected suncc on Linux.  All the mdct-based audio codecs were
broken.

> So IMO this is a before win64 vs. after win64 issue and not at all a inline
> vs yasm issue.

It is simple matter of not relying on undefined behaviour.  I hope we can
all agree that undefined behaviour should not be relied upon.

> With yasm the only reason not to do split asm is that yasm has more
> overhead namely for each call

The function call overhead is exactly the same with yasm or C,
assuming the C compiler doesn't generate ridiculous prologues and
epilogues.  Please stop claiming anything else.  Nobody is talking
about asm that actually gets inlined.

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



More information about the ffmpeg-devel mailing list