Re: [boost] Advice sought on memory allocation latency reduction C++ standard proposal

Subject: Re: [boost] Advice sought on memory allocation latency reduction C++ standard proposal
From: Fernando Pelliccioni (fpelliccioni_at_[hidden])
Date: 2010-09-29 09:40:00

On Wed, Sep 22, 2010 at 4:49 PM, Niall Douglas <s_sourceforge_at_[hidden]>wrote:

> Dear Boost Devs,
>
> I am hoping to gain feedback on an ISO C++ standard library proposal
> I hope to submit. It consists of a rationale
> (http://mallocv2.wordpress.com/) which shows how growth in RAM
> capacity is exponentially outgrowing the growth in RAM access speed.
> The consequences are profound: computer software which has always
> been written under the assumption of scarcity of RAM capacity will
> need to be retargeted to assume the scarcity of RAM access speed
> instead.
>
> I appreciate that Boost is not the C++ standard library, however I
> have asked this on comp.std.c++ and received no reply at all.
>
> The proposal comes in two parts: (i) The C proposal
> (http://mallocv2.wordpress.com/the-c-proposal-text/) which extends
> the classic 1979 malloc API to enable realloc() to speculatively
> attempt in-place allocation resizing and (ii) the C++ proposal
> (http://mallocv2.wordpress.com/the-cpp-proposal-text/) which extends
> std::allocator<> with batch allocation and deallocation member
> functions along with a reallocate() member function. These work much
> as expected and are intended for STL implementations - I have given a
> sample std::vector<>::reserve() implementation for the Dinkumware STL
> which attempts an in-place extension before performing a move
> construction of the vector contents.
>
> I am going to guess that these member functions will be fairly
> uncontroversial - reallocate() in particular has been in the SGI STL
> for a while, though in an unhelpful form which is basically a
> realloc() wrapper. What I think will likely be much more
> controversial are the new std namespace functions:
>
>  template<class T, class allocator=allocator<T>, class... Args>
> typename allocator<T>::pointer New(Args&&... args);
>  template<class T, class allocator=allocator<T>, class... Args>
> typename allocator<T>::pointer NewA(size_t n, Args&&... args);
>  template<class T, class allocator=allocator<T> > void
> Delete(typename allocator<T>::const_pointer p);
>  template<class T, class allocator=allocator<T> > void
> DeleteA(typename allocator<T>::const_pointer p);
>
> These parallel global operators new and delete except of course that
> they are standard functions and take a std::allocator<> type with
> which they perform the allocation and deallocation. The biggest
> danger here obviously enough is the chance of collision with any
> New() or Delete() defined by application code as the overloading and
> type specialisation problems (thanks to the unhelpful syntax) of
> operators new and delete are well known. The second biggest danger is
> the perhaps confusing duplication of functionality, though of course
> std::New() and std::Delete() are intended as a superset of global
> operators new and delete.
>
> I would appreciate any feedback, and in case you don't think
> discussion of this topic is appropriate here I will cross post this
> email to comp.std.c++. You can reply there instead if you wish.
>
> My thanks in advance for your time and consideration.
>
> Niall Douglas
>

Have you checked this out?
Maybe it can help.

http://www.canonware.com/jemalloc/

Regards,
Fernando.