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 autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!linus!linus!linus!mbunix!eachus From: eachus@largo.mitre.org (Robert I. Eachus) Newsgroups: comp.lang.ada Subject: Re: Ada vs C implementation efficiency Message-ID: Date: 20 Jun 91 19:37:11 GMT References: <1336.677341010@osprey> Sender: news@linus.mitre.org (News Service) Organization: The Mitre Corp., Bedford, MA. In-Reply-To: munck@STARS.RESTON.UNISYS.COM's message of 19 Jun 91 14:16:50 GMT Nntp-Posting-Host: largo.mitre.org List-Id: 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...