std.allocator ready for some abuse

[Manu]

On 25 October 2013 05:54, Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org
> wrote:

> Hello,
>
>
> I know it's been a long wait. Hopefully it was worth it. The alpha release
> of untyped allocators is ready for tire-kicking and a test drive.
>
> Code: https://github.com/andralex/**phobos/blob/allocator/std/**
> allocator.d<https://github.com/andralex/phobos/blob/allocator/std/allocator.d>
>
> Dox: http://erdani.com/d/phobos-**prerelease/std_allocator.html<http://erdani.com/d/phobos-prerelease/std_allocator.html>
>
> Warning: this is alpha quality. Unit tests are thin, and there are no
> benchmarks. Both would be appreciated, particularly benchmarks to validate
> the gains (which I speculate can be very sizable) of custom-built,
> special-purpose allocators compared to traditional allocators.
>
> I acknowledge I'm clearly in no position to evaluate this design. I have
> been knocking around it for long enough to have no idea how easy it is to
> get into it from the outside, or how good it is. By all signs I could
> gather this feels like good design, and one of the best I've ever put
> together. The allocators defined have an archetypal feeling, are flexible
> both statically and dynamically, and morph and combine in infinite ways.
>
> CAllocator and CAllocatorImpl make the link between the static and dynamic
> worlds. Once an allocator is assembled out of pieces and finely tuned,
> wrapping it in a dynamic API is a snap.
>
> Please destroy! I've literally sweat as I'm sending this :o).


I like it. It seems like a solid foundation.
I'm still very curious to see how the next phase (deep language
integration) will look though.


My immediate reactions:

1. I'm still sad there are no allocAligned() functions or something of that
type to request explicit alignment with allocations. I'm not sure there is
sufficient support for requesting alignment with allocations. The set-able
alignment property approach seems a little weird (and only seemed to be
supported on one allocator?). I guess experience will tell if this is
sufficient and/or convenient.
I'd still like to see an allocWithAlignment() method or something, which
may be implemented efficiently by allocators that can support it.

2. I see some lines like this:
 assert(parent.alignment >= X.alignof);
What if parent.alignment < X.alignof? If 'parent' is something with an
inflexible alignment, like malloc or the GC, what is the proper
(convenient) way to reconcile the requirement?

3. FreeList has some options; minSize, maxSize, maxNodes. When I'm using a
freelist, the most important option to me is to be able to allocate new
nodes in batches. I'd like an option added to control the batch size, so
multiple new nodes are allocated in contiguous blocks when the pool grows.
Perhaps add a 4th parameter; minBatchSize = 1? (to retain support for your
existing logic batching small allocations into larger allocated blocks)
The main reasons for this are cache/spatial locality of small allocations,
and minimising overhead burden on the upstream allocator.

4. OT: Working with D struct's, you often encounter, for instance:

struct Region(uint minAlign = platformAlignment)
{
private BasicRegion!(minAlign) base;
...

Doesn't this make you sad? It makes me sad quite regularly.
Especially when the very next line is (often): alias base this;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20131026/681d2f80/attachment-0001.html>