This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Faster compilation speed
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Matt Austern <austern at apple dot com>
- Cc: "David S. Miller" <davem at redhat dot com>, <dje at watson dot ibm dot com>,<mrs at apple dot com>, <gcc at gcc dot gnu dot org>
- Date: Mon, 12 Aug 2002 17:27:03 -0400 (EDT)
- Subject: Re: Faster compilation speed
- Reply-to: dberlin at dberlin dot org
On Mon, 12 Aug 2002, Matt Austern wrote:
> On Monday, August 12, 2002, at 12:43 PM, David S. Miller wrote:
>
> > From: Matt Austern <austern@apple.com>
> > Date: Mon, 12 Aug 2002 12:47:30 -0700
> >
> > And yes, we're aware that many gains are possible only
> > if we rewrite the parser or redesign the tree structure. The
> > only reason we haven't started on rewriting the parser is
> > that someone else is already doing it.
> >
> > So work on an attempt at RTL refcounting, the patch below is a place
> > to start.
>
> Thanks for the pointer, that's a useful starting point.
>
> But, at the risk of sounding like a broken record... Do
> we have benchmarks showing that RTL gc is one of
> the major causes of slow compile speed?
>
> At the moment, we're spending a lot of time doing
> benchmarking and trying to figure out just where the
> time is going. I realize this has its limitations, that
> poorly designed data structures may end up resulting
> in tiny bits of overhead everywhere even if they never
> show up in a profile. But at least we can try to
> understand what kinds of programs are especially
> bad. (One interesting fact, for example: one file that
> we care a lot about takes twice as long to compile with
> the C++ front end than with the C front end.)
Well, the tools for this stuff are much better on osx than on Linux, so
you guys are probably ahead of others in figuring out whether GC is really
bad for us.
You can easily get numbers like data cache miss cycles, etc, and graph
them nicely with MONster.
-Dan