The paper Why Programmer-specified Aliasing is a Bad Idea[0] evaluated the effectiveness of restrict in 2004. They found that adding optimal restrict annotations provided only a minor performance improvement, on average less than 1% across the SPEC2000 benchmarks.
How much of this is because nobody puts effort into these optimizations?
The Rust compiler has repeatedly found critical bugs in LLVM's restrict / noalias support, bugs that would impact C / C++ as well if any real-world C / C++ programs actually used it.
If compilers produce straight-up broken code in these situations, I can only imagine they're not putting a lot of effort into these optimization strategies.
> How much of this is because nobody puts effort into these optimizations?
restrict is rare in C and C++ but common in Fortran; array parameters in Fortran aren't allowed to alias. Intel and IBM both have great Fortran compilers so I would expect their C and C++ compilers to have good support for restrict.
What? I use it whenever I have a function that takes two or more pointers if I know they can't refer to overlapping memory. And it's part of the signature for memcpy since C99
When he said "anyone" he meant "almost anyone". You're an outlier if you use `restrict` regularly.
I checked on grep.app, there are 10k results for `restrict` for C code, compared to 700k for `struct` (I know they're not directly comparable but that gives an idea.
That seems like about the right proportion to me - struct solves a much more common problem than restrict does. And to be fair, it is a lesser known feature. But user-the-name is implying that restrict is somehow difficult to use or understand, which I don't agree with at all.
