On 2008-12-06 15:55:44 +0100, dsimca <[EMAIL PROTECTED]> said:
== Quote from Fawzi Mohamed ([EMAIL PROTECTED])'s article
I think that it could be useful to add an argument to to
frameInit/free, in any case not just to speed things up, but to quickly
catch mismatched init/free calls.
Can you elaborate on this? I'm not exactly sure what such an argument
would look
like. Also, I wanted to make TempAlloc fairly simple even if it costs some
performance so that I would actually want to use it. If doing
something like this
adds a lot of complexity for the caller, I probably won't implement it. Right
now, I like the simple mixin API.
it could simply be an int storing the place in the stack...
So if someone forgets to remove the frame the next call will see it
immediately.
By the way couldn't you avoid the thread local State by simply keeping
a stack of State structures?
Then instead of the thread local State you would simply look at the top
of the State Stack, it should be faster and more self contained.
Then the element to check could really be the size of the stack, and if
it is simply an int you can make it optional, if present you check for
mismatches... and you get rid of passing the State out...
int initFrame()// returns the number of frames of the stack
void freeFrame(int handler=-1)// frees the frame, if handler is >=0
then checks the number of frames
using GC.malloc in malloc for large requested sizes kind of defeats the
stated purpose (and what makes superstack more difficult to use) of not
being GC scanned, even if I understand the problem of either making
bookkeeping more complicated or create potentially big holes in the
stack...
I see over 4MB in a single allocation to be kind of a corner case
anyhow. If you
need to allocate this much memory for a temp variable that doesn't escape the
current scope, in a single allocation (probably pretty unusual
already), since the
cost of an allocation is sublinear in bytes allocated, the allocation time will
likely be dwarfed by the time it takes to use the memory for whatever
you need it
for. Furthermore, whether by frameInit/frameFree or by
TempAlloc.malloc/TempAlloc.free, the memory gets freed deterministically rather
than waiting for the GC to run to free it, so it's still faster than using new,
etc. In fact, I'm thinking I should have made this limit ~1MB (about
1/4 the size
of a TempAlloc block) since allocating 4MB will always require the
creation of a
new block anyhow.
I'm open to suggestions about how to deal with these large block cases,
but I will
prioritize handling the common case of much smaller allocations efficiently and
cleanly over what I feel is somewhat of a corner case.
no problem I understand, and I am not a user yet.
OT:
I just read (when looking for your previous messages) about your
statistics library. Nice!
You might be interested in giving a look to tango's random package, it
has fast generation of accurate random bumbers with gauss exp and gamma
distributions...
D1.0, but bringing it to D2.0 shouldn't be difficult...
Fawzi
