[FFmpeg-devel] [PATCH] SSE RDFT

[Michael Niedermayer]

On Mon, Mar 15, 2010 at 12:31:12AM +0000, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > On Sun, Mar 14, 2010 at 10:51:06PM +0000, M?ns Rullg?rd wrote:
> >> Alex Converse <alex.converse at gmail.com> writes:
> >> 
> >> > 2010/3/14 M?ns Rullg?rd <mans at mansr.com>:
> >> >> Alex Converse <alex.converse at gmail.com> writes:
> >> >>
> >> >>> I'm sure I've made some embarrassingly amateurish mistakes here.
> >> >>> Feedback is more than welcome.
> >> >>
> >> >> The first one is doing it in inline asm. ?New asm should preferably
> >> >> use yasm.
> >> >>
> >> >
> >> > Dammed if you do, dammed if you don't. Last time did an SSE function I
> >> > used yasm and there were complaints that people preferred inline.
> >> 
> >> Michael is the only person insisting on inline.  Everybody else agress
> >> that yasm is far more reliable.
> >
> > reliability is one part, portability, flexibility,maintainability and speed
> > another, and you dont know everybodies oppinion
> 
> I know the opinion of those who have stated theirs.
> 
> > thats besides that iam x86 maintainer and the author of quite alot of the
> > x86 code thus i claim that i do know what i talk about. I was the one keeping
> > the inline asm working over the years and thus if i say its little work
> > really you can belive me it is.
> 
> Yes, you readily complain about how gcc inserts useless code around
> asm blocks.  Yasm doesn't do that...

yasm doesnt support more than 1 block and requires call overhead any time
execution enters of leaves this block due to call overhead.


> 
> Also, the inline asm frequently fails on one or more configurations.

new asm ocasionally fails, its also occasionally buggy like any code can
be, but once it works it tends to stay that way. And sure gcc can be
buggy too occasionally. nasm/yasm had its bugs too
If one version is buggy use one that is not, we tend not to workaround
compiler bugs quickly but rather expect the bugs to be fixed where they
are.


> I've rarely seen you fix any of that, at least not without being
> repeatedly prompted.

you are getting annoying. And iam considering to step back as x86 maintainer
if this continues, its no fun to do the work and then be attacked for it
or have others dictate what style one should use in code thouse dictating dont
maintain at all
or having to make long lists of what one did and why and why not and about
other people should fix the bugs they caused themselfs and so on


> 
> Furthermore, I trust Jason and Loren just as much as I trust you in
> these matters.  They both prefer yasm.

they do AFAIK, but i dont and i maintain the x86 code in ffmpeg while
they dont
iam sure you will find people prefering all kinds of things over what we
do and they might have good reasons for their prefering. It makes sense
to consider alternatives but ultimately the people doing the work on that
specific part of the code decide how it is done.
you are voluteering to take over x86 asm maintaince are you?


> 
> > yasm vs. inline is for the most part bikeshed, but there are cases where one
> > wants to keep parts of the code in C for maintainability or integrate the
> > code into C code avoiding call overhead. For these cases inline is required
> > And we dont always know ahead of time where call overhead will matter.
> 
> We were talking about code called through a function pointer here.

yes, so it falls in the category that can be done in inline or yasm
technically, that is the choice is a matter of preference/bikeshed

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100315/b24d4c05/attachment.pgp>