Re: Ada vs. C++

["Marin D. Condic" <mcondic-nospam@quadruscorp.com>]

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