Re: Why C is much slower than Fortran

Erik Corry <erik@arbat.com>
2 Jun 1999 01:33:53 -0400

          From comp.compilers

Related articles
[4 earlier articles]
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)
Re: Why C is much slower than Fortran djb@koobera.math.uic.edu (1999-06-02)
Re: Why C is much slower than Fortran Peter.Mayne@compaq.com (Peter Mayne) (1999-06-03)
Re: Why C is much slower than Fortran lindahl@pbm.com (1999-06-06)
Re: Why C is much slower than Fortran john@iastate.edu (1999-06-12)
[2 later articles]
| List of all articles for this month |

From: Erik Corry <erik@arbat.com>
Newsgroups: comp.lang.c++,comp.compilers,comp.arch
Date: 2 Jun 1999 01:33:53 -0400
Organization: University of Aarhus, Department of Computer Science (DAIMI)
References: <3710584B.1C0F05F5@hotmail.com> 99-05-011 99-05-037 99-05-057 99-05-142
Keywords: architecture, performance

In comp.arch Joseph H Allen <jhallen@world.std.com> wrote:
> We've been going over this argument for eons, with only two solutions
> provided:


> Fortran - generate fast, but possibly buggy code
> C, C++ - generate correct, but slow code


> The only true solution for the alias problem is going to come from hardware:


I saw a rather nice solution on Usenet a few years ago.


All functions where optimisations are impossible due to C's liberal
aliasing rules are automatically compiled in two versions, one where
Fortran aliasing is assumed and one where it isn't. When you call the
function the compiler calls the right one according to whether it can
prove that arguments are unaliased.


Of course, while you are compiling the non-aliased version of the
function you can usually call the non-aliased versions of any
sub/functions you need, so very little, if any checking is needed. At
some point you created the arrays/poiners involved, and at that point
your compiler can probably tell that they are not aliased. The linker
can fix things up if a non-alias version of the function doesn't
exist.


Has this been tried and failed?


Another solution is the support in the new C9x standard for specifying
that parameters are unaliased. This also means that C can be made to
run as fast as Fortran, though not quite as automatically. On the
other hand, making programmers think about these issues isn't
altogether a bad thing, given things like the aliasing bug in SPECfp95
mentioned on comp.arch today.


--
Erik Corry erik@arbat.com


Post a followup to this message

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