February 18, 2013
I'm interested in experimenting with game development in D, but the only thing putting me off is D's heavy GC reliance, which at the moment is a stop-the-world GC.

One of the biggest killers in game development is unreliable performance and before I tread down the D path I'm interested in knowing just what it is possible to do with the GC in D.

I'm not so knowledgable in the theory behind GCs but I know that in natively compiled languages your options are much more limited. I found CDGC as an apparently abandoned attempt at a concurrent GC (which also uses fork(), but the way Windows is going I'm caring less and less about them anyway).

So, how good can D's GC get?
February 18, 2013
On Monday, 18 February 2013 at 08:33:41 UTC, Nicholas Smith wrote:
> I'm interested in experimenting with game development in D, but the only thing putting me off is D's heavy GC reliance, which at the moment is a stop-the-world GC.
>
> One of the biggest killers in game development is unreliable performance and before I tread down the D path I'm interested in knowing just what it is possible to do with the GC in D.
>
> I'm not so knowledgable in the theory behind GCs but I know that in natively compiled languages your options are much more limited. I found CDGC as an apparently abandoned attempt at a concurrent GC (which also uses fork(), but the way Windows is going I'm caring less and less about them anyway).
>
> So, how good can D's GC get?

This is technically possible. But require a lot of work. We are far away from it.

You may want to talk with Manu about using for games.
February 18, 2013
Am 18.02.2013 09:33, schrieb Nicholas Smith:
> I'm interested in experimenting with game development in D, but the only
> thing putting me off is D's heavy GC reliance, which at the moment is a
> stop-the-world GC.
>
> One of the biggest killers in game development is unreliable performance
> and before I tread down the D path I'm interested in knowing just what
> it is possible to do with the GC in D.
>
> I'm not so knowledgable in the theory behind GCs but I know that in
> natively compiled languages your options are much more limited. I found
> CDGC as an apparently abandoned attempt at a concurrent GC (which also
> uses fork(), but the way Windows is going I'm caring less and less about
> them anyway).
>
> So, how good can D's GC get?

I wen't down this path already and I ended up not using the GC at all:

http://3d.benjamin-thaut.de/?p=20

-- 
Kind Regards
Benjamin Thaut
February 18, 2013
On 02/18/2013 11:35 AM, Benjamin Thaut wrote:
> I wen't down this path already and I ended up not using the GC at all:
>
> http://3d.benjamin-thaut.de/?p=20

But reading your blog post, it seems that the main problem was not GC in the general sense, but the fact that for various functionality druntime makes unnecessary allocations.  Deal with those, and with-GC D ought to speed up a lot.  Or have I misunderstood what you wrote?
February 18, 2013
Am 18.02.2013 11:35, schrieb Benjamin Thaut:
> I wen't down this path already and I ended up not using the GC at all:
> http://3d.benjamin-thaut.de/?p=20
>

are your speed fixes - for example the TypeInfo string creation etc. part of current druntime?
February 18, 2013
Am 18.02.2013 13:40, schrieb Joseph Rushton Wakeling:
> On 02/18/2013 11:35 AM, Benjamin Thaut wrote:
>> I wen't down this path already and I ended up not using the GC at all:
>>
>> http://3d.benjamin-thaut.de/?p=20
>
> But reading your blog post, it seems that the main problem was not GC in
> the general sense, but the fact that for various functionality druntime
> makes unnecessary allocations.  Deal with those, and with-GC D ought to
> speed up a lot.  Or have I misunderstood what you 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.
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.

-- 
Kind Regards
Benjamin Thaut
February 18, 2013
Am 18.02.2013 13:48, schrieb dennis luehring:
> Am 18.02.2013 11:35, schrieb Benjamin Thaut:
>> I wen't down this path already and I ended up not using the GC at all:
>> http://3d.benjamin-thaut.de/?p=20
>>
>
> are your speed fixes - for example the TypeInfo string creation etc.
> part of current druntime?

Some of the problems have already been fixed since I wrote the article, but not all of them.
About your particular question: I'm currently in the progress of getting it ready to be merged (d-style and other nitpicking stuff and some problems in phobos)
https://github.com/D-Programming-Language/druntime/pull/370

-- 
Kind Regards
Benjamin Thaut
February 18, 2013
On Monday, 18 February 2013 at 12:56:33 UTC, Benjamin Thaut wrote:
> Am 18.02.2013 13:48, schrieb dennis luehring:
>> Am 18.02.2013 11:35, schrieb Benjamin Thaut:
>>> I wen't down this path already and I ended up not using the GC at all:
>>> http://3d.benjamin-thaut.de/?p=20
>>>
>>
>> are your speed fixes - for example the TypeInfo string creation etc.
>> part of current druntime?
>
> Some of the problems have already been fixed since I wrote the article, but not all of them.
> About your particular question: I'm currently in the progress of getting it ready to be merged (d-style and other nitpicking stuff and some problems in phobos)
> https://github.com/D-Programming-Language/druntime/pull/370

Have you already done the nitpicking corrections and not pushed them to github or would you be interested in a pull request fixing them.
February 18, 2013
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.

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.
February 18, 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
« First   ‹ Prev
1 2 3 4
Top | Discussion index | About this forum | D home