On Friday, 8 May 2015 at 19:34:13 UTC, 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).
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).
