Ada vs. C++

Ada vs. C++

[G]

  Has anyone done any measurements on the different speeds and
memory requirements of comparable applications written in C++
and Ada95.  I am learning both languages.

--
Thankyou.
--
G.

Re: Ada vs. C++

[Ted Dennison]

In article <38A37C97.9E181025@interact.net.au>,
  G <gmw@interact.net.au> wrote:
>   Has anyone done any measurements on the different speeds and
> memory requirements of comparable applications written in C++
> and Ada95.  I am learning both languages.

No. Compiled procedural languages generally do not have a "speed"
associated with them that can be compared to the speed of other
such languages. How fast your Ada or C++ code runs depends almost
entirely on your design and the quality of your compilers (eg: how well
they optimize). There really isn't anything  pervasive in either
language that can be said to cause every algorithm in one to be slower
than the equivalent in the other. Theoreticly it may be easier for
compilers to optimize Ada than C++ due to Ada's more restrained approach
to pointers and aliasing. But that issue would only have bearing if
every compiler vendor spent the exact same amount of effort trying to
optimize, which they don't.

If you had 2 specific compilers you wanted to compare, that question
would be meaningful. Also, if you were to ask about maintainablity or
readability, you would have a general issue that could be discussed.
This is also a much more meaningful question in these days of desktop
supercomputers.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Ada vs. C++

[Gautier]

>   Has anyone done any measurements on the different speeds and
> memory requirements of comparable applications written in C++
> and Ada95.  I am learning both languages.

For simple performance comparisons (fixed allocations) it would
be interesting - and rather comparing with Fortran compilers, THE
reference...

For programs using many temporary objects Ada offers possibilities
that C/C++/Fortran may not offer. I think to multi-precision
integer calculations that can be done without any dynamic allocation
(no 'new', 'free', nor memory fragmentation problems that arise quickly
in that context), because of ability of returning and manipulating
non-trivial objects (unconstrained arrays).

Beware of not comparing a bad C++ compiler with a good Ada one (or
reversely) and conclude something about the languages...
You have to precise how differently the programs can be coded in
both languages. If you program in Ada just like C you might
overuse allocations. Reversely, if you program the same algos
using Ada's nested procedures, local objects, subtyping etc.
it could bring good surpises...

-- 
Gautier

_____\\________________\_______\
http://members.xoom.com/gdemont/

Re: Ada vs. C++

[Bobby D. Bryant]

Gautier wrote:

> Beware of not comparing a bad C++ compiler with a good Ada one (or
> reversely) and conclude something about the languages...

A contrary strategy, based purely on pragmatics, is to compare the two
compilers you would actually use. For example, a poor student might feel
restricted to the GNU or other free compilers, affording a fairly limited
choice, which could be narrowed down by experiment.

However, unless you're writing throw-away code I would agree with the
sentiment of an earlier poster: you might be more interested in using
whichever language tempts you to write the more maintainable code.

If speed is the only concern, you could simply write "Hello, world!" for
every project, no matter what the requirements call for, and when
criticized say "Yeah, it's got some bugs, but it sure runs fast!".  I urge
you to get in the habit of thinking in terms of correctness and
reliability rather than raw speed, and maintainability is, IMO, an
absolute essential for having correctness and reliability.

Bobby Bryant
Austin, Texas

Re: Ada vs. C++

[Larry Kilgallen]

In article <38A4E40E.2FA51C81@mail.utexas.edu>, "Bobby D. Bryant" <bdbryant@mail.utexas.edu> writes:

> However, unless you're writing throw-away code I would agree with the
> sentiment of an earlier poster: you might be more interested in using
> whichever language tempts you to write the more maintainable code.

I told a stranger at a conference dinner table that I liked Ada because
it was readily maintained.  He responded, quite seriously, that he used
another language but he had made it a career practice only to write new
code and never to maintain anything he had written.

(Sorry, I did not record his name, in case anyone wanted his resume :-).

Re: Ada vs. C++

[Tarjei T. Jensen]

G wrote in message <38A37C97.9E181025@interact.net.au>...
>  Has anyone done any measurements on the different speeds and
>memory requirements of comparable applications written in C++
>and Ada95.  I am learning both languages.


I don't think anything like that is available.

Anyway, leaning two languages at once may not be a good idea. I suggest you
concentrate on Ada first and then apply what you have learnt to C++. It should
make learning C++ a LOT easier.

You may want to read the december issue of the Linux journal (The interview
with the author of the Bazaar and the Cathedral). The interesting thing is the
rise of Python as a scripting language. It is claimed that 90% of  errors in
"working" software is related to memory management. Ada is probably better at
managing its use of memory than C++.

The key to Python success in a Perlified world is ETS (effort to solution). It
is less effort to write scripts in Python than in Perl. Perl has a lot of bells
and whistles, but have a horrible syntax.

Greetings,

Re: Ada vs. C++

[Gary]

Then there is REXX.  REXX has fairly decent (straightforward, easy to understand)
syntax.  I vastly prefer REXX to PERL.  NetREXX can be used in place of JAVA to
simplify those types of tasks as well.

"Tarjei T. Jensen" wrote:

> G wrote in message <38A37C97.9E181025@interact.net.au>...
> >  Has anyone done any measurements on the different speeds and
> >memory requirements of comparable applications written in C++
> >and Ada95.  I am learning both languages.
>
> I don't think anything like that is available.
>
> Anyway, leaning two languages at once may not be a good idea. I suggest you
> concentrate on Ada first and then apply what you have learnt to C++. It should
> make learning C++ a LOT easier.
>
> You may want to read the december issue of the Linux journal (The interview
> with the author of the Bazaar and the Cathedral). The interesting thing is the
> rise of Python as a scripting language. It is claimed that 90% of  errors in
> "working" software is related to memory management. Ada is probably better at
> managing its use of memory than C++.
>
> The key to Python success in a Perlified world is ETS (effort to solution). It
> is less effort to write scripts in Python than in Perl. Perl has a lot of bells
> and whistles, but have a horrible syntax.
>
> Greetings,

Re: Ada vs. C++

[Tarjei T. Jensen]

Gary wrote in message <38A42AE8.478DB03F@lmtas.lmco.com>...
>Then there is REXX.  REXX has fairly decent (straightforward, easy to
understand)
>syntax.  I vastly prefer REXX to PERL.  NetREXX can be used in place of JAVA
to
>simplify those types of tasks as well.


The syntax is not bad, but the semantics is horrible. The semantics of rexx
makes it unsafe at any speed. I prefer the predictability of perl.


Greetings,

Re: Ada vs. C++

[Florian Weimer]

"Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> writes:

> You may want to read the december issue of the Linux journal (The interview
> with the author of the Bazaar and the Cathedral). The interesting thing is the
> rise of Python as a scripting language. It is claimed that 90% of  errors in
> "working" software is related to memory management.

The people implementing long-living server processes in Python have
experienced this. ;)  Python memory management is based on reference
counting, and it's quite easy to create cyclic data structures by
accident.

Re: Ada vs. C++

[Gisle S�lensminde]

In article <87snyzoad9.fsf@deneb.cygnus.argh.org>, Florian Weimer wrote:
>"Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> writes:
>
>> You may want to read the december issue of the Linux journal (The interview
>> with the author of the Bazaar and the Cathedral). The interesting thing is the
>> rise of Python as a scripting language. It is claimed that 90% of  errors in
>> "working" software is related to memory management.
>

>The people implementing long-living server processes in Python have
>experienced this. ;)  Python memory management is based on reference
>counting, and it's quite easy to create cyclic data structures by
>accident.

Python and other garbage-collected systems gives the 
responibility for memory management to the runtime system instead
of the programmer. In this case the runtime system is designed
in a way that may cause problems in programs which is runing for a 
long period. For a highlevel/scripting language like python, 
it's certainly a benefit to remove the burden of memory management
from the programmer, even when the garbage collector in imperfect.

But of cause, this GC problem may prevent people from using python
for server software, until this problem is solved.

--
Gisle S�lensminde ( gisle@ii.uib.no )   

ln -s /dev/null ~/.netscape/cookies

Re: Ada vs. C++

[Preben Randhol]

"Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> writes:

| You may want to read the december issue of the Linux journal (The interview
| with the author of the Bazaar and the Cathedral). The interesting thing is the
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

You mean ES Raymond ? I don't care much for what he has about Ada in
the jargon file. Not that I take that "dictionary" serious.

-- 
Preben Randhol -- [randhol@pvv.org] -- [http://www.pvv.org/~randhol/]     
         "Det eneste trygge stedet i verden er inne i en fortelling." 
                                                      -- Athol Fugard

Re: Ada vs. C++

[Preben Randhol]

G <gmw@interact.net.au> writes:

|   Has anyone done any measurements on the different speeds and
| memory requirements of comparable applications written in C++
| and Ada95.  I am learning both languages.

Probably, but it is not very interesting. You should rather look at
the language design when your trying to assess the two languages.

-- 
Preben Randhol -- [randhol@pvv.org] -- [http://www.pvv.org/~randhol/]     
         "Det eneste trygge stedet i verden er inne i en fortelling." 
                                                      -- Athol Fugard

Re: Ada vs. C++

[Vincent DIEMUNSCH]

G a �crit :

>   Has anyone done any measurements on the different speeds and
> memory requirements of comparable applications written in C++
> and Ada95.  I am learning both languages.
>
> --
> Thankyou.
> --
> G.

Such a comparison is not obvious, it relies too much of the compiler's
optimization.
But Tartan who makes both C and Ada compilers for Digital Signal
Processors seems to like Ada much better than C to implement the same
algorithms.

see : http://www.adahome.com/Ammo/Stories/Tartan-Realtime.html

See is due to the fact that Ada gives a more abstract and precise
definition of what as to be done, compared to C who tend to stay at a
lower level. Therefore although  it is easier to write a simple C
compiler, when it turns to optimization, Ada is much better.

Borland who made both C and Pascal compilers said the same. Pascal can
be seen as an "ancestor" of Ada, because it's syntax is quite close.

Re: Ada vs. C++

[Gautier]

(...)
> See is due to the fact that Ada gives a more abstract and precise
> definition of what as to be done, compared to C who tend to stay at a
> lower level. Therefore although  it is easier to write a simple C
> compiler, when it turns to optimization, Ada is much better.
> 
> Borland who made both C and Pascal compilers said the same. Pascal can
> be seen as an "ancestor" of Ada, because it's syntax is quite close.

Interesting... since Borland didn't provide optimisation on their Pascal
compilers (maybe until some recent version of Delphi ?).

Another remark: Pascal (at least the Borland ones...) allows transtyping
*implicitely* (unlike Ada) all integer types between 8,16,32 bits! This
produces horrible machine code that permanently zeroes an upper byte somewhere,
although the programmer doesn't guess anything... Seen plenty of such useless
cases with Pascal->Ada translations.

-- 
Gautier

_____\\________________\_______\_________
http://members.xoom.com/gdemont/gsoft.htm

Re: Ada vs. C++

[Richard D Riehle]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2972 bytes --]

In article <38A7EE61.353F9ECF@edf.fr>,
	Vincent DIEMUNSCH <vincent.diemunsch@edf.fr> wrote:

>G a �crit :
>
>>   Has anyone done any measurements on the different speeds and
>> memory requirements of comparable applications written in C++
>> and Ada95.  I am learning both languages.

Alas, comparisons of this sort are not very useful.   Even when Ada is
superior, C++ is chosen.  We just received word from another client
working on a large-scale DoD safety-critical system that they are going
to switch to more C++.  This is just another in the long list of those
we have heard from, since abrogation of the DoD Ada single-language policy
who have made the ridiculous decision to abandon Ada in favor of C++.  

For some of these companies, the reason for choosing C++ has nothing to do 
with the relative merits of the two languages.  It has little to do with
abrogation of the Ada policy. It has a lot to do with the quality of the Ada
compilers and associated tools, especially debugging tools.  For a least
one platform, we are told it has to do with the unavailability of a satisfactory 
compiler and associated support.  

C++, when compared to Ada, is pretty awful.  Some of those abandoing Ada even
admit that. C++ tools, consulting support, trained personnel, and available 
infrastructure seem to overwhelm Ada from the perspective of those building software.  

We can complain about the stupidity of those who select C++ over Ada, but they
are making their decisions on the basis of other factors than relative quality
of the two language designs.  

On the positive side, some commercial developers are showing themselves to be 
smarter than the DoD contractors, and selecting Ada.  This is a small group at
present.  It is also a demanding group.   If they don't get the support they
need, the tools required to do their work, and the compilers that actually 
perform as expected, they will drop their commitment faster than you can 
say Countess of Lovelace.  

A couple of the Ada compiler vendors are demonstrating some entrepreneurial
spirit.  Others are still operating under the "feeding at the DoD trough model."
Any organization that says, "We could build that, but who will fund it?" is
lost before it starts.   If there is a market, build products to support it.
If there is no market, can one be created?   No one is going to "fund" the
Ada industry anymore.  Although abrogation of the "mandate" was absurdly
premature, we are now going to survive or not under the rules of the free
market place.  

I wonder if this problem can be corrected.  I hope so.  I worry about the
use of C++ in safety-critical weapon systems.  I worry about sending our
service personnel into harm's way using C++.  But we in the Ada industry
are as much at fault for these bad decisions as those who are making them.

C++ versus Ada.  Sheesh!  Doggerel versus great literature.  Rap music
versus Mozart.  "You can lead a horticulture but ... "

Richard Riehle

gdb question, was Re: Ada vs. C++

[tmoran]

>It has a lot to do with the quality of the Ada compilers and
>associated tools, especially debugging tools.
  I recently needed, for the first time, to use gdb.  It seemed
non-obvious and extremely klutzy.  Is that just my unfamiliarity,
or does that match others' observation?
  Of course the fact I've been able to live without that kind
of debugger for so long reinforces the observation that a "debugger"
of that kind is less vital with Ada than with other languages.

Re: gdb question, was Re: Ada vs. C++

[Ted Dennison]

In article <PI1q4.4873$yt2.142554@nnrp3-w.snfc21.pbi.net>,
  tmoran@bix.com wrote:
> >It has a lot to do with the quality of the Ada compilers and
> >associated tools, especially debugging tools.
>   I recently needed, for the first time, to use gdb.  It seemed
> non-obvious and extremely klutzy.  Is that just my unfamiliarity,
> or does that match others' observation?

GDB itself, yes I agree. GDBTK on the other hand is quite nice.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: gdb question, was Re: Ada vs. C++

[Ehud Lamm]

On Tue, 15 Feb 2000 tmoran@bix.com wrote:

|>It has a lot to do with the quality of the Ada compilers and
|>associated tools, especially debugging tools.
|I recently needed, for the first time, to use gdb.  It seemed
|non-obvious and extremely klutzy.  Is that just my unfamiliarity,
|or does thatmatch others' observation?

My students hate it. My experience is that it is so uncomfortable, that I
almost never use it.

Luck for me, I don't like debuggers at all. But if you need one, it'd
better be easier to use. 

Another issue is that when invoked from AdaGide you are thrown into a new
style of interface (TCL), which is inconsistent and confusing - not to
mention all the windows that are open at once.

Ehud Lamm mslamm@mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm <== My home on the web 
Check it out and subscribe to the E-List- for interesting essays and more!

Re: gdb question, was Re: Ada vs. C++

[Stephen Leake]

tmoran@bix.com writes:

>   I recently needed, for the first time, to use gdb.  It seemed
> non-obvious and extremely klutzy.  Is that just my unfamiliarity,
> or does that match others' observation?

I use gdb under Emacs on Win32, and I love it. I've also used the
Borland IDE debugger on Win32, the ObjectAda IDE debugger on Win32,
and the DEC VMS debugger. Of these, only the DEC debugger comes close
to gdb.

Any new interface feels klutzy at first, until you learn how to do
basic things. When you get past that, you begin to see the true power
of the tool.

For example, using the Borland debugger, you can't examine local
variables in functions on the current call stack; you can only examine
the variables in the current function. gdb can examine all variables
on the call stack.

I have not played with the various GUI interfaces to gdb, because
Emacs already does everything I might need from a GUI.

>   Of course the fact I've been able to live without that kind
> of debugger for so long reinforces the observation that a "debugger"
> of that kind is less vital with Ada than with other languages.

I tend to jump right into gdb to find a bug, because it is so easy and
so powerful. Then I go back and fix my unit test to show the bug,
then I fix the bug. I guess we just have different styles!

-- Stephe

Re: gdb question, was Re: Ada vs. C++

[Robert A Duff]

tmoran@bix.com writes:

>   I recently needed, for the first time, to use gdb.  It seemed
> non-obvious and extremely klutzy.  Is that just my unfamiliarity,
> or does that match others' observation?

I don't much like gdb, either.  But in general, I don't like to spend a
lot of time in debuggers anyway -- better to try to understand the
code.

When I do use gdb, I use it under Emacs, which makes it much more
pleasant (eg automatically shows the part of the program you're in).

- Bob

Re: gdb question, was Re: Ada vs. C++

[Mike Dimmick]

"Robert A Duff" <bobduff@world.std.com> wrote in message
news:wcchff97z2w.fsf@world.std.com...
> tmoran@bix.com writes:
>
> >   I recently needed, for the first time, to use gdb.  It seemed
> > non-obvious and extremely klutzy.  Is that just my unfamiliarity,
> > or does that match others' observation?
>
> I don't much like gdb, either.  But in general, I don't like to spend
a
> lot of time in debuggers anyway -- better to try to understand the
> code.
>
> When I do use gdb, I use it under Emacs, which makes it much more
> pleasant (eg automatically shows the part of the program you're in).

My own experience with gdb, under linux, was very nasty -- though it may
have been the version of gdb (4.17.0.11): it insisted on listing the C
files that GNAT generated rather than my source files!  All I wanted to
find out was where I was getting an exception raised.

I ended up recompiling the program (which was minimal anyway) under
Windows and using GDB/TK to find the source line.  This release actually
told me under the backtrace where the error was occurring.

Not a friendly tool.

By contrast, MS Visual C++ has a great debugger -- but you do tend to do
quite a bit more work in it than with GNAT, I'll grant you.

--
Mike Dimmick

Re: gdb question, was Re: Ada vs. C++

[Jeff Creem]

Mike Dimmick <mike@dimmick.demon.co.uk> wrote in message
news:952459362.11185.1.nnrp-12.d4e5bde1@news.demon.co.uk...

>
> My own experience with gdb, under linux, was very nasty -- though it may
> have been the version of gdb (4.17.0.11): it insisted on listing the C
> files that GNAT generated rather than my source files!  All I wanted to
> find out was where I was getting an exception raised.
>
> I ended up recompiling the program (which was minimal anyway) under
> Windows and using GDB/TK to find the source line.  This release actually
> told me under the backtrace where the error was occurring.
>

Actually GNAT only generates 1 c file (and the newer versions don't even
have to do that).

If you had checked the documentation and/or stepped into the code a little
the ada would have
magically appeared... Of course I am assuming that you had the Ada aware
gdb....(And even
if you did not, you could still see the Ada source).

I do prefer the ddd interface to gdb...Makes it much easier to use when you
don't use gdb
much.

As always I would recommend consulting the super secret hidden information
about gdb and GNAT the the
files who's names can not be mentioned...

Re: Ada vs. C++

[Marin D. Condic]

G wrote:
> 
>   Has anyone done any measurements on the different speeds and
> memory requirements of comparable applications written in C++
> and Ada95.  I am learning both languages.
> 
If your purpose is to select a compiler for a project with some sort of
time critical requirement then I would suggest that you find some
code/algorithms that are similar to the intended application (I/O
intensive, Math intensive, Memory intensive, etc.) and feed them through
a few compilers to see what you get. This sort of benchmarking can prove
useful and there may be some of that work done by various realtime
projects which folks might be willing to share.

If your question is more along the lines of "Which language is faster
and more memory efficient?" then I'm afraid you will get no useful
information on that subject. For benchmarking purposes, you cannot
separate the language from the implementation. One man's Ada compiler
may produce dramatically better code than another man's C++ compiler.
Likewise, the opposite. This really tells you nothing about either
language - just how well/poorly someone implemented the language.

This much can be said: There is nothing inherent in Ada that would make
it less efficient than C++. In some ways, Ada syntax is superior for
optimization purposes because more information is available to the
compiler. In other ways, Ada could be slower because of the requirements
for runtime checks. However, the language allows you to turn off runtime
checks if efficiency is a major concern. (When doing realtime control
systems, we routinely turned off checks and had code that was every bit
as efficient as that which could be produced by any other language.)

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

Visit my web site at:  http://www.mcondic.com/

"Capitalism without failure is like religion without sin." 
        --  Allan Meltzer, Economist 
=============================================================

Re: Ada vs. C++

[Robert I. Eachus]

"Marin D. Condic" wrote:
 
> If your question is more along the lines of "Which language is faster
> and more memory efficient?" then I'm afraid you will get no useful
> information on that subject. For benchmarking purposes, you cannot
> separate the language from the implementation. One man's Ada compiler
> may produce dramatically better code than another man's C++ compiler.
> Likewise, the opposite. This really tells you nothing about either
> language - just how well/poorly someone implemented the language.

> This much can be said: There is nothing inherent in Ada that would make
> it less efficient than C++. In some ways, Ada syntax is superior for
> optimization purposes because more information is available to the
> compiler. In other ways, Ada could be slower because of the requirements
> for runtime checks. However, the language allows you to turn off runtime
> checks if efficiency is a major concern. (When doing realtime control
> systems, we routinely turned off checks and had code that was every bit
> as efficient as that which could be produced by any other language.)

    Both are true, but neither addresses the real reason that it is
difficult to
develop good multi-lingual benchmarks.  Let me take a simple example. 
Say I want
to measure the speed of string assignment in C and Ada.  I write a
simple string assignment
in C, Ada, C++, and, just for the fun of it, in PL/I.  The naive C looks
something like:

   *char[30] a, b
   int i
   ...
   for(i=0, i<30, i++)
     a[i] = b[i]
   */ please excuse any errors in writing poor C. ;-) */

And the naive Ada would be:

   A, B: String(1..30);
   ...
   B := (others => 'b'); -- To avoid erroneousness and bounded error
issues...
   ...
   A := B;

Of course the assignement outside the timing loop may turn out to be
slower than the one inside,
or you could find that the compiler initializes B and A statically, and
takes no time at all.  (But that is a side issue here, except that you
figure out that you need to read the value of
B from outside the program to avoid such optimizations.)

  Now a decent C programmer looks at the C code, and says, "Oh no, that
is not how it is done."
He then writes code which mallocs a and b, and uses strcpy for the
assignment.  This is a significant improvement in the benchmark, but now
you need to alter the Ada program to match.
The length of the strings is now determined at run-time, but does this
mean you should use the heap, or maybe the right match is to use
Unbounded_String?  After a lot of back and forth, aggrement is reached
to use Unbounded_String.  This makes the C++ programmer happy, since he
has a foundation class which seems to match the Ada nicely.  But the
PL/I programmer wants to use char (128) varying.  (Corresponds to Ada
Bounded_Strings.)

  So now you have several alternatives.  Not all langauges support all
of them, and which are "native" to the language, and which are part of
the standard run-time varys from language to language.

  The benchmarks you want can be written, but it is very tough.  You end
up writing a detailed formal specification, debugging the specification
through several iterations, having groups familiar with both langauges
and implementations code against the formal specification, then finally
test to the specifications.  There are such benchmarks, for example TPC
for transaction processing, the LINPAC benchmarks, etc.  However, even
if you go though all that, you end up testing the quality of the
implementation teams more than anything else.  My favorite example of
such "cheating" was a case where the hands down winner of the benchmark
was the slowest (by far) hardware system offered.  However, their
benchmark team had taken advantage of the specification that certain
large matrices were sparse.  Using a sparse representation of the data
significantly increased the cache hit ratio, and as a bonus, kept all
the data in physical memory.  Since the benchmark was designed to
reflect the real application, we modified other benchmarks to use the
same technique.  On some it actually slowed the benchmark down
significantly.  We might have been able to come up with different matrix
representations better suited to the other hardware, but that wasn't the
purpose of the benchmark.  We were trying to insure that the hardware
proposed could meet the requirements.  So the bidder with the clever
programmers could bid less expensive equipment and gain an advantage.

Re: Ada vs. C++

[Tarjei Tj�stheim Jensen]

Robert I. Eachus wrote:

>   The benchmarks you want can be written, but it is very tough.  You end
> up writing a detailed formal specification, debugging the specification
> through several iterations, having groups familiar with both langauges
> and implementations code against the formal specification, then finally
> test to the specifications.  There are such benchmarks, for example TPC
> for transaction processing, the LINPAC benchmarks, etc.  However, even
> if you go though all that, you end up testing the quality of the
> implementation teams more than anything else.

TPC is not really a benchmark. There is  nothing to compare. Every system is
different. There seems to be practically no rules. You end up trying to
compare a single CPU machine with a moderate amount of memory and five disks
with one that has six CPUs, eight hundred disks and a hideous amount of
memory. They won't even run the same database software. Nobody is required to
vary the configuration so that you can determine the effect of e.g. adding an
extra CPU. For the vendors it is ideal, for me as someone who tries to find
the right system it is utterly useless.

Greetings,

Re: Ada vs. C++

[Marin D. Condic]

Robert I. Eachus wrote:
> 
> implementation teams more than anything else.  My favorite example of
> such "cheating" was a case where the hands down winner of the benchmark
> was the slowest (by far) hardware system offered.  However, their
> benchmark team had taken advantage of the specification that certain
> large matrices were sparse.  Using a sparse representation of the data

The last time I was in the business of benchmarking compilers, we took a
somewhat different approach. We got some code that was typical of engine
controls and also were the things that consumed the most time. We had
procedures that read A/D converters, did engineering unit conversions,
coil interpolations for RVDTs, univariate and bivariate curve reads,
etc. We then tried to estimate how many of each such unit we were going
to execute in a cycle. By patching together some of these routines, we
created a benchmark that would look reasonably close to what the actual
code would do. This was then run through a variety of Ada compilers to
see what the results would look like. We found it to be useful because
each compiler would do some things better than the others so you needed
a benchmark that simulated the kinds of things you planned on doing the
most.

Had we tried to compare Ada to something else it might have been
possible to come up with very similar code. Engine control code
typically does not use the real sophisticated features of any language -
mostly math, single-word data manipulations, some bit-twiddling, etc.
Not much use of things like dynamic data structures, etc, where language
features may make much larger impact. We stood a reasonable chance of
comparing languages in that realm, but even there, I'd believe the
biggest differences would be due to the quality of the compiler and not
the language itself.

In any event, I wouldn't let the vendor write the benchmark. That seems
a little too much like letting the fox guard the hen house. :-)

At the end of the day, I think most of these language efficiency
comparisons get so difficult that you're not usually generating much
usable information. The object of the game is to figure out if you can
get enough efficiency out of Language/Compiler "X" to actually get the
job done. Chances are more than one language and compiler will get you
there. So you buy one and then learn how to live with that decision.

BTW, most of the C programmers who I have heard harping about language
efficiency spend their time developing code for workstations that only
has human response time constraints. They don't know what a hard
realtime system is like and its hard to imagine why they care so much
about language efficiency. If it runs too slow, go buy a bigger box! ;-)

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

***PLEASE REMOVE THE "-NOSPAM" PART OF MY RETURN ADDRESS***

Visit my web site at:  http://www.mcondic.com/

"Because that's where they keep the money."
    --  Willie Sutton when asked why he robbed banks. 
=============================================================