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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,81cf52699486abe7
X-Google-Attributes: gid103376,public
From: Ehud Lamm <mslamm@mscc.huji.ac.il>
Subject: Re: Code size of Ada ? was Re: Ada95 Strengths/Weaknesses.
Date: 1999/09/30
Message-ID: 
 <Pine.A41.3.96-heb-2.07.990930154826.68392B-100000@pluto.mscc.huji.ac.il>#1/1
X-Deja-AN: 531137822
References: <37EED7B8.245C0054@yukyonline.co.yuky>
 <7smp30$9aa1@news.cis.okstate.edu> <7sp8m9$a6e$1@nnrp1.deja.com>
 <37F0D03C.DE4807D4@icn.siemens.de> <7srnb9$2u3$1@nnrp1.deja.com>
 <1999Sep29.075617.1@eisner> <37F22BB1.F3524D60@icn.siemens.de>
 <7sts6b$kla$1@nnrp1.deja.com> <37F349BB.B1F39ECF@icn.siemens.de>
 <7svmrk$tkl$1@nnrp1.deja.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII
Organization: The hebrew University of Jerusalem
Mime-Version: 1.0
Newsgroups: comp.lang.ada
Date: 1999-09-30T00:00:00+00:00
List-Id: <comp.lang.ada>

On Thu, 30 Sep 1999, Robert Dewar wrote:

|Now of course if you use high level constructs in Ada that have
|no analogy in C, you will pay a price. But that's always the
|case, programming at a higher semantic level almost always
|(not always, but almost) costs in space and time (if you don't
|like this, you can always write in machine language and save
|lots of time and space over high level languages like C :-)
|

I'd like to respond to this, even though it is a little off topic, even
for this roving thread. I think the "almost always" claim is an
overstatement - as I am sure Robert knows. 
Today's processors (esp. RISC, superscalar, bredictive brancing etc.) have
many features that make writing good machine code for them quite hard.
Good optimizing compilers, many times, outperform all but the most expert
of programmers. Now surely, a programmer who fails to use the right
compiler switches will also fail to produce good machine code by hand.
Hand tuning machine code is hard. The abstraction mechanisms of HLL help
you think more clearly about the actuall problem to be solved - getting to
a better algorithm - and with the aid of a good compiler, tend to produce
better results.
(Not to mention all the other benefiets: less bugs, easier maint. etc.)

In most cases I've seen sending someone to code in machine language (or
let's be more realistic - Assembly language), won't bring faster programs
- UNLESS that person has a verey good knowledge of how things really work
in the first place.

I had a student once, who always insisted on using shift (in his C code)
instead of multiplication, when multiplying by two. I'll let you guess
which C code produced faster object code, what optimization did (not to
mention some funny run time checks I saw on one compiler...). The only way
to convince him that (a) a negligable speed increase is not worth the
obsufication and that (b) there isn't any speed increase anyway was to
examine the assembly listing from the compiler. 
Alas a week later he had a new clever idea. 
I have a feeling he will never "get it."

I wouldn't bet on Assembly, unless knowing the exact problem and
programmer invovled.

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!