This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Easy way to try out alternate allocators?

This is a move from a thread (incorrectly) started on the libstdc++ ML.
Another reply there has already pointed me towards:

and --enable-libstdcxx-allocator, which looks promising, but I have not
tried yet.

Ed Smith-Rowland <> writes:
> tom fogal wrote:
> > I'm finding our app is slow where it shouldn't be, and some
> > profiling has revealed we're spending a significant amount of time
> > allocating memory.  Confusingly, oprofile tells me we're spending
> > 99% of our time in operator new, yet sysprof says the major
> > offender is vector's push_back.
> >
> > Is there any compile-time flag to enable a different allocator
> > globally?  I'm hoping to find a _GLIBCXX_DEBUG but for, say,
> > __mt_alloc.  Unfortunately there are a *lot* of vectors involved
> > (which is probably why its slow ... copying between them), so
> > specifying an explicit allocator on each of them would be painful.
> >
> > Other debugging / performance suggestions welcome as well.  Thanks,
> Have you tried reserve to grab a bunch of memory before hand?

To a limited extent.  The issue is that we've got a loop that calls
a method which generates a vector and passes that vector to another
submodule.  The submodule, in turn, decomposes the argument vector into
its own internal vector.  In pseudo-code:

  foreach s in something:

    foreach x in s:
      create a vector, `v'

    foreach elem in v:
      for i from 0 to 12:

I have tried both reserve and resize at the lower levels -- in
call_submodule -- but they don't help enough.  Interestingly, when
switching to resize my time ends up in __uninitialized_copy_fill (or
maybe just __uninitialized_copy? or __uninitialized_fill?  I forget the
exact name), but it doesn't matter much: it still spends about the same
amount of time regardless of whether it's in push_back or __whatever.

Ideally, generate_data would append to a vector, and the bottom of the
stack would pass the whole vector to `submodule' *after* the loop,
instead of piecemeal.  I could guesstimate the overall size of the
vector pretty accurately there, and submodule could either grab the
pointer, or at least know the overall size and copy it in one shot.

Unfortunately, making that transformation is involved.

> I'm surprised vector is slow as opposed to list or something since
> the former allocated memory in chunks.

I actually haven't tried a list or a deque; like you, I assume it will
be significantly more expensive (and it's certainly expensive in terms
of time to implement -- I might as well fix it, in the manner I've
outline above).

> push_back could allocate memory to grow the vector as necessary but
> it should do so in blocks according to some heuristic.

I'm not sure what libstdc++'s heuristic is, but we're probably
straining it here. `something' is 128x80x90 elements here, and 128^3
would still be considered `really small'.  Multiply that by my guess of
24 elems 'foreach x in s', and multiply it again by my not-guess of 12
elements per `x'.

My guess is that most people are using std::vectors with much smaller
datasets, and any heuristics would be designed for such smaller
datasets.  That's entirely unverified.

> Also, the constructor for your objects is run.  Objects are copied.
> Are there a lot of things inside your elements that need to be heap
> allocated?

Looks like no.  These are simple, not-quite-POD primitives that every
graphics programmer seems to develop independently: std::vector's of
Point, Vector, and double.

> If you have a good swap method for your elements things could be
> better,

Ahh, defining my own swap!  I'd forgotten about that; good advice.

> especially if you compile in -std=c++0x the elements are moved
> instead of copied for further savings.  C++0X is supposed to bring
> something called a scoped allocator.  I have to admit I'm new to that
> though.

Don't I wish.  Unfortunately 0X is a long way out for some of us.  I
just managed convincing people around here that we should use tr1
features; MS didn't even support it until something like a year ago.
If that's any indicator, I can start making the argument for C++0x in
2020... :(

Thanks for the discussion,


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]