🚀 go-pugleaf

On 6 Nov 90 01:21:12 GMT, chased@rbbb.Eng.Sun.COM (David Chase) said:

chased> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:

pcg> Point taken. However, *you* (not you personally, of course) are
pcg> proposing new untried and potentially hazardous technology. The
pcg> burden of proof in on you and your customers.

chased> I don't think that the technology is as new or untried as you
chased> seem to think.

Well some of it is. All the parts where one is trying to do serious
program rewriting are akin to program synthesis, which is still way from
anything I would depend on. Also, the point is that it is not
*necessary*; it is only used for cost/benefit reasons. It remains to be
shown that the costs are greater than the benefits. Jim Giles says that
any optimizer that is not bug free is _broken_, and thus (I guess from
his tone) irrelevant to our discussion. He therefore dismisses a large
part of the cost side of the equation, which is a bit too easy.

chased> The set of optimizations that one hopes a modern compiler would
chased> perform [ ... have been with us for a long time and thus ... ]
chased> are no more "potentially hazardous" than scanning and parsing.

Ahem. Scanning and parsing are usually context-free, they do not involve
any interpretation of the input (semantics), their algebras are very
well understood indeed and fairly simple, etc... -- I would grant though
that code generation is approaching the level of confidence of parsing
and scanning (thanks to the works of people trying to automate as much
of it as possible), but even that is subject to doubt.

But I concede that many of the optimizations that you mention are indeed
'traditional'; given sufficiently large amounts of time, talent and
effort they could be performed reliably inside a code generator.

But then my second level of argument is triggered -- they may have
become cost-effective for the user (visible performance gain, small
reliability loss), but is it true that investing in an aggressive
optimizer is the best way to achieve that user level cost-effectiveness?

Better training may give greater and longer lasting benefits, using
higher level languages may give greater and longer lasting benefits,
source level programmer's assistant may give greater and longer lasting
benefits. All such technologies are tested and proven (except for
programmer's assistants, unfortunately).

Better training and use of higher level languages do not apply to the
"dusty deck" and "dusty programmer" problems, admittedly, so there
aggressive optimization may be justified, but even then there is some
reason to think that programmer's assistants and source rewriting may be
preferable to aggressive optimization, and mor eresearch on that may pay
off better than more research on aggressive optimization.

pcg> For starters I produce the general principle that a bigger and more
pcg> complicated program, unless proven otherwise, has to be presumed to be
pcg> buggier.

chased> Agreed, generally true.  A quick glance around the programs that
chased> I run every day reveals that the (text of the) optimizer (for C,
chased> Fortran, Pascal, and Modula-2) is smaller (often by an order of
chased> magnitude) than vmunix, gnuemacs, dbx, cfront, and several
chased> language front ends.

But these comparisons are not that meaningful! Bugs in the editor and in
the debugger are not as dangerous as those in the compiler. Bugs in the
OS are almost as dangerous though. Also, a lot of these programs is
relatively trivial and unimportant -- almost all of an aggressive
optimizer is critical.

Not every type of program has the same bug intensity -- scanners and
parser can be reasonably expected to have much less bug intensity than
optimizers, and whatever they intrinsic complexity they are in any case
*necessary*. An optimizer is not *necessary*; especially not an
aggressive optimizer, give that there are alternatives. A code
generator, a parser and a scanner and symbol table management are
necessary.

The argument is not, I repeat here for the millionth time, that
optimizers are useless or infinitely buggy or otherwise that if they are
perfect using them is a no loss situation -- it is that, since they are
not necessary, and they are very critical, they must be *proven* to add
more value (performance) than they subtract (*extra*, avoidable bugs),
and that their effect is not best achieved by other means.

chased> So, should I worry more about bugs in the front ends, bugs in
chased> the editor, bugs in the OS, bugs in the debugger, or bugs in the
chased> optimizer?

You should worry a lot about them too! I am no less unhappy about the
size of vmunix, GNU Emacs, gdb and so on than about the size of gcc and
cfront and accomplices. Indeed I am consistent in other newgroups in
complaining about the large increases in complexity and unreliability,
with little gain in performance (or loss of it) or in functionality,
that these programs give, and offering examples of equivalent technology
that is better designed and provides the same benefits at lower cost.
RISC software!

chased> Although, if people cared that much more about reliability than
chased> they do about speed, I think we'd see a lot more people
chased> programming in languages other than Fortran, C, and C++.  Of
chased> course, that's another discussion, but it probably gives some
chased> indication of what people expect from their compilers (besides
chased> perfection, of course).

Let's be temporarily diverted to that other, sociological discussion:

If they cared about speed almost all programmers would be much better
off if they used a higher level language and left code generation to the
compiler, or to a programmer's assistant, or to the authors of a
library.  What instead they expect is to write poor code themselves and
have a magic optimizer substitute it with the better code that a higher
level language would have more economically and reliably translated
into.

To get back to the admittedly exxagerated tobacco industry analogy -- if
smokers cared about their health, they would be eating carrots instead,
but they don't.  This is maybe a good reason to be a cigarette
manufacturer (there is a market demand) but maybe not a good reason to
say that if people don't care about a problem it is irrelevant.
--
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