digitalmars.D - Sneak preview into std.allocator's porcelain
- Andrei Alexandrescu (2/2) May 06 2015 http://erdani.com/d/phobos-prerelease/std_experimental_allocator_porcela...
- Vladimir Panteleev (10/12) May 06 2015 Now that https://issues.dlang.org/show_bug.cgi?id=8269 was fixed,
- Andrei Alexandrescu (3/16) May 07 2015 Sadly that won't be possible with the current design; all higher-level
- Vladimir Panteleev (4/28) May 07 2015 Not what I meant. This is your idea:
- Namespace (1/3) May 07 2015 Oh, my dream could come true... :)
- Andrei Alexandrescu (4/29) May 07 2015 Oh I see. That will be operational once we get the built-in allocating
- deadalnix (5/8) May 08 2015 I'm not sure how desirable this is. This require a round trip to
- Vladimir Panteleev (7/15) May 08 2015 It will still be no worse than the current situation (GC
- deadalnix (5/21) May 08 2015 It IS worse. Current GC to not do a round trip to TLS (which IS
- Vladimir Panteleev (6/28) May 08 2015 I don't know enough about TLS to argue but it strikes me as odd
- deadalnix (7/12) May 08 2015 No it won't, but I'd like us to be compared to state of the art
- Andrei Alexandrescu (3/15) May 08 2015 Of course! I actually do think std.allocator is a net improvement over
- Andrei Alexandrescu (4/23) May 08 2015 Well you either do TLS or do some interlocking. Frying pan vs. fire.
- Jacob Carlborg (5/6) May 10 2015 Be sure you do that on more than one platform. For example, the emulate
- deadalnix (25/29) May 10 2015 I was trying to come up with a good benchmark for TLS, but it is
- Andrei Alexandrescu (7/21) May 08 2015 That's right. That reminds me I need to implement a sort of a pool
- Vladimir Panteleev (3/6) May 08 2015 Pascal calls these functions "Mark" and "Release" :)
- Andrei Alexandrescu (3/10) May 08 2015 Yah the virtual barrier is a necessary evil. For ultimate performance
- Brian Schott (11/13) May 07 2015 *Reads module name* "...toilets? Oh. Wait. This is is allocator
- Andrei Alexandrescu (2/15) May 07 2015 Sounds good, will do. Thanks! -- Andrei
- =?UTF-8?B?QWxpIMOHZWhyZWxp?= (5/12) May 07 2015 If it is related to allocators, I am not familiar with that term. Could
- Andrei Alexandrescu (3/17) May 07 2015 https://git-scm.com/book/tr/v2/Git-Internals-Plumbing-and-Porcelain
- Jonathan M Davis (5/7) May 10 2015 I always thought that it was a bit vulgar, myself, but git has
- Alex Parrill (4/6) May 07 2015 The links for allocator.temp and allocator.typed lead to 404
- Andrei Alexandrescu (3/9) May 07 2015 Sorry, those modules are not used anymore (stuff that used to be in type...
- Jonathan M Davis (14/15) May 10 2015 On the face of it, it's doing roughly what I expected, though the
http://erdani.com/d/phobos-prerelease/std_experimental_allocator_porcelain.html Andrei
May 06 2015
On Thursday, 7 May 2015 at 02:28:45 UTC, Andrei Alexandrescu wrote:http://erdani.com/d/phobos-prerelease/std_experimental_allocator_porcelain.html AndreiNow 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
On 5/6/15 11:00 PM, Vladimir Panteleev wrote:On Thursday, 7 May 2015 at 02:28:45 UTC, Andrei Alexandrescu wrote:Sadly that won't be possible with the current design; all higher-level functions are not methods and instead rely on UFCS. -- Andreihttp://erdani.com/d/phobos-prerelease/std_experimental_allocator_porcelain.html AndreiNow 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 07 2015
On Thursday, 7 May 2015 at 17:57:24 UTC, Andrei Alexandrescu wrote:On 5/6/15 11:00 PM, Vladimir Panteleev wrote:Not what I meant. This is your idea: http://forum.dlang.org/post/l4ccb4$25ul$1 digitalmars.comOn Thursday, 7 May 2015 at 02:28:45 UTC, Andrei Alexandrescu wrote:Sadly that won't be possible with the current design; all higher-level functions are not methods and instead rely on UFCS. -- Andreihttp://erdani.com/d/phobos-prerelease/std_experimental_allocator_porcelain.html AndreiNow 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 07 2015
Not what I meant. This is your idea: http://forum.dlang.org/post/l4ccb4$25ul$1 digitalmars.comOh, my dream could come true... :)
May 07 2015
On 5/7/15 11:06 AM, Vladimir Panteleev wrote:On Thursday, 7 May 2015 at 17:57:24 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, -- AndreiOn 5/6/15 11:00 PM, Vladimir Panteleev wrote:Not what I meant. This is your idea: http://forum.dlang.org/post/l4ccb4$25ul$1 digitalmars.comOn Thursday, 7 May 2015 at 02:28:45 UTC, Andrei Alexandrescu wrote:Sadly that won't be possible with the current design; all higher-level functions are not methods and instead rely on UFCS. -- Andreihttp://erdani.com/d/phobos-prerelease/std_experimental_allocator_porcelain.html AndreiNow 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 07 2015
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, -- AndreiI'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
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: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.Oh I see. That will be operational once we get the built-in allocating expressions (new, array literals, delegates...) to use theAllocator. Cool, thanks, -- AndreiI'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
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: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).On Thursday, 7 May 2015 at 18:25:39 UTC, Andrei Alexandrescu wrote: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.Oh I see. That will be operational once we get the built-in allocating expressions (new, array literals, delegates...) to use theAllocator. Cool, thanks, -- AndreiI'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
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: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).On Friday, 8 May 2015 at 19:04:20 UTC, deadalnix wrote: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).On Thursday, 7 May 2015 at 18:25:39 UTC, Andrei Alexandrescu wrote: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.Oh I see. That will be operational once we get the built-in allocating expressions (new, array literals, delegates...) to use theAllocator. Cool, thanks, -- AndreiI'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
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
On 5/8/15 1:17 PM, deadalnix wrote:On Friday, 8 May 2015 at 19:54:26 UTC, Vladimir Panteleev wrote: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. -- AndreiI 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
On 5/8/15 12:34 PM, deadalnix wrote:On Friday, 8 May 2015 at 19:13:21 UTC, Vladimir Panteleev wrote: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. -- AndreiOn Friday, 8 May 2015 at 19:04:20 UTC, deadalnix wrote: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).On Thursday, 7 May 2015 at 18:25:39 UTC, Andrei Alexandrescu wrote: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.Oh I see. That will be operational once we get the built-in allocating expressions (new, array literals, delegates...) to use theAllocator. Cool, thanks, -- AndreiI'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
On 2015-05-08 21:55, Andrei Alexandrescu wrote:a few measurements would be in order. -- AndreiBe 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
On Sunday, 10 May 2015 at 16:56:27 UTC, Jacob Carlborg wrote:On 2015-05-08 21:55, Andrei Alexandrescu wrote: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.a few measurements would be in order. -- AndreiBe sure you do that on more than one platform. For example, the emulate TLS on OS X can be quite slow, I've heard.
May 10 2015
On 5/8/15 12:13 PM, Vladimir Panteleev wrote:On Friday, 8 May 2015 at 19:04:20 UTC, deadalnix wrote: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. AndreiOn Thursday, 7 May 2015 at 18:25:39 UTC, Andrei Alexandrescu wrote: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.Oh I see. That will be operational once we get the built-in allocating expressions (new, array literals, delegates...) to use theAllocator. Cool, thanks, -- AndreiI'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
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
On 5/8/15 12:04 PM, deadalnix wrote:On Thursday, 7 May 2015 at 18:25:39 UTC, Andrei Alexandrescu wrote:Yah the virtual barrier is a necessary evil. For ultimate performance you'd need a local allocator object fronting the built-in one. -- AndreiOh I see. That will be operational once we get the built-in allocating expressions (new, array literals, delegates...) to use theAllocator. Cool, thanks, -- AndreiI'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
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
On 5/7/15 2:18 AM, Brian Schott wrote:On Thursday, 7 May 2015 at 02:28:45 UTC, Andrei Alexandrescu wrote:Sounds good, will do. Thanks! -- Andreihttp://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
On 05/07/2015 02:18 AM, Brian Schott wrote:On Thursday, 7 May 2015 at 02:28:45 UTC, Andrei Alexandrescu wrote:I thought dishes and tea cups. :)http://erdani.com/d/phobos-prerelease/std_experimental_allocator_porcelain.html Andrei*Reads module name* "...toilets? Oh. Wait.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
On 5/7/15 11:13 AM, Ali Çehreli wrote:On 05/07/2015 02:18 AM, Brian Schott wrote:https://git-scm.com/book/tr/v2/Git-Internals-Plumbing-and-Porcelain Made perfect sense the second I first saw it. -- AndreiOn Thursday, 7 May 2015 at 02:28:45 UTC, Andrei Alexandrescu wrote: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"? Alihttp://erdani.com/d/phobos-prerelease/std_experimental_allocator_porcelain.html Andrei*Reads module name* "...toilets? Oh. Wait.
May 07 2015
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. -- AndreiI 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
On Thursday, 7 May 2015 at 02:28:45 UTC, Andrei Alexandrescu wrote:http://erdani.com/d/phobos-prerelease/std_experimental_allocator_porcelain.html AndreiThe links for allocator.temp and allocator.typed lead to 404 pages.
May 07 2015
"Alex Parrill" <initrd.gz gmail.com> wrote:On Thursday, 7 May 2015 at 02:28:45 UTC, Andrei Alexandrescu wrote:Sorry, those modules are not used anymore (stuff that used to be in typed is now in porcelain and temp is just a dump).http://erdani.com/d/phobos-prerelease/std_experimental_allocator_porcelain.html AndreiThe links for allocator.temp and allocator.typed lead to 404 pages.
May 07 2015
On Thursday, 7 May 2015 at 02:28:45 UTC, Andrei Alexandrescu wrote:http://erdani.com/d/phobos-prerelease/std_experimental_allocator_porcelain.htmlOn 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