[FFmpeg-devel] Inline ASM vs. Intrinsics

Måns Rullgård mans
Fri May 11 22:10:26 CEST 2007


Michael Niedermayer <michaelni at gmx.at> writes:

> Hi
>
> On Fri, May 11, 2007 at 07:44:53PM +0100, M?ns Rullg?rd wrote:
>> Michael Niedermayer <michaelni at gmx.at> writes:
>> 
>> > Hi
>> >
>> > On Fri, May 11, 2007 at 10:22:32AM -0400, Dave Dodge wrote:
>> >> On Fri, May 11, 2007 at 02:06:11PM +0200, Guillaume POIRIER wrote:
>> >> > Exactly. I wrongfully assumed that "register" keywork was honnored
>> >> > with xmm/mm intrinsics, but I was wrong. It's simply ignored by ICC. I
>> >> > don't know about GCC.
>> >> 
>> >> According to its documentation gcc also ignores the "register" storage
>> >> class specifier, except in a few special cases:
>> >> 
>> >>   - when using asm in a declaration to explicitly specify which register.
>> >>   - when using -O0.
>> >>   - when using setjmp on certain rare target platforms.
>> >> 
>> >> Aside: on IA64 icc supports only intrinsics -- no inline assembly.  On
>> >> the one hand IA64 assembly is so painful that you'd rarely want to
>> >> write it manually anyway; but the downside is that the intrinsics
>> >
>> > IA64 is a complete failure with and without intrinsics
>> 
>> IA64 is a complete commercial failure.  Its performance is far better
>> than any x86-based CPU of the same time period.  The main reason it
>> failed was lack of good x86 emulation, and people insisting on
>> continuing to run the same old rubbish non-portable software.
>
> really?  can you point to some benchmarks? (not from intel of
> course) i thought it was significantly slower than compareable CPUs
> (same time period and same price range) even when both run natively
> compiled code (with similarly good compilers of course)

Sorry, I don't have any benchmarks handy.  I just remember playing
with one in uni, and it was quite fast compared to the P3 machines
also available, particularly for floating point.

> and even if it was faster its was conceptually flawed (=missdesigned)
> it tried to move things from runtime to compiletime which are not
> "constant" but change depending on the data the code works on
> and from what i remember its a nightmare for a compiler to generate
> good code for it ...

And you're suggesting the x86 is not conceptually flawed?  Hanging on
to a 30-year old design when much better ways are known seems like an
unusually bad idea to me.

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




More information about the ffmpeg-devel mailing list