[FFmpeg-devel] [PATCH] update doc/optimization.txt
Tue Sep 21 11:21:11 CEST 2010
On Mon, Sep 20, 2010 at 11:41:35PM +0100, M?ns Rullg?rd wrote:
> 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.
merging 2 blocks and converting to yasm in one patch does not make
"converting to yasm" fix the issue that was fixed by "merging the blocks"
> >> 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.
i would say it less strong like it was dirty way of handling things
but yes in principle i agree
though again this isnt a yasm vs. inline issue, its a "too lazy/hard to
convert the C in between to asm" issue
> > 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.
thats not true, the split asm cases surely where inlined and a 1:1 conversion
to yasm would have had additional call overhead.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Thouse who are best at talking, realize last or never when they are wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel