This is the mail archive of the
mailing list for the GCC project.
Re: [RFA] update ggc_min_heapsize_heuristic()
- From: Trevor Saunders <tbsaunde at tbsaunde dot org>
- To: Markus Trippelsdorf <markus at trippelsdorf dot de>
- Cc: Alexander Monakov <amonakov at ispras dot ru>, gcc at gcc dot gnu dot org
- Date: Mon, 10 Apr 2017 06:00:55 -0400
- Subject: Re: [RFA] update ggc_min_heapsize_heuristic()
- Authentication-results: sourceware.org; auth=none
- References: <20170409144125.GA10606@x4> <alpine.LNX.email@example.com> <20170409191019.GA294@x4> <20170409200621.GC294@x4>
On Sun, Apr 09, 2017 at 10:06:21PM +0200, Markus Trippelsdorf wrote:
> On 2017.04.09 at 21:10 +0200, Markus Trippelsdorf wrote:
> > On 2017.04.09 at 21:25 +0300, Alexander Monakov wrote:
> > > On Sun, 9 Apr 2017, Markus Trippelsdorf wrote:
> > >
> > > > The minimum size heuristic for the garbage collector's heap, before it
> > > > starts collecting, was last updated over ten years ago.
> > > > It currently has a hard upper limit of 128MB.
> > > > This is too low for current machines where 8GB of RAM is normal.
> > > > So, it seems to me, a new upper bound of 1GB would be appropriate.
> > >
> > > While amount of available RAM has grown, so has the number of available CPU
> > > cores (counteracting RAM growth for parallel builds). Building under a
> > > virtualized environment with less-than-host RAM got also more common I think.
> > >
> > > Bumping it all the way up to 1GB seems excessive, how did you arrive at that
> > > figure? E.g. my recollection from watching a Firefox build is that most of
> > > compiler instances need under 0.5GB (RSS).
> > 1GB was just a number I've picked to get the discussion going.
> > And you are right, 512MB looks like a good compromise.
> > > > Compile times of large C++ projects improve by over 10% due to this
> > > > change.
> > >
> > > Can you explain a bit more, what projects you've tested?.. 10+% looks
> > > surprisingly high to me.
> > I've checked LLVM build times on ppc64le and X86_64.
> Here are the ppc64le numbers (llvm+clang+lld Release build):
> --param ggc-min-heapsize=131072 :
> ninja -j60 15951.08s user 256.68s system 5448% cpu 4:57.46 total
> --param ggc-min-heapsize=524288 :
> ninja -j60 14192.62s user 253.14s system 5527% cpu 4:21.34 total
seriously nice! that said I do unfortunately see where the its too late
in the release cycle argument is coming from, but I think we should at
least do something for gcc 8.