Re: is Ada 'better' than C? (Was: Re: C is 'better' than Ada because...)

[kdq@emoryi.jpl.nasa.gov (Kevin D. Quitt)]

On Tue, 06 Aug 1996 10:56:41 +0200, Antoine Leca <Antoine.Leca@Renault.Fr>
wrote:

>Kevin D. Quitt wrote:
>> I think that anybody who depends on optimization to make their code work
>It seems clear that a code which work with optimisations on and don't work 
>when they're off is brocken, isn't it?

Unless you're talking about timing being a factor.


>> or to make it efficient is barking up the wrong tree. 
>Ah ah.  This's not the same.
>For me, an optimizer is clearly the tool you need when you're seeking
>efficiency. 

For me, an optimizer is the tool to use to avoid gross deficiencies in the
compiler and code, and to make certain judgements about what works best on the
hardware.  For efficiency, we agree, one chooses one's algorithms carefully.


>> Except for unusual
>> circumstances (e.g., embedded code), one should write straightforward, easily
>> debugged/tested/modified code. 
>Full OK with you here.  You could add "maintainable" if it sounded English.

debugged/tested/maintained/modified.



>> Once the code works, *then* you turn on the optimizers (and test again). 
>OK again.  For much code, I don't think this step is necessary.

Agreed.  Optimizer technology is fairly reasonable nowadays.  I haven't had
one break my code in a little while.


>> Barring that, look at the code produced and see what the
>> compiler's problem is, and what alternate/equivalent code can be used to help
>> the compiler.  This latter is rarely necessary, and usually under exotic
>> circumstances.
>
>Very rarely, IMHO.

True, but I just had to do that for the code I work on for the Cassini
spacecraft.  The optimizer (source unidentified to protect the innocent -
i.e., me), was what I call a pessimizing cross-compiler (for the 8085).  I had
12K of ROM, and when I inherited the code, it compiled to 13K, and was only
about 10% functional.  I had to determine which C constructs generated what
code, and merely by changing the idiom of the code, I reduced it to less than
half the size.

>you need a good knowledge of the arcanes of the machine	- agreed
>(this is not given to everyone, nor it seems necessary to me).	- agreed
>And to be of useful help
>you must understand why the compiler has produced the actual output, i.e. to
>understand the internal mechanisms of the compiler.  Moreover, to actually help
>the compiler, you'd to be even more "clever" by knowing what each differences 
>will make to the output, thus knowing how the compiler reacts to each source 
>layout. (Kevin, "you" above doesn't mean yourself, of course)

The output of this compiler was pretty straightforward, with very little
optimization, and none from line-to-line; so I could and did easily determine
what the output would be for a given line of code.


>To me, this is not the right way for programming efficiency _as a whole_.

Hallelujah!


>Your scheme drives to a world where _all_ programmers must be experts in compiler
>theory (admittedly, all programmers involved with efficiency).  I don't feel like
>it: for me, it is much better to have compilers writters that do a better job
>while writting "cleverer" optimizers, perhaps at the cost of compile time, than
>to teach every programmers how to hardcode an over-optimisation of the output
>code.

I believe it's always best to be completely familiar with one's tools if one
expects to be the best possible at one's trade.  What you say is true for most
programmers, but I don't consider most programmers to be particularly good.
(That's no different than most of *any* profession; I'm not just picking on
programmers.  90% of *everything* is crud.)


>What I don't clearly see is whether C or Ada (or whatever else) is better or worse
>in the process of writing optimizers and improving them.
>Advantages of C are the small size of the language (not the same with C++ :) and
>its broad audience, which drives biggers teams of compilers writters to the point.

(This latter is why COBOL's ungainly source produces truly high-quality
executables.  All the man-years of work on the compilers and optimizers.)


>Advantages of Ada are the fewest number of side effects or branches, which help to
>compute execution paths.

Pointer aliasing kills most of the best optimizations possible.  Ada doesn't
have that problem.  Some C compilers now come with a switch that tells the
optimizer you're promising you haven't done any pointer aliasing.


>The demonstration is difficult

Part of my bias is that I'm an old hat, close-to-the-metal programmer.  I
resent any language features that "protect" me from the sharp edges by not
letting me near them.

-- 
#include <standard_disclaimer.h>
 _
Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up
Per the FCA, this email address may not be added to any commercial mail list