Re: Why C is much slower than Fortran

On 9 May 1999 18:41:46 -0400, hrubin@stat.purdue.edu (Herman Rubin)
wrote:
>
>As someone who has deliberately written programs which violate all
>sorts of restrictions of this type FOR SPEED, I must object to the
>attitude of the compiler writers that these things must not be done.
>
>If the compiler questions an action of the programmer, it should
>allow the programmer to decide. I believe that we need many kinds
>of optimization to be done which are now prohibited, and some of
>which are too difficult to be done "automatically", such as
>allowing alternative macros, possibly nested, to accomplish those
>actions which are desired, and optimizing the choice at the
>lowest level.


Compiler optimizations are meant to preserve the semantic meaning of
the program while transforming the syntactic form into an equivalent,
but faster form. When the programmer deliberately uses a form from
which the compiler cannot derive semantic meaning, the correct
optimizations that can be performed are limited.


The compiler MUST assume that the type you declared is indicative of
the way you intend to use the value. If, for example, you declare an
array of union types, the compiler has no way of knowing what type of
data will actually be present at run time and cannot be as aggressive
in optimizing access to the array. Then you the programmer get
disgusted with the performance, open code your own pointer arithmetic,
get a large performance boost and gripe about the quality of the
compiler. Huh? You were deliberately vague in your language and got
then angry when the compiler didn't understand !


Aliased values (the subject of this thread) cannot be cached in
registers across function calls because the *real* value in memory
might be changed without the cached value being changed. But aliasing
is a natural side effect of procedural code unless there is a
provision for global register optimization. Note that most compilers
do not really perform "global" register optimization - what they refer
to as global is really "global within the compilation module". True
inter-module optimization is rare.


You really have to write pure functional (mathematical) code to
guarantee no aliasing is present. Purely functional code (with no
side effects) can be optimized practically out of existence. OTOH,
code with no side effects generally isn't very useful ... but that's a
different issue.


>There are ways to speed up code which seem to be anathema to those
>who design languages and produce compilers. Should we not let the
>user inform the system what is going on, which seems not to have
>been considered by those providing tools.


Most compiler writers do understand how to accelerate code. Most
programmers do NOT understand that not all code can be accelerated.
The way to get the most out of your compiler is to write simple, clear
code and not use clever tricks.




As John said, the language specification is a contract. When you
breach the contract (deliberately or otherwise) by using language
outside the translator's domain, you can realistically only expect
"best effort" in the translation. People certainly don't expect more
from human translators. Why do they expect more from a robot?.




George Neuner
Dynamic Resolutions, Inc.

Return to the comp.compilers page.
Search the comp.compilers archives again.