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 12:14:53 GMT From: slinky.cs.nyu.edu!slinky.cs.nyu.edu!nobody@nyu.edu (Robert Dewar) Subject: Re: Query about monitor (passive) task optimization Message-ID: <245f3t$j3@schonberg.cs.nyu.edu> List-Id: Regarding Richard's notes on GCC: one point here is that GCC realy does not do any complex global optimizations of the type attempted in the optimizing PL1 compiler, at least as far as I understand its structure. Perhaps the experience that Richard reports is actually a confirmation that such optimizations are the ones that tend to cause trouble. GCC generates extremely good local code, and its success in competing against what on paper would seem to be much more ambitious attempts at optimization just go to show that concentrating on good local code gets you most of the way without needing very complex optimizations. The kind of optimizations we are talking about here: recognizing entire tasks as obeying a set of restrictions (typically involving intermodule link time analysis if the bodies are separately compiled), and then performing (again at link time in the general case) extensive transformations on the program tree are definitely not the kind of thing that GCC goes in for (GCC does not even attempt intermodule register allocation, a la MIPS, let alone more complex intermodule transformations). Incidentally, if you think that compiling the spec and body of a task in the same unit is an acceptable restriction for activating this kind of optimizat ion, then I would react that I would *much* prefer a pragma in the spec to this kind of severely destructuring kind of restriction.