Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #3775

the death of optimization compiler

Cross-posted to 2 groups.

Show key headers only | View raw

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]

Back to comp.compilers | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

the death of optimization compiler Anton Antimo <anton@safunu.org> - 2026-10-12 18:17 -0300
  Re: the death of optimization compiler anton@mips.complang.tuwien.ac.at - 2026-10-16 10:41 +0000
    Re: the death of optimization compiler tfb <tfb@work.it.out> - 2026-10-16 17:52 +0000
    Re: the death of optimization compiler Stefan Monnier <monnier@iro.umontreal.ca> - 2026-10-16 18:52 -0400
      Re: the death of optimization compiler Derek M Jones <derek@knosof.co.uk> - 2026-10-17 20:42 +0100
    Re: the death of optimization compiler Stefan Monnier <monnier@iro.umontreal.ca> - 2026-10-16 18:47 -0400

csiph-web