comp.lang.ada
 help / color / mirror / Atom feed
From: eachus@largo.mitre.org (Robert I. Eachus)
Subject: Re: Ada vs C implementation efficiency
Date: 20 Jun 91 19:37:11 GMT	[thread overview]
Message-ID: <EACHUS.91Jun20143711@largo.mitre.org> (raw)
In-Reply-To: munck@STARS.RESTON.UNISYS.COM's message of 19 Jun 91 14:16:50 GMT

In article <1336.677341010@osprey> munck@STARS.RESTON.UNISYS.COM (Bob Munck) writes:

   In INFO-ADA Digest V91 #165, eachus@mitre-bedford.arpa  (Robert I. Eachus)
   said:

   > ...  In general, for good compilers
   >and good benchmarks a program will run fastest in the language it was
   >originally written in.

   You CAN'T mean that exactly as written.  Surely the history of a benchmark
   has little to do with its results.  Maybe you mean something like "line-at-
   a-time, uncritical translation of a program from one language to another
   almost always result in poor performance of the translated program compared
   to the original."?

    Yep! I meant exactly what I said.  A "good" benchmark will be
balanced so that it tests all features "equally." But equality is
measured in the language of the benchmark.  Let's use Dhrystone, Ada,
and C, instead of hypothetical names.  Dhrystone tests many string
functions, some of which are extremely quick in Ada programs such as
string length.  When these tests are translated to C, where string
length is normally done with a library call that scans for a terminal
null, that function is overrepresented in the benchmark.  On the flip
side things that are hard in Ada but are easy in C are slightly
underrepresented.  None of this should be surprising to anyone who
does benchmarking, the same thing happens when you use an instruction
mix that is appropriate for architecture family A on machines from
family B.

    I do have my doubts about "coerce the compiler to generate what I
    wanted."  What happens when a new compiler release doesn't coerce
    the same way?  Besides, playing with object code makes hair grow on
    your palms.

    But if I coerce the compiler to get speed now, and the compiler
changes all that happens is that the program may slow down.  In
practice, compiler writers don't take optimizations out when making
new releases, they may just catch cases they missed last time.  So if
C := Float(A) * B; is significantly slower than C := B * Float(A); I
change the code and report the "bug" so that next time I won't have to
worry.

--

					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...

  reply	other threads:[~1991-06-20 19:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1991-06-19 14:16 Ada vs C implementation efficiency Bob Munck
1991-06-20 19:37 ` Robert I. Eachus [this message]
  -- strict thread matches above, loose matches on Subject: below --
1991-06-15 17:37 Sam Harbaugh-AFES PROJECT
1991-06-17  9:49 ` George C. Harrison, Norfolk State University
1991-06-19 23:33   ` Bob Kitzberger @sation
1991-06-18 16:48 ` Robert I. Eachus
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox