[FFmpeg-devel] [flamefest-start] A little something on MMX/SSE intrinsics

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> On Thu, Feb 28, 2008 at 02:44:51PM +0100, Luca Barbato wrote:
> [...]
>> > 
>> > I guess you can always try, though, but don't do anything to
>> > discourage people who know altivec from adding more. There's still a
>> > lot missing from H.264.
>> 
>> I know, no time to hack that stuff lately...
>> 
>> That said I think won't hurt getting some people solve this issue 
>> between me (liking intrisics for powerpc/spu development) and michael 
>> (disparaging them since his arch has them uglier and apparently slower)
>
> I feel like iam talking against brick walls. The point is that intrinsics
> are flawed because they are unpredictable, gcc could generate efficient
> code from them, but it as well can (and does in current versions on x86)
> generate completely dismal code. This does not go away if gcc becomes better
> at generating code.

I still insist that it is the compiler that is unpredictable, not the
intrinsics as such.

On modern hardware, functions like sqrt() and sin() are little more
than FPU intrinsics.  Does that mean we should now start writing
asm("sqrt %0", "=r"(x)) instead of sqrt(x)?

> It seems our disagreement is not about intrinsics vs. asm being better but
> about the minimum quality and performance of the code. 5% speedloss is not
> acceptable! Even much smaller speedlosses need some justification.

I agree that a 5% speed loss is not acceptable, and I agree that plain
asm is currently better than intrinsics for x86.  I do not agree that
intrinsics are inherently bad.

You have your opinion, others have theirs.  Let's just leave it at that.

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