[FFmpeg-devel] [PATCH] SSE RDFT
Måns Rullgård
mans
Mon Mar 15 01:31:12 CET 2010
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...
Also, the inline asm frequently fails on one or more configurations.
I've rarely seen you fix any of that, at least not without being
repeatedly prompted.
Furthermore, I trust Jason and Loren just as much as I trust you in
these matters. They both prefer yasm.
> 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.
--
M?ns Rullg?rd
mans at mansr.com
More information about the ffmpeg-devel
mailing list