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