From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-0.0 required=3.0 tests=BAYES_40 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 1 Aug 93 03:25:49 GMT
From: seas.gwu.edu!mfeldman@uunet.uu.net  (Michael Feldman)
Subject: Re: Query about monitor (passive) task optimization
Message-ID: <1993Aug1.032549.18816@seas.gwu.edu>
List-Id: <comp.lang.ada>

In article <23corr$a8g@schonberg.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) wr
ites:
>Mike assumes that automatic recognition of passive tasks is a good thing.
>He is apparently unaware that this is by no means obvious, and indeed most
>of the Ada folks in realtime areas that I have talked to do not AT ALL like
>the idea of such automatic recognition, and much prefer explicit control
>over thread structure.
Well, obviously we are in disagreement here. Somewhere I got the idea that
the purpose of high-level languages was PRECISELY to buffer the programmer
from these little implementation details and learn to have faith in the
compiler. As compilers mature they get better and better at the various
optimizations, which (should) become more and more transparent to the
programmer, who simply ends up delighted at the performance but doesn't
know or care why.

Yes, there may be some realtime guys who object to losing ANY 
control. These are the same folks who use shared variables, and indeed
probanly use a lot of global data because parameter passing is, at least
in their minds, "inefficient". I can't dispute their perceived need to
do these things; I'll stipulate that they've gotta do what they've gotta do.

What about the rest of the world? Realtime ain't all there is. Tasking is
not just a realtime structure, it's also an ABSTRACTION mechanism. Somehow
in trying to keep the realtimers happy, the rest of us got lost in the dust.

Tasking need not be nearly as "inefficient" as it is sometimes claimed
to be. I assert that we (usually) could not care less about the
order of evaluation of expressions (and if we do care we use parentheses,
etc., to second-guess the compiler). There are lots of things we usually
leave to the optimizer to sort out for us. Do we need a pragma to get
a short loop unrolled? A constant calculation pulled out of a loop?
No, that's motherhood.

I claim that tasking is (rather, should have been) in a similar category.
It's an abstraction mechanism; we use it to express concurrent algorithms,
or rather to express algorithms in a concurrent manner. That's what we
were told in the early days of tasking; some of us actually still believe
it. It's the business of the compiler writer to get everything done for
us in the most optimal way. Over time, the compilers get better and
better, and we get happier and happier because the better and better
gets more and more transparent, requiring less micro-managing from us.

If certain kinds of tasks can be implemented more efficiently, without
my having to second-guess with pragmas, so much the better. I hope
that Robert hasn't been around the real-time Establishment so long that 
he's forgotten the _rest_ of what tasking is supposed to be about.
>
>Many of us felt in the Ada 9X process that the needs for efficient 
>tasking would better be met by formalizing and structuring the opportunities
>for this kind of task optimization, but it was quite clear that the realtime
>community much prefers the explicit approach as exemplified by the protected
>type feature of 9X.

I quite agree that the 9X process has listened to the realtimers. That
is not inappropriate, but I think it may have been carried to the extreme.
Protected types are basically taking us back to monitors. Maybe they
should have been there all along. But that's only half the story. I'm afraid
that being able to satisfy their R/T customers with protected types, the
vendor folks will let themselves off the hook from really trying to
optimize tasking for the rest of us. 

I don't deny that it's important to listen to the customer. But listening
ONLY to the (current) customer deprives the compiler folks of the great
thrill of getting out front and leading, instead of following the
(government) customer all the time. Robert, it's all part of the same
mentality.
>
>I also know that Alsys found in deciding how to proceed that people in 
>general much preferred the kind of explicit pragma approach that Verdix
>uses to the kind of automatic recognition that DDC does.

I'm people. Nobody asked me. They asked their realtime customers.  They
asked mostly the guys who want to control every bit and every microsecond,
and neglected those of us who think we are paying compiler writers
to get REALLY GOOD (over time) at optimizing stuff without bothering us
with details like pragmas. I'd be less prone to kvetch about the obscene
prices if I thought our money was buying that kind of technical leadership.
>
>So, sure it's nice to see different vendors doing different things and taking
>different approaches, but Mike's "finally! at last! someone doing something
>reasonable for tasking!" approach is plainly inappropriate.
>
What the heck, I won't split hairs with you. Good people can disagree,
and we are plainly in disagreement on this. 

Mike Feldman