On sufficiently smart compilers

&gt; Unreliable optimizations and performance-critical software<p>This is why we will not have, and should not want, a &quot;sufficiently smart compiler,&quot; but instead a &quot;sufficiently predictable compiler.&quot; If the compiler is an enormously complex inference system, then tiny language-level changes can result in huge performance changes (see &quot;space leaks&quot; in Haskell, or &quot;auto-vectorization&quot; in basically anything). The solution isn&#x27;t adding more knobs to the compiler; it&#x27;s adding easier inter-language communication. Scripting languages like Matlab, Perl, Python, and R have been doing this right for decades: make a good effort at a specific domain (math, text, statistics), and make it easy to call into lower-level code for the key pieces.

Compiler optimizations as part of libraries is definitely something I would like to see more languages explore. I think this is something that could fit quite well into Rust, actually, with its philosophy of allowing compiler plugins.<p>A simple example: Most high-level array implementations have a <i>reserve</i> method that allows you to specify the expected number of items added to the array. This allows allocating all required memory up front and hence avoids re-allocs and the associated copies.<p>In many cases, it would be trivial for a compiler to automatically determine the size of the array and add a reserve call automatically (because the entries are added in a loop with an easily-determined iteration count). Yet compilers cannot be allowed to do that, because doing so changes the visible behaviour of the program.<p>However, <i>the library in which the array is implemented</i> is free to define the semantics of the array. So that library could provide some hint to the compiler, in essence a library-provided optimization pass, which allows such reserve calls to be added automatically.<p>I&#x27;m not saying that coming up with a good DSL to describe such optimization is easy, but it may well be worthwhile in the long run.

Tools already exist for doing run time traces of compiled programs and then optimizing accordingly. A lot of what they focus on is improving locality, moving portions of the executable that are run together near each other so improve the instruction cache hit rate. They also much more aggressively inline, to the point that the overall code size increases but hopefully so does performance.<p>You actually get a huge amount of perf gains just from improving locality, a lot of in-depth optimizations are possible but I am not sure what compilers now days actually do, it has been a long time since I worked on a compiler team!

I&#x27;d like to see projects that can integrate the runtime information provided by a JIT VM. What if such a project used this information from the start? Then, the programmers might be able to use information like: This variable has only ever had an int in it, ever, over the entire lifetime of the app.<p>Such information might be problematic to integrate into a legacy project, but in a language which allowed for optional type annotation, such information could be fed into programmer tools and more easily analyzed. (Example: So, this code here where it&#x27;s not an int -- do we really need to have this, or could we move the error checking elsewhere, so we can just say that&#x27;s an int?)

It seems like errors in the rewrite rules themselves would potentially create very hard-to-debug problems with the runtime code.