Sometimes. Other times you write inneficient C because it makes the code simpler.

The greatest value brought by compiler optimisations is removing the overhead of convenience. Sometimes that is about avoiding the boxing that is a necessity in many high level languages, but in other cases it serves to allow a more modular programming style without overhead. Stream fusion is a good example: it lets you structure your program as small and composable units, without the cost of manifesting intermediate results. That is not merely about avoiding the inherent inefficiency of e.g. Haskell, but about permitting different styles of programming, and the argument is that a low level language simply cannot allow such a style (without overhead), because the required optimisations are not practical to implement.

you can imagine a version of Haskell that doesn’t have polymorphism or laziness, that only has unboxed integers, and as a result doesn’t need a GC. in such a language it’s still easy for the compiler to do stream fusion; whereas it’s still hard in C because the compiler needs to prove the loop doesn’t have side effects.

Is there any work trying to apply transformers to compiler optimization? Seems like we have some new tools to potentially make compilers even better.

But yes, humans can still usually optimize better.

The other thing you see with high level languages is a death by a thousand cuts due to things like cache locality or instruction level parallelism. It’s very, very hard to write a VM with stuff going on like JIT and GC and a heap allocator that gives you good locality or ILP. A major problem is that yes you can optimize for that, including in real time, but that not only adds work but adds work that implies a cache flush.

The latter point — cache locality and ILP — is why some C/C++/Rust code is faster when compiled optimizing for space instead of for “speed.” Less code means it fits in cache.

All that being said, HLLs usually offer superior programmer productivity, especially for novice to mid career devs who aren’t quite up to things like comprehending the Rust borrow checker. Machine time has to be weighed against human time. The latter is usually more expensive (but not always at scale!).

when’s the last time you wrote a parallel array traversal in C?

also, consider reading the linked post about how assembly instructions are no longer a good approximation of how your computer works: https://queue.acm.org/detail.cfm?id=3212479. in general, writing in a language that is not close to the hardware allows the compiler to adapt when the hardware changes; for example futhark has the ability to execute using either SIMD or GPUs precisely because it’s not over-determined by the source language. C ties processors to the model of the PDP-11, which hasn’t been manufactured for 30 years.