|Re: Why C is much slower than Fortran firstname.lastname@example.org (Daniel Barker) (1999-04-18)|
|Re: Why C is much slower than Fortran email@example.com (Thomas Elken) (1999-04-29)|
|Re: Why C is much slower than Fortran firstname.lastname@example.org (Daniel Barker) (1999-04-30)|
|Re: Why C is much slower than Fortran email@example.com (Robert Harley) (1999-05-03)|
|Re: Why C is much slower than Fortran firstname.lastname@example.org (1999-05-09)|
|Re: Why C is much slower than Fortran email@example.com (1999-05-16)|
|Re: Why C is much slower than Fortran firstname.lastname@example.org (1999-05-16)|
|Re: Why C is much slower than Fortran email@example.com (Reid Tatge) (1999-05-20)|
|Re: Why C is much slower than Fortran firstname.lastname@example.org (1999-05-29)|
|Re: Why C is much slower than Fortran email@example.com (H.W. Stockman) (1999-06-02)|
|Re: Why C is much slower than Fortran firstname.lastname@example.org (Erik Corry) (1999-06-02)|
|Re: Why C is much slower than Fortran email@example.com (1999-06-02)|
|Re: Why C is much slower than Fortran firstname.lastname@example.org (Daniel Barker) (1999-06-02)|
|[9 later articles]|
|From:||email@example.com (George Neuner)|
|Date:||16 May 1999 15:26:05 -0400|
|Organization:||Dynamic ReSolutions, Inc.|
|References:||<3710584B.1C0F05F5@hotmail.com> 99-04-105 99-04-107 99-05-011 99-05-037|
On 9 May 1999 18:41:46 -0400, firstname.lastname@example.org (Herman Rubin)
>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
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
>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?.
Dynamic Resolutions, Inc.
Return to the
Search the comp.compilers archives again.