Re: alloca / _alloca / dynamic stack memory
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.
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.
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.
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.
"peter koch" <peter.koch.larsen@gmail.com> wrote in message
news:1173537691.645408.309110@8g2000cwh.googlegroups.com...
You have a bad habit: top posting. Get rid of it!
On 9 Mar., 22:26, Michael Crawley
<MichaelCraw...@discussions.microsoft.com> wrote:
The default new and delete operators are very slow..they hit malloc/free
somewhere, which are used to access a shared heap that all of the
process's
threads compete over. There is usually a speed improvement if we can
remove
some of this competition for a lock used within malloc/free.
How do you know that that is the case? Did you verify that the default
operator new does not use thread local storage?
In my opinion, you are doing the things upside-down: you assume that
something is slow and decide to optimise that part. But the reality is
that you have not tested the code to find out if new/delete is truly a
bottleneck.
As Knuth said: "Premature optimization is the root of all evil". Test
your code first and then replace the memory manager if that part seems
to take to long. Perhaps (probably!) the bottleneck will show up not
in new/delete but in some other location, and you will be able to
forget your hack.
/Peter