Re: C is 'better' than Ada because...

[ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe)]

In article <01bb7bfc$3c5ca460$96ee6fcf@timhome2> "Tim Behrendsen"
<tim@airshields.com> writes: 

>   The one big advantage C has traditionally had over other
>   languages is efficient compilation.  The reason is that 'C' is one
>   of the few languages that provides concepts such as register
>   variables to give hints to the compiler.

I would remind readers of the figures I recently posted for a numerical
integration program on an UltraSparc:
	C:      13   seconds (SPARCompiler C SC4.0)
	Scheme:  5   seconds (Stalin 0.6, then SPARCompiler C)
Well, those figures are out of date.
	Scheme:  0.9 seconds (Stalin 0.7, then SPARCompiler C)

>   Yes, you can wave your hand and say, "well, the compiler
>   should take care of that".  But then, reality rears its head, and
>   we realize that there are *no* compilers that are that smart.
>   Here's an old saying that I just made up ...

>   Behrendsen's Law: "All optimizers are crap."

There are some truly *awesome* modern compilers.  One of the reasons that
Stalin gets the time way down is that it optimises the *whole* program,
including specialising the run-time system for this particular program.
It does some truly *amazing* things that no sane programmer would dream
of doing, or having done, would ever be willing to do a second time.
The VORTEX compiler for Cecil also does truly awesome things.  One of
the things VORTEX does and Stalin doesn't do is that it will use the
run-time profile from a previous execution of the program to guide its
optimisation this time round.  Guess what:  SPARCompiler C can do it too.
(MIPS have been doing it for years.)  Human programmers just don't do this
except on code of the utmost importance, and then they just don't live
long enough or work fast enough to keep their tuning up to date with
changes to the program.

I further note that the SPARCompiler C compiler can optimise *differently*
for several versions of the SPARC, several versions of the PowerPC, and
several versions of the 80*86.  On the SPARC, it wants to know the size of
the cache!  I haven't the slightest clue what it does with it, and what I
know from the literature of what it *could* do with that information tells
me that once again, it is taking advantage of information that the average
programmer does not have and could not use if s/he had it.  (To start with,
I didn't even know what model of SPARC I have; I had to ask the compiler
what it thought -native meant!)

One of the ways SPARCompiler C gets better performance than earlier C
compilers from Sun is that it *ignores* programmer-supplied 'register'
declarations (I think there is a command line option to honour them, but
I haven't ever bothered using it).  And Scheme, of course, has never had
such things.

>   We will never have an optimizer that can do as good a job
>   as human optimization until we get "strong AI", but that would
>   take an actual science of AI to exist (let's not get started on
>   *that*!).  C is one of few languages that recognizes this.

You just haven't a clue about the things modern compilers can do, and do do.
Loop unrolling, strip-mining, vectorising, analysing the class hierarchy so
as to replace dynamic dispatch by inlined code, branch prediction based on
profiles, AND IT ALL HAPPENS EVERY TIME I RUN THE COMPILER.  What we get
right now is better than almost every programmer there is, and we get it
far cheaper.

And you know what?  C is one of the *harder* languages to optimise!
-- 
Fifty years of programming language research, and we end up with C++ ???
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.