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 15:26:42 GMT From: ddciiny!jls@uunet.uu.net (Jonathan Schilling) Subject: Re: Query about monitor (passive) task optimization Message-ID: List-Id: 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. -- Jonathan Schilling DDC-I, Inc. uunet!ddciiny!jls