How can D become adopted at my company?

[Sean Kelly]

On Apr 29, 2012, at 2:38 AM, Manu <turkeyman at gmail.com> wrote:

> On 28 April 2012 18:16, Peter Alexander <peter.alexander.au at 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. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120429/a1d6840c/attachment.html>