🚀 go-pugleaf

On 1 Nov 90 23:46:28 GMT, chased@rbbb.Eng.Sun.COM (David Chase) said:

chased> 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";

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

chased> Read your own posting, please, and note that what you quote did not
chased> say what you say it said.  "I claim I can prove" is most definitely
chased> not the same as "I have proved".

Ahem. Agreed, it is not the same. This is a bit too easy... :-)

chased> It means that the steps in optimization are based on little
chased> proofs, and sketches of proves; it doesn't mean that there is a
chased> big book proving the compiler correct.

It so easy to convince oneself that things will work...

chased> Such a book *could* be written if the need existed (the
chased> existance of dire need would be demonstrated by the exhibition
chased> of wheelbarrows full of money to finance its writing).

Point taken. However, *you* (not you personally, of course) are
proposing new untried and potentially hazardous technology. The burden
of proof in on you and your customers. If one believes without proof, in
the presence of arguments that counsel diffidence, amen.

chased> And, regarding, the tobacco industry analogy (an ad hominem analogy,
chased> too -- aren't vile insults what one uses when arguing from a weak
chased> position?),

I am sorry that it was perceived as insults and not grave humour. And
certainly it was not meant to be ad hominem. Hey, I actually like David
Chase (and Jim Giles). Good discussions, even if we do not necessaily
agree, are excellent learning exercises, as layers of assumptions and
different world views are exposed. And no doubt David Chase and Jim
Giles are people one can learn from. OK?

chased> I will suggest that you have no evidence, only anecdotes,
chased> for the alleged pervasive bugginess of optimizing compilers.

For starters I produce the general principle that a bigger and more
complicated program, unless proven otherwise, has to be presumed to be
buggier. There is a discipline called software physics, a branch of
software engineering, that collects such grim statistics.

chased> Certainly you have nothing like the evidence gathered to
chased> demonstrate a connection between tobacco and lung disease, and
chased> only hand-waving claims as to the cause-and-effect link.

There is a large body of evidence about a strong correlation between
complexity and size and bugginess (note that it seems that over a
program's lifetime the number of bugs seems to be related *only* to its
size and complexity, not to debugging effort, etc..., for a given level
of programming expertise).

chased> I *am* selling my skills, but I fail to see that there is
chased> anything pernicious about that.

Nothing wrong about that, except that your compilers do not carry the
warning "The President of ACM reminds you that aggressive optimization
may be hazardous to your program's correctness" :-). Again you have to
prove or at least argue that the well known general principle that
bigger and hairier means buggier does not apply to your aggressive
optimizers.

If you were using the same technology in source level rewriting
assistants things would be different -- the burden of ultimate
responsibility for the program logic's reliability shifts from you to
the programmer.

chased> It is also unclear that your claims about the speed/risk trade-offs
chased> are in any way connected with reality.  Speed gained for you by an
chased> optimizing compiler is speed that you don't have to work for by
chased> hand-coding (though both can be used together to get even more
chased> speed-up if that is necessary), and the time saved by the programmer
chased> is more time that can be spent debugging and testing the code.

Again, what about the alternative of unbundling the risky rewriting
logic from the compiler and putting it in a source level rewriting
assistant? This is my favourite alternative. You could have as much fun
and business (and probably more) writing a source level rewriting
assistant as an aggressive optimizer, and it would be cleaner
engineering, and probably even more effective as to results.

chased> Every programmer I know has a bug introduction rate higher than
chased> any compiler that I've ever used (but this is purely anecdotal
chased> -- perhaps it is completely different for other people, eh?  do
chased> *you* find more compiler-introduced bugs than author-introduced
chased> bugs in *your* code?), so it is in fact more reliable to let the
chased> compiler do the optimizing, even if you don't use the time saved
chased> for additional testing and debugging.

and also:

chased> I've said several of the things that I said in this article before --
chased> you might seriously consider comparing the bug-introduction rate of
chased> programmers, both skilled and ordinary, with the bug-introduction rate
chased> of several "aggressively optimizing" compilers.

Ah no, this cannot stand. The compiler does a completely different job
from the programmer -- the programmer must *invent* new code, and show
ti respects some specification, the compiler must merely translate it,
showing that the translation is done according to hopefully well defined
rules. As long as things remain like this I am happy. Unfortunately
aggressive optimization is a step away from this, because it requires an
element of invention, and using less well defined rules.

chased> You might also check to see if there are any trends in compiler
chased> bug rates over time, and see how that correlates with the
chased> optimizations performed by those compilers.  I think you'll find
chased> that your claims are not supported.

This would be an interesting exercise for supporters of aggressive
optimization. Maybe they would be able to show that the general rule is
not true for aggressive optimizers, or that the increased level of
problems is compensated by the gains in resource economy. Maybe not. I
woudl like to remind that that I have no claims -- merely skepticism
about *their* unsupported claims, and the idea that motivated skepticism
counsels caution, much caution.
--
Piercarlo "Peter" Grandi           | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk