Re: Query about monitor (passive) task optimization

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

First of all, Mike says that "we are in disagreement". If we means Robert and
Mike, then he is reading my original message carelessly, since nowhere in that
message did I express my opinion on the matter -- I merely reported the
empirical fact that a substantial number of real-time people object to
automatic recognition of passive tasks.

Well disagreeing with that would say you did not believe this was the case,
but the rest of Mike's message makes it clear that he does recognize this
(although he doesn't like it).

Now, what do I think about this? Well I don't really see a huge market for
optimized tasking that is not under control of the user. Mike says he want
s this factility, but I have trouble believing this, because I doubt he has
applications where this kind of optimization is important. Instead I would
guess he is speaking not for himself, but for a constituency that he imagines
exists. This consituency is not the hard real-time folks [Mike it isn't just
some psychological glitch that makes these people want to control thinks, they
have to have close control if they are to ensure that deadlines are met etc.]

Does this constituency in fact exist? Well I doubt it is significant. Most
people either don't care very much about efficiency of tasking or they care
very much. If you care very much, then you just can't afford to leave it to
some unknown algorithm in the compiler for passive tasking optimization, 
resulting in a situation where you have no idea whether a task you write
represents a real thread of control with its attendant overhead or not.

Mike speaks glibly of improving compiler technology, but the trouble with
optimizations of this kind is that the only technology that is in sight is
the ability to recognize certain special cases. Either these cases are
extremelye easy to describe and program or they are not. If they are, then
you at least want compiler support to make sure that you do not stray outside
the recognized idioms, and you might as well have a pragma for this purpose.
Otherwise you get a situation where a small maintenance change breaks the
optimization pattern, and suddenly there is a big non-linear response in the
performance of the program. If on the other hand the description of what cases
can be optimized is complex (as is likely to be the case, because the compiler
typically will be operating at that stage on a tree that has been subjected
to a series of hard to specify and describe transformations), then you are
in really deep water, since no one can tell what is going on.

A similar sort of situation arises in transformational programming in general.
Should a compiler try major transformations on its own (e.g. replacing a 
simple high level statement of a sort with a complex algorithmn such as
heap sort, or do recursion rearrangement to reduce space usage to linear
instead of exponential?) Well of course such transformations are of course
possible automaticaly in a limited set of circumstances, but you tend to get
a very difficult to use system if you try to do things automatically.

In short, I think it is probably a bad idea to put too much effort into this
kind of optimization. Believe me, there are *plenty* of opportunities for
more straightforward optimization that have by no means been fully exploited.
As a result I think it would be a bad idea for vendors to put much effort
in this area.

One more thing. As we well know, Mike is on the lookout for cheap compilers
for educational use, which is fair enough, but he cannot at the same time
expect to influence the commercial vendors in terms of what optimizations
they might offer. If indeed the constituency that he imagines exists, it
would presumably have resources to encourage the vendors to move in this
direction. The fact that vendors have not heard people clamoring for this
kind of support I think legitimately indicates that this constuency does
not in fact exist. 

The facile belief that compilers can do amazing optimizations is often
heard. Indeed I think the original Ada design was in some cases badly
influenced by this belief (why for instance is there no proper control
over storage management in Ada 83 -- at least part of the answer is that
some people thought that compilers would be able to do an amazing job
of implementing garbage collectors and special storage management
optimizations. Well ten years ago I would have said this was an unrealistic
expectation. Ten years later my opinion is not changed one iota, since
there has been essentially no advance in compiler optimization technology
(of a relevant kind) in this time.

	Robert
	Robert
	Robert   tt