| > You've just invited the assumption that your compiler can do SROA as the basis for better performance - how is that an abstraction? "Expands to the exact same code everywhere on every imaginable compiler, even toy compilers nobody uses" is not part of the definition of "abstraction". > If you really care about performance to the point of register occupancy, you need to look at the context. The "abstraction" of having a Point type with methods is almost certainly far from optimal, because it doesn't fit SIMD well. What do you think http://www.agner.org/optimize/#vectorclass is then? > It's then also not "good engineering practice" to use it. Yes, it is! It makes your code more readable, and if you're compiling on any production-quality C compiler anywhere your Point class will have the same performance as the raw version. Lower maintenance cost, fewer bugs, same performance. |
MSVC compiler doesn't do SROA, as far as I know.
> What do you think http://www.agner.org/optimize/#vectorclass is then?
Have you actually looked at that thing? It's not a Point struct, I can tell you that. There's nothing abstract about it.
If you want to take advantage of SIMD fully, you need to lay out your data in a very specific way. A Point {x,y,z} struct doesn't naturally fit a SIMD register.
Now, if you're willing to make a lot of assumptions on your compiler, you can do something like this: http://www.codersnotes.com/notes/maths-lib-2016/
Still, you need to put in the work and the research. No magic.
> Yes, it is! It makes your code more readable, and if you're compiling on any production-quality C compiler anywhere your Point class will have the same performance as the raw version. Lower maintenance cost, fewer bugs, same performance.
If performance really matters then your abstract solution is almost certainly suboptimal and it's not good engineering practice to use it for the sake of readability.