

Red Hat at the ISO C++ Standards Meeting: Parallelism and Concurrency - anand-s
https://developerblog.redhat.com/2015/06/16/red-hat-at-the-iso-c-standards-meeting-may-2015-parallelism-and-concurrency/

======
stagger87
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
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
_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
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.

