I haven't designed any CPUs myself, someone with more experience could give you more details.

But I don't think this carries much weight anymore, might have been true way back in the days.

C gives you more control, which means it's possible to go faster if you know exactly what you're doing.

Definitely not true. One look at what a modern C compiler does to optimize the code you give it will disabuse you of that notion.

There's nothing special or magic about C code, and, if anything, C has moved further and further away from its "portable assembler" moniker over time. And compilers can emit very similar machine instructions for the same type of algorithm regardless of whether you're writing C, Rust, Go, Zig, etc.

Consider, for example, that clang/LLVM doesn't even really compile C. The C is first translated into LLVM's IR, which is then used to emit machine instructions.

It sort of is and isn't true. CPUs are designed to make certain programming models work very well, and they've done so at the costs of making other kinds of programming paradigms work well (as compared to, say, a GPU, which wants a programming model for which C and C-like languages are clearly ill-fitting). So it's not a wrong statement if you think of it as "designed for C-like languages."

But if you're using it in the sense of "C is a privileged language in terms of its connection to hardware architecture, " well, C isn't, and that statement is patently false. There's not a major difference between C, C++, Rust, Zig--even going as far afield as bytecode languages like Java and C#, or fully interpreted stuff like Python or Perl, especially as far as computer architects are concerned.

(And in the sense of "this is the language that architects care most about for tuning performance," I think that's actually C++, simply because that tends to be the language for the proprietary HPC software that pays the big bucks for compiler support.)

I don't think that's true. They've co-evolved, but C simply does less.

I've never seen a good way to make a CPU that's good for "not C" languages. Those are usually by people who are aggressively uninterested in being fast and so insist on semantics that simply wouldn't get faster if done in hardware. Like the way most Haskell programs execute is just bad and based on bad ideas.

But in both cases, modern CPUs are mostly network- then I/O- then memory-bound. Most C programs aren't written to respect that very well.