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.0 required=3.0 tests=BAYES_20 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 29 Oct 92 16:55:22 GMT From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!jvnc.net!yal e.edu!qt.cs.utexas.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!mksol!mccall@u cbvax.Berkeley.EDU (fred j mccall 575-3539) Subject: Re: Real time and concurrency (was: What is real-time?) Message-ID: <1992Oct29.165522.20023@mksol.dseg.ti.com> List-Id: In <1992Oct27.040609.24215@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman ) writes: >The point here is that over the decades we have added constructs to >languages in order to support application needs, particularly the >_human_ needs we describe as all the -ilities (maintainability, >readability, etc. etc.). Tasking is really no different from all >the other higher-level constructs in that regard. This starts to become an issue of how much stuff belongs in the language, how much should be kept at the OS or 'environment' level, and how much would be better served by allowing it to be handled by outside tools that could evolve faster than a language spec can? >That R/T folks find tasking "not fast enough" to meet their needs in >specific projects, gives me a sense of deja vu. In the 70s, when >"structured programming" was the rage, using procedures to break up >programs - mainly to improve _human_ productivity - was often blasted >as hopelessly academic, because compilers couldn't deliver the goods >efficiently. Remember those days? Vividly. In fact, at some times we are STILL in those days -- it all depends on just what the constraints are. >In the end, compilers did a better job, computers speeded up, >and hardware architects gave us stack machines to support procedure calls. >Not many people would give strong arguments against procedures these days. The only argument against them is if they keep you from meeting the requirements. While rarer than it used to be, this CAN still happen to you. >Undoubtedly there are some functional holes in the tasking model; some >are plugged by Ada-9X. But the basic model is, IMHO, sound, and if we >actually use it, instead of just complaining about it all the time, our >compiler folks and machine architects will find more efficient ways >to support it. The Rational machine (on the hardware side) and POSIX >threads (on the software side) are examples of how this is already >happening. But you can't use it if you can't meet the requirements. Note that several people here have been talking about using global shared memory WITH ADA in order to get sufficient speed. This is the same way this sort of thing is done in every other language, so I'm not sure why Ada would be such a big win in such a case. >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. True, within limits. However, sometimes you can't get there from here, at which point it's time to look for a faster algorithm and code arrangement. >2. Fast enough is fast enough. When you can get there from here. >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. Sometimes the only way to get there is to tear out great whacking chunks, rework the algorithm, and write a monolithic mess with shared sections and global variables. >4. Measure (or at least analyze openmindedly) before deciding. ALWAYS a good idea. >5. You gotta do what you gotta do. But make sure you gotta do it. EXACTLY. And when you gotta, just tell all the various breeds of bigots to get out of the way and let you get the job done. -- "Insisting on perfect safety is for people who don't have the balls to live in the real world." -- Mary Shafer, NASA Ames Dryden ------------------------------------------------------------------------------ Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.