Possibility of non stop-the-world GC in the future?
Benjamin Thaut
code at benjamin-thaut.de
Mon Feb 18 06:47:19 PST 2013
Am 18.02.2013 15:38, schrieb deadalnix:
> On Monday, 18 February 2013 at 12:54:24 UTC, Benjamin Thaut wrote:
>> The main problem is that programming with a GC encourages programming
>> with memory leaks. As the gc will take care of any leaked memory and
>> you don't get any feedback about how much memory you actually allocate.
>
> You can apply the same reasoning to any language feature.
>
> Bound checking encourage lazy buffer overflow checking. OOP and
> functional encourage indirect branching. And I can go on and on.
>
Of course. I'm just saing that in the field of game programming beeing
aware of the memory layout and beeing aware in what way memory is used
is the key factor for good performance. Having a GC makes it way to easy
to just ignore all the memory related issues, which is why I don't like
programming with a GC in the field of games.
> Everything that help a programmer is generally good, as long as getting
> performances back is allowed with extra work (what GC.free allows you to
> do). In other terms, if you free what you allocate you get back to
> manual memory management (well, expect some runtime weirdness).
>
>> Also even if you do manual pooling and use a GC you still pay a big
>> performance impact because the GC will scan the pooled memory without
>> actually freeing anything. But scanning takes time too. And those
>> interrupts by the GC will be long enough to interrupt regular gameplay.
>> D would at least need a incremental Mark & Sweep to be usable in
>> games. But in my opinion a GC is not needed at all when developing
>> games, it makes a lot of sense for other fields though.
>
> You'll find that in term of memory management, no magic solution exists.
> Sometime GC is faster, sometime relying on manual memory management is
> the best. Most of a the time an hybrid approach between several
> techniques best results.
Agreed. But as long as D does not have a Garbage Collector that is as
powerfull as the GC of the .NET 4 runtime you will be better of
(performance wise) not using a GC at all when programming performance
critical parts of game engines.
--
Kind Regards
Benjamin Thaut
More information about the Digitalmars-d
mailing list