From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!netcomsv!jls From: jls@netcom.COM (Jim Showalter) Newsgroups: comp.lang.ada Subject: Re: vs Ada - Don't forget the prime directive! Message-ID: <1991Jun19.182601.8337@netcom.COM> Date: 19 Jun 91 18:26:01 GMT References: <9106151802.AA16989@zach.fit.edu> <311@trwacs.UUCP> <1991Jun18.040142.2616@netcom.COM> <313@trwacs.UUCP> Organization: Netcom - Online Communication Services UNIX System {408 241-9760 guest} List-Id: >Actually, the 10-12 MLI/statement is with error checking turned >off. With it turned on, we're in the 15-20 range. The data >are recent and for an efficient compiler. I refer you to other posts in this thread comparing Ada and C compilers for counterexamples. Sounds to me like your compiler needs some work. >The Ada task rendezvous is notorious in the performance engineering >community as a feature to be avoided in real-time and near-real-time >applications. I guess it kind of depends on how you define "performance engineering community". The people I've been working with over the last four years certainly qualify as members of that community, and they have successfully used Ada tasking on numerous applications with hard real time scheduling deadlines (a telecommunications switch and a series of ships with a distributed real time approach to managing ship operations come to mind). If you're not familiar with the rate monotonic scheduling algorithm, you might do well to go read up on it. >I have written a set of C++ classes that give me >a multi-tasking environment when I need it, and they're a lot >more efficient than Ada. Prove it. Provide numbers. Specify platforms, operating systems, compilers, etc. Otherwise, this is just anecdotal. >I don't usually use them, preferring >instead to use the operating system tasking mechanism, but I >will use them before I use Ada tasking. Uh, in case you've forgotten, one of the reasons Ada has tasking is for embedded systems where the overhead of an operating system is simply unacceptable. Claiming that you've solved the problem of real time performance by escaping to a real time operating system is fine, provided you HAVE a real time operating system. If, on the other hand, you've got a bare CPU, you basically have two choices: 1) use a language other than Ada and cobble together your own homebrew version of a real time kernel (which as we all know is both a very efficient use of one's time and highly portable) or 2) use Ada and rely on the real time kernel provided by the Ada vendor to support Ada tasking. >My experience is that hiding the machine architecture from the >coder usually decreases the performance of the code by a >factor of at least 5. What sorts of things do you build? I would agree that writing an abstract device driver is both not a good idea and probably a contradiction in terms. On the other hand, writing a DBMS that depends for most of its implementation on highly machine- dependent calls is rather shortsighted if you have any intention of ever running said DBMS on anything other than one platform. Nothing is black-and-white; there are appropriate times to get down to the base hardware to make something go really fast, but there are lots of other times when getting down to the base hardware is a really dumb idea. That's why Ada supports the range of extremes (including inlining and machine code insertion). >The data are weeks to months old and generally proprietary. Yeah, isn't that always the way? "I could prove that Ada is too slow to be used for real time, it's just that the data I have is secret". And yet, I have NON-secret success stories concerning Ada on hard real time projects. For example, call up Rational and ask for their writeup on the Bofors Ship System 2000 project--they'll be happy to share this with anybody. >Hence, by using Ada, you're >reducing your programming and maintenance costs (which >are also programming costs) but decreasing your performance >and increasing your integration and test costs (which >is expensive anyway). Actually, integration and test is pretty darned simple with Ada, since the formal specifications and such make things plug together better than with most languages. There are even some studies that prove (from real project data) that integration and test takes less time on Ada projects than for comparable projects in other languages. I think you meant to say "decreasing your performance and increasing your tuning costs". Considering that maintenance represents the biggest chunk of the pie by far, and considering that tuning is a relatively straightforward "final pass", I think you've just made a real strong argument for using Ada instead of C as a means of reducing total lifecycle software development costs, which has been my argument all along. -- *** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 **** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *