[RFA] update ggc_min_heapsize_heuristic()
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. Compile times of large C++ projects improve by over 10% due to this change. What do you think? Thanks. diff --git a/gcc/ggc-common.c b/gcc/ggc-common.c index b4c36fb0bbd4..91e121d7dafe 100644 --- a/gcc/ggc-common.c +++ b/gcc/ggc-common.c @@ -810,7 +810,7 @@ ggc_min_heapsize_heuristic (void) phys_kbytes = MIN (phys_kbytes, limit_kbytes); phys_kbytes = MAX (phys_kbytes, 4 * 1024); - phys_kbytes = MIN (phys_kbytes, 128 * 1024); + phys_kbytes = MIN (phys_kbytes, 1000 * 1024); return phys_kbytes; } -- Markus
Re: [RFA] update ggc_min_heapsize_heuristic()
On Sun, Apr 9, 2017 at 4:41 PM, 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. > > Compile times of large C++ projects improve by over 10% due to this > change. How does memory use change? > What do you think? Personally I think it's a bit late for GCC 7. Richard. > Thanks. > > > diff --git a/gcc/ggc-common.c b/gcc/ggc-common.c > index b4c36fb0bbd4..91e121d7dafe 100644 > --- a/gcc/ggc-common.c > +++ b/gcc/ggc-common.c > @@ -810,7 +810,7 @@ ggc_min_heapsize_heuristic (void) >phys_kbytes = MIN (phys_kbytes, limit_kbytes); > >phys_kbytes = MAX (phys_kbytes, 4 * 1024); > - phys_kbytes = MIN (phys_kbytes, 128 * 1024); > + phys_kbytes = MIN (phys_kbytes, 1000 * 1024); > >return phys_kbytes; > } > > -- > Markus
Re: [RFA] update ggc_min_heapsize_heuristic()
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). > 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. > What do you think? I wonder if it's possible to reap most of the compile time benefit with a bit more modest gc threshold increase? Thanks. Alexander
Re: [RFA] update ggc_min_heapsize_heuristic()
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. But you can observe the effect also with a single big C++ file like tramp3d-v4.cpp. On my old machine: --param ggc-min-heapsize=131072 : 26.97 secs / 711MB peak memory (current default) --param ggc-min-heapsize=393216 : 26.04 secs / 886MB peak memory --param ggc-min-heapsize=524288 : 25.37 secs / 983MB peak memory --param ggc-min-heapsize=100 : 25.36 secs / 990MB peak memory > > What do you think? > > I wonder if it's possible to reap most of the compile time benefit with a bit > more modest gc threshold increase? 512MB looks like the sweet spot. And of course one is basically trading memory usage for compile time performance. -- Markus
Re: [RFA] update ggc_min_heapsize_heuristic()
On 2017.04.09 at 20:23 +0200, Richard Biener wrote: > On Sun, Apr 9, 2017 at 4:41 PM, 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. > > > > Compile times of large C++ projects improve by over 10% due to this > > change. > > How does memory use change? It increases e.g. 25% on tramp3d-v4.cpp when increasing ggc-min-heapsize from 131072 (default) to 524288. -- Markus
Re: [RFA] update ggc_min_heapsize_heuristic()
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 -- Markus
Renaming moutline-msabi-xlogues to mcall-ms2sysv-xlogues
After careful thought, I'm renaming -moutline-msabi-xlogues to -mcall-ms2sysv-xlogues and would appreciate some feedback or any objections. This is a new gcc8 feature that emits prologues and epilogues that call or tail-call stubs in libgcc when 64-bit ms_abi function calls a sysv_abi function and is required to consider 10 SSE registers clobbered. I haven't been terribly happy with the name "moutline-msabi-xlogues." First of all, as Sandra has pointed out, the language used in gcc for in-line verse out-of-line is always "inline" or "no-inline" and never "outline". Yet changing this to "mno-inline-msabi-xlogues" seems to get further from describing what it does. So I've been browsing through the gcc docs for other archs and noticed that they all use different terminology for their options that call or jump to stubs as a substitute for emitting inline saves & restores for registers. ARC: -mno-millicode AVR: -mcall-prologues V850: -mno-prolog-function(enabled by default) I think that PowerPC/rs6000 does this without an option (or maybe in -Os?). What makes this feature different is that it has a vary narrow scope, so I'm thinking "mcall-ms2sysv-xlogues" is a good and brief descriptor. Any comments, objections? Thanks, Daniel
gcc-7-20170409 is now available
Snapshot gcc-7-20170409 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20170409/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 246794 You'll find: gcc-7-20170409.tar.bz2 Complete GCC SHA256=c7ac21e2d824a2474b07b93658521745fa23bfb1cf5110205af3e61e783e29a4 SHA1=9d1862389ba25ac367e0823c9a64f75ceb7f504b Diffs from 7-20170402 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
