Even compiled intrinsic SIMD beats most hand-coded kernels these days
Intrinsics basically are hand-coded assembly: you're specifying every single instruction manually, just in an obfuscated syntax, and without a proper assembler preprocessor.
At that point, it's way easier to just write it straight by hand.
Also, there are still plenty of things compilers are terrible at with intrinsics. This includes things like:
1) Register allocation. Compilers, even "good" ones, will throw things on the stack willy-nilly. The biggest problem here is that the compiler hides register utilization from the programmer, preventing him or her from seeing how many registers are used. If you're aware of register usage, you can tweak the algorithm to avoid the problem.
2) Compilers are truly terrible at making up calling conventions for calls within assembly (e.g. to a subfunction). Humans can make whatever calling convention they like, which can give great performance improvements in functions like FFTs (see: libav split radix fft) that are inherently recursive. In the case of the aforementioned FFT, Loren was able to make a handwritten-asm Altivec version around ~40% faster than intrinsics, IIRC.
3) Compilers are not very good at organizing code; in many cases, it is useful to split up code and reuse blocks to save on code cache (see: x264 trellis asm). This avoids inlining it and creating a massive mess -- which, by the way, trashes the compiler's register allocator too. When using the compiler to do this, you run into the problem of 2); it can't allocate registers efficiently between code blocks, or come up with a decent calling convention, so it's inefficient.
4) There are some things that no compiler in existence is currently able to do, like computed jumps without tables to a templated set of functions (see: x264 cacheline SAD asm).
I could swear I had read a similar rant of yours somewhere before, but could not find it.
Anyway, I do not disagree with you. What I was trying to convey was not so much the quality of current intrinsic code, but the progress that has been made in the last ~5 years in this respect. I remember writing some intrinsic code that became a series of useless stores and loads all over the place. When that is your baseline, current tech is impressive, modulo the issues you've quite correctly pointed out.
Intrinsics basically are hand-coded assembly: you're specifying every single instruction manually, just in an obfuscated syntax, and without a proper assembler preprocessor.
At that point, it's way easier to just write it straight by hand.
Also, there are still plenty of things compilers are terrible at with intrinsics. This includes things like:
1) Register allocation. Compilers, even "good" ones, will throw things on the stack willy-nilly. The biggest problem here is that the compiler hides register utilization from the programmer, preventing him or her from seeing how many registers are used. If you're aware of register usage, you can tweak the algorithm to avoid the problem.
2) Compilers are truly terrible at making up calling conventions for calls within assembly (e.g. to a subfunction). Humans can make whatever calling convention they like, which can give great performance improvements in functions like FFTs (see: libav split radix fft) that are inherently recursive. In the case of the aforementioned FFT, Loren was able to make a handwritten-asm Altivec version around ~40% faster than intrinsics, IIRC.
3) Compilers are not very good at organizing code; in many cases, it is useful to split up code and reuse blocks to save on code cache (see: x264 trellis asm). This avoids inlining it and creating a massive mess -- which, by the way, trashes the compiler's register allocator too. When using the compiler to do this, you run into the problem of 2); it can't allocate registers efficiently between code blocks, or come up with a decent calling convention, so it's inefficient.
4) There are some things that no compiler in existence is currently able to do, like computed jumps without tables to a templated set of functions (see: x264 cacheline SAD asm).