<div dir="ltr">On 25 May 2013 00:58, H. S. Teoh <span dir="ltr"><<a href="mailto:hsteoh@quickfur.ath.cx" target="_blank">hsteoh@quickfur.ath.cx</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On Fri, May 24, 2013 at 09:34:41AM +1000, Manu wrote:<br>
[...]<br>
<div class="im">> Just to be clear, while I've hard many have, I've NEVER argued for<br>
> removing the GC. I think that's a hallmark of a modern language. I<br>
> want to use the GC in games, but it needs to have performance<br>
> characteristics that are applicable to realtime and embedded use.<br>
> Those are:<br>
> 1. Can't stop the world.<br>
> 2. Needs tight controls, enable/disable, and the allocators interface<br>
> so alternative memory sources can be used in mane places.<br>
> 3. Needs to (somehow) run incrementally. I'm happy to budget a few<br>
</div>> hundred 盜 per frame, but not a millisecond every 10 frames, or 1<br>
<div class="im">> second every 1000.<br>
>     It can have 1-2% of overall frame time each frame, but it can't<br>
> have 10-100% of random frames here and there. This results in<br>
> framerate spikes.<br>
<br>
</div>Makes sense, so basically the GC should not cause jittery framerates,<br>
but should distribute its workload across frames so that the framerate<br>
is more-or-less constant?<br></blockquote><div><br></div><div style>Precisely.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
> The GC its self can be much less efficient than the existing GC if it<br>
> want's, it's only important that it can be halted at fine grained<br>
> intervals, and that it will eventually complete its collect cycle over<br>
> the long-term.<br>
><br>
> I know that an incremental GC like this is very complex, but I've<br>
> never heard of any real experiments, so maybe it's not impossible?<br>
<br>
</div>Is there a hard upper limit to how much time the GC can take per frame?<br>
Is it acceptable to use, say, a millisecond every frame as long as it's<br>
*every* frame and not every 10 frames (which causes jitter)?<br></blockquote><div><br></div><div style>Errr, well, 1ms is about 7% of the frame, that's quite a long time.</div><div style>I'd be feeling pretty uneasy about any library that claimed to want 7% of the whole game time, and didn't offer any visual/gameplay benefits...</div>
<div style>Maybe if the GC happened to render some sweet water effects, or perform some awesome cloth physics or something while it was at it ;)<br></div><div><div>I'd say 7% is too much for many developers.</div></div>
<div><br></div><div style>I think 2% sacrifice for simplifying memory management would probably get through without much argument.</div><div style>That's ~300µs... a few hundred microseconds seems reasonable. Maybe a little more if targeting 30fps.</div>
<div style>If it stuck to that strictly, I'd possibly even grant it permission to stop the world...</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

For me, I'm also interested in incremental GCs -- for time-sensitive<br>
applications (even if it's just soft realtime, not hard), long<br>
stop-the-world pauses are really disruptive. I'd rather have the option<br>
of a somewhat larger memory footprint and a less efficient GC (in terms<br>
of rate of memory reclamation) if it can be incremental, rather than a<br>
very efficient GC that introduces big pauses every now and then. I'm<br>
even willing to settle for lower framerates if it means I don't have to<br>
deal with framerate spikes that makes the result jittery and unpleasant.<br></blockquote><div><br></div><div style>One important detail to consider for realtime usage, is that it's very unconventional to allocate at runtime at all...</div>
<div style>Perhaps a couple of short lived temp buffers each frame, and the occasional change in resources as you progress through a world (which are probably not allocated in GC memory anyway).</div><div style>Surely the relatively high temporal consistency of the heap across cycles can be leveraged here somehow to help?</div>
</div></div></div>