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

["Tim Behrendsen" <tim@airshields.com>]

William Clodius <clodius@hotspec.lanl.gov> wrote in article 
> There is no reason why a good compiler should generate worse code for
> an array access than for a pointer access. An array can be constructed
> by the compiler as a single block of memory whose access via indices
> is the same as through a pointer. Au contraire, because a pointer can
> be associated with any object of compatible type the analysis for a
> highly optimizing compiler is more difficult with pointers than with
> arrays. The problem with arrays in C is their lack of flexibility in
> term of dynamic memory allocation, that if they are associated with a
> pointer at any point in the scope alias analysis becomes more
> compicated for the compiler, and that when pased as an argument
> to a user defined function they are not distinguished from pointers.

I normally use IBM's C compiler under AIX.  I'm not sure where it
fits in the scheme of things, but it seems to do a pretty decent
job optimizing.

I had an [ex-]employee who wrote the slowest code on the face of
the earth.  Because of performance problems in our application,
I went through and analyzed his code.  The man almost never used
pointers, and almost always used array accesses.  These algorithms
were much more complex that the trivial examples we've been
talking about.

I rewrote the subroutines to use pointers, and with an eye toward
easy optimization by the compiler.  The algorithms used were
exactly the same; I just reworked the stylistic expression of them.
I didn't view the assembly language output, or anything processor
specific like that.  I simply coded things in a straightforward
data-flow sort of way, keeping the amount of context information
that the compiler needed at any one point in the subroutine to
a minimum.

I was easily able to get 3-4x performance improvements.

My point is that, yes, optimizers can do a good job in certain
circumstances, but out in the real world with very complex
subroutines, there is only so much that is possible.  Perhaps
I've only used compilers with bad optimizers, but isn't it
better to code programs for straightforward optimization and
not depend on what goes on behind the scenes?  Who goes back
and checks what the compiler produced? At least until you
begin profiling the program to figure out why the darn thing
is so slow ...

>   Run time profiling/compiler feedback: This can certainly provide
>   good information back to the compiler, but it seems a little
>   dangerous.  I have not used this type of optimization, so my
>   opinion means little in this case, except for just my general
>   impression.  Anything other than a trivial program is going
>   to be very difficult to simulate real-world conditions in order
>   to get an optimal result.  The downside is if your test conditions
>   are wrong, you may end up with a "most pessimum" optimization.
>
> But if your test conditions are wrong you have typically not
> appropriately tested all aspects of the code, including the
> correctness of its output, its robustness, and its general
> efficiency.

I disagree; I can test all the code paths without them necessarily
being executed the relative number of times that a real world
test would bring.  Take a relational DBMS; I can test all of the
SQL constructs that may be supported, but that doesn't mean that
I have real-world databases at my disposal in order to general
code optimization statistics.

> Actually C has relatively little in the way of data flow concepts as
> data flow is commonly understood. A true data flow language would
> avoid side effects in almost every context except I/O. Your example is
> full of side effects, some of which, particularly GetValue(arg), are
> difficult to optimize. Depending on the context a data flow language
> might have the syntax
> 
> array[1:n] = GetValye(arg(1:n));
> where (array /= 0) { ... }
> 
> in the above GetValue is required to not have side effects so that the
> definition 
> 
> array[1:n] = GetValye(arg(1:n));
> 
> can be understood as occuring in parallel. In C for full optimization
> the compiler has to determine that arg is not aliased with elements of
> array, and that GetValue has no side effects. Note that a highly
> pipelined architecture is comparable to a truly parallel architecture
> in many optimization issues.

I would imagine that C would rather stink when it comes to
automated parallization (but then, what doesn't?).  Ordering a
pipeline is much less complex of a problem that parallelizing
an algorithm, though!  If I'm not mistaken, however, it used to
be the case the parallelizing compilers were primarily for
FORTRAN, because of it's very primitive (read: lack of side
effects) nature.  This is somewhat dated knowledge on my part,
though. There may be more sophisticated solutions out there
nowadays.

I guess my point is not that any construct in C is automatically
able to be optimized to the limit; it's that it's possible
to code things in such a way that it gets optimized very well.

-- Tim Behrendsen (tim@airshields.com)