Path: csiph.com!weretis.net!feeder9.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Anton Antimo Newsgroups: comp.compilers,comp.lang.lisp Subject: the death of optimization compiler Date: Mon, 12 Oct 2026 18:17:18 -0300 Organization: Compilers Central Sender: johnl%iecc.com Approved: comp.compilers@iecc.com Message-ID: <26-10-010@comp.compilers> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="4388"; mail-complaints-to="abuse@iecc.com" Keywords: optimize, Lisp, comment Posted-Date: 15 Oct 2026 23:56:38 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:3775 comp.lang.lisp:61744 I recalled this lecture and these quotes recently when I was looking at the syntax of the Rust programming language, seeing how the programmer is to supposed to tell the compiler what is mutable so that the compiler can in turn handle memory management. I'm not particularly interested in memory management, but it seems to be an illustration of how programmer teams up with machine to solve problems---and how the Lisp language seems to be a great fit for the job (for the reasons expressed by Knuth in the quote at end of this post). So I'm choosing comp.lang.lisp as the follow-up-to newsgroups because I think this post is more about Lisp than compilers. But the quotes here might get the interest of comp.compilers in particular because it's been many years now and people might want to discuss what has changed, if anything. --8<-------------------------------------------------------->8--- Daniel J. Bernstein in 2015: Wikipedia: --- ``By the late 1990s for even performance sensitive code, optimizing compilers exceeded the performance of human experts.'' Bernstein: --- ``The experts disagree, and hold the speed records.'' Mike Pall, LuaJIT author in 2011: --- ``If you write an interpreter, [...] [t]here’s just no way you can reasonably expect even the most advanced C compilers to [optimize it] on your behalf.'' Source: ``The death of optimizing compilers'', Daniel J. Bernstein, University of Illinois at Chicago, Technische Universiteit Eindhoven, lecture from April 16th, 2015. --8<-------------------------------------------------------->8--- In 1974, Donald Knuth had already remarked: --8<-------------------------------------------------------->8--- For 15 years or so I have been trying to think of how to write a compiler that really produces top quality code. For example, most of the MIX programs in my books are considerably more efficient than any of today’s most visionary compiling schemes would be able to produce. [...] We [...] always [ran] up against the same problem: the compiler needs to be in a dialog with the programmer; it needs to know properties of the data, and whether certain cases can arise, etc. For some reason we all (especially me) had a mental block about optimization, namely that we always regarded it as a behind-the- scenes activity, [...] which the programmer isn’t supposed to know. This veil was first lifted from my eyes in [...] 1973, when I ran across a remark by Hoare [...] 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? A program-manipulation system is obviously what we’ve been leading up to, and I wonder why I never thought of it before. Of course, the idea isn’t original with me; when I told Hoare, he said, “Exactly!” and referred me to a recent work by Darlington and Burstall [...] which describes a system which removes some recursions from a LISP-like language (curiously, without introducing any [go-to]’s) [...]. Since LISP programs are easily manipulated as LISP [...] objects, there has also been a rather extensive development of similar ideas in this domain, notably by Warren Teitelman [...]. The time is clearly ripe for program-manipulation systems, and a great deal of further work suggests itself. Source: ``Structured programming with go to statements,'' Donald E. Knuth, ACM Computing Surveys (CSUR) 6.4 (1974): 261--301. --8<-------------------------------------------------------->8--- It seems to me that telling the compiler what is mutable is a clear illustration of how a compiler is in dialog with the programmer, just like declaring a variable's type, with the C ``register'' keyword as another example. And Common Lisp with its declare-optimize-speed directives right at the place where the programmer wishes for compiler help seems to be another illustration of what Knuth is talking about in his paper. So it seems that Knuth and Hoare were indeed insightful in the 70s. And it's mysterious to me how people always implement a new syntax for their language when the Lisp syntax is so suitable for program manipulation as Knuth mentioned. My hypothesis is that syntax turns out to be easily implemented, so people always try to leave their mark by inventing a new one. Clojure, for example, is a great example of how sophisticated Java could have been since its inception. But I guess Lisp's syntax is not considered pedestrian, right? [I left this in both groups since it seems an interesting compiler question. -John]