* [PATCH] Decrease integer-share-limit
@ 2012-08-16 13:41 Richard Guenther
2012-08-16 14:37 ` Paolo Carlini
0 siblings, 1 reply; 5+ messages in thread
From: Richard Guenther @ 2012-08-16 13:41 UTC (permalink / raw)
To: gcc-patches
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",
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] Decrease integer-share-limit
2012-08-16 13:41 [PATCH] Decrease integer-share-limit Richard Guenther
@ 2012-08-16 14:37 ` Paolo Carlini
2012-08-16 14:46 ` Richard Guenther
0 siblings, 1 reply; 5+ messages in thread
From: Paolo Carlini @ 2012-08-16 14:37 UTC (permalink / raw)
To: Richard Guenther; +Cc: gcc-patches
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] Decrease integer-share-limit
2012-08-16 14:37 ` Paolo Carlini
@ 2012-08-16 14:46 ` Richard Guenther
2012-08-16 14:59 ` Jakub Jelinek
0 siblings, 1 reply; 5+ messages in thread
From: Richard Guenther @ 2012-08-16 14:46 UTC (permalink / raw)
To: Paolo Carlini; +Cc: gcc-patches
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] Decrease integer-share-limit
2012-08-16 14:46 ` Richard Guenther
@ 2012-08-16 14:59 ` Jakub Jelinek
2012-08-17 7:52 ` Richard Guenther
0 siblings, 1 reply; 5+ messages in thread
From: Jakub Jelinek @ 2012-08-16 14:59 UTC (permalink / raw)
To: Richard Guenther; +Cc: Paolo Carlini, gcc-patches
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] Decrease integer-share-limit
2012-08-16 14:59 ` Jakub Jelinek
@ 2012-08-17 7:52 ` Richard Guenther
0 siblings, 0 replies; 5+ messages in thread
From: Richard Guenther @ 2012-08-17 7:52 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: Paolo Carlini, gcc-patches
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-08-17 7:52 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-08-16 13:41 [PATCH] Decrease integer-share-limit Richard Guenther
2012-08-16 14:37 ` Paolo Carlini
2012-08-16 14:46 ` Richard Guenther
2012-08-16 14:59 ` Jakub Jelinek
2012-08-17 7:52 ` Richard Guenther
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).