Re: Some aspect of GCC memory consumption increased by recent patch

[Jan Hubicka <jh at suse dot cz>]

> Ben Elliston wrote:
> >Jan Hubicka <jh@suse.cz> writes:
> >
> >
> >>up to 3% memory consumption increase looks pretty serious even
> >>tought we save some memory on generate-3.4.ii.  Is there some
> >>understanding why it happens and/or some hope that it will get
> >>solved?
> >
> >
> >I spent a bit of time thinking about this today.
> >
> >Nathan, is it possible that the pre-allocation strategy for the
> >type-safe vectors is causing a higher than usual peak in memory
> >consumption?  I note that vec.h says "Reallocation causes an
> >exponential increase in vector size."
> 
> yeah, I talked with Honza on IRC about this.  I don't think the exponential
> increase is the problem.  There are two other issues.
> 
> 1) The default length is 4 slots.  As most blocks only have 1 or 2 edges,
> that is probably wrong.  I'd guess 2 would be a better default.  It's not
> obvious to me as to whether _most_ blocks have 1 exit, or 2 exits.  I 
> suspect
> that defaulting to 1 is too conservative.
> 
> 2) The length and alloc members are 32bits, they need not be.  I think
> I should make them default to 'unsigned short', thereby removing 1 word
> from a vector.  This extra size is someting that's causing Geoff Keating not
> to want to use them for an attribute mechanism rewrite.  For vectors
> which could get really long, we'd have yet another definition macro 
> (bleah!).
> 
> It'd have to be something like DEF_LONG_VEC_{GC,MALLOC}_{P,O}.  Do you all
> think the LONG bit should be part of use too (i.e. allow LONG_VEC(thing) and
> VEC(thing)).  It seems to me that that would be the right thing.
> 
> IIRC, the old structure contained three words per edge (next, prev and 
> edge),
> thus a vector defaulting to 4 slots (6words), would only be a saving if the
> average number of edges per block was >= 2.
> 
> Can you experiment with reducing the default allocation size? It's contained
> in vec.c.
> 
> BTW, is forwarding the memory usage info from the point of call of the 
> vector
> api functions the right thing? (Rather than merely indicate the vector API
> function itself?)
In general, I think it is quite important to know who is consuming the
memory so it is better to forward the info. However vecotors, like
varrays, are bit special by the fact that singe vector is usually grown
at several places so the overall memory consumption of each vector gets
distributed into many lines making it more dificult to track down.

Perhaps it would be best to have specialized statistics like we do have
for varrays, but I don't think it is very critical at the moment.

Honza
> 
> nathan
> 
> -- 
> Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
> nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk
> 
>