Re: Why C is much slower than Fortran

hrubin@stat.purdue.edu (Herman Rubin)
9 May 1999 18:41:46 -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)
[9 later articles]
| List of all articles for this month |

From: hrubin@stat.purdue.edu (Herman Rubin)
Newsgroups: comp.lang.c++,comp.compilers
Date: 9 May 1999 18:41:46 -0400
Organization: Purdue University Statistics Department
References: <3710584B.1C0F05F5@hotmail.com> 99-04-105 99-04-107 99-05-011
Keywords: C, design, comment

Robert Harley <harley@corton.inria.fr> wrote:
>Our moderator wrote:


>> C lets you alias anything to anything, and that does indeed cause
>> optimization problems. The C9X draft has a "restrict" keyword [...]


>But ANSI C has a rule which disallows aliasing anything to anything!


>The rule is that an object in memory can only be accessed through
>lvalues of the same type, possibly in a struct or union, or of char
>type (here the types are considered modulo signed/unsigned and
>qualifiers).


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.


>Presumably the "alias=typed" flag uses this rule to optimise better.


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.


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.


>The restrict keyword can be used to give extra aliasing information,
>even between objects of the same type where ANSI aliasing does not
>help.
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
hrubin@stat.purdue.edu Phone: (765)494-6054 FAX: (765)494-0558
[I have to disagree. The language definition is a contract between the
programmer and the compiler writer. The programmer agrees to write in
the defined language, the compiler writer agrees to write it. If you want
to write in some language similar but not identical to the one that the
compiler accepts, you can hardly complain if the compiler doesn't do what
you want. But I'd still like to see a concrete examples of the macro
approach you've been advocating for many years. -John]


Post a followup to this message

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