C vs. FORTRAN

[Jim Giles]

In article <3136 at phoenix.Princeton.EDU>, mjschmel at phoenix.Princeton.EDU (Michael J. Schmelzer) writes:
> [...]
> Given that C produces assembly code very similar to the source
> code it came from, why should it be any slower than the object
> code generated by a FORTRAN compiler?

Who says that efficient object code needs to resemble the source very
much?  In fact, on pipelined machines, good object code always appears
quite confused compared to the source - all those code movement
optimizations.  Actually, even without pipelining, the object code
should be quite different - constant folding, common expression
elimination, strength reduction, and register allocation can all
rearrange the code quite a bit.  It may be true that many C compilers
produce object code that resembles source, but this is probably a
deficiency of those compilers.

> Furthermore, wouldn't optimizers eliminate any difference between
> their final products?

Depends on what type of optimization you're talking about.  The multi-
dimensioned array problems (which have seen so much recent discussion)
are hard for C to optimize because the language simple doesn't have
the dependency information available to it (not even in source).
Also, many C compilers throw out much of the dependency information at
an early stage in the compile process - no later optimization can get
it back.  Of course, the compiler could optimize anyway (by assuming
that no dependencies exist), but this would break code that really DID
contain dependencies.

Of course, C may have the reputation of being slow simply because the
compilers available to most people don't optimize very well.  Certainly
all the C compilers I've seen could stand some improvement (the famous
pcc - pessimizing C compiler, for example).

J. Giles
Los Alamos