4 ms·
There are libraries abstracting the SIMD calls if that's what you want, e.g. faster (https://github.com/AdamNiederer/faster https://github.com/AdamNiederer/fast
by sgift 7y ago
There are libraries abstracting the SIMD calls if that's what you want, e.g. faster (https://github.com/AdamNiederer/faster https://github.com/AdamNiederer/faster) or simdeez (https://github.com/jackmott/simdeez https://github.com/jackmott/simdeez), but these have to use basic operations at the end of the day too and this post shows how to do that.
I'm not sure renaming the primitive operations provided by intel/amd to something "nicer" would help much here. Using plain SIMD will always be ugly and at least you can Google the names and get back the Intel documentation without first translating from a different name.
- dragontamer 7y agoI disagree with the parent poster's phrasing, but they have a point: CUDA (for GPUs) and IPSC (for CPUs) makes SIMD code far easier to write. I think OpenMP / Intel Autovectorizers / etc. etc. are all taking the wrong approach. The "graphics guys" have figured out a better model for thinking in SIMD. With that being said, normal code has major issues before it can be converted into "Graphics-SIMD" form. Most importantly: data-layout is straight up "wrong", with most data-layouts in AOS (array of structs) instead of SOA form. Writing code that interfaces between AOS and SOA is tedious, and I'm unconvinced that any general solution can be done automatically. (Remember: the key is to convert between the forms "efficiently", because the only reason we're putting up with SIMD at all is due to performance reasons).