[TWEAK] More info on the gcc speedup issue
gschafer at zip.com.au
Mon Feb 24 14:04:33 PST 2003
(provocative keyword in subject is completely intentional :-)
You'll recall the post I made here:-
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.
ps - here is the relevant bits from the 3.3 info page:-
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.
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