That's not a fair assessment. Major compilers (LLVM, GCC, Intel) are able to vectorize real world code to a useful extent. No, they won't reorganize data to be more SIMD friendly but they can take the hard work out of writing ISA specific assemmbly.
Also, the point where you have reorganized your whole computation to be AVX-friendly it is just extra obfuscation to try to wrtie regular C and then check that the compiler outputs what you meant. Just using SIMD instructions is WYSIWYG; writing pure C is like competing in an obfuscated C contest.
Keep in mind it is not only SIMD, one might use shuffles and permutations in registers etc to communicate between the SIMD "threads".
I think the SSE/AVX intrinsics are nice to work with; they do what they say, but GCC will also turn them into something else if not supported, and perhaps apply some extra optimizations.
For more complex stuff I'd be looking at ISPC or OpenCL before assembly since I can't afford to write ISA specific code.
https://github.com/numba/llvmlite/issues/270
is contrived but the structure resembles code I maintain related to differential equation integration. Autovec provides a very nice speed up for very little effort.
Try compiling this with recent gcc:
uint8_t dumb_checksum(uint8_t *ar) {
uint8_t ans = 0;
for (int i = 0; i < 320; i++) ans += ar[i];
return ans;
}
That's because C is crap in that aspect and doesn't give enough guarantees and intents.
With a better language you could have great autovectorization in ever higher level code than C.
"Just rely on autovectorization" is what people have wanted to do for over a decade. We have yet to see satisfactory results for C. Why would JS be any easier?
> and for JS engines to provide OpenCL-like GPGPU-targeted APIs, following the trail that WebGL blazed with JS shaders.
Please don't! Nobody wants more APIs that rely on passing a string for a driver blob to compile. Standardize an IR (Web Assembly makes the most sense here).