[noch]

> I want one that takes however long needed to get the fastest binary.

Year after year, people keep saying this or things like it. But it's worth remembering that it is not the compiler that makes your code fast, but how you structure your data transformations that makes code fast. In 2014, Mike Acton taught us that the best compiler optimisations can only account for 1-10% of the performance optimisation problem space. "The vast majority of [performance] problems, are problems the compiler cannot reason about." https://youtu.be/rX0ItVEVjHc?t=2097

[mlindner]

Is that really true in all cases though? That's certainly true for languages like c++ and C and other compiles languages with manual memory management because the compiler can't re-order things past a memory load. That's less true I think for languages like where Rust can get to (even if they're not there yet). In Rust you can reason about memory allocations because there's guaranteed invariants in safe rust that let the compiler reason more about what the code is doing and rearrange instructions more than what would be possible in C or C++.

[noch]

> [...] because the compiler can't re-order things past a memory load.

Re-ordering of reads and writes is not really the problem either, even if we assume that one could automatically safely reorder reads and writes arbitrarily to yield significant optimisations. Fundamentally, the compiler does not know the semantics of your data and the relationships between pieces of data and the logic of their transformations. Knowledge of your specific problem and the specific data you are transforming yields the majority of the powerful optimisation opportunities. Similarly, a garbage collector doesn't know the meaning of your data or your algorithms.

> Is that really true in all cases though?

Consider: Given a set of data, if a compiler or garbage collector understood the data sufficiently, then there would be no need for you to exist to write the program, because the compiler could simply write the data transformations itself and generate the program.

However, one is encouraged to do experiments for oneself. Concrete profiling data, not abstract theory, is what matters when evaluating cost-benefit of any approach.