Sneak preview into std.allocator's porcelain

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Fri May 8 12:55:03 PDT 2015


On 5/8/15 12:34 PM, deadalnix wrote:
> On Friday, 8 May 2015 at 19:13:21 UTC, Vladimir Panteleev wrote:
>> On Friday, 8 May 2015 at 19:04:20 UTC, deadalnix wrote:
>>> On Thursday, 7 May 2015 at 18:25:39 UTC, Andrei Alexandrescu wrote:
>>>> Oh I see. That will be operational once we get the built-in
>>>> allocating expressions (new, array literals, delegates...) to use
>>>> theAllocator. Cool, thanks, -- Andrei
>>>
>>> I'm not sure how desirable this is. This require a round trip to TLS
>>> + virtual function call. That can be expensive, but even worse, will
>>> make the optimizer blind.
>>
>> It will still be no worse than the current situation (GC invocation).
>> Performance-sensitive algorithms can use an allocator (which won't be
>> wrapped in a class) that in turn allocates memory in bulk from
>> theAllocator. This pattern will allow you to discard all scratch
>> memory at once once you're done with it.
>
> It IS worse. Current GC to not do a round trip to TLS (which IS slow,
> especially when dynamic linking is involved) and the optimizer can
> understand the API and optimize based on it (LDC does it to some extent).

Well you either do TLS or do some interlocking. Frying pan vs. fire. 
Lake vs. well. Before this devolves into yet another Epic Debate, a few 
measurements would be in order. -- Andrei


More information about the Digitalmars-d mailing list