How can D become adopted at my company?

[Manu]

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120429/26951edf/attachment.html>