D on next-gen consoles and for game development

[Manu]

On 24 May 2013 17:57, Don <turnyourkidsintocash at nospam.com> wrote:

> 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.
>

Yeah, I've often wanted API's in that fashion too.
I wonder if it would be worth creating overloads of allocating functions
that receive an output buffer argument, rather than return an allocated
buffer...
Too messy?


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

How does that work?

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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130525/769bb25b/attachment-0001.html>