C is hard to optimise. Graydon Hoare gave a nice introductory compilers talk that went into some of the reasons why

http://venge.net/graydon/talks/CompilerTalk-2019.pdf

One well known obstacle to optimizing C is the difficulty of alias analysis. It's easier to do that for languages that don't have C's unrestricted pointers.

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)

C is very "pointer heavy", and much code involves chasing linked lists and the like. This tends not to suit VLIW well.

Modern languages like Rust tend to produce more instructions for the same high-level logic, but those instructions are easier to schedule for superscalar CPUs. It typically ends up as a bit of a wash on CISC processors, but could be better than C/C++ on VLIW.

I guess we'll never know now...

C is pointer heavy if you write pointer heavy code

> What types of languages do you see would enable more efficient VLIW compilers?

I was thinking of languages where dependencies are more explicit and the idea of a global evaluation order isn't there in the first place. I'd be very interested to see a reduceron-style effort that implemented graph-reduction evaluation on a VLIW processor.

> Somehow I suspect the limited uptake of better suited languages to be a sign that they aren't very helpful most of the time, and most of the parallel operations people do is more like serving a lot of individually sequential transactions per second, which is something C and unix is pretty good at.

Heh, that was the idea that those barrel-processor SPARCs were designed around. But they weren't so successful in the market either in the end.

The TMS320C6678 (C66x architecture) DSPs still use VLIW and work pretty well. Like most DSPs, they're typically programmed using C, for which TI supplies optimised libraries for processor-intensive operations. IIRC, the compiler itself was fairly standard.