• bearophile <bearophileHUGS lycos.com> Jun 11 2011
• bearophile <bearophileHUGS lycos.com> Jun 11 2011
• dsimcha <dsimcha yahoo.com> Jun 11 2011
• Walter Bright <newshound2 digitalmars.com> Jun 11 2011
• Jens Mueller <jens.k.mueller gmx.de> Jun 14 2011

bearophile <bearophileHUGS lycos.com> writes:

dsimcha:

 I've overhauled my TempAlloc proposal based on some of the suggestions I've
received.


It's improved :-)


3.  Make alignedMalloc and friends private for now, again to make the proposal
more tightly focused.<


They are useful so I'd like such alignedCMalloc / free to be generally visible,
with a template argument to specify the desire alignment, that defaults to 16.
But I agree it's better to not put it in std.tempalloc.


The first segment of the TempAlloc stack is allocated lazily, so no space is
allocated in any thread that does not use TempAlloc.<


Is this causing any slowdown in the usage of the memory?


static void* malloc(size_t nbytes);<


I think the docs have to say this is aligned memory (and there is no way to
specify a smaller alignment).


In this case sizes may be specified for any number of dimensions from 1 to the
number in T. <


Isn't it bug prone to allow to specify a number of sizes less than the number
of dimensions?


 double[] foo = TempAlloc.newArray!(double[])(100);


A little usability problem: an array of array of double or just array of double?

Bye,
bearophile

bearophile <bearophileHUGS lycos.com> writes:

 dsimcha:
 
 I've overhauled my TempAlloc proposal based on some of the suggestions I've
received.




One more thing: now TempAlloc is one single struct, so I think it's better to
move it in a module that contains stuff for alternative memory managements.
Creating a little Phobos module just for this struct looks a bit like a name
waste.

Bye,
bearophile

dsimcha <dsimcha yahoo.com> writes:

On 6/11/2011 7:04 PM, bearophile wrote:
 dsimcha:

 I've overhauled my TempAlloc proposal based on some of the suggestions I've
received.


 It's improved :-)


 3.  Make alignedMalloc and friends private for now, again to make the proposal
more tightly focused.<


 They are useful so I'd like such alignedCMalloc / free to be generally
visible, with a template argument to specify the desire alignment, that
defaults to 16. But I agree it's better to not put it in std.tempalloc.


Eventually, I may make them visible.  For now, I want to make this 
proposal tightly focused.

 The first segment of the TempAlloc stack is allocated lazily, so no space is
allocated in any thread that does not use TempAlloc.<


 Is this causing any slowdown in the usage of the memory?


Technically yes, because every call to anything TempAlloc-related has to 
compare a pointer to null.  In practice, I don't think this is ever a 
significant slowdown.

 static void* malloc(size_t nbytes);<


 I think the docs have to say this is aligned memory (and there is no way to
specify a smaller alignment).


I guess I could put in the docs that it's 16-byte aligned, but there are 
two reasons why specifying smaller alignment isn't allowed:

1.  It would clutter the API with a feature that that is very 
infrequently used.

2.  It would probably have a performance penalty, whereas rounding up 
all allocations to a hard-coded power of two is dirt-cheap.

 In this case sizes may be specified for any number of dimensions from 1 to the
number in T.<


 Isn't it bug prone to allow to specify a number of sizes less than the number
of dimensions?



I don't see why it is, though perhaps I should include this as an 
example, too:

// Allocate an array of 100 double[]'s and don't initialize them.
double[][] matrix = TempAlloc.newArray!(double[][])(100);

// Use it.
matrix[0] = TempAlloc.newArray!(double[])(100);

 double[] foo = TempAlloc.newArray!(double[])(100);


 A little usability problem: an array of array of double or just array of
double?


Yeah, you might be getting a little confused because I actually changed 
this in the overhaul.  Used to be that you would write:

double[] foo = newStack!double(100);

The reason I did this was to make the multidimensional syntax sane.
 Bye,
 bearophile

Walter Bright <newshound2 digitalmars.com> writes:

bearophile, some way in which you are replying causes Thunderbird to lose track 
of the thread you are replying to, and starts a new thread.

Jens Mueller <jens.k.mueller gmx.de> writes:

Walter Bright wrote:
 bearophile, some way in which you are replying causes Thunderbird to
 lose track of the thread you are replying to, and starts a new
 thread.


His posts have no In-Reply-To field set. I believe that's the problem.
mutt also looses track of his replies.

Jens