On Apr 29, 2012, at 2:38 AM, Manu <turkey...@gmail.com> wrote: > On 28 April 2012 18:16, Peter Alexander <peter.alexander...@gmail.com> wrote: > On Saturday, 28 April 2012 at 09:14:51 UTC, SomeDude wrote: > On Saturday, 28 April 2012 at 09:12:23 UTC, SomeDude wrote: > > Real time guarantees on a GC is not something we are going to offer anytime > soon anyway. While a minimal library, loosely based on the C standard > library, with some more bells and whistles that could be borrowed from > Phobos, this is a goal that is achievable in a foreseeable future. And both > game developers and embedded programmers would be interested. > > Note that Kenta Cho, who wrote fast games in D1, used this approach, and it > worked very well for him. > > I also write games in D. > > My approach is this: use the GC all you want during loading or other > non-interactive parts of the game and then just make sure that you don't use > it during gameplay. > > GC vs. manual memory allocation is a non-issue for real-time guarantees. The > simple fact of the matter is that you should be using neither. I also don't > use malloc/free during runtime because it has the same non-real-time problems > as using the GC. A single malloc can stall for tens of milliseconds or more, > and that's simply too much. > > Just learn how to write code that doesn't allocate memory. > > A bigger problem with GC for games is memory management i.e. controlling how > much memory is currently allocated, and what systems are using what memory. > Having deterministic memory usage is preferable for those cases because I > know that as soon as I delete something that the memory is available for > something else. I don't get that guarantee with a GC. > > I think that basically sums it up. > > I'm interested to know is whether using a new precise GC will guarantee ALL > unreferenced stuff will be cleaned on any given sweep. > I can imagine a model in games where I could: > 1 Use the GC to allocate as much as I like during initialisation > 2 During runtime you never allocate anyway, so disable the GC (this is when > it is important to know about hidden allocations) > 3 During some clean-up, first run the logic to de-reference all things that > are no longer required > 4 Finally, force a precise GC scan, which should guarantee that all > no-longer referenced memory would be cleaned up at that time. > > This would actually be a very convenient working model for games. But it only > works if I know everything that was released will definitely be cleaned, > otherwise I may not be ale to allocate the next level (games often allocate > all memory a machine has within 100k or so).
For a use pattern like this, one thing that may work is to add a GC proxy immediately before loading a level. To unload the level, terminate that GC.
