Sneak preview into std.allocator's porcelain
Andrei Alexandrescu via Digitalmars-d
digitalmars-d at puremagic.com
Fri May 8 13:40:48 PDT 2015
On 5/8/15 1:17 PM, deadalnix wrote:
> On Friday, 8 May 2015 at 19:54:26 UTC, Vladimir Panteleev wrote:
>> I don't know enough about TLS to argue but it strikes me as odd that
>> it would be slower than the layers of un-inlinable extern(C) calls,
>> going through lifetime.d, gc.d, gcx.d, there locking on a global
>> mutex, and allocating memory accordingly to a general-purpose GC (vs.
>> specialized allocator).
>
> No it won't, but I'd like us to be compared to state of the art
> allocator (jemalloc, java's G1 and so on) rather than the current thing
> that we have that is universally recognized as being not good, to put it
> nicely.
>
> You want to compare yourself to what the best guy in town are doing, not
> the drunk hobo wandering around.
Of course! I actually do think std.allocator is a net improvement over
the state of the art. And if it isn't, we need to make it so. -- Andrei
More information about the Digitalmars-d
mailing list