Boost logo

Boost :

Subject: [boost] Advice sought on memory allocation latency reduction C++ standard proposal
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2010-09-22 15:49:56

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
( 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

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
( which extends
the classic 1979 malloc API to enable realloc() to speculatively
attempt in-place allocation resizing and (ii) the C++ proposal
( 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

Technology & Consulting Services - ned Productions Limited. VAT reg: IE 9708311Q. Company no: 

Boost list run by bdawes at, gregod at, cpdaniel at, john at