Hardware doing the work (Was Re: Why C is much slower than Fortran)

Chris Reedy <creedy@mitretek.org>
2 Jun 1999 10:34:04 -0400

          From comp.compilers

Related articles
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 gneuner@dyn.com (1999-05-16)
Re: Why C is much slower than Fortran jhallen@world.std.com (1999-05-29)
Hardware doing the work (Was Re: Why C is much slower than Fortran) creedy@mitretek.org (Chris Reedy) (1999-06-02)
Re: Hardware doing the work (Was Re: Why C is much slower than Fortran jhallen@world.std.com (1999-06-03)
Re: Hardware doing the work (Was Re: Why C is much slower than Fortran sjc@netcom.com (1999-06-06)
Re: Hardware doing the work (Was Re: Why C is much slower than Fortran zalman@netcom.com (1999-06-06)
| List of all articles for this month |
From: Chris Reedy <creedy@mitretek.org>
Newsgroups: comp.compilers,comp.arch
Date: 2 Jun 1999 10:34:04 -0400
Organization: Compilers Central
References: <3710584B.1C0F05F5@hotmail.com> 99-05-011 99-05-037 99-05-057 99-05-142
Keywords: C, Fortran, architecture, comment

Joseph H Allen 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:
>
> [snipped discussion about hardware snooping memory contents]
>
> [Maybe or maybe not. This idea of registers that snoop on memory has been
> proposed for a long time, but except maybe for the new IA64 nobody's ever
> done it. -John]


For historical reasons, I find this argument unpersuasive. The problem
is that having hardware handle these issues leads one down a road that
ultimately ends in very CISCy designs like the ill-fated Intel
432. This kind of design fails, IMHO, because there is no mechanism
for the compiler to communicate knowledge obtained from static
analysis to the hardware so it can take advantage of it during
execution. The IA64 continues down the road (started by the original
RISC processors) of requiring _more_, not less, analysis by the
compiler in order to make the hardware run efficiently.


I believe that the "only true solution" will ultimately be
improvements in programming languages that improve developers ability
to communicate their intentions to the compiler so that the compiler
can do a better job of communicating the programmer's intentions to
the hardware.


    Chris


--
Dr. Christopher L. Reedy, Mail Stop Z551
Mitretek Systems, 7525 Colshire Drive, McLean, VA 22102-7400
Email: creedy@mitretek.org Phone: (703) 610-1615 FAX: (703) 610-1603
[I agree that better, probably higher level, languages will make it possible
to write faster and more reliable programs. But I think that it remains to
be seen whether the computers that will run them will be anywhere near as
complicated as IA64. I understand what they're trying to do, but this
smells a lot like the 432, doing all sorts of favors for the programmer
that the programmer doesn't end up wanting. -John]


Post a followup to this message

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