<div dir="ltr">On 24 May 2013 17:57, Don <span dir="ltr"><<a href="mailto:turnyourkidsintocash@nospam.com" target="_blank">turnyourkidsintocash@nospam.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thursday, 23 May 2013 at 18:22:54 UTC, Joseph Rushton Wakeling wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On 05/23/2013 08:13 PM, Brad Anderson wrote:<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Now I'm wondering what can be done to foster this newly acquired credibility in<br>
games.  By far the biggest issue I hear about when it comes to people working on<br>
games in D is the garbage collector.  You can work around the GC without too<br>
much difficulty as Manu's experience shared in his DConf talk shows but a lot of<br>
people new to D don't know how to do that.  We could also use some tools and<br>
guides to help people identify and avoid GC use when necessary.<br>
</blockquote></div></blockquote>
<br>
<br>
It's worth noting that our code at Sociomantic faces *exactly* the same issues.<br>
We cannot use Phobos because of its reliance on the GC.<br>
Essentially, we want to have the option of avoiding GC usage in every single function.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As a starting point, do we have a list of the Phobos functions that allocate<br>
using GC when there's no need to?  That's a concern of Manu's that it ought to<br>
be possible to address relatively swiftly if the information is to hand.<br>
</blockquote>
<br></div>
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.<br>
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.<br>
<br>
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.<br></blockquote><div><br></div><div style>Yeah, I've often wanted API's in that fashion too.</div>
<div style>I wonder if it would be worth creating overloads of allocating functions that receive an output buffer argument, rather than return an allocated buffer...</div><div style>Too messy?</div><div><br></div><div><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But anyway, after fixing the obvious Phobos offenders, another huge step would be to get TempAlloc into druntime and used wherever possible in Phobos.<br></blockquote><div><br></div><div style>How does that work?</div><div style>
<br></div><div style>One pattern I've used a lot is, since we have a regular 60hz timeslice and fairly a regular pattern from frame to frame, we use a temp heap which pushes allocations on the end like a stack, then wipe it clean at the state of the next frame.</div>
<div style>Great for any small allocations that last no longer than a single frame. It's fast (collection is instant), and it also combats memory fragmentation, which is also critically important when working on memory limited systems with no virtual memory/page file.</div>
</div></div></div>