Doesn't the restrict keyword solve this?

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.

[0] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.94....

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.

I don't think anyone has ever used the restrict keyword, or understood what it does.

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.

That probably explains it. In many shops, C may as well have stopped at C89.

I've been working with C since the early 90's. I've never seen any code use restrict.

Also large chunks of libc use it as well, e.g. the printf family of functions.

derp.

So Rust comes to mind, right? Anything else?

FORTRAN or any language with lots of arrays and matrices.

I suspect if you want a HW architecture for running array operations you'll end up with something like a vector machine (e.g. ARM SVE(2) ) or a GPU rather than a VLIW CPU?

VLIW is basically a more flexible kind of vector machine.

And a traditional scalar architecture is more flexible still. The trick is to pick the correct set of tradeoffs for the targeted applications. I claim that for most array style workloads vector/GPU architectures are flexible enough, and offer better perf/watt and perf/chip area.

So, APL?

Absolutely yes that would make sense (or more likely the modern "derivatives" like J & K)