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: Speeding up GC


I ran a few more tests (Pentium III with 256mb ram, 1Ghz).

1. I set minimum storage used so that gc_collect never did anything. This
increased the build time by about 3% compared to normal. The largest program
insn-recog.c just fit into my 256mb of ram. If the build is 3% slower, then
GCC must be about 5% slower because phase 1 of the build is the native
compiler, and there are various shell scripts and other programs that run as
well, diluting the speedup, so the GCC speedup is more than the bootstrap
speedup.

2. Replace ggc-page.c with a routine that just allocated everything with
xmalloc. I had to add a 4 bytes header for the storage length because
gc_realloc is used in half a dozen places. This bootstrapped about 3% faster
than the normal bootstrap, meaning the compiler was about 5% faster.

Implications from this:

1. GC overhead is high. Allocating with xmalloc was 5% faster, even though no
storage was freed. It was 10% faster than running the GC allocation code but
not freeing anything. So the combined effect of the extra path length from
gc_alloc and the cache hit from non-locality is at least 10%. In fact it is
probably more, because I had to allocate the extra 4 bytes, and so I used more
memory, and additionally, I did not align the storage which usually would have
a performance impact. None of the above overhead of GC is captured in the GCC
reports, which therefore greatly understate the cost of GC.

2. GC overhead in -O0 is very high. The percentage of GC overhead in
non-optimised compiles is far greater, based on my earlier profiles. It is
reported (by gprof) as ~10-12%. So it is probably more like 20-25% (based on
ratios above), which is very large.

3. A new GCC default and option are needed. It would in my opinion be a good
idea to have a heuristic which said

- If the file is small, do not do GC. Instead do simple contiguous allocation.
We should align things properly, and also we should change gc_realloc to
require the callers to provide the old length so we don't have to store the
length.

- If the file is very large, use GC. The default size could be a configure
option.

- Allow user to override and force use or non-use of GC.

I would clean up and submit this patch but it is just to hard too get patches
onto gcc if you do not have write access.

4. This all makes it appear that there are a lot of performance wins to be
found in GCC. Future changes to GC should be done after testing of the effect
on performance.

Tim Josling


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