How can D become adopted at my company?

[Manu]

On 29 April 2012 16:53, Sean Kelly <sean at invisibleduck.org> wrote:

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

Interesting work around, although there are many other things that don't
get freed from state to state, and things that are shared by both state A
and B are best to keep around, save the unload/reload time of that resource
(there is always lots of sharing, it adds up).
Is it technically possible to have a precise GC clean up all unreferenced
memory in one big pass?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120430/158a9692/attachment-0001.html>