[PATCH] Decrease integer-share-limit

[PATCH] Decrease integer-share-limit

[Richard Guenther]

This decreases the integer-share-limit to make sure the TREE_VEC we
allocate for the small cached integers has a reasonable size for
our GC memory allocator.  With the current value (256) and a reduced 
testcase from PR54146 we see

tree.c:1224 (build_int_cst_wide)                         40: 0.0%          
0: 0.0%   35443680: 8.7%   11635920:39.0%       9305

thus 39% overhead (oops, that TREE_VEC has size 2080).  Reducing
this to 251 yields

tree.c:1224 (build_int_cst_wide)                         40: 0.0%          
0: 0.0%   11698864: 3.0%      33696: 0.2%       9154

which is much nicer (size 2048 for signed ints, 1020 bytes on
32bit hosts if I counted correctly).

I'm queueing this for a bootstrap & regtest run.

Richard.

2012-08-16  Richard Guenther  <rguenther@suse.de>

	* params.def (integer-share-limit): Decrease from 256 to 251,
	add rationale.

Index: gcc/params.def
===================================================================
*** gcc/params.def	(revision 190442)
--- gcc/params.def	(working copy)
*************** DEFPARAM(PARAM_MAX_LAST_VALUE_RTL,
*** 638,648 ****
  
  /* INTEGER_CST nodes are shared for values [{-1,0} .. N) for
     {signed,unsigned} integral types.  This determines N.
!    Experimentation shows 256 to be a good value.  */
  DEFPARAM (PARAM_INTEGER_SHARE_LIMIT,
  	  "integer-share-limit",
  	  "The upper bound for sharing integer constants",
! 	  256, 2, 2)
  
  DEFPARAM (PARAM_SSP_BUFFER_SIZE,
  	  "ssp-buffer-size",
--- 638,649 ----
  
  /* INTEGER_CST nodes are shared for values [{-1,0} .. N) for
     {signed,unsigned} integral types.  This determines N.
!    Experimentation shows 251 to be a good value that generates the
!    least amount of garbage for allocating the TREE_VEC storage.  */
  DEFPARAM (PARAM_INTEGER_SHARE_LIMIT,
  	  "integer-share-limit",
  	  "The upper bound for sharing integer constants",
! 	  251, 2, 2)
  
  DEFPARAM (PARAM_SSP_BUFFER_SIZE,
  	  "ssp-buffer-size",

Re: [PATCH] Decrease integer-share-limit

[Paolo Carlini]

Hi,

On 08/16/2012 03:39 PM, Richard Guenther wrote:
> This decreases the integer-share-limit to make sure the TREE_VEC we
> allocate for the small cached integers has a reasonable size for
> our GC memory allocator.
Out of curiosity (just in case you hav two spare minutes) do you have 
any idea why this is so? I mean, naively one would think that allowing 
for any 8 bit constant would be a nice idea; puzzlingly, however the 
comment in the code says just "experimentation". I'm wondering if 
tweaking a bit the memory allocator itself could allow for the full 8 
bit range without a big memory waste...

Paolo.

Re: [PATCH] Decrease integer-share-limit

[Richard Guenther]

On Thu, 16 Aug 2012, Paolo Carlini wrote:

> Hi,
> 
> On 08/16/2012 03:39 PM, Richard Guenther wrote:
> > This decreases the integer-share-limit to make sure the TREE_VEC we
> > allocate for the small cached integers has a reasonable size for
> > our GC memory allocator.
> Out of curiosity (just in case you hav two spare minutes) do you have any idea
> why this is so? I mean, naively one would think that allowing for any 8 bit
> constant would be a nice idea; puzzlingly, however the comment in the code
> says just "experimentation". I'm wondering if tweaking a bit the memory
> allocator itself could allow for the full 8 bit range without a big memory
> waste...

The GC memory allocator works on "pages", there are not pages of
arbitrary size but only power-of-two sizes.  It's hard to improve
the allocator here.

Richard.

Re: [PATCH] Decrease integer-share-limit

[Jakub Jelinek]

On Thu, Aug 16, 2012 at 04:44:03PM +0200, Richard Guenther wrote:
> On Thu, 16 Aug 2012, Paolo Carlini wrote:
> > On 08/16/2012 03:39 PM, Richard Guenther wrote:
> > > This decreases the integer-share-limit to make sure the TREE_VEC we
> > > allocate for the small cached integers has a reasonable size for
> > > our GC memory allocator.
> > Out of curiosity (just in case you hav two spare minutes) do you have any idea
> > why this is so? I mean, naively one would think that allowing for any 8 bit
> > constant would be a nice idea; puzzlingly, however the comment in the code
> > says just "experimentation". I'm wondering if tweaking a bit the memory
> > allocator itself could allow for the full 8 bit range without a big memory
> > waste...
> 
> The GC memory allocator works on "pages", there are not pages of
> arbitrary size but only power-of-two sizes.  It's hard to improve
> the allocator here.

The allocations are either power-of-two, or a couple of extra listed sizes.
So, the alternative would be to add an extra size for the default integer
share limit vector.  See extra_order_size_table in ggc-page.c.  Of course
only provided there are many of those vectors.

	Jakub

Re: [PATCH] Decrease integer-share-limit

[Richard Guenther]

On Thu, 16 Aug 2012, Jakub Jelinek wrote:

> On Thu, Aug 16, 2012 at 04:44:03PM +0200, Richard Guenther wrote:
> > On Thu, 16 Aug 2012, Paolo Carlini wrote:
> > > On 08/16/2012 03:39 PM, Richard Guenther wrote:
> > > > This decreases the integer-share-limit to make sure the TREE_VEC we
> > > > allocate for the small cached integers has a reasonable size for
> > > > our GC memory allocator.
> > > Out of curiosity (just in case you hav two spare minutes) do you have any idea
> > > why this is so? I mean, naively one would think that allowing for any 8 bit
> > > constant would be a nice idea; puzzlingly, however the comment in the code
> > > says just "experimentation". I'm wondering if tweaking a bit the memory
> > > allocator itself could allow for the full 8 bit range without a big memory
> > > waste...
> > 
> > The GC memory allocator works on "pages", there are not pages of
> > arbitrary size but only power-of-two sizes.  It's hard to improve
> > the allocator here.
> 
> The allocations are either power-of-two, or a couple of extra listed sizes.
> So, the alternative would be to add an extra size for the default integer
> share limit vector.  See extra_order_size_table in ggc-page.c.  Of course
> only provided there are many of those vectors.

I doubt that a special size of 2080 / 1040 would be a good thing.
(I doubt we make very good use of most of the small integer share
vectors anyway, but that's for another thing ...)

I've now applied the patch.

Richard.