On 11/2/2014 3:57 PM, Dicebot wrote:
On Saturday, 1 November 2014 at 17:50:33 UTC, Walter Bright wrote:
It is not the same thing as ref/out buffer argument.
Don't understand your comment.
Steven comment has mentioned two things about Tango approach - using stack
buffer as initial buffer and extensive usage of ref parameters for such
arguments. std.internal.scopebuffer on its own only addresses the former.
I still have no idea how this would apply here.
We have been running
ping-pong comments about it for a several times now. All
std.internal.scopebuffer does is reducing heap allocation count at cost of stack
consumption (and switching to raw malloc for heap) - it does not change big-O
estimate of heap allocations unless it is used as a buffer argument - at which
point it is no better than plain array.
1. stack allocation is not much of an issue here because these routines in
druntime are not recursive, and there's plenty of stack available for what
druntime is using toString for.
Fibers.
Ironically one more problematic parts of Tango for us is the Layout one which
uses somewhat big stack buffer for formatting the arguments into string. It is a
very common reason for fiber stack overflows (and thus segfaults) unless default
size is changed.
With 64-bit systems and lazy stack page allocation it is not a critical problem
anymore but it is still important problem because any growth of effective fiber
stack prevents one from using it as truly cheap context abstraction.
Persistent thread-local heap buffer that gets reused by many bound fibers can be
much better in that regard.
There is no problem with having the max stack allocation for scopebuffer use set
smaller for 32 bit code than 64 bit code.
2. "All it does" is an inadequate summary. Most of the time it completely
eliminates the need for allocations. This is a BIG deal, and the source of
much of the speed of Warp. The cases where it does fall back to heap
allocation do not leave GC memory around.
We have a very different applications in mind. Warp is "normal" single user
application and I am speaking about servers. Those have very different
performance profiles and requirements, successful experience in one domain is
simply irrelevant to other.
What part of druntime would be special case for servers?
3. There is big-O in worst case, which is very unlikely, and big-O in 99% of
the cases, which for scopebuffer is O(1).
And with servers you need to always consider worst case as default or meet the
DoS attack.
Minimizing allocations is about dealing with the most common cases.
I am not even sure where 99% comes from because input length is
usually defined by application domain and stack usage of scopebuffer is set
inside library code.
It's not that hard.
4. You're discounting the API of scopebuffer which is usable as an output
range, fitting it right in with Phobos' pipeline design.
Any array is output range :)
The point is what to do when the array gets full.
