low level optimization

Dan Bernstein brnstnd at kramden.acf.nyu.edu
Wed Apr 17 11:45:59 AEST 1991


In article <21527 at lanl.gov> jlg at cochiti.lanl.gov (Jim Giles) writes:
> We've been through this again and again.  C can't hold a candle to
> Fortran for array manipulation because Fortran is free to assume that
> array arguments to procedures are _not_ aliased to each other or to
> globals.

Except on vector machines, Fortran array code can be converted into C
pointer code which will run at the same speed *without* the optimizer
that Fortran requires. Aliasing does not inhibit this (usually rather
mechanical) translation. On vector machines aliasing is a problem, but
they provide adequate directives to control aliasing.

On the other hand, no matter how powerful your Fortran optimizer is,
there will be a pointer program P for which any array code translation
will be SLOWER. This is a simple application of the halting problem.
Most importantly, that pointer program P comes up frighteningly often in
practice.

Looks to me like C wins here.

> There is not a single significant optimization
> technique that is not inhibited to some extent or other by aliasing.

Hand optimization. Try it, and your programs will run a lot faster for
relatively little effort.

> Some experimental systems allow the
> compiler to do restricted types of interprocedural analysis to detect
> aliasing - this is non-standard since it violates separate compilation
> constraints.

The second half of that statement is incorrect. The compiler must act AS
IF the code had been separately compiled. This in no way prohibits
interprocedural optimizations. Read the standard (or any of the
available elementary introductions to it) to learn about the as-if rule.

---Dan



More information about the Comp.lang.c mailing list