Re: [v3] __pool_alloc rework

[Dhruv Matani <dhruvbird at gmx dot net>]

Hi all,
	May I suggest a simple but possibly effective way to speed up the
already fast pool_alloc in the mt-case. Well, if you observe, there is
only one lock for the pool, while the pool is split up into 128/8 parts.
So, a speed up could be definitely achieved by keeping one lock for each
part of the pool right?

So, if for example Thread-1 asks for 8 bytes, and Thread-2 asks for
16-bytes simultaneously, then one of them will have to wait for the
other to finish and return, with the current design, while with the
proposed design, both can run simultaneously n a Multiprocessor system.

Also, the suggestion by Carlo Wood about not locking while in operator
new can be implemented, however, I'm not quite sure whether it will be
worth the effort, because the number of times the code finds itself
within op.new would probably be very small compared to otherwise.

-Dhruv.


On Sat, 2004-06-19 at 05:48, Carlo Wood wrote:
> On Fri, Jun 18, 2004 at 05:02:37PM +0200, Paolo Carlini wrote:
> > Carlo Wood wrote:
> > 
> > >There is no problem in the non-threaded case: then there are no locks at 
> > >all.
> > >
> > I don't understand: I'm talking about __threads == false in the original 
> > design (that which shipped with 3.3.x)
> 
> I mean that in the view of my specific problem (thus, not the performance
> problem you talk about) the only thing that matters are multi-threaded
> applications.  We should only talk about and consider the MT case.
> 
> > >I am not convinced that a pool allocator has to be poor in performance
> > >in a MT application.
> > > 
> > >
> > During the last months we posted numbers and there is a whole literature 
> > about that.
> 
> Ok
> 
> > >If you'd start to call the default allocator (like is used by std::string
> > >for example) mt_alloc in MT case, then that doesn't change anything for my
> > >problem: I'd still need to know if the current thread holds the lock or
> > >the current thread should never hold the lock while calling malloc/new.
> > >
> > ;) Of course we are not talking about naming things one way or another. 
> 
> I understood that.  I am looking at this from the point of view of a user,
> and then - when the API stays more or less the same and we only consider
> multi-threaded applications (see above), then the only thing that changes
> from my point of view, as user, is the name of the allocator.
> 
> > We are talking about *a different* allocator, optimized for MT.
> > The mt_alloc indeed, the one you find in /include/ext/mt_allocator.h.
> > Future developments, particularly so in the area of optimizing the
> > performance for MT, belongs to mt_alloc.
> 
> But also this allocator sets a lock.  Is this lock set when the allocator
> calls operator new in order to allocate more memory?
> 
> If so, then is it possible to either change that (only call new at the moment
> the lock is not set) ?
> 
> .. or provide a public accessor that allows me to see if the current thread
> holds the lock *) ?
-- 
        -Dhruv Matani.
http://www.geocities.com/dhruvbird/

Proud to be a Vegetarian.
http://www.vegetarianstarterkit.com/
http://www.vegkids.com/vegkids/index.html