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,
	MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!spool.mu.edu!agate!dog.ee.lbl.gov!nosc!cod!sampson
From: sampson@cod.NOSC.MIL (Charles H. Sampson)
Newsgroups: comp.lang.ada
Subject: Re: vs Ada - Don't forget the prime directive!
Message-ID: <3142@cod.NOSC.MIL>
Date: 19 Jun 91 21:02:50 GMT
References: <311@trwacs.UUCP> <1991Jun18.040142.2616@netcom.COM> <313@trwacs.UUCP>
Organization: Computer Sciences Corporation
List-Id: <comp.lang.ada>

In article <313@trwacs.UUCP> erwin@trwacs.UUCP (Harry Erwin) writes:

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

     Is this statement what was intended?  It seems to be saying that if
if you write two versions of a program, version A in a language that hides
the machine architecture and version B in a language that makes it easy to
get at the architecture, then the execution time of version A will be five
times that of version B.  I find this extremely surprising.  Usually when
such comparisons are made, version B's language is assembly and the slow-
down attributed to version A's language is stated as a percentage, most of
the time less than 100%.  Notice that the key adjective in the statement is
_usually_, not _sometimes_.  Even for _sometimes_ I'd consider a factor of
five surprising, except for some very special small programs that fully
exploit a special hardware feature.

>The data are weeks to months old and generally proprietary.
>My experience over the last 12 years is that Ada, Pascal,
>and similar languages (CMS2, Modula-2, etc.) generate code
>that always has to be tuned in integration and test to
>overcome implementation inefficiencies. The performance
>improvement during tuning is almost always at least 10-to-1,
>and frequently reflects subtle characteristics of the
>hardware architecture, which those languages are intended
>to hide from the programmer. Tuning is less frequently
>needed for C code, and the inefficiencies to be overcome
>are significantly less. 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).  ...

     I think that there is a moral obligation to publish these results.
They are contrary to _every_ Ada project I know about.  At the beginning
we were surprised to find out that our test and integration costs and
time were reduced when using Ada.  We expected to pay a high development
cost, to be recouped during maintenance, the accepted belief of the day.
We were surprised to find out that our total development time using Ada
was about the same as before, with more time spent in design and coding,
less in testing and integration.  We now schedule projects based on this
experience.  (For _we_ in this paragraph, read _I and every experienced
Ada person I know_.)

     That 10-to-1 performance improvement during tuning is yet another
surprising claim.  I was quite pleased with myself a few years ago when
I approached 2-to-1 in tuning an old program that had never been tuned
before and that job involved inline insertion of assembly code in three
inner loops!  (The name of the language that would allow me to do that
is withheld to protect innocent ears.)

                             Charlie