what is the fastest memory allocation method???

[bluekite2000]

new/delete, std::allocator, pool_allocator or mt_allocator??? What r
the pros and cons if each method?
PS: I m designing a matrix/tensor/vector lib, all of which call
base_constructor of class Array.

 

[Victor Bazarov]

new/delete, std::allocator, pool_allocator or mt_allocator??? What r
the pros and cons if each method?

std::allocator uses new/delete (usually, could be slightly different,
depending on the implementation). I don't know what pool_allocator or
mt_allocator are (read: there are no such things in the Standard C++).

PS: I m designing a matrix/tensor/vector lib, all of which call
base_constructor of class Array.

'new' and 'delete' usually use 'malloc' or 'free' anyway, so you are
probably not going to see much difference even if you overload 'new'
and 'delete'. First make it work, then make it fast (and only if you
find that dynamic memory allocation is the bottleneck).

V

 

[bluekite2000]

Not according to gcc document, which states:
The easiest way of fulfilling the requirements is to call operator new
each time a container needs memory, and to call operator delete each
time the container releases memory. BUT this method is horribly slow.

Or we can keep old memory around, and reuse it in a pool to save time.
The old libstdc++-v2 used a memory pool, and so do we. As of 3.0, it's
on by default

 

[Wiseguy]

(e-mail address removed) scribbled on the stall wall:

new/delete, std::allocator, pool_allocator or mt_allocator??? What r
the pros and cons if each method?
PS: I m designing a matrix/tensor/vector lib, all of which call
base_constructor of class Array.

No guarantee on your specific HW/OS but

#define size sizeof(char)*10000
static char array[size];

is probably the fastest way to allocate memory :^)
then do what you want with the block.

 

[GTO]

You need to avoid cash misses when using your math library. Everything else
will depend on the implementation of your C++ compiler in question,
operating system specifics and, of course, the HW. It's not too language
specific.

BTW, why do want to reinvent the wheel? There are already plenty of
libraries available that deal with multilinear data structures and that are
fine-tuned for particular OS/HW combinations.

Gregor

 

[Hans Malherbe]

Faster memory allocation than the ones you listed is of course the
stack.

It's worth mentioning since it's easy to miss opportunities to avoid
the heap if you don't specifically look for them.

 

[Rolf Magnus]

(e-mail address removed) scribbled on the stall wall:


No guarantee on your specific HW/OS but

#define size sizeof(char)*10000

sizeof(char) is 1. And prefer constants over macros. So just replace that
with:

const size_t size = 10000;

static char array[size];

is probably the fastest way to allocate memory :^)
then do what you want with the block.

This is not guaranteed to be aligned properly for anything else than char,
so this is not guaranteed to work on every system. Further, some systems
allow mis-aligned access, but with reduced performance. So while your
allocation might be faster, the actual use of the memory could be slower.

 

[simont]

(e-mail address removed) wrote:

I'm not sure which part of Victor's post you're replying to, since you
didn't quote it. I'm guessing it is:

Not according to gcc document,

You didn't say you wanted it to be gcc-specific. Besides, you're
wrong.

which states:

The easiest way of fulfilling the requirements is to call operator
new each time a container needs memory, and to call operator delete
each time the container releases memory. BUT this method is
horribly slow.

Or we can keep old memory around, and reuse it in a pool to save
time. The old libstdc++-v2 used a memory pool, and so do we. As of
3.0, it's on by default

That doesn't mean that libstdc++'s std::allocator doesn't use
new/delete. It just describes how it handles the memory it has
acquired with new, and when it decides to dispose of that memory with
delete.

PS: I m designing a matrix/tensor/vector lib, all of which call
base_constructor of class Array.

If you provide for pluggable allocators, like the STL implementation
whose documentation you quoted, then you can replace std::allocator
with something more specialised /if and when/ profiling shows it
necessary, for relatively minimal upfront effort.

Note that the optimal allocator may vary depending on the context in
which your library is used, so allowing the user to tailor this to
the app probably gives the most mileage anyway.