www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Sneak preview into std.allocator's porcelain

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
http://erdani.com/d/phobos-prerelease/std_experimental_allocator_porcelain.html

Andrei
May 06 2015
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thursday, 7 May 2015 at 02:28:45 UTC, Andrei Alexandrescu 
wrote:

 http://erdani.com/d/phobos-prerelease/std_experimental_allocator_porcelain.html

 Andrei


Now that https://issues.dlang.org/show_bug.cgi?id=8269 was fixed, 
how about that idea of using with(scopeAllocator(...)) { /* use 
theAllocator */ } ?

I.e. encapsulating

auto oldAllocator = theAllocator;
scope(exit) theAllocator = oldAllocator;
theAllocator = allocatorObject(...);

into a nice RAII type and then using it with WithStatement.
May 06 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/6/15 11:00 PM, Vladimir Panteleev wrote:

 On Thursday, 7 May 2015 at 02:28:45 UTC, Andrei Alexandrescu wrote:

 http://erdani.com/d/phobos-prerelease/std_experimental_allocator_porcelain.html


 Andrei


 Now that https://issues.dlang.org/show_bug.cgi?id=8269 was fixed, how
 about that idea of using with(scopeAllocator(...)) { /* use theAllocator
 */ } ?

 I.e. encapsulating

 auto oldAllocator = theAllocator;
 scope(exit) theAllocator = oldAllocator;
 theAllocator = allocatorObject(...);

 into a nice RAII type and then using it with WithStatement.


Sadly that won't be possible with the current design; all higher-level 
functions are not methods and instead rely on UFCS. -- Andrei
May 07 2015
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thursday, 7 May 2015 at 17:57:24 UTC, Andrei Alexandrescu 
wrote:

 On 5/6/15 11:00 PM, Vladimir Panteleev wrote:

 On Thursday, 7 May 2015 at 02:28:45 UTC, Andrei Alexandrescu 
 wrote:

 http://erdani.com/d/phobos-prerelease/std_experimental_allocator_porcelain.html


 Andrei


 Now that https://issues.dlang.org/show_bug.cgi?id=8269 was 
 fixed, how
 about that idea of using with(scopeAllocator(...)) { /* use 
 theAllocator
 */ } ?

 I.e. encapsulating

 auto oldAllocator = theAllocator;
 scope(exit) theAllocator = oldAllocator;
 theAllocator = allocatorObject(...);

 into a nice RAII type and then using it with WithStatement.


 Sadly that won't be possible with the current design; all 
 higher-level functions are not methods and instead rely on 
 UFCS. -- Andrei


Not what I meant. This is your idea:

http://forum.dlang.org/post/l4ccb4$25ul$1 digitalmars.com
May 07 2015
next sibling parent "Namespace" <rswhite4 gmail.com> writes:
 Not what I meant. This is your idea:

 http://forum.dlang.org/post/l4ccb4$25ul$1 digitalmars.com


Oh, my dream could come true... :)
May 07 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/7/15 11:06 AM, Vladimir Panteleev wrote:

 On Thursday, 7 May 2015 at 17:57:24 UTC, Andrei Alexandrescu wrote:

 On 5/6/15 11:00 PM, Vladimir Panteleev wrote:

 On Thursday, 7 May 2015 at 02:28:45 UTC, Andrei Alexandrescu wrote:

 http://erdani.com/d/phobos-prerelease/std_experimental_allocator_porcelain.html



 Andrei


 Now that https://issues.dlang.org/show_bug.cgi?id=8269 was fixed, how
 about that idea of using with(scopeAllocator(...)) { /* use theAllocator
 */ } ?

 I.e. encapsulating

 auto oldAllocator = theAllocator;
 scope(exit) theAllocator = oldAllocator;
 theAllocator = allocatorObject(...);

 into a nice RAII type and then using it with WithStatement.


 Sadly that won't be possible with the current design; all higher-level
 functions are not methods and instead rely on UFCS. -- Andrei


 Not what I meant. This is your idea:

 http://forum.dlang.org/post/l4ccb4$25ul$1 digitalmars.com


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
May 07 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
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.
May 08 2015
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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.
May 08 2015
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
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).
May 08 2015
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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).
May 08 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
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.
May 08 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
May 08 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
May 08 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-05-08 21:55, Andrei Alexandrescu wrote:


 a few measurements would be in order. -- Andrei


Be sure you do that on more than one platform. For example, the emulate 
TLS on OS X can be quite slow, I've heard.

-- 
/Jacob Carlborg
May 10 2015
parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 10 May 2015 at 16:56:27 UTC, Jacob Carlborg wrote:

 On 2015-05-08 21:55, Andrei Alexandrescu wrote:


 a few measurements would be in order. -- Andrei


 Be sure you do that on more than one platform. For example, the 
 emulate TLS on OS X can be quite slow, I've heard.


I was trying to come up with a good benchmark for TLS, but it is 
remarkably difficult.

Usually, you have one TLS segment per linker module (meaning one 
for your app + one per shared object). You have once segment that 
is kept around by the compiler to be used.

Once you access TLS in your code, things goes as follow:
1/ The compiler know you have the right segment around and so 
segment lookup needs to take place.
2/ The compiler don't know it, but you have the right segment. In 
which case you do a round trip in the runtime, but take the fast 
path.
3/ You have the wrong segment, in which case the runtime have to 
figure out what is the right segment, and that is slow and often 
imply locks, and even, in worst case scenarii, round trip to the 
OS.

A good benchmark must have TLS accessed from the application and 
from some shared object, be big enough so the compiler do not see 
through all these access (or is will simply keep both segment 
around which it won't do by default, but will if necessity is 
apparent), and have a realistic access pattern (it is fairly easy 
to trash the perfs by doing ping pong between the 2 TLS segment, 
but it is probably not very realistic).

Long story short, I'm worried by this TLS issue, but I'd welcome 
more data.
May 10 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/8/15 12:13 PM, 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.


That's right. That reminds me I need to implement a sort of a pool 
allocator that remembers all allocations that went through it, and 
release them all in the destructor.

What's a good name for that? I thought MarkSweepAllocator is it, but 
that term is more often used in conjunction with garbage collection.


Andrei
May 08 2015
parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Friday, 8 May 2015 at 19:53:16 UTC, Andrei Alexandrescu wrote:

 What's a good name for that? I thought MarkSweepAllocator is 
 it, but that term is more often used in conjunction with 
 garbage collection.


Pascal calls these functions "Mark" and "Release" :)

I named mine TrackingAllocator but that's probably too ambiguous.
May 08 2015
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/8/15 12:04 PM, 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.


Yah the virtual barrier is a necessary evil. For ultimate performance 
you'd need a local allocator object fronting the built-in one. -- Andrei
May 08 2015
prev sibling next sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
On Thursday, 7 May 2015 at 02:28:45 UTC, Andrei Alexandrescu 
wrote:

 http://erdani.com/d/phobos-prerelease/std_experimental_allocator_porcelain.html

 Andrei


*Reads module name* "...toilets? Oh. Wait. This is is allocator 
stuff."

Looks like there's a macro expansion problem in makeArray's 
"Throws:" section.

IAllocator.empty and IAllocator.zeroesAllocations, 
CAllocatorImpl.impl, CAllocatorImpl.empty, and 
CAllocatorImpl.zeroesAllocations are missing  property.

Can we get a different name for "kill"? That makes me think of 
processes. How about "dispose"?
May 07 2015
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/7/15 2:18 AM, Brian Schott wrote:

 On Thursday, 7 May 2015 at 02:28:45 UTC, Andrei Alexandrescu wrote:

 http://erdani.com/d/phobos-prerelease/std_experimental_allocator_porcelain.html


 Andrei


 *Reads module name* "...toilets? Oh. Wait. This is is allocator stuff."

 Looks like there's a macro expansion problem in makeArray's "Throws:"
 section.

 IAllocator.empty and IAllocator.zeroesAllocations, CAllocatorImpl.impl,
 CAllocatorImpl.empty, and CAllocatorImpl.zeroesAllocations are missing
  property.

 Can we get a different name for "kill"? That makes me think of
 processes. How about "dispose"?


Sounds good, will do. Thanks! -- Andrei
May 07 2015
prev sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 05/07/2015 02:18 AM, Brian Schott wrote:

 On Thursday, 7 May 2015 at 02:28:45 UTC, Andrei Alexandrescu wrote:

 http://erdani.com/d/phobos-prerelease/std_experimental_allocator_porcelain.html


 Andrei


 *Reads module name* "...toilets? Oh. Wait.


I thought dishes and tea cups. :)


 This is is allocator stuff."


If it is related to allocators, I am not familiar with that term. Could 
someone please explain why "porcelain"?

Ali
May 07 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/7/15 11:13 AM, Ali Çehreli wrote:

 On 05/07/2015 02:18 AM, Brian Schott wrote:

 On Thursday, 7 May 2015 at 02:28:45 UTC, Andrei Alexandrescu wrote:

 http://erdani.com/d/phobos-prerelease/std_experimental_allocator_porcelain.html



 Andrei


 *Reads module name* "...toilets? Oh. Wait.


 I thought dishes and tea cups. :)

  > This is is allocator stuff."

 If it is related to allocators, I am not familiar with that term. Could
 someone please explain why "porcelain"?

 Ali


https://git-scm.com/book/tr/v2/Git-Internals-Plumbing-and-Porcelain

Made perfect sense the second I first saw it. -- Andrei
May 07 2015
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, 7 May 2015 at 18:26:47 UTC, Andrei Alexandrescu 
wrote:

 https://git-scm.com/book/tr/v2/Git-Internals-Plumbing-and-Porcelain

 Made perfect sense the second I first saw it. -- Andrei


I always thought that it was a bit vulgar, myself, but git has 
made the term at least somewhat common in this context.

- Jonathan M Davis
May 10 2015
prev sibling next sibling parent reply "Alex Parrill" <initrd.gz gmail.com> writes:
On Thursday, 7 May 2015 at 02:28:45 UTC, Andrei Alexandrescu 
wrote:

 http://erdani.com/d/phobos-prerelease/std_experimental_allocator_porcelain.html

 Andrei


The links for allocator.temp and allocator.typed lead to 404 
pages.
May 07 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdan.org> writes:
"Alex Parrill" <initrd.gz gmail.com> wrote:

 On Thursday, 7 May 2015 at 02:28:45 UTC, Andrei Alexandrescu wrote:

 http://erdani.com/d/phobos-prerelease/std_experimental_allocator_porcelain.html
 
 Andrei


 
 The links for allocator.temp and allocator.typed lead to 404 pages.


Sorry, those modules are not used anymore (stuff that used to be in typed
is now in porcelain and temp is just a dump).
May 07 2015
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, 7 May 2015 at 02:28:45 UTC, Andrei Alexandrescu 
wrote:

 http://erdani.com/d/phobos-prerelease/std_experimental_allocator_porcelain.html


On the face of it, it's doing roughly what I expected, though the 
devil's in the details, and it's likely taking care of quite a 
few things that I hadn't thought of. I was surprised to see that 
arrays didn't just use make, but on further inspection, I would 
guess that it was just easier to have a separate makeArray due to 
differences in arguments, since otherwise, you'd need to muck 
around with make's auto ref parameters to make sure that they 
lined up with the parameters that makeArray currently expects 
when make was instantiated with an array and give an error 
otherwise, and makeArray makes the parameters clear in the 
signature.

- Jonathan M Davis
May 10 2015