“I keep hearing the catch-phrase among programmers that “the compiler is better than you [think].”

It’s such a silly statement. Perhaps it is true for those who say it …

That you have to even use intrinsics in the first place is a pretty good indicator compilers still have a long long way to go.

Interesting article, and good to see gcc is kicking bottom here. I don’t think it’s that they know the cpu more than intel does, they can just ‘afford’ more resources, and can share implementation with other cpu’s like power or cell’s spu.

I’m kind of surprised sse doesn’t speed things up more though, is it just that the sisd code runs is so fast or that the simd unit isn’t that fast? (compared to say cell/spu).

If your target is x86, try using -mfpmath=sse,387 for single-scalar operations.

On an additional note, llvm-gcc seems to pass all tests except comparison prediction.

Extra note, GCC 4.5 will have plugin support. I plan to write a plugin that will enhance the SSE generation code (mainly swizzle merging and branch prediction with SSE vectors).

In fact, it actually became more efficient because GCC inline asm required explicit load/unload into registers (loop counters, addresses, etc.) to be passed into the inline asm block, while the intrinsics-generated code used the registers from the preceding code.

Finally, if you have labels in inline assembly, the block can’t be inside an inline function, since the label might end up appearing twice in the same asm file. My previous solution was to jump by a manually-calculated offset to where the label would be—very tedious.

Basically speaking, GCC 4.4 has made it easier and more efficient to code simple to understand and somewhat portable vector routines, than to write them in straight C/C++ and pray that the vectorizer picks up the loop (which is something they should work on now).

GCC is incapable of handling it correctly, constantly moving data from/to the stack. The performance difference is up to 4 times faster for ICC !