Re: alloca / _alloca / dynamic stack memory
On 12 Mar., 16:18, "Ben Voigt" <r...@nospam.nospam> wrote:
Don't want to top-post, but your message isn't being properly quoted, so I
can't comment inline.
The default implementation of operator new uses a process-wide heap with
synchronization overhead. Anyone who has ever written multi-threaded code
knows this, because you can allocate on one thread and free on another.
Nothing prevents a pool-based allocator from allowing release from a
different thread than the one that allocates. You could e.g. use a non-
locking allocator or you could use a standard cheap mutex. If
contention is rare, I believe this to be rather efficient.
The default implementation of operator new is quite slow and causes severe
memory fragmentation. Microsoft advertises this as an "advantage" of the
.NET garbage collector, and it's the primary reason that C# is competitve
with C++ performance-wise. Give the C++ program a pool allocator or task
allocator, and C# is left in the dust again.
Thread local storage isn't the same as an internally unsynchronized heap.
It is not. But a pool-allocator is likely to use thread-local storage
internally. Sorry about the confusion.
Also, performance profiling would be good, but you must also consider that
new/delete is typically not something you can remove from a program to
determine its performance impact, and profiling will include all the calls
from system libraries, which you can't replace.
You profile in order to determine the bottleneck. If new/delete is not
a bottleneck, why bother to improve performance there?
I think the OP is solving his problem the wrong way, a per-thread heap or a
task-based scratch space would be equally efficient, not suffer from stack
corruption and potential exploits in the case of a buffer overflow, and not
require fragile inline assembly hacking dependent on the exact stack
handling chosen by the compiler.
No. The OP is solving his problem the wrong way by not understanding
the nature of the problem, The only evidence we have that new/delete
is a problem is that the OP believes so. This type of statements
always make me suspicious: when it comes to performance it really is
paramount that you know where the bottleneck is, and experience has
told us that programmers are quite bad at this.
/Peter
[snip]