🚀 go-pugleaf

pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
>chased> The compiler-writer's claim is "I can prove that these
>chased> optimizations conform to the standard";

>STOP THE PRESSES! Compiler writer proves that he can do program
>rewriting in a bug free way! Program synthethizers must be round the
>corner! Major software companies stocks collapse!

Read your own posting, please, and note that what you quote did not
say what you say it said.  "I claim I can prove" is most definitely
not the same as "I have proved".  It means that the steps in
optimization are based on little proofs, and sketches of proves; it
doesn't mean that there is a big book proving the compiler correct.
Such a book *could* be written if the need existed (the existance of
dire need would be demonstrated by the exhibition of wheelbarrows full
of money to finance its writing).

Note, too, that I never claimed that the optimizations performed,
however aggressive, are anywhere near general-purpose program
rewriting or program synthesis.  I have claimed, and will continue to
claim, that what transformations are performed are based on a carefully
worked-out understanding of certain program transformations.

Regarding the virtual-machine-to-physical-machine mapping, if the
standard only specifies that we must reproduce the I/O and approximate
resource consumption of the virtual machine, then that's what we'll do
if it makes the code faster.  Where does it say that we should not do
this?

And, regarding, the tobacco industry analogy (an ad hominem analogy,
too -- aren't vile insults what one uses when arguing from a weak
position?), I will suggest that you have no evidence, only anecdotes,
for the alleged pervasive bugginess of optimizing compilers.
Certainly you have nothing like the evidence gathered to demonstrate a
connection between tobacco and lung disease, and only hand-waving
claims as to the cause-and-effect link.  I *am* selling my skills, but
I fail to see that there is anything pernicious about that.

I think it is also true that new compilers will be both more
aggressive and less buggy; if nothing else, the test suites only grow
larger and more comprehensive, and faster, cheaper machines allow more
tests to be run in a given amount of time, and wished-for and formerly
ad-hoc optimizations are being backed up by better theory.  The need
for better compilers will also increase with time as clock rates and
potential parallelism increase (both of these things pound harder on
memory, and increase the gains of good register allocation and
locality-enhancing transformations).

It is also unclear that your claims about the speed/risk trade-offs
are in any way connected with reality.  Speed gained for you by an
optimizing compiler is speed that you don't have to work for by
hand-coding (though both can be used together to get even more
speed-up if that is necessary), and the time saved by the programmer
is more time that can be spent debugging and testing the code.  Every
programmer I know has a bug introduction rate higher than any compiler
that I've ever used (but this is purely anecdotal -- perhaps it is
completely different for other people, eh?  do *you* find more
compiler-introduced bugs than author-introduced bugs in *your* code?),
so it is in fact more reliable to let the compiler do the optimizing,
even if you don't use the time saved for additional testing and
debugging.

Now, I will grant one important thing, which I think is also important
to you -- if I had garbage collection, I would be a more productive
programmer.  Garbage collection is available for "C", but it is
potentially broken by optimizing compiler for C, which means that one
powerful productivity and bug-avoiding aid is unavailable if you
optimize.  However, no specification for C anywhere in existence
guarantees that a garbage collector should be able to function, and
most programmers do not take advantage of garbage collectors, and some
programmers write (perfectly legal) code that is guaranteed to break a
collector at any level of optimization.  It pains me that this is the
case, but it is so, and if it increases the SPECmark to break a
non-standard piece of code, even a useful one, that piece of code will
be broken.  There's always Lisp, ML, Eiffel, Russell, Modula-3, and
Miranda.

I've said several of the things that I said in this article before --
you might seriously consider comparing the bug-introduction rate of
programmers, both skilled and ordinary, with the bug-introduction rate
of several "aggressively optimizing" compilers.  You might also check
to see if there are any trends in compiler bug rates over time, and
see how that correlates with the optimizations performed by those
compilers.  I think you'll find that your claims are not supported.

David Chase
Sun Microsystems, Inc.