Re: open64 versus gcc

Brooks Moses <>
3 Dec 2006 21:33:44 -0500

          From comp.compilers

Related articles
[6 earlier articles]
Re: open64 versus gcc (Diego Novillo) (2006-11-29)
Re: open64 versus gcc (A.L.) (2006-12-01)
Re: open64 versus gcc (A.L.) (2006-12-01)
Re: open64 versus gcc (Jonathan Thornburg -- remove -animal to reply) (2006-12-03)
Re: open64 versus gcc (Diego Novillo) (2006-12-03)
Re: open64 versus gcc (Greg Lindahl) (2006-12-03)
Re: open64 versus gcc (Brooks Moses) (2006-12-03)
Re: open64 versus gcc (Gary Oblock) (2006-12-03)
Re: open64 versus gcc (ST) (2006-12-06)
| List of all articles for this month |

From: Brooks Moses <>
Newsgroups: comp.compilers
Date: 3 Dec 2006 21:33:44 -0500
Organization: Stanford University
References: 06-11-09406-11-100 06-11-104 06-11-113 06-11-120 06-11-124 06-12-015 06-12-016
Keywords: arithmetic, GCC
Posted-Date: 03 Dec 2006 21:33:44 EST

A.L. wrote:
> On 1 Dec 2006 09:49:03 -0500, "A.L." <> wrote:
>> [GCC is fine for systems programming. I've never done serious
>> numerical work in it, so you may well be right about that. -John]
> Disclaimer: My expiments with gcc and numerical computations ended
> in 2003. Maybe since this time something changedIf there is somebody
> here who is using the up-to-date version of gcc for large scale,
> intensive floating point number crunching, please share the
> experience.

Well, it's benchmarks rather than a real-world experience, but
Polyhedron's Fortran benchmarks are specifically aimed at "large-scale
intensive floating-point number crunching". On those, gfortran (the gcc
Fortran front-end) comes in, on average, about 25-30% slower than the
best compilers -- but there's a fair bit of variation; in a fair number
of cases it's about as fast as anything else.

It should also be noted that this is testing GCC's Fortran front end
(gfortran), of course, rather than the far-more-mature C or C++
compilers; that probably accounts for some of the slowness. (Compare,
for instance, the g95 compiler, which also uses the gcc backend but
doesn't have nearly as much optimization work on the frontend.) In
particular, I believe the notable slowness on the AERMOD benchmark has
been traced to one particular inner loop optimization that's missed in
the front end.

Actual results (for P4 on Linux) here, and this page links AMD results:

At the very least, it's certainly quite usable for serious numerical
work; the OpenFOAM CFD package (which I use) uses gcc, and seems to work
quite acceptably well, though that doesn't mean too much since I haven't
actually compared the results with other compilers.

- Brooks

The "bmoses-nospam" address is valid; no unmunging needed.

Post a followup to this message

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