August 26, 2015 Re: associative arrays with manual memory management | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ilya Yaroshenko | On Wednesday, 26 August 2015 at 09:20:33 UTC, Ilya Yaroshenko wrote:
> Only if you would use a shared allocator like Mallocator or GCAllocator.
Are there cases where a non-shared version of Mallocator or GCAllocator is motivated?
If not could, maybe the shared-ness could be inferred?
|
August 26, 2015 Re: associative arrays with manual memory management | ||||
---|---|---|---|---|
| ||||
Posted in reply to Per Nordlöw | On Wednesday, 26 August 2015 at 13:12:38 UTC, Per Nordlöw wrote: > On Wednesday, 26 August 2015 at 09:20:33 UTC, Ilya Yaroshenko wrote: >> Only if you would use a shared allocator like Mallocator or GCAllocator. > > Are there cases where a non-shared version of Mallocator or GCAllocator is motivated? Mallocator and GCAllocator are always shared. Possibly D will have ThreadLocalGCAllocator in the future. > > If not could, maybe the shared-ness could be inferred? `aa` function just uses shared type for shared argument and vise versa. GCAllocator.instance and Mallocator.instance. are always shared. |
August 26, 2015 Re: associative arrays with manual memory management | ||||
---|---|---|---|---|
| ||||
Posted in reply to Per Nordlöw | On Wednesday, 26 August 2015 at 12:10:17 UTC, Per Nordlöw wrote:
> highlights
>
> It would be nice to also see an example at
> https://github.com/arexeu/aammm
>
> that shows AA-usage in conjunction with some other allocator such as FreeList and add a note about the performance improvement this gives.
>
> In that case, would it be possible to have factory functions for AA that automatically derives allocator parameters from key and value type for specific allocators?
>
> What do you say?
It is possible but not so useful, thought. `AA!(...).Entry.sizeof` and `AA!(...).Entry.alignof` should be accessible from user code since v0.0.3 . They can be used to construct allocators. I will add example with FreeList.
|
August 26, 2015 Re: associative arrays with manual memory management | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ilya Yaroshenko | On Wednesday, 26 August 2015 at 14:21:41 UTC, Ilya Yaroshenko wrote: > It is possible but not so useful, thought. Why is it not so useful? > `AA!(...).Entry.sizeof` and `AA!(...).Entry.alignof` should be accessible from user code since v0.0.3 . They can be used to construct allocators. I will add example with FreeList. Great! Thanks! |
August 26, 2015 Re: associative arrays with manual memory management | ||||
---|---|---|---|---|
| ||||
Posted in reply to Per Nordlöw | On Wednesday, 26 August 2015 at 14:24:54 UTC, Per Nordlöw wrote:
> On Wednesday, 26 August 2015 at 14:21:41 UTC, Ilya Yaroshenko wrote:
>> It is possible but not so useful, thought.
>
> Why is it not so useful?
Because looks like allocators have different additional params, that dose not related to AA.
|
September 13, 2015 Re: associative arrays with manual memory management | ||||
---|---|---|---|---|
| ||||
Posted in reply to Per Nordlöw | On Wednesday, 26 August 2015 at 12:10:17 UTC, Per Nordlöw wrote: > On Wednesday, 26 August 2015 at 10:48:11 UTC, Ilya Yaroshenko > >> auto a = aa!(string, int)(Mallocator.instance); // 3rd CT > > highlights > > It would be nice to also see an example at > https://github.com/arexeu/aammm > > that shows AA-usage in conjunction with some other allocator such as FreeList and add a note about the performance improvement this gives. I have not any significant performance improvement with FreeList/SharedFreeList comparing with Mallocator. However, the difference can be significant for server with 20-30 core CPUs because malloc function use internal lock. Simple benchmark: https://github.com/arexeu/aammm/commit/260ef4f94618b85463dec5c90e0b894b08750d07#diff-24efeb785f1d7039ab1c9bc29ba99c99R1071 |
Copyright © 1999-2021 by the D Language Foundation