This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Suggestions for improving gcc 3.2 compilation speed?
- From: Joel Sherrill <joel dot sherrill at OARcorp dot com>
- To: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Cc: awinkler at maad dot com, gcc at gcc dot gnu dot org
- Date: Fri, 28 Feb 2003 08:16:22 -0600
- Subject: Re: Suggestions for improving gcc 3.2 compilation speed?
- Organization: OAR Corporation
- References: <3E5E99B5.8000705@maad.com> <200302280358.WAA25372@caip.rutgers.edu>
"Kaveh R. Ghazi" wrote:
>
> > I've been running gcc 2.95.3 on a 1Ghz/512MB RAM PC running RedHat
> > 7.2. It takes 20 minutes to compile my application, so I recently got
> > a new computer to reduce the time I wait for compiles. This new
> > computer is a 2.8 Ghz CPU/1GB RAM running RedHat 8.0. Since RedHat 8.0
> > comes with gcc 3.2 I figured I'd give it a try. It takes 20 minutes to
> > compile my application. (!!!)
> >
> > I'm a little frustrated that the compilation speed is so slow with gcc
> > 3.2, especially since this is a commercial application (i.e., this is
> > my job). Is there anything I can do to improve the compilation speed?
> > Will newer gcc releases be as fast as gcc 2.95.3 (or faster)? Or is my
> > best bet to stick with 2.95.3?
>
> With 1GB of RAM, try this patch it might help some. But on machines
> with less memory it may cause thrashing, so it's not a general
> solution.
Have you tried using some parallelism in your build? I work on an
application with 425K lines of mostly C++ which we build for two
target OSes. It takes about 20 minutes on a 2.4 Ghz dual Xeon
with 2 GB RAM. We added a -j option to make and the build time
dropped to a little under 8 minutes. The parallel make keeps the
CPU busy while the OS is accessing the disk to read source files
and write objects. The difference in CPU utilization is incredible.
The non-parallel make only hit about 25% CPU utiliization. The
parallel version stays close to 100% for most of the build.
> I'd appreciate hearing from you what effect it has.
>
> Thanks,
> --Kaveh
>
> PS: What language is your app written in?
>
> diff -rup orig/egcc-3.2-CVS20030223/gcc/ggc-page.c egcc-3.2-CVS20030223/gcc/ggc-page.c
> --- orig/egcc-3.2-CVS20030223/gcc/ggc-page.c 2002-01-05 17:11:21.000000000 -0500
> +++ egcc-3.2-CVS20030223/gcc/ggc-page.c 2003-02-23 19:13:27.726803129 -0500
> @@ -344,11 +344,11 @@ static struct globals
> this factor times the allocation at the end of the last collection.
> In other words, total allocation must expand by (this factor minus
> one) before collection is performed. */
> -#define GGC_MIN_EXPAND_FOR_GC (1.3)
> +#define GGC_MIN_EXPAND_FOR_GC (2.0)
>
> /* Bound `allocated_last_gc' to 4MB, to prevent the memory expansion
> test from triggering too often when the heap is small. */
> -#define GGC_MIN_LAST_ALLOCATED (4 * 1024 * 1024)
> +#define GGC_MIN_LAST_ALLOCATED (128 * 1024 * 1024)
>
> /* Allocate pages in chunks of this size, to throttle calls to memory
> allocation routines. The first page is used, the rest go onto the
--
Joel Sherrill, Ph.D. Director of Research & Development
joel at OARcorp dot com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985