> Depends on the context! Interesting distinction to draw. That's a pretty good definition for high level vs low level programming languages. Vector types and

> Depends on the context! Interesting distinction to draw. That's a pretty good definition for high level vs low level programming languages. Vector types and compiler intrinsics with an eye on the generated assembly are a good way to go for high performance subroutines. If you're willing to change the compiler back end to better serve the ISA, there's a decent chance you can emit exactly the machine code you wanted from somewhat convenient source code. edit: your post at https://matklad.github.io/2023/04/09/can-you-trust-a-compiler-to-optimize-your-code.html https://matklad.github.io/2023/04/09/can-you-trust-a-compile... is great on this topic, thanks for the blog. Where I disagree is the implication that higher level languages do not need a way to write code certain that an optimisation (transform?) will fire. All the constexpr clutter from C++ is an attempt to force optimisations to happen regardless of compiler (or compiler invocation, e.g. to say you want some map thing in .rodata in -O0 debug builds). Transforms guaranteed by the language - whether vectorisation, monomorphising generics, garbage collection, constant folding - are inherently more useful things than heuristic optimisations where you hope for the best. I'm happy to see Zig is moving in that direction for memory copies and wish them good hunting with the aliasing analysis. Hinted at in a sister comment, I think a missing lever in software dev is adding guaranteed-to-fire compiler transforms in application libraries. E.g. define some regex implementation along with optimisations that act on said regex implementation. Requires a sanely extensible compiler.