Re: Sneak preview into std.allocator's porcelain
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
Re: Sneak preview into std.allocator's porcelain
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
Re: Sneak preview into std.allocator's porcelain
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.
Re: Sneak preview into std.allocator's porcelain
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
Re: Sneak preview into std.allocator's porcelain
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
Re: Sneak preview into std.allocator's porcelain
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.
Re: Sneak preview into std.allocator's porcelain
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).
Re: Sneak preview into std.allocator's porcelain
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.
Re: Sneak preview into std.allocator's porcelain
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
Re: Sneak preview into std.allocator's porcelain
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.
Re: Sneak preview into std.allocator's porcelain
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.
Re: Sneak preview into std.allocator's porcelain
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).
Re: Sneak preview into std.allocator's porcelain
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
Re: Sneak preview into std.allocator's porcelain
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
Re: Sneak preview into std.allocator's porcelain
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?
Re: Sneak preview into std.allocator's porcelain
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
Re: Sneak preview into std.allocator's porcelain
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
Re: Sneak preview into std.allocator's porcelain
Not what I meant. This is your idea: http://forum.dlang.org/post/l4ccb4$25ul$1...@digitalmars.com Oh, my dream could come true... :)
Re: Sneak preview into std.allocator's porcelain
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
Re: Sneak preview into std.allocator's porcelain
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
Re: Sneak preview into std.allocator's porcelain
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
Re: Sneak preview into std.allocator's porcelain
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
Re: Sneak preview into std.allocator's porcelain
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.
Re: Sneak preview into std.allocator's porcelain
Alex Parrill initrd...@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).
Re: Sneak preview into std.allocator's porcelain
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.
Sneak preview into std.allocator's porcelain
http://erdani.com/d/phobos-prerelease/std_experimental_allocator_porcelain.html Andrei
