4 ms·

> We have yet to see satisfactory results for C... That's not a fair assessment. Major compilers (LLVM, GCC, Intel) are able to vectorize real world code to a

> We have yet to see satisfactory results for C... 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.

dagss 9y ago
I think the parent with "satisfactory" meant "possible to achieve the maximum performance the hardware will support" (after all why settle for less?) You are answering another question. 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.
- marmaduke 9y ago
  Yeah I didn't mean that I would be over backwards to make it work, just that I happen to see great speed ups for my real world code with almost no effort. For more complex stuff I'd be looking at ISPC or OpenCL before assembly since I can't afford to write ISA specific code.
- marmaduke 9y ago
  Also, in my experience, maximum performance for most algorithms is not a clear cut line that I fall short of for lack of motivation. I see that maximum as a rather fuzzy unknown, approaching it is has diminishing returns on the time spent optimizing.
brian-armstrong 9y ago
This isn't actually true for any meaningful speedup. You will at least need to use intrinsics to start to get as much as you can from the cpu
- marmaduke 9y ago
  The C kernel I've written here https://github.com/numba/llvmlite/issues/270 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.
tmyklebu 9y ago
> Major compilers (LLVM, GCC, Intel) are able to vectorize real world code to a useful extent. 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; } You don't get satisfactory results. I, at least, don't have a clear mental model of when gcc will do something reasonable and when it will generate a large amount of bad code.
- marmaduke 9y ago
  Sure there are bugs. There are also compiler flags which elucidate the model of loops it has and how it makes its decisions.

dagss 9y ago

I think the parent with "satisfactory" meant "possible to achieve the maximum performance the hardware will support" (after all why settle for less?) You are answering another question. 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.

marmaduke 9y ago
Yeah I didn't mean that I would be over backwards to make it work, just that I happen to see great speed ups for my real world code with almost no effort. For more complex stuff I'd be looking at ISPC or OpenCL before assembly since I can't afford to write ISA specific code.
marmaduke 9y ago
Also, in my experience, maximum performance for most algorithms is not a clear cut line that I fall short of for lack of motivation. I see that maximum as a rather fuzzy unknown, approaching it is has diminishing returns on the time spent optimizing.

brian-armstrong 9y ago

This isn't actually true for any meaningful speedup. You will at least need to use intrinsics to start to get as much as you can from the cpu

marmaduke 9y ago
The C kernel I've written here https://github.com/numba/llvmlite/issues/270 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.

tmyklebu 9y ago

> Major compilers (LLVM, GCC, Intel) are able to vectorize real world code to a useful extent. 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; } You don't get satisfactory results. I, at least, don't have a clear mental model of when gcc will do something reasonable and when it will generate a large amount of bad code.

marmaduke 9y ago
Sure there are bugs. There are also compiler flags which elucidate the model of loops it has and how it makes its decisions.