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 20:10:03 GMT
From: seas.gwu.edu!mfeldman@uunet.uu.net  (Michael Feldman)
Subject: Re: Query about monitor (passive) task optimization
Message-ID: <1993Aug3.201003.448@seas.gwu.edu>
List-Id: <comp.lang.ada>

In article <CB6w8I.9xt@ddciiny.UUCP> jls@ddciiny.UUCP (Jonathan Schilling) writ
es:
>In article <1993Aug2.181750.19343@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael
 Feldman) writes:
>>
>> [discussion of compiler optimization and performance traps in Ada]
>>
>>And this will ALWAYS be true of high-level languages and optimization.
>>If you've gotta control every bit, write it in assembler. If you're
>>writing it in a HLL, these things will bite you now and then. Yep.
>>That's life.
>
>Yes.  It should be pointed out that Ada is in no way unique in this area.
>C++ has a number of tricky areas relating to real-time performance (that
>incidentally programmers coming from Ada will be better prepared to deal
>with than those coming from C).  Even in C the user has to worry about
>whether the standard library functions are reentrant, whether they have
>hidden extrefs that aren't appropriate for real-time, whether the malloc
>algorithm behaves reasonably, etc.  [The July 1993 issue of "Embedded
>Systems Programming" has two long articles on these subjects.]  Then if
>the programmer is using a rl-time kernel product to provide concurrency
>support, there are the performance characteristics of that product to
>learn, and occasionally get caught by.
>
You betcha. People who try to use concurrency without understanding it
are in for BIG trouble. The nice thing about Ada is that at least the
concurrency constructs are up front, in the language, where (IMHO)
they belong, not buried in what amounts to just a subprogram library. 
(POSIX or whatever) That was, you may recall, the original idea. People
were actually supposed to USE tasks, not end-run them as many are doing
now. Understanding tasks, and USING them, was supposed to spur the
vendors into working _really_ hard to optimize the hell out of them.

So what do we have now? POSIX/Ada bindings. Packages. Subroutine calls.
I'm not dumping on the good work done in developing the POSIX/Ada
bindings; I'm saying that such things should not really be necessary,
if the compilers were doing what we pay for them to do - give us good, 
correct code that really exploits the hardware and the power of the language.

THAT, my friends, is where Ada could win BIG. If only...

Mike Feldman