Re: Why C is much slower than Fortran

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

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