Re: Why C is much slower than Fortran

gneuner@dyn.com (George Neuner)
16 May 1999 15:26:05 -0400

          From comp.compilers

Related articles
Re: Why C is much slower than Fortran sokal@holyrood.ed.ac.uk (Daniel Barker) (1999-04-18)
Re: Why C is much slower than Fortran telken@sgi.com (Thomas Elken) (1999-04-29)
Re: Why C is much slower than Fortran sokal@holyrood.ed.ac.uk (Daniel Barker) (1999-04-30)
Re: Why C is much slower than Fortran harley@corton.inria.fr (Robert Harley) (1999-05-03)
Re: Why C is much slower than Fortran hrubin@stat.purdue.edu (1999-05-09)
Re: Why C is much slower than Fortran terryg@uswest.net (1999-05-16)
Re: Why C is much slower than Fortran gneuner@dyn.com (1999-05-16)
Re: Why C is much slower than Fortran reid@micro.ti.com (Reid Tatge) (1999-05-20)
Re: Why C is much slower than Fortran jhallen@world.std.com (1999-05-29)
Re: Why C is much slower than Fortran hwstock@wizard.com (H.W. Stockman) (1999-06-02)
Re: Why C is much slower than Fortran erik@arbat.com (Erik Corry) (1999-06-02)
Re: Why C is much slower than Fortran lindahl@pbm.com (1999-06-02)
Re: Why C is much slower than Fortran sokal@holyrood.ed.ac.uk (Daniel Barker) (1999-06-02)
[9 later articles]
| List of all articles for this month |

From: gneuner@dyn.com (George Neuner)
Newsgroups: comp.lang.c++,comp.compilers
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
Keywords: design

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.


Post a followup to this message

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