This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Suggestions for improving gcc 3.2 compilation speed?



"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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]