By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,159 Members | 947 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,159 IT Pros & Developers. It's quick & easy.

what is the fastest memory allocation method???

P: n/a
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.

Jul 23 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
bl**********@gmail.com wrote:
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
Jul 23 '05 #2

P: n/a
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

Jul 23 '05 #3

P: n/a
bl**********@gmail.com 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.

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Jul 23 '05 #4

P: n/a
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

<bl**********@gmail.com> wrote in message
news:11*********************@g14g2000cwa.googlegro ups.com...
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.

Jul 23 '05 #5

P: n/a
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.

Jul 23 '05 #6

P: n/a
Wiseguy wrote:
bl**********@gmail.com 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


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.

Jul 23 '05 #7

P: n/a
bl**********@gmail.com 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:
bluekite2...@gmail.com wrote:
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++).


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.

Jul 23 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.