--- Comment #116 from Rob Jacques <> 2011-04-14 19:00:38 PDT ---
(In reply to comment #113)
> (In reply to comment #112)
> > Anything with hard realtime requirements cannot do allocation - even in 
> > C/C++,
> > malloc() does not have an upper limit on its time.
> > 
> > What is done is to pre-allocate everything necessary before entering the 
> > hard
> > realtime section.
> This does not apply to the discussion. Video games do not have hard-realtime
> requirements.

Yes, they do. It's called the frame rate. (Though I'd guess to be technical, 
this a soft-realtime requirement.)

> Garbage collection speed dictates how much work must the programmer do to
> offset the GC's slowness. If the GC is fast enough that it does not cause
> performance issues on systems satisfying the game's minimum system
> requirements, the programmer doesn't need to care about it at all. Otherwise,
> they must do some work (the slower the GC, the more work) to reduce the size 
> of
> the heap, or the number of allocations, or ultimately abandon heap allocation
> entirely. This might be easy in simple video games, but becomes increasingly
> painful in very large projects, with non-trivial user interfaces etc.
> So, by making the GC slower, you are creating more work for me. I am not happy
> about it.

Why do you think the GC will get slower? One of the major points of a precise
GC is that it does less total work than a conservative GC. Why? Because
following a pointer, even if it goes nowhere, is an expensive operation (I'd
guess O(log Heap_Size)) to say nothing of the cost of keeping around and
tracing the excess garbage. And the more precision the GC has, the less
pointers it has to trace per unit memory and the total memory traced is reduced
as well. So it's win-win.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to