On Tue, 11 Nov 2008 20:39:07 +0300, dsimcha <[EMAIL PROTECTED]> wrote:
I've noticed that, when writing multithreaded number crunching code,
allocating memory for temporary storage can be a huge threading
bottleneck.
Of course, the obvious, but ugly solution is to pre-allocate and recycle
temp
variables. However, this breaks encapsulation at every place imaginable.
An alternative that I've tried recently is to use alloca to stack
allocate the
temporary arrays if they are small enough. If the arrays being
allocated are
larger, I heap allocate, and this isn't a problem because in the large
array
case, the number crunching takes up enough time that heap allocations
aren't
much of a bottleneck anymore. However, this is also butt ugly because I
have
to use a bunch of pointers and casts and explicitly test the size for it
to
work. Given that this is highly useful, I think a nice feature for D
would be
to have some kind of a scheme to make this clean. For example:
auto foo = newTemp[length];
If length is larger than some arbitrary but reasonable value, this is
heap
allocated. If length is small, it is stack allocated. Either way,
allowing
the array to escape the current scope is undefined behavior and the
compiler
would detect at least the simple cases of this. Ideally, since this
would
only be used for temp variables in performance-critical code, the
contents of
the array would also not be initialized.
It would be nice to do this in a library, but there's no obvious way to
do it
without compiler support, since calling a function sets up a new stack
frame.
I'd like to just do it with an interface like:
auto foo = newTemp!(T)(length).
Anyone know any ASM frame pointer hacks to make something like this
workable?
Otherwise, is there enough interest in this that it might belong in the
core
language?
I would *LOVE* to see Variable-Length Arrays in D (they are implemented in
C99)
void foo(int i)
{
int[i] myArray; // this is a static stack-allocated array (size can't
be changed)
assert(myArray.length() == i);
}
