My experience differs. We've used SIMD intrinsics extensively, and almost never use assembly for this. We write huge quantities of performance critical code, as

My experience differs. We've used SIMD intrinsics extensively, and almost never use assembly for this. We write huge quantities of performance critical code, as do you. Many of the limitations that you discuss are real, but we've got strategies to avoid them. We do compile a dozen versions, which is horrible, but there it is. We get peak performance out of code using intrinsics. By 'peak', I mean close to the limits that can be achieved given the latency of the critical path and the number of operations that need to be carried out in total divided by the ports that can execute them. In order to persuade gcc to get register allocation and scheduling right, we typically have to program in a style that closely resembles assembly, and a fair bit of our critical code is automatically generated and hand-unrolled/pipelined/scheduled. This is still easier than coding everything in assembly, especially when something goes wrong. Large quantities of unrolling, and careful management of potential problems like aliasing, typically gets modern x86 what it needs to be able to overcome the problems of gcc. :-) Quite often the asm generated looks like shit but I have noticed a number of cases where improving the asm to be more sane actually reduces performance, often due to the fact that a modern x86 processor is doing weird things with the resulting code.