Hacker News Reader

Comment by gumby | Hacker News Reader

> It is crazy sometimes how you try to program something the best you ever could with classical C++, and then someone comes along and makes a version using SIMD that is over 10x faster (but less portable code).

But that’s one of the points of a systems programming language (of which C++ is one) — it tries to be portably as efficient as possible but makes it easy to do target-specific programming when required.

> I really wish compilers were better at auto vectorization

FORTRAN compilers sure are, since aliasing is not allowed. C++ is kneecapped by following C’s memory model.

View on HN

But why is C++ refusing to add "restrict" to its spec? C has restrict in its spec, C++ has not. Of course compilers inherit restrict from C, but it's not super portable due to C++ not officially supporting it. But why?!

In or out of the spec doesn't really matter. You can use __restrict__ in C++ and any compiler will diligently accept it, if not for the occasional warning.

The larger issue is that C and C++ have convoluted aliasing rules which makes reasoning and flagging non-aliased regions hard. The most innocent of cast can break strict aliasing rules and send you in horrible debugging scenarios. The sad side effect being people adding -fno-strict-aliasing to -O2/3.

I was wondering the same! I just recently came across the restrict keyword (thanks to someone mentioning it on HN) but I have never seen it being mentioned before, even though I was looking into all sorts of optimizations (also ChatGPT would never bring it up on its own).

Since with templating everything seems to be going header only anyways, I feel like we should give the compiler more power to reason about the memory layout, even through multiple levels of function invocation/inlining.

I wrote some library where basically all shapes can be infered at compile-time (through templates) but the compiler only rarely seems to take advantage of this.

It's not just aliasing. gcc is quite bad at autovectorising in general, clang is much better.

Here's a trivial algorithm that gcc borks over because 'bool' is used instead of 'int', even fixing that the codegen isn't great:

https://godbolt.org/z/hf7szo78E

Really good example.

It also sucks that you have no way of knowing at build time whether autovectorisation succeeded. Even if you have it working initially it can silently break and you don't know where. So using clang, you're careful and you check the generated code and everything is great, then later it isn't and you have to go hunting to find out why.

Fortran compilers can assume that (many) dummy arguments to a particular procedure reference do not alias each other, true. But there are many other ways in which aliasing can happen in a conforming Fortran program.

Reply on news.ycombinator.com