View mode: basic / threaded / horizontal-split · Log in · Help
February 18, 2013
Possibility of non stop-the-world GC in the future?
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
Re: Possibility of non stop-the-world GC in the future?
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
Re: Possibility of non stop-the-world GC in the future?
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
Re: Possibility of non stop-the-world GC in the future?
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
Re: Possibility of non stop-the-world GC in the future?
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
Re: Possibility of non stop-the-world GC in the future?
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
Re: Possibility of non stop-the-world GC in the future?
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
Re: Possibility of non stop-the-world GC in the future?
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
Re: Possibility of non stop-the-world GC in the future?
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
Re: Possibility of non stop-the-world GC in the future?
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