Re: Why C is much slower than Fortran

lindahl@pbm.com (Greg Lindahl)
2 Jun 1999 01:34:20 -0400

          From comp.compilers

Related articles
[5 earlier articles]
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)
Re: Why C is much slower than Fortran erik@arbat.com (Erik Corry) (1999-06-14)
[1 later articles]
| List of all articles for this month |
From: lindahl@pbm.com (Greg Lindahl)
Newsgroups: comp.lang.c++,comp.compilers,comp.arch
Date: 2 Jun 1999 01:34:20 -0400
Organization: a guest of Shadow Island Games
References: 99-05-142
Keywords: architecture, performance

jhallen@world.std.com (Joseph H Allen) writes:


> But what would be the speedup from this fix? If it's the same 50% to
> 100% speedup you get with using Fortran instead of C, I'd say that the
> extra hardware would be worth it.


You want to have everyone spend money on hardware that will never be
used? Right. I'd much rather have a software option to detect aliasing
mistakes. Aliasing mistakes are much less common than bounds mistakes;
how many hardware architectures have hardware bounds checking?


-- g


Post a followup to this message

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