4 ms·

I don't think any sort of SIMD data type is necessary. There are so many wrappers/libraries for this already, and so many different requirements and nuances to

I don't think any sort of SIMD data type is necessary. There are so many wrappers/libraries for this already, and so many different requirements and nuances to be able to make a one size fits all data type. There are hundreds(thousands?) of intrinsics, how do you keep up with new ones and expose all of that functionality?

yoklov 11y ago
I don't think it's a worthless goal (it's not that bad writing different versions of the code for different processors, since it's pretty mechanical and really only done at the end, but it would be nice not to have to), but I don't really trust the C++ standards committee to do a good job of it. Thinking about SIMD in an object oriented way (e.g. the way the committee typically designs things) is just dead wrong, and will not result in any signficant performance gains relative to the scalar code. The best way to get good performance is to use each lane of the SIMD register to represent an additional element that's processed simultaneously, because otherwise you lose a lot of flexibility. E.g. instead of v1 = {x1, y1, z1, w1}, v2 = {x2, y2, z2, w2}, ... you have v1 = {x1, x2, x3, x4}, v2 = {y1, y2, y3, y4}, ... etc.
- davvid 11y ago
  I don't really trust the C++ standards committee to do a good job of it. Thinking about SIMD in an object oriented way (e.g. the way the committee typically designs things) is just dead wrong I'm curious, what makes you think that that the C++ committee would take an object-oriented approach to SIMD? Are you generally jaded on C++ (understandable, the language is by no means "simple"), or is there a specific historical precedent that suggests that it would go that way? My sense has been that Modern C++ has been leaning towards data-driven, functional-programming-influenced features. I would actually be surprised to see C++ become "more OO", whatever that means. C++ is generally a multi-paradigm language.
  - yoklov 11y ago
    Yes, I'm a bit jaded on C++, despite using it regularly. And a functional programming approach here would suffer the same issues as an object oriented approach. The issue with both is that they like to operate on the data elements one at a time, and lay out each element in memory interleaved, and this is not what you want for SIMD most of the time. Actually functional code tends to want to abstract these details from you, which defeats a lot of the point of SIMD... so I'll ignore that.

yoklov 11y ago

I don't think it's a worthless goal (it's not that bad writing different versions of the code for different processors, since it's pretty mechanical and really only done at the end, but it would be nice not to have to), but I don't really trust the C++ standards committee to do a good job of it. Thinking about SIMD in an object oriented way (e.g. the way the committee typically designs things) is just dead wrong, and will not result in any signficant performance gains relative to the scalar code. The best way to get good performance is to use each lane of the SIMD register to represent an additional element that's processed simultaneously, because otherwise you lose a lot of flexibility. E.g. instead of v1 = {x1, y1, z1, w1}, v2 = {x2, y2, z2, w2}, ... you have v1 = {x1, x2, x3, x4}, v2 = {y1, y2, y3, y4}, ... etc.

davvid 11y ago
I don't really trust the C++ standards committee to do a good job of it. Thinking about SIMD in an object oriented way (e.g. the way the committee typically designs things) is just dead wrong I'm curious, what makes you think that that the C++ committee would take an object-oriented approach to SIMD? Are you generally jaded on C++ (understandable, the language is by no means "simple"), or is there a specific historical precedent that suggests that it would go that way? My sense has been that Modern C++ has been leaning towards data-driven, functional-programming-influenced features. I would actually be surprised to see C++ become "more OO", whatever that means. C++ is generally a multi-paradigm language.
- yoklov 11y ago
  Yes, I'm a bit jaded on C++, despite using it regularly. And a functional programming approach here would suffer the same issues as an object oriented approach. The issue with both is that they like to operate on the data elements one at a time, and lay out each element in memory interleaved, and this is not what you want for SIMD most of the time. Actually functional code tends to want to abstract these details from you, which defeats a lot of the point of SIMD... so I'll ignore that.