| > MSVC compiler doesn't do SROA, as far as I know. Yes, it has since at least 2010 (and probably earlier). See "scalar replacement": https://blogs.msdn.microsoft.com/vcblog/2009/11/02/visual-c-... > Have you actually looked at that thing? It's not a Point struct, I can tell you that. There's nothing abstract about it. The Vec classes can be used as Point structs. > 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. So pad it out to 4 fields, using homogeneous coordinates. > 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/ That's not making a lot of assumptions about your compiler. The x87 floating point stack, for example, has been obsolete for a long time. > 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. I disagree. Let's look at actual examples. "Almost certainly" suboptimal abstractions are not what we've seen in Rust, for example, which leans on abstractions heavily. |
See my reply to whitequark_, this seems to be loop-specific.
> The Vec classes can be used as Point structs.
Oh, sure. Which one though? How do I abstract this, again?
> So pad it out to 4 fields, using homogeneous coordinates.
In other words, "do something else than what I originally did" and "potentially leave 25% throughput on the table".
I think you're trying to pull a fast one on me.
> That's not making a lot of assumptions about your compiler. The x87 floating point stack, for example, has been obsolete for a long time.
Did you even read beyond the first paragraphs? There's five compiler-specific flags you'll have to get right for any of this to work.
Again, there's no free lunch...
> I disagree. Let's look at actual examples. "Almost certainly" suboptimal abstractions are not what we've seen in Rust, for example, which leans on abstractions heavily.
Could you just scroll up for a moment? We are talking about this because someone wrote the "abstract" version of squaring a number and some optimization didn't kick in, resulting in significantly degraded performance. And that's a trivial example! In a real codebase, you'll have to carefully audit compiler output to see if it does the right thing, potentially requiring you to rewrite code. For Rust, you also have the blessing that there is only one compiler...