Re: Containers, Allocators and Purity
On Thursday, 24 March 2016 at 11:18:06 UTC, Nordlöw wrote: Could somebody briefly outline how the thread-locality (non-GC-locked) of allocators relates to the purity of the containers using them? This because I want to move forward with optimizations in my knowledge graph that requires GC-free array containers storing value typed elements (integers) which preferrably has pure API. Specifically, I want to use something like https://github.com/economicmodeling/containers/blob/master/src/containers/dynamicarray.d that is `@safe pure` and uses lock-free allocations in a heavily multi-threaded application. If I want purity aswell which `std.experimental.allocators` are possible? After a quick glance at: https://github.com/economicmodeling/containers/blob/master/src/containers/dynamicarray.d It looks like if `useGC == false`, all of the methods should be `pure`-ready, except for `remove(size_t)` and `~this()`. These two methods use `typeid.destroy`, which I don't think is `pure`.
Re: Containers, Allocators and Purity
On Thursday, 24 March 2016 at 11:18:06 UTC, Nordlöw wrote: Could somebody briefly outline how the thread-locality (non-GC-locked) of allocators relates to the purity of the containers using them? This because I want to move forward with optimizations in my knowledge graph that requires GC-free array containers storing value typed elements (integers) which preferrably has pure API. Specifically, I want to use something like https://github.com/economicmodeling/containers/blob/master/src/containers/dynamicarray.d that is `@safe pure` and uses lock-free allocations in a heavily multi-threaded application. If I want purity aswell which `std.experimental.allocators` are possible? Currently almost nothing in `std.experimental.allocators` is explicitly marked as pure, except for some of the things in ./common.d (https://github.com/D-Programming-Language/phobos/pull/3957 *shameless plug*). Thankfully make, makeArray, dispose and some of the allocators are templates, so you can rely on attribute inference. The most important thing is that you need to have pure `allocate` and `deallocate` methods. After this `make` and friends will work like magic (at least for types with pure `this` and `~this`). `pure` statefull allocator essentially means that it has to be thread-local, so there are no global side-effects. Essentially, to achieve this you can make a large initial allocation in each thread (even from a non-pure allocator) and then you can make `pure` sub-allocations out of it. You can read more about my adventures with my `pure` smart pointer here: http://forum.dlang.org/post/eegjluaiwvdxfnbxk...@forum.dlang.org http://forum.dlang.org/post/bvgyrfvuqrqcyvhkq...@forum.dlang.org
Containers, Allocators and Purity
Could somebody briefly outline how the thread-locality (non-GC-locked) of allocators relates to the purity of the containers using them? This because I want to move forward with optimizations in my knowledge graph that requires GC-free array containers storing value typed elements (integers) which preferrably has pure API. Specifically, I want to use something like https://github.com/economicmodeling/containers/blob/master/src/containers/dynamicarray.d that is `@safe pure` and uses lock-free allocations in a heavily multi-threaded application. If I want purity aswell which `std.experimental.allocators` are possible?
