[TWEAK] More info on the gcc speedup issue

Jonathan Serafini serafini.jonathan at teccart.qc.ca
Thu Feb 27 07:20:43 PST 2003


Just wanted to say ..
I tried this out for the heck of it with the values of :
	#define GGC_MIN_EXPAND_FOR_GC (1.6)
	#define GGC_MIN_LAST_ALLOCATED (64 * 1024 * 1024)
**not on linux box atm.. So this is approximate.. Coming from a
seriously tired and addled mind**
**didnt bother tweaking the above.. My box has got 600+ Mb of ram so
this works for me**

Chapter 5 - Purelfs buildtime was about 1h40 WITH the mod and about
2h20+ WITHOUT...

All in all its a nice performance gain and I havnt had any probs..

Final comments : COOL ! =D

-----Original Message-----
From: lfs-dev-bounce at linuxfromscratch.org
[mailto:lfs-dev-bounce at linuxfromscratch.org] On Behalf Of Greg Schafer
Subject: [TWEAK] More info on the gcc speedup issue

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.

-- 
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