This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 4.1: Buildable on GHz machines only?
- From: Joe Buck <Joe dot Buck at synopsys dot COM>
- To: "H. J. Lu" <hjl at lucon dot org>
- Cc: Andrew Haley <aph at redhat dot com>,Alexandre Oliva <aoliva at redhat dot com>,David Edelsohn <dje at watson dot ibm dot com>, Andreas Schwab <schwab at suse dot de>,Richard Earnshaw <rearnsha at gcc dot gnu dot org>,Andrew Pinski <pinskia at physics dot uc dot edu>,Paul Koning <pkoning at equallogic dot com>, s dot bosscher at student dot tudelft dot nl,gcc at gcc dot gnu dot org, matt at 3am-software dot com, cow at compsoc dot man dot ac dot uk
- Date: Wed, 4 May 2005 09:00:05 -0700
- Subject: Re: GCC 4.1: Buildable on GHz machines only?
- References: <17008.59023.361787.925505@cuddles.cambridge.redhat.com> <jebr7z80nt.fsf@sykes.suse.de> <17009.2368.986169.753001@cuddles.cambridge.redhat.com> <200504281609.j3SG9ZD27524@makai.watson.ibm.com> <20050428164727.GB30649@synopsys.com> <200504281654.j3SGs0D27158@makai.watson.ibm.com> <oracncw0a1.fsf@livre.redhat.lsd.ic.unicamp.br> <20050503220342.GA23969@synopsys.com> <17016.41624.799846.161219@cuddles.cambridge.redhat.com> <20050504134157.GA5261@lucon.org>
On Wed, May 04, 2005 at 06:41:59AM -0700, H. J. Lu wrote:
> On Wed, May 04, 2005 at 11:23:20AM +0100, Andrew Haley wrote:
> > Joe Buck writes:
> > > Richard Henderson showed that the libjava build spends 2/3 of its time
> > > in libtool, and that his hand-hacked (but not portable) modification to
> > > invoke the appropriate binutils commands directly gave a huge speedup.
> >
> > Yes, but please bear in mind that this *only* happens when you have a
> > machine with huge RAM. For other people with small RAM, the link
> > itself is an important factor. Also, other people have found that the
> > libtool script consumes a smaller part of total execution time: rth's
> > measurements are at one extreme of the scale.
>
> We have been working on linker speed. If you have a number to show
> that the GNU linker is very slow on certain things, I will take a
> look.
I'm glad you're looking at speeding up the linker. Please make sure to
look at memory consumption as well, since performance falls off a cliff
once the working set exceeds physical memory. A good test would be to
bootstrap gcc on a machine with 256M, or that is artificially limited to
256M (I seem to recall that you can tell a Linux kernel you have only a
given amount of memory).