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

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

-- 
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 
472909.