[TWEAK] More info on the gcc speedup issue

Greg Schafer gschafer at zip.com.au
Mon Feb 24 14:04:33 PST 2003


Hi

(provocative keyword in subject is completely intentional :-)

You'll recall the post I made here:-

http://archive.linuxfromscratch.org/mail-archives/lfs-dev/2003/02/0565.html

which pointed out a potential speedup when compiling large c++ projects.

Since then, the gcc guys have implemented some heuristics to dynamically
adjust the Garbage Collection parameters based on the physical RAM in the
machine it is running on and some other things. These changes have made it
into gcc CVS HEAD (3.4) and the 3.3 branch.

If you want to see what the parameters are for your machine:-

 - check out the 3.3 branch "-r gcc-3_3-branch" from CVS
 - compile and install somewhere safe e.g. --prefix=/opt/gcc-3.3
 - once installed, compile a test program using -v and it will show what
   paramaters were used.

On my 512MB machine it prints:-

"GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64481"


WARNING - FOR TESTERS AND TWEAKERS ONLY! NOT FOR PRODUCTION!

Keep in mind the GC was rewritten somewhat in 3.3 but the initial tests on
3.2.x show the gains to be worthwhile. Therefore if you want to test out
3.2.x you'll need to find this part of ggc-page.c:-

/* Skip garbage collection if the current allocation is not at least
   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)

/* 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)

And amend accordingly. So in my case, I'd need to change to something like:-

#define GGC_MIN_EXPAND_FOR_GC (1.6)
#define GGC_MIN_LAST_ALLOCATED (64 * 1024 * 1024)

The first one means 60% instead of default 30%. The second one means 64MB
instead of default 4MB.

WARNING! - I HAVEN'T TESTED THE ABOVE YET! I have only tested the initial
suggestion of bumping GGC_MIN_LAST_ALLOCATED to 16MB and that works fine.
The gcc guys say this is not a code generating change. It is only a "compile
time" performance tweak. But test at your own risk.

Yes, this is a TWEAK and I don't care. Tweak bashers can go to hell. My
record stands for itself. If the only thing that people can pick holes in is
my choice of words like "tweak" and "pure" then I'm doing alright.

Greg


ps - here is the relevant bits from the 3.3 info page:-

    `ggc-min-expand'
          GCC uses a garbage collector to manage its own memory
          allocation.  This parameter specifies the minimum percentage
          by which the garbage collector's heap should be allowed to
          expand between collections.  Tuning this may improve
          compilation speed; it has no effect on code generation.

          The default is 30% + 70% * (RAM/1GB) with an upper bound of
          100% when RAM >= 1GB.  If `getrlimit' is available, the
          notion of "RAM" is the smallest of actual RAM, RLIMIT_RSS,
          RLIMIT_DATA and RLIMIT_AS.  If GCC is not able to calculate
          RAM on a particular platform, the lower bound of 30% is used.
          Setting this parameter and `ggc-min-heapsize' to zero causes
          a full collection to occur at every opportunity.  This is
          extremely slow, but can be useful for debugging.

    `ggc-min-heapsize'
          Minimum size of the garbage collector's heap before it begins
          bothering to collect garbage.  The first collection occurs
          after the heap expands by `ggc-min-expand'% beyond
          `ggc-min-heapsize'.  Again, tuning this may improve
          compilation speed, and has no effect on code generation.

          The default is RAM/8, with a lower bound of 4096 (four
          megabytes) and an upper bound of 131072 (128 megabytes).  If
          `getrlimit' is available, the notion of "RAM" is the smallest
          of actual RAM, RLIMIT_RSS, RLIMIT_DATA and RLIMIT_AS.  If GCC
          is not able to calculate RAM on a particular platform, the
          lower bound is used.  Setting this parameter very large
          effectively disables garbage collection.  Setting this
          parameter and `ggc-min-expand' to zero causes a full
          collection to occur at every opportunity.
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list