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.8 required=3.0 tests=BAYES_50 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 27 Oct 92 17:16:04 GMT From: dog.ee.lbl.gov!overload.lbl.gov!agate!spool.mu.edu!sdd.hp.com!zaphod.mps. ohio-state.edu!cis.ohio-state.edu!news.sei.cmu.edu!lph@ucbvax.Berkeley.EDU (La rry Howard) Subject: Re: Real time and concurrency (was: What is real-time?) Message-ID: <1992Oct27.171604.23987@sei.cmu.edu> List-Id: In article <1992Oct27.040609.24215@seas.gwu.edu>, mfeldman@seas.gwu.edu (Michael Feldman) writes: |> |> Before rejecting this or that language feature on a project, I argue |> as I always have, with the following aphorisms (I didn't make these up): |> |> 1. It's easier to make a correct program fast than a fast program correct. |> |> 2. Fast enough is fast enough. |> |> 3. If it's not, optimize from the inside out. Find the 10% of the |> code that does the 90% of the work, optimize it till it's fast |> enough, and forget about the rest. |> |> 4. Measure (or at least analyze openmindedly) before deciding. |> |> 5. You gotta do what you gotta do. But make sure you gotta do it. |> While I don't disagree with what Dr. Feldman has said, I think his aphorisms focus on "fast" at the expense of what really matters in real-time systems -- predictability. In systems where the time when computations are performed is as important as the results of the computations, performance optimization is _not_ merely a matter of increasing the speed of certain computations. Local efficiency optimizations are _not_ local issues in real-time systems, they relate directly to global scheduling decisions and to the analysis framework used to predict the performance of the whole from attributes of the parts. We have found that design strategies which permit the selection of language features as a part of global design to be an effective way to make early predictions of system performance. We do this by understanding the global design (architecture) in terms of a relatively few design elements which embody global coordination decisions (communication, activation, synchronization) in sets of mechanisms associated with the elements. The partitioning consists entirely of instances of these elements. The mechanisms each design element provides can be mapped to programming language features. Instances of the elements inherit these decisions by means of software templates associated with the elements. We can analyze such a system early in its development by using specifications of the design element instances to perform design simulation. The latter reconstructs the system as synthetic instances of design elements sized according to their specifications. The simulation is then studied on the target virtual machine. As we consider alternatives for mapping design element mechanisms to language features in software templates, we can investigate the run-time implications of these decisions in the context of the global design. Of course, this is an example of global optimization -- decisions by the few affecting the many. We can analyze local optimizations at the global (system) level through performance variables associated with the instances of the design elements. Values for these variables (worse-case execution time, period, order, coherence) are communicated to system designers using specification forms. As described above, these performance variables are used to size synthetic instances of design elements for performance studies using design simulation. In this way, the effects of local optimizations (as changes in timing) can be related to the analysis of system run-time behavior. Finally, I support those who believe that when rejecting Ada tasking we should be careful not to "throw the baby out with the bath water." Lots of good work (for example by the RMARTS project at SEI) has shown that preemptive, priority-based scheduling with Ada-83 tasks can be used (within certain constraints) predictably and efficiently for real-time systems, with advantages over non-preemptive approaches. The laggards will warm up to it. Larry Howard (lph@sei.cmu.edu) | Software Engineering Institute, Carnegie Mellon Univ. | Vera pro gratiis. Pittsburgh, PA 15213-3890 (412) 268-6397/5857 (fax) |