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=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 3 Aug 93 10:11:31 GMT
From: pipex!sunic!celsiustech.se!bjkae@uunet.uu.net  (Bjorn Kallberg)
Subject: Re: Query about monitor (passive) task optimization
Message-ID: <1993Aug3.101131.15013@celsiustech.se>
List-Id: <comp.lang.ada>

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.

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".


>>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. 

>
>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.


>
>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. 

>Mike Feldman

bj|rn K{llberg