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: 9 Aug 93 14:48:34 GMT
From: ddciiny!jls@uunet.uu.net  (Jonathan Schilling)
Subject: Re: Query about monitor (passive) task optimization
Message-ID: <CBHyGz.Jup@ddciiny.UUCP>
List-Id: <comp.lang.ada>

In article <244ktf$61@schonberg.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) wri
tes:
>Jonothan Shilling asks why people do not want automatic task optimization.
>After all, he asks, it only makes programs run faster.
>
>Well the point is that in realtime programs, running faster is not typically
>a requirement. The requirement is that all tasks complete their assigned
>tasks on schedule. General optimizations that may or may not speed up some
>tasks, depending on what the compiler can figure out, are not much help to
>a programmer who must demonstrate that the program he writes will meet its
>deadlines.
 
I concede your point for the general case, where tasks map to some
tangible application function (an airplane's navigation, an engine's
operation, etc.).  But in the particular case of monitor (passive)
tasks, the tasks are somewhat artificial, in that they exist only
to sychronize access to some resource.  They don't really map to
any application function, and probably don't have any assigned
schedule.  It seems to me that you would always want such tasks
to run as fast as possible.

>Imagine a worst case. Suppose a compiler used some probabilistic algorithm
>to estimate how it should optimize tasks. This is not unreasonable. The
>compiler has incomplete information about the program being compiled, so
>game theory would suggest that an optimizal strategy would be a mixed
>stratecy involving probabilistic choices. Well such a compiler would be
>unusable in real-time contexts -- every time you compiled, you might find
>that different tasks were optimized and the program would change its
>execution characteristics and perhaps correctness.
>
>On the other hand, this compiler would, on average, execute Ada programs
>faster than a compiler which did not do such probabistic optimization.

I certainly agree that any compiler that did this should tie the 
optimization to a pragma PROBABILISTIC, and then to a pragma
ARE_YOU_SURE_YOU_REALLY_WANT_TO_DO_THIS.

Obviously, any optimizations that involve tradeoffs (whether time vs.
space, task vs. task, instruction scheduling vs. debugging clarity) 
should be under some kind of user control.  But most Ada optimizations, 
tasking or non-tasking, don't involve tradeoffs; they involve recognizing
simple instances of generally complex constructs.  It's those that I'm in 
favor of compilers doing automatically.

-- 
Jonathan Schilling
DDC-I, Inc.
uunet!ddciiny!jls