|  | When to use a customized allocator instead of the default on | | |
| | | Peng Yu |  |
|  Posted: Tue Aug 19, 2008 12:39 am Post subject: When to use a customized allocator instead of the default on |  |
Hi,
In Generic Programming and the STL by Matthew H. Austern, it does not
recommend to change the default allocators, unless it is really
necessary. However, for example, the following post shows that the
default allocator might not give the best performance. I'm wondering
what is the rule of thumb to replace the default allocator with a
customized one or not.
LINK
Thanks,
Peng
--
[ See LINK for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
| |
| | | David Abrahams | |
| | Posted: Tue Aug 19, 2008 9:49 am Post subject: Re: When to use a customized allocator instead of the defaul | |
on Mon Aug 18 2008, Peng Yu <PengYu.UT-AT-gmail.com> wrote:
| Quote: | Hi,
In Generic Programming and the STL by Matthew H. Austern, it does not
recommend to change the default allocators, unless it is really
necessary. However, for example, the following post shows that the
default allocator might not give the best performance. I'm wondering
what is the rule of thumb to replace the default allocator with a
customized one or not.
|
Build your application, profile it, and make sure allocation is a
significant bottleneck before doing anything special. If it is, try
replacing the allocator and measure again to make sure it really makes a
difference.
--
Dave Abrahams
BoostPro Computing
LINK
[ See LINK for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
| |
| | | Maciej Sobczak | |
| | Posted: Tue Aug 19, 2008 9:58 am Post subject: Re: When to use a customized allocator instead of the defaul | |
| |  | |
On 19 Sie, 02:39, Peng Yu <PengYu...@gmail.com> wrote:
| Quote: | I'm wondering
what is the rule of thumb to replace the default allocator with a
customized one or not.
|
There can't be any rules of thumb to replace default and standard
tools, since they are well, default and standard.
Personally, I had very good results with custom allocator for node-
based containers where the container was used in some scoped context,
like within a single function. The custom allocator that I used
allocated memory from the system in big chunks, where "big" means
order(s) of magnitute bigger than the container node size. The
allocator did not release anything until the end of its lifetime, when
the deallocation was done with few shots.
Of course, the allocator lived longer than its associated container,
but that was easy to ensure within the given scope.
The benefit of such a setup was massive reduction of the number of
physical allocations and deallocations.
There is no "rule of thumb" in the above, just an opportunity to
benefit from the specific container usage pattern.
--
Maciej Sobczak * LINK * LINK
--
[ See LINK for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
| |
| | | Sergey P. Derevyago | |
| | Posted: Tue Aug 19, 2008 9:23 pm Post subject: Re: When to use a customized allocator instead of the defaul | |
| | | |
Peng Yu wrote:
| Quote: | I'm wondering
what is the rule of thumb to replace the default allocator with a
customized one or not.
Sure, |
and the rule is: always try to _understand_ what you want to get!
There is no “I’d like to get a better program” but “I’d like to get a
program that provides a better solution for this particular XXX problem”.
As for the C++ default allocator and new/delete operators, the sad
points are:
1. Default (i.e. provided by your compiler vendor) C++ memory allocators
are really bad. It always makes sense to plug something like
LINK and see
the difference.
2. The widespread (i.e. “default”) understanding of MT programming is
really bad. Multithreading is not about LOCKING but is defined by an
application DESIGN that ALLOWS for concurrent or simultaneous execution.
As a result, default C++ allocators should (must?) be avoided in
well-designed applications: thread-private memory allocators do really
allow for simultaneous execution so they are the way to go!
--
With all respect, Sergey. LINK
mailto : ders at skeptik.net
--
[ See LINK for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
| |
| | | Chris M. Thomasson | |
| | Posted: Thu Aug 21, 2008 8:57 pm Post subject: Re: When to use a customized allocator instead of the defaul | |
| | | |
"Sergey P. Derevyago" <non-existent@iobox.com> wrote in message
news:48aacfdf$0$90268$14726298@news.sunsite.dk...
| Quote: | Peng Yu wrote:
I'm wondering
what is the rule of thumb to replace the default allocator with a
customized one or not.
Sure,
and the rule is: always try to _understand_ what you want to get!
There is no “I’d like to get a better program” but “I’d like to get a
program that provides a better solution for this particular XXX problem”.
As for the C++ default allocator and new/delete operators, the sad
points are:
1. Default (i.e. provided by your compiler vendor) C++ memory allocators
are really bad. It always makes sense to plug something like
LINK and see
the difference.
2. The widespread (i.e. “default”) understanding of MT programming is
really bad. Multithreading is not about LOCKING but is defined by an
application DESIGN that ALLOWS for concurrent or simultaneous execution.
As a result, default C++ allocators should (must?) be avoided in
well-designed applications: thread-private memory allocators do really
allow for simultaneous execution so they are the way to go!
|
Your allocator is a great tool to have however you seem to fail to mention
that there are general-purpose allocators that are also based on
thread-private memory pools. You can replace global new/delete with said
allocators indeed. They are just as fast as yours, however they are general
purpose and can be used in a multi-threaded context. For instance, you
cannot use your allocator with virtually any existing multi-threaded
software out there. Why, well, because most of that software expects that
memory allocated from Thread A with `new' can be subsequently `delete'd in
another Thread. Here are some of those types of allocators that are both
general-purpose and are based on thread-private memory pools:
LINK
LINK
LINK
(this uses a quick and dirty region allocation algorithm for C++... Its
pre-alpha, and not ready for prime time. However, IMVHO, its a great way to
see a fully functioning compact algorithm which compiles (x86 and MSVC 6 or
higher) and works... Any questions? I will gladly answer any of them)
--
[ See LINK for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
| |
| | | Peng Yu | |
| | Posted: Thu Aug 21, 2008 9:00 pm Post subject: Re: When to use a customized allocator instead of the defaul | |
| | | |
On Aug 19, 4:23 pm, "Sergey P. Derevyago" <non-exist...@iobox.com>
wrote:
| Quote: | Peng Yu wrote:
I'm wondering
what is the rule of thumb to replace the default allocator with a
customized one or not.
Sure,
and the rule is: always try to _understand_ what you want to get!
There is no “I’d like to get a better program” but “I’d like to get a
program that provides a better solution for this particular XXX problem”.
As for the C++ default allocator and new/delete operators, the sad
points are:
1. Default (i.e. provided by your compiler vendor) C++ memory allocators
are really bad. It always makes sense to plug something LINK see
the difference.
|
I'm wondering if the default ones are always bad. If most of the time
the default ones are bad, why not just use the better ones as the
default? Is it because there is some practical barrier to change the C+
+ standard? Or the default ones is better in many cases?
| Quote: | 2. The widespread (i.e. “default”) understanding of MT programming is
really bad. Multithreading is not about LOCKING but is defined by an
application DESIGN that ALLOWS for concurrent or simultaneous execution.
As a result, default C++ allocators should (must?) be avoided in
well-designed applications: thread-private memory allocators do really
allow for simultaneous execution so they are the way to go!
|
--
[ See LINK for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
| |
| | | Sergey P. Derevyago | |
| | Posted: Fri Aug 22, 2008 1:01 pm Post subject: Re: When to use a customized allocator instead of the defaul | |
| | | |
Peng Yu wrote:
| Quote: | I'm wondering if the default ones are always bad.
I don't think that compiler vendors work hard to bring yet another BAD |
general purpose allocator :)
The point is that _general purpose_ allocators must show reasonable
performance in a "general case" but allocating of big number of small
objects of fixed size is everyday but not "general case" problem. So
default new/delete operators aren’t good in this.
It’s implicitly supposed that one can build its own fast and special
allocator on top of reasonably good new/delete and get the best possible
results from the both sides.
Here are the snippets from comp.programming.threads
-----------------------------------8<-----------------------------------
...mem_pool doesn't relie on any OS specific features and can be used
in ordinary single-threaded environment without any penalty. There is no
thread-specific overhead in the code!
So the main points are:
1. Design your application to allow for simultaneous execution. I.e.
don't allocate/free the memory across the thread bounds (if you can't
prove that it really makes sense _for this particular task_).
2. Then use mem_pool as a thread-private (sometimes, data-private)
allocator to greatly improve the performance.
In essence, non-synchronized mem_pool allocator is built on top of
ordinary new/delete synchronized operator so the combination of
mem_pool+new is really used. On the contrary, Streamflow tries to
replace not the mem_pool allocator itself by the whole mem_pool+new
combination!
So if you're going to compare mem_pool to some other allocator
please make sure that it uses the same synchronized "new part" of the
mem_pool+new combination. I.e. it's not quite fair to compare
mem_pool+"old bad new" with heavily optimized SuperPuperAllocator: you
should cut the appropriate synchronized part of SuperPuperAllocator and
plug it to mem_pool instead of "old bad new" to see the difference
mem_pool can give.
-----------------------------------8<-----------------------------------
The point is that well-designed MT application with the combination of
"mem_pool+new" will always beat "just new" for any possible "new".
-----------------------------------8<-----------------------------------
With all respect, Sergey. LINK
mailto : ders at skeptik.net
--
[ See LINK for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
| |
|
|
