On Saturday, 31 March 2018 at 19:38:31 UTC, Per Nordlöw wrote:
> On Saturday, 31 March 2018 at 19:31:37 UTC, Rubn wrote:
>> Be willing to change your code, the allocator can change at any point. What you implement today may not work tomorrow, what you fix to work for tomorrow may not end up working the next day (in terms of releases). That really should be something that is mentioned when you suggest using an experimential feature, there's no guarantees at all. It might not even get put into phobos. If your project is going to be used over the course of a year or more than maybe you shouldn't use it.
>
> Ok, thanks for the point.
>
> Is the dub package stdx-allocator [1] a better alternative in this regard?
>
> [1] https://github.com/dlang-community/stdx-allocator

Yep, that's why it was created. It's a snapshot of

https://docarchives.dlang.io/v2.077.0/phobos/std_experimental_allocator.html

It might be updated later, but with dub it's really easy to lock it to a specific version - which you can't when upgrading the compiler.

On Friday, 30 March 2018 at 23:09:33 UTC, Alexandru Jercaianu wrote:
> Hello,
>
> You can try the following:
>     struct Node
>     {
>         char[64] arr;
>     }
>
>      enum numNodes = 100_000_000;
>      void[] buf = GCAllocator.instance.allocate(numNodes * Node.sizeof);
>      auto reg = Region!(NullAllocator, 16)(cast(ubyte[])buf);

Thanks!

Is a `minAlign` of 16 recommended over 8 when allocating classes or arrays?

On Saturday, 31 March 2018 at 20:17:26 UTC, Per Nordlöw wrote:
>>      auto reg = Region!(NullAllocator, 16)(cast(ubyte[])buf);
>
> Thanks!

Turns out that Region allocator wasn't fully qualified:

https://github.com/dlang/phobos/pull/6400

This will make it possible to allocate with it in pure code :)

On Saturday, 31 March 2018 at 20:17:26 UTC, Per Nordlöw wrote:
> On Friday, 30 March 2018 at 23:09:33 UTC, Alexandru Jercaianu wrote:
>> Hello,
>>
>> You can try the following:
>>     struct Node
>>     {
>>         char[64] arr;
>>     }
>>
>>      enum numNodes = 100_000_000;
>>      void[] buf = GCAllocator.instance.allocate(numNodes * Node.sizeof);
>>      auto reg = Region!(NullAllocator, 16)(cast(ubyte[])buf);
>
> Thanks!
>
> Is a `minAlign` of 16 recommended over 8 when allocating classes or arrays?
Hi,
I'm glad it was helpful.
To be honest, I don't know which alignment would be better and it probably depends on your machine.
This here says that 16 would work just fine [1] so I would go with that.

[1] - https://dlang.org/library/std/experimental/allocator/common/platform_alignment.html

On Sunday, 1 April 2018 at 10:59:55 UTC, Alexandru jercaianu wrote:
> On Saturday, 31 March 2018 at 20:17:26 UTC, Per Nordlöw wrote:
>> On Friday, 30 March 2018 at 23:09:33 UTC, Alexandru Jercaianu wrote:
>>> Hello,
>>>
>>> You can try the following:
>>>     struct Node
>>>     {
>>>         char[64] arr;
>>>     }
>>>
>>>      enum numNodes = 100_000_000;
>>>      void[] buf = GCAllocator.instance.allocate(numNodes * Node.sizeof);
>>>      auto reg = Region!(NullAllocator, 16)(cast(ubyte[])buf);
>>
>> Thanks!
>>
>> Is a `minAlign` of 16 recommended over 8 when allocating classes or arrays?
> Hi,
> I'm glad it was helpful.
> To be honest, I don't know which alignment would be better and it probably depends on your machine.
> This here says that 16 would work just fine [1] so I would go with that.
>
> [1] - https://dlang.org/library/std/experimental/allocator/common/platform_alignment.html

Thanks. I presume if we know what type we should allocate, in my case a class `C`, we should use `C.alignof` otherwise we should default to `platformAlignment`.

On 3/30/18 4:31 PM, Per Nordlöw wrote:
> I'm working on a graph database with tens of millions of small nodes containing typically around 8-64 bytes of member data. Is there a faster way of allocating many small class objects such as
> 
> class Node
> {
>      // abstract members
> }
> 
> class StrNode : Node
> {
>      string value;
> }
> 
> // more Node-types...
> 
> other than
> 
> const nodeCount = 10_000_000;
> foreach (0 .. n)
> {
>      auto node = new Node(someData);
>      // connect node...
> }
> 

You may be interested in this proposal, which was inspired by trying to implement a reserve feature for AAs (requires a similar mechanism).

https://issues.dlang.org/show_bug.cgi?id=17881

Note that the recommendations in the replies here have the unfortunate drawback of tying all allocations to one block, scanned by the GC all at once, and will only get collected when none of them are referenced. On 32-bit systems this also leads to a high likelihood of false pointers keeping the block alive.

More use cases for the feature request may help push for acceptance.

-Steve

On Monday, 2 April 2018 at 18:22:43 UTC, Steven Schveighoffer wrote:
> You may be interested in this proposal, which was inspired by trying to implement a reserve feature for AAs (requires a similar mechanism).
>
> https://issues.dlang.org/show_bug.cgi?id=17881
> 

Ok, thanks. I'll push for it.

One thing, though, that boggles me; how does the GC know where each class instance start and what type it has when I the allocator constructs it using `emplace` in my Region? So that the GC knows which destructor to call where.

Furher, is it ok to use my allocator to allocate both pod, structs and classes? Or aren't allocators supposed to be used in that way?

On 4/2/18 2:51 PM, Per Nordlöw wrote:
> On Monday, 2 April 2018 at 18:22:43 UTC, Steven Schveighoffer wrote:
>> You may be interested in this proposal, which was inspired by trying to implement a reserve feature for AAs (requires a similar mechanism).
>>
>> https://issues.dlang.org/show_bug.cgi?id=17881
>>
> 
> Ok, thanks. I'll push for it.
> 
> One thing, though, that boggles me; how does the GC know where each class instance start and what type it has when I the allocator constructs it using `emplace` in my Region? So that the GC knows which destructor to call where.

It probably doesn't. Yet another reason to have a feature for this supported by the GC instead of a wrapper allocator.

> Furher, is it ok to use my allocator to allocate both pod, structs and classes? Or aren't allocators supposed to be used in that way?

An allocator can be used to create anything AFAIK.

-Steve