Future Directions for Optimizing Compilers
While the suggestions are definitely interesting, and the fact that compilation times are given proper attention is positive, it does seem to me that this is still pushing in the wrong direction, overall, of fully automatic optimization.<p>We now have machines that are fast enough for many&#x2F;most activities, as evidenced by production code that&#x27;s written in Ruby, Python, JS, etc.  For these we don&#x27;t really need optimizations.<p>On the other hand, performance critical routines tend to require human attention, and for these the approach of having the optimizations fully automated is generally less than helpful.<p>As Knuth put it, in 1974 nonetheless:<p>&quot;For some reason we all (especially me) had a mental block about optimization, namely that we always regarded it a behind-the-scenes activity, to be done in the machine language, which the programmer isn’t supposed to know. This veil was first lifted from my eyes in the Fall of 1973. when I ran across a remark by Hoare [42] that, ideally, a language should be designed so that an optimizing compiler can describe its optimizations in the source language. Of course! Why hadn’t I ever thought of it?<p>Once we have a suitable language, we will be able to have what seems to be emerging as the programming system of the future: an interactive program-manipulation system ...&quot;   -- <a href="http:&#x2F;&#x2F;www.cs.sjsu.edu&#x2F;~mak&#x2F;CS185C&#x2F;KnuthStructuredProgrammingGoTo.pdf" rel="nofollow">http:&#x2F;&#x2F;www.cs.sjsu.edu&#x2F;~mak&#x2F;CS185C&#x2F;KnuthStructuredProgrammin...</a><p>So let&#x27;s have systems&#x2F;languages that allow us to express performance constraints and performance-oriented transformations, and let the compiler&#x2F;language assist us in doing this.