On Thursday, 23 May 2013 at 18:22:54 UTC, Joseph Rushton Wakeling wrote:
> On 05/23/2013 08:13 PM, Brad Anderson wrote:
>> Now I'm wondering what can be done to foster this newly acquired credibility in
>> games.  By far the biggest issue I hear about when it comes to people working on
>> games in D is the garbage collector.  You can work around the GC without too
>> much difficulty as Manu's experience shared in his DConf talk shows but a lot of
>> people new to D don't know how to do that.  We could also use some tools and
>> guides to help people identify and avoid GC use when necessary.


It's worth noting that our code at Sociomantic faces *exactly* the same issues.
We cannot use Phobos because of its reliance on the GC.
Essentially, we want to have the option of avoiding GC usage in every single function.

> As a starting point, do we have a list of the Phobos functions that allocate
> using GC when there's no need to?  That's a concern of Manu's that it ought to
> be possible to address relatively swiftly if the information is to hand.

That is only part of the problem with Phobos. The bigger problem is with the functions that DO need to allocate memory. In Tango, and in our code, all such functions accept a buffer to store the results in.
So that, even though they need to allocate memory, if you call the function a thousand times, it only allocates memory once, and keeps reusing the buffer.

I'm not sure how feasible it is to add that afterwards. I hope it can be done without changing all the API's, but I fear it might not be.

But anyway, after fixing the obvious Phobos offenders, another huge step would be to get TempAlloc into druntime and used wherever possible in Phobos.

On Friday, 24 May 2013 at 07:57:42 UTC, Don wrote:
> It's worth noting that our code at Sociomantic faces *exactly* the same issues.

It is worth noting that _anyone_ trying to write code with either soft or hard real-time requirements faces exactly the same issues ;)

On 2013-05-24 01:51, Joseph Rushton Wakeling wrote:

> This also seems to suggest that an ideal solution might be to have several
> different GC strategies, the choice of which could be made at compile time
> depending on what's most suitable for the application in question.

You can already swap the GC implementation at link time.

-- 
/Jacob Carlborg

On Friday, 24 May 2013 at 08:01:35 UTC, Jacob Carlborg wrote:
> On 2013-05-24 01:51, Joseph Rushton Wakeling wrote:
>
>> This also seems to suggest that an ideal solution might be to have several
>> different GC strategies, the choice of which could be made at compile time
>> depending on what's most suitable for the application in question.
>
> You can already swap the GC implementation at link time.

Yep, exactly. Hard-wired GC is not the problem. Lack of alternative GC's is the problem. Lack of tools to reliably control avoiding of GC calls at all is the problem.

On Friday, 24 May 2013 at 08:01:35 UTC, Jacob Carlborg wrote:
> On 2013-05-24 01:51, Joseph Rushton Wakeling wrote:
>
>> This also seems to suggest that an ideal solution might be to have several
>> different GC strategies, the choice of which could be made at compile time
>> depending on what's most suitable for the application in question.
>
> You can already swap the GC implementation at link time.

Granted the GC fit in the model. Which means no barriers for instance.

24-May-2013 09:02, Manu пишет:
> On 24 May 2013 14:11, Marco Leise <Marco.Leise@gmx.de
> <mailto:Marco.Leise@gmx.de>> wrote:
>
>     Am Thu, 23 May 2013 20:21:47 -0400
>     schrieb "Jonathan M Davis" <jmdavisProg@gmx.com
>     <mailto:jmdavisProg@gmx.com>>:
>
>      > At some point, we're probably going to need to
>      > benchmark stuff more agressively and optimize Phobos in general
>     more, because
>      > it's the standard library. And eliminating unnecessary memory
>     allocations
>      > definitely goes along with that.
>      >
>      > - Jonathan M Davis
>
>     On a related note, a while back I benchmarked the naive Phobos
>     approach to create a Windows API (wchar) string from a D
>     string with using alloca to convert the string on a piece of
>     stack memory like this: http://dpaste.1azy.net/b60d37d4
>     IIRC it was 13(!) times faster for ~100 chars of English text
>     and 5 times for some multi-byte characters.
>     I think this approach is too hackish for Phobos, but it
>     demonstrates that there is much room.
>
>
> I don't think it's hack-ish at all, that's precisely what the stack is
> there for. It would be awesome for people to use alloca in places that
> it makes sense.
> Especially in cases where the function is a leaf or leaf-stem (ie, if
> there is no possibility of recursion), then using the stack should be
> encouraged.
> For safety, obviously phobos should do something like:
>    void[] buffer = bytes < reasonable_anticipated_buffer_size ?
> alloca(bytes) : new void[bytes];
>
> toStringz is a very common source of allocations. This alloca approach
> would be great in those cases, filenames in particular.

Alternatively just make a TLS buffer as scratchpad and use that everywhere.

-- 
Dmitry Olshansky

On Friday, 24 May 2013 at 09:40:03 UTC, Dmitry Olshansky wrote:
> Alternatively just make a TLS buffer as scratchpad and use that everywhere.

I believe that's what TempAlloc is for.

On 2013-05-23 23:42, Joseph Rushton Wakeling wrote:

> I'm also in agreement with Manu.  There may well already be bugs for some of
> them -- e.g. there is one for toUpperInPlace which he referred to, and the
> source of the allocation is clear and is even responsible for other bugs:
> http://d.puremagic.com/issues/show_bug.cgi?id=9629

toUpper/lower cannot be made in place if it should handle all Unicode. Some characters will change their length when convert to/from uppercase. Examples of these are the German double S and some Turkish I.

-- 
/Jacob Carlborg

24-May-2013 13:49, Jacob Carlborg пишет:
> On 2013-05-23 23:42, Joseph Rushton Wakeling wrote:
>
>> I'm also in agreement with Manu.  There may well already be bugs for
>> some of
>> them -- e.g. there is one for toUpperInPlace which he referred to, and
>> the
>> source of the allocation is clear and is even responsible for other bugs:
>> http://d.puremagic.com/issues/show_bug.cgi?id=9629
>
> toUpper/lower cannot be made in place if it should handle all Unicode.
> Some characters will change their length when convert to/from uppercase.
> Examples of these are the German double S and some Turkish I.
>

Yes! Now we're getting somewhere. The function was a mistake to begin with.

-- 
Dmitry Olshansky

On Friday, 24 May 2013 at 09:49:40 UTC, Jacob Carlborg wrote:
> toUpper/lower cannot be made in place if it should handle all Unicode. Some characters will change their length when convert to/from uppercase. Examples of these are the German double S and some Turkish I.

In that case it should only allocate when needed. Most strings are ASCII and will not change size.