Re: vs Ada - Don't forget the prime directive!

[jls@netcom.COM (Jim Showalter)]

>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++.    *