Re: Query about monitor (passive) task optimization

[seas.gwu.edu!mfeldman@uunet.uu.net (Michael Feldman)]

In article <1993Aug3.101131.15013@celsiustech.se> bjkae@celsiustech.se (Bjorn K
allberg) writes:
>In article <1993Aug2.174739.16569@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael
 Feldman) writes:
>
>>How does this differ from _any_ optimization? Do you want compiler-dependent
>>pragmas for every teeny little optimization? I doubt it.
>
>It is a matter of scale. Changing from a passive task to a full task
>implementation may presumably increase the time a factor of ten, and may be 
>a factor of 100, if it is a simple case with no guards etc. 
>A full rendez-vous is one of the more expensive constructs in the language.
>
Yes, it is. That is EXACTLY why the compiler writers should be exerting
more effort to detect special cases and use heuristics to cut it down.
Instead, what they are doing is asking US to specify, in compiler-
dependent detail, the special cases for them. That is a cop-out.

>On the other hand, I would be very glad to have advice from the compiler.
>"This is a passive task, if you allow me I will optimize it for you".
>
I have no problem with such an advisory. 

Indeed, another advisory would be even better: "this appears to be a hybrid 
task that is difficult to optimize. Consider doing blah-blah restructuring
to make it more efficient; if you do, it'll run 10 times faster." 

I know, in general this is an expert-system problem. So? There's LOT of human 
domain expertise to draw on. Are the vendors building this kind of smarts into 
the front-ends of their systems? If they did, it would propagate to all
their zillion validations, because these big families have common
front-ends. One would think they'd see money in that.

(They could even fund some university projects to dope out all the
issues and suggest the heuristics and rules. Students are cheap.
A programmer, loaded up with overhead, costs $100k a year or more.
Students are a whole lot cheaper. Somehow the Ada companies forgot
that. Remember the days when TeleSoft employed UCSD students?)
>
>>>By the way, are not the automatic type conversions made by some programming
>>>languages, like PL1, quite wonderful? You don't have to write a lot of
>>>silly and unneccesary stuff. 
>>
>>Different issue. These implicit conversions, which caused everyone so much
>>heartache, were part of the language design, not an implementer choice.
>>The passive-task thing is an IMPLEMENTATION-DEPENDENT PRAGMA. Or, in the
>>case of DDC-I, they just do it.
>
>Now you are talking about standardisation, i.e. similarities between '
>different compilers. From a person using just one compiler, it is similar
>enought. To trust the compiler without explicit advice, or not to trust
>the compiler. 

It's still a different issue. If anything, it was much better defined
in PL/I. The compiler always knew what it was doing, and what it was doing
conformed (assuming the compiler was not buggy) to well-defined rules in
the PL/I "LRM". (I know, I taught that junk for years!) In Ada's case,
the LRM leaves a lot PURPOSELY unspecified, hoping that programmers will
get used to the idea of an abstract structure. In fact, in the early days
of Ada compilers the vendors WOULD NOT EVEN TELL YOU IF YOU ASKED. I
remember once, some years ago, asking the lead techie at an Ada vendor
to give me a list of the context-switch points in their tasking runtime.
His answer? "That's proprietary information." That's the truth! Sheesh.
>
>>
>>My objection was to some Ada users feeling that they need to control every
>>bit and microsecond of tasking. Why don't they insist on pragmas to
>>control every expression evaluation? I suspect it's because programmers
>>understand expressions and do not understand concurrency. And when they
>>
>One of the difficulties we have found using Ada for large project is, that
>it is so easy to write code, where the source code is very compact and
>"elegant", but the generated executable is painstakingly large and in-
>efficient. This can naturally be overcome, but it needs an explicit
>effort.

That is precisely what I meant. Either there was something subtle you
weren't understanding, or the compiler was not doing what you paid it to do.
I mean no offense, but I said a day or so ago that a lot of this is
due to dumb programmers or dumb compilers or both. As a teacher, I
can help to smarten up the people. I can't help to smarten up the compilers,
though, unless the vendors really want to. And I doubt that they do.
>
>
>>
>>What Ada was supposed to be about was a common language for which the
>>validation process guaranteed most behavior. This was supposed to lead
>>to a very active and innovative compiler industry that would find lots
>>of neat ways of exploiting the language features, and lots of users
>>who would learn the features and trust their compilers.
>>
>>So did it happen that way?
>>
>No, and as the compilers are less than optimal, it is still more important
>to know what actually happens. 

Naturally. I always find myself working at two levels. The first could be
described as "here's how it ought to be"; the second could be described
as "you gotta do what you gotta do". With a _given_ compiler on a _given_
project, you often end up with the second. So do my teaching and
consulting clients. That should not prevent us from pestering the
vendors to do a better job in earning that $25k per seat.

Cheers -

Mike Feldman