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