Related articles |
---|
Are C logical operators beging lowered too soon? cdg@nullstone.com (1995-02-13) |
Optimizing Across && And || bart@cs.uoregon.edu (1995-02-15) |
Re: Optimizing Across && And || preston@tera.com (1995-02-18) |
Re: Optimizing Across && And || bill@amber.ssd.csd.harris.com (1995-02-19) |
Re: Optimizing Across && And || bart@cs.uoregon.edu (1995-02-21) |
Re: Optimizing Across && And || whalley@fork.cs.fsu.edu (David Whalley) (1995-02-22) |
Re: Optimizing Across && And || bart@cs.uoregon.edu (1995-02-23) |
Re: Optimizing Across && And || bill@amber.ssd.csd.harris.com (1995-02-24) |
Re: Optimizing Across && And || glew@ichips.intel.com (1995-02-27) |
Re: Optimizing Across && And || bill@amber.ssd.csd.harris.com (1995-02-28) |
Re: Optimizing Across && And || bill@amber.ssd.csd.harris.com (1995-02-28) |
Re: Optimizing Across && And || ryg@summit.novell.com (1995-03-03) |
Re: Optimizing Across && And || leichter@zodiac.rutgers.edu (1995-03-07) |
Re: Optimizing Across && And || preston@tera.com (1995-03-08) |
[6 later articles] |
Newsgroups: | comp.compilers |
From: | bill@amber.ssd.csd.harris.com (Bill Leonard) |
Keywords: | C, optimize |
Organization: | Harris Computer Systems, Ft. Lauderdale FL |
References: | 95-02-110 95-02-143 |
Date: | Fri, 24 Feb 1995 15:25:47 GMT |
preston@tera.com (Preston Briggs) writes:
> The results were very disappointing. I found no available compiler
> (free, cheap, or expensive) that approached what I had ignorantly
> considered "the state of the art."
>
> Talking to various people about this, I've come across several
> possible explanations:
>
> C compilers don't work that hard, traditionally.
> More interesting would be a similar set of tests on Fortran
> compilers.
>
> Nobody in the industry reads recently published compiler papers.
> ^^^^^ or understands
> ^^^^^^^^^^^ or believes
>
> where only "reads" is a criticism of the industry.
> "Understands" and "believes" are meant to suggest
> possible weaknesses in the papers.
>
> None of the things I test really matter. The only things that
> matter these days are software pipelining and cache management.
>
> Writing optimizers is expensive and time consuming.
> Everything I tested was fairly old (had to be, since they were
> released products). How could I expect them to incorporate
> recent research results?
That last reason is the primary one for us. To say it a different way:
The main difficulty with the published research is that it often
requires a major redesign of one's optimizer (or entire back end).
Unfortunately, this means that most research can only be applied if one
is designing a new compiler or optimizer, which doesn't happen very
often.
Having once been responsible for (and still somewhat peripherally involved
with) the optimizer of a production compiler, I can say that mostly it is
this factor that keeps us from using published research results. We try
very hard to make our C compiler perform as much optimization as possible,
and we do read (and understand) published compiler papers.
In fact, when we designed our compiler back end, we based it on the best
published research we could find at the time. But of course now that is
over 10 years old. Fortunately, it seems we made a good choice, because
our compilers seem to do a very good job and are fairly easily enhanced and
retargeted.
Preston's comment about "None of these things really matter" is somewhat
true, though, I'd say. The big performance wins come from exploiting
parallelism, either in vector processing, parallel processing, or
pipelining, or reducing memory traffic, say through cache management. If
you have the choice of spending multiple man-years on an optimization that
gets you a 5% improvement versus an optimization that gets you 50%, which
will you choose?
--
Bill Leonard
Harris Computer Systems Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL 33309
Bill.Leonard@mail.hcsc.com
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.