D on next-gen consoles and for game development

[Regan Heath]

On Fri, 24 May 2013 11:38:40 +0100, Dicebot <m.strashun at gmail.com> wrote:

> On Friday, 24 May 2013 at 10:24:13 UTC, Regan Heath wrote:
>> It's not the allocation caused by ~ which is the issue though is it,  
>> it's the collection it might trigger, right?
>
> Depends. When it comes to real-time software you can't say without  
> studying specific task requirements. Stop-the-world collection is a  
> complete disaster but, for example, if you consider concurrent one like  
> Leandro has shown - it can satisfy soft real-time requirements. But only  
> if heap size managed by GC stays reasonably low - thus the need to  
> control that you don't allocate in an unexpected ways.
>
>> So what you really need are 3 main things:
>>
>> 1. A way to prevent the GC collecting until a given point(*).
>
> You can do it now. Does not help if world is stopped and/or you can't  
> limit collection time.

If you disable collection, then the GC runs out of memory what happens?   
Does it simply ask the OS for more memory?  I assumed, from Leandro's  
talk, that it would block on the GC lock until collection completed, or  
simply fail if collection was disabled.

Also, the key to the idea I gave was to control collection only in the  
real-time thread/part of the application.

>> 2. A way to limit the GC collection time.
>
> Or run it concurrently with low priority. Will do for lot of _soft_  
> real-time.

I don't think Manu is doing _soft_ real-time, he wants a hard guarantee it  
will not exceed 100us (or similar).

Concurrent may be a possible solution as well, but if you think about it  
my idea is basically a second isolated collector running in a real-time  
context concurrently.

>> 3. For phobos functions to be optimised to not allocate or to use  
>> alloca where possible.
>
> Really important one as helps not only game dev / soft real-time  
> servers, but also hardcore embedded.

Sure, it's desirable to be more efficient but it's no longer essential if  
the allocations no longer cost you anything in the real-time thread -  
that's the point.

What do you think of the idea of making marked threads except from normal  
GC processing and isolating their allocations to a single page/pool in  
order to control and reduce collection times?

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/