Re: Query about monitor (passive) task optimization

[slinky.cs.nyu.edu!slinky.cs.nyu.edu!nobody@nyu.edu (Robert Dewar)]

Mike certainly seems to be in ranting an raving mode again ("Beltway
bandit mentality") etc.

I think his comments betray a real lack of familiarity with the reality of
production compilers. Elaborate optimizations are almost always a mistake.
They don't pay off in real life nearly as much as people hope, and they
tend to make compilers very expensive to produce, very expensive to maintain
and unreliable.

The maintenance issue in particular is important. A typical situation is that
a complex optimization is installed. It works on all the test programs, and
works well for a while, then a customer discovers a bug where the optimizer
screws up [I don't suppose anyone reading this newsgroup has *ever* had
such an experience :-) ]

The maintenance required is a complete reanalysis of the optimization
algorithms to fix the problems arising presumably from some bad analysis
in the first place. In practice maintenance people are not capable of this,
and the easy maintenance fix is simply to disconnect the optimization. Fran
Allen, of IBM, once said in a talk I heard (I don't know if this is in print)
that nearly half of the optimizations in the IBM optimizating PL1 compiler
were disconnected during the maintenance process.

Certainly one might criticize the Ada vendors and second guess how they
had spent their money (Mike you might want to talk to one of the many
investors who lost their money and tell them that you are irritated that
Ada compiler companies have never invested money up front to try to make
money!) However, it is clear to me that if Mike directed the spending of
such money he would manage to blow it much faster.

You want to know where I would spend money: bindings, bindings, and then
if any was left over, bindings.


	Robert