🚀 go-pugleaf

In article <4467@brazos.Rice.edu> preston@titan.rice.edu (Preston Briggs) writes:

   I'd like a compiler to make code to make the computer do what I want.
   Unfortunately, it can't read minds, so I have to write a program
   to give it a hint.  Since it's so stupid, I have to be fairly 
   specific about how it's to do things like multiplying matrices.

Agreed. We are speaking of *implementation* languages.

   On the other hand, an optimizing compiling allows me to avoid
   too much tedium.

Let me be stroppy: I'd say "allows me sloppy, opaque coding".

   Strength reducers are good enough that I don't need to mess
   with pointer variables. Various forms of redundancy elimination
   are good enough that I needn't bother about every little common
   subexpression.  Vectorizers are good enough so that I need not
   manually insert vector primitives.  Register allocators are
   good enough that I need not scatter register declarations about.

About the "good enough" I am somewhat skeptical (especially about
the register allocators -- but then again, many modern machines
have more registers than variables...). Also, most of the time
these optimizations are irrelevant.

   Constant propagation is strong enough so that I can afford
   to declare some constants in convenient places, without bothering about
   folding every constant expression by hand.

This is *not* an optimization. It does not involve second
guessing the program's semantics. It is just good code
generation. Like removing redundant code, inlining, reordering
expression's operands (where allowed by language rules), etc...

   And all these optimizations work exceptionally well on the
   inner loops that consume so much time.

Not entirely true. Again, at least some armchair evidence tends
to support the idea that hand care does a lot of good. And the
inner loops are rare enough you can devote your attention to them.

   The optimizer is written once, by the compiler writer.
   I, on the other hand, write many programs and I'm able to
   take advantage of the optimizer in all my programs.

This argument remains true for good code generation, and the
machine independent programming it affords. It is even true for
SQL query optimizers, most of the time, and they do *very* high
level planning and strategies; but not always. Even with SQL (or
similar things) you have to do hand optimization in critical
cases.

   It costs compile time, but it's cheaper to use the computer
   to optimize my code than to do it by hand.

It encourages less precise coding, and makes the compiler many
times larger, and these are *very* bad news, and very costly too.
All this to optimize very little pieces of code, which could be
manually sorted out, and with improvement on their information
content for both humans and programs that read them.
--
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk