Re: An idea for heap allocation at near stack allocation speed
On Feb 14, 8:57 pm, Bjarke Hammersholt Roune <bjarke.ro...@gmail.com>
wrote:
On Feb 14, 12:20 pm, itaj sherman <itajsher...@gmail.com> wrote:
It was something I came across at work once, that made me think about
what I described. I can't remember what it was. But it wasn't crutial
from performance POV back then, and I never got into more details
about this idea.
Actually I never talked about it with anyone, so that's quite nice I
saw your question here and got reminded about that. It's good to know
that it makes sense to someone else but me.
Maybe I'll think more about it. I'll tell you if I get something
interesting.
You are completely right. For now I just want to replace stack
allocation, and my design can do everything you can do with stack
allocation. So far so good. Yet as you point out it would be even
better to be able to expand stack allocation to classes that allocate
their own memory internally. This requires some way to tell an object
how it is being allocated. The preliminary idea I have on that is
template specialization. There would be some function template<T>
construct(...), and if some T wants to do something special when
allocated via StackAlloc<T> then it would specialize construct to do
the right thing by allocating all its dynamic size (type 2) members
using the stack allocator. E.g. a mechanism like that is necessary for
convenient use of classes using the trick of placing a one-element
array at the end that can actually be more than 1 element by putting
the class T in a buffer that is larger than sizeof(T). It would be
awesome to have "StackAlloc<T> myObj(size);" just work for such T's.
I think it can be any argument there, not just size. The type of the
instance that is being initialized should know how to use the
parameter to calculate the needed size.
These are all just general ideas, I never really thought about these
details carefully.
For example:
{
int size = ...;
StackAlloc< fixed_vector< X > > b( size );
}
The initialization of
{
std::vector< std::vector< X > > a;
//put values into a...
StackAlloc< fixed_vector< fixed_vector< X> > > b( a ); //this should
be done with 1 special-stack allocation, no dynamic.
}
fixed_vector initialization should be implemented to check the size of
the argument container to calculate how much memory to ask from the
allocator. If going by what I said in the other reply, it should
probabely be inside fixed_size_traits< fixed_vector< T >
::calculate_size. In this case T = X when initializing each element
of type fixed_vector<X>, and T = fixed_vector<X> for the main object.
More specifically, it would be in a certain overload:
temlate< typename T, typename U >
size_t fixed_size_traits< fixed_vector< T >
::calculate_size( std::vector< U > const& r )
{
return ... + ( r.size() * sizeof(T) ) + ...;
}
Appart from that, I have a few small suggestions:
* Many c++ implementations have special support for such stack
operations. In these cases you want to use the implementation's
mechanism to allocate that memory, and don't need your own.
I'd love an example of this. Don't all stack-based memory suffer from
the issue of stack overflow?
No, I was wrong. I was just thinking about the alloca( size_t )
function that Windows and some linux have.
It allocates on the real stack. But I didn't think about it carefuly.
It's actually not very useful in this case, because deallocation is
automatic at the end of the calling function. Especially not helpful
if you're going for an unlimited stack size (to avoid overflow).
I was thinking more about how to even allow stack allocations with run-
time size determination at all, rather than further thinking about
allowing unlimited amounts of data.
I suppose you will have to implement the stack structure, or find some
third party data structure that can provide these requirements.
itaj