Re: Speeding up GC

[Guillermo Ballester Valor <gbv at oxixares dot com>]

Hi,

I'm not gcc developer, but this mail seems to me a lot promising. Is there any 
strong problem with the Tim's allocation sugestions?.  

Guillermo.

On Saturday 17 August 2002 14:12, Tim Josling wrote:
> 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

-- 
Guillermo Ballester Valor
gbv@oxixares.com
Ogijares, Granada  SPAIN