www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Possibility of non stop-the-world GC in the future?

reply "Nicholas Smith" <nmsmith65 gmail.com> writes:
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?
Feb 18 2013
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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.
Feb 18 2013
prev sibling next sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
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
Feb 18 2013
next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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?
Feb 18 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
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
Feb 18 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
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.
Feb 18 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
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
Feb 18 2013
parent "Nicholas Smith" <nmsmith65 gmail.com> writes:
On Monday, 18 February 2013 at 14:47:19 UTC, Benjamin Thaut wrote:

 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.


.NET's GC is really nice for games, as far as GCs go. Something 
like that would make a memory-managed D acceptable.

I'm happy for a  nogc D though, and in many ways it's a better 
option (and it's easier to make happen). This is what I need to 
consider D viable for me. Notify me when this is integrated into 
D! I think a lack of support for purely manual memory management 
in D is what causes a lot of C and C++ programmers to turn their 
nose up at it. It sure is a beautiful language and I'm excited to 
see it grow. Pure MMM could widen its appeal.
Feb 22 2013
prev sibling next sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
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?
Feb 18 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
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
Feb 18 2013
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
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.
Feb 18 2013
parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 18.02.2013 15:14, schrieb John Colvin:

 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.


I'm currently in the progress of doing so. I had exams and thus not that 
much time. But they are over now and I can continue to work on this pull 
request. I tend to only push when all currently known issues are fixed. 
Thats why there are no new commits yet.

-- 
Kind Regards
Benjamin Thaut
Feb 18 2013
prev sibling next sibling parent reply "Sergei Nosov" <sergei.nosov gmail.com> writes:
On Monday, 18 February 2013 at 10:35:59 UTC, 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


http://dlang.org/garbage.html has a list of features that rely on 
GC and I would say everything in this list is something you 
cannot (simply) do without dynamic allocation.

And as far as I'm concerned, you don't want to use even dynamic 
allocation in a game due to real-time constraints, since any 
dynamic allocation is non-deterministic. I don't know any 
"serious" project that doesn't use pre-allocation and stuff.

Do I understand it correctly, that you pointed out the parts in 
druntime/phobos that "overrely" on GC (could be done without it, 
but done otherwise)?

Cause if not - avoiding everything from that list should make GC 
present almost unnoticeable. And that's what you want to do 
anyways, whether GC is present or not, if you're really targeting 
real-time.
Feb 18 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 18.02.2013 16:08, schrieb Sergei Nosov:

 On Monday, 18 February 2013 at 10:35:59 UTC, 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


 http://dlang.org/garbage.html has a list of features that rely on GC and
 I would say everything in this list is something you cannot (simply) do
 without dynamic allocation.

 And as far as I'm concerned, you don't want to use even dynamic
 allocation in a game due to real-time constraints, since any dynamic
 allocation is non-deterministic. I don't know any "serious" project that
 doesn't use pre-allocation and stuff.


Well games are only soft-realtime. So you can afford having dynamic 
allocations. But you are correct. For dynamic allocations it is usually 
tried to use custom allocators which are backed by preallocated memory 
blocks. But still its a lot less of a problem to use malloc a free on a 
even during the simulation compared to a stop the world mark & sweep.


 Do I understand it correctly, that you pointed out the parts in
 druntime/phobos that "overrely" on GC (could be done without it, but
 done otherwise)?


Yes correct. But if you would do them otherwise you wouldn't need a GC 
in the first place. The whole point of the GC is that you can be more 
productive by not caring about this stuff.


 Cause if not - avoiding everything from that list should make GC present
 almost unnoticeable. And that's what you want to do anyways, whether GC
 is present or not, if you're really targeting real-time.


Correct. Still I rather have a system that gives me errors when I make 
hidden runtime allocations then having the GC clean them up for me. 
Coding by convetion never works out well, especially in lager teams.

Kind Regards
Benjamin Thaut
Feb 18 2013
next sibling parent reply "Sergei Nosov" <sergei.nosov gmail.com> writes:
On Monday, 18 February 2013 at 17:58:56 UTC, Benjamin Thaut wrote:

 Yes correct. But if you would do them otherwise you wouldn't 
 need a GC in the first place. The whole point of the GC is that 
 you can be more productive by not caring about this stuff.


Well, that's kind of strange. I guess std library is not the 
place where you want to care about productivity over performance. 
Is there anything preventing fixing those? Did you brought that 
up to the developers? Or may be you know their attitude?


 Correct. Still I rather have a system that gives me errors when 
 I make hidden runtime allocations then having the GC clean them 
 up for me. Coding by convetion never works out well, especially 
 in lager teams.


Then I guess you would rather use C++ than D. =) It's more of 
"idiomatic" subject than anything else. One of the ways C++ and D 
differs is the answer to the question "what should happen if you 
do something *fancy*?".

The C++ answer is "the program should crash (go to the undefined 
behavior area)". And the D answer is "the program should 
sacrifice performance/memory, but remain in a well-defined state 
and *do the right thing*".
Feb 18 2013
parent reply "Dicebot" <m.strashun gmail.com> writes:
On Tuesday, 19 February 2013 at 07:19:06 UTC, Sergei Nosov wrote:

 Then I guess you would rather use C++ than D. =) It's more of 
 "idiomatic" subject than anything else. One of the ways C++ and 
 D differs is the answer to the question "what should happen if 
 you do something *fancy*?".

 The C++ answer is "the program should crash (go to the 
 undefined behavior area)". And the D answer is "the program 
 should sacrifice performance/memory, but remain in a 
 well-defined state and *do the right thing*".


This is unreasonable. D targets itself as a system programming 
language, among the others usage cases, and thus request to have 
a compiler-enforced memory usage guard is perfectly valid. What 
shall it do if something "fancy" is attempted in  nogc? Issue a 
compile-time error, profit!
Feb 18 2013
parent "Sergei Nosov" <sergei.nosov gmail.com> writes:
On Tuesday, 19 February 2013 at 07:36:43 UTC, Dicebot wrote:

 This is unreasonable. D targets itself as a system programming 
 language, among the others usage cases, and thus request to 
 have a compiler-enforced memory usage guard is perfectly valid. 
 What shall it do if something "fancy" is attempted in  nogc? 
 Issue a compile-time error, profit!


I have nothing against  nogc. It seems to be a nice idea. I would 
like to see a way to "talk to GC" in D.

What I'm saying is things seem not to be that bad right now.
Feb 19 2013
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Monday, 18 February 2013 at 17:58:56 UTC, Benjamin Thaut wrote:

 Yes correct. But if you would do them otherwise you wouldn't 
 need a GC in the first place. The whole point of the GC is that 
 you can be more productive by not caring about this stuff.


That a very limited view of things. GC avoid many bookeping that 
you would have done with manual memory management, and depending 
on the code, granted you can tolerate some floating garbage, it 
can even be faster.

Coupled with immutability, GC allow to get rid of ownership. It 
allow to avoid many copies and allocation you'd have done with 
other memory management systems.

GC is surely not the magic tool that solve all problems, but it 
does way more that what you claim. It does open new doors.
Feb 19 2013
parent reply "Minas Mina" <minas_mina1990 hotmail.co.uk> writes:
 nogc sounds nice, but how could someone use classes(OOP) with 
this?
Feb 19 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 19.02.2013 17:45, schrieb Minas Mina:

  nogc sounds nice, but how could someone use classes(OOP) with this?


The same way you do in c++. Manual memory management.
Feb 19 2013
next sibling parent "Rob T" <alanb ucora.com> writes:
On Tuesday, 19 February 2013 at 18:45:00 UTC, Benjamin Thaut 
wrote:

 Am 19.02.2013 17:45, schrieb Minas Mina:

  nogc sounds nice, but how could someone use classes(OOP) with 
 this?


 The same way you do in c++. Manual memory management.


Yeah, it would basically reduce memory management of D down to 
the level of C++, but it would still be much better than C++ and 
we can target localized sections of code to be  nogc only where 
needed, so we can get the best out of both worlds.

For  nogc sections of code, it would be very useful if Phobos had 
smart pointers, similar to what have in C++11.

--rt
Feb 19 2013
prev sibling parent reply "Minas Mina" <minas_mina1990 hotmail.co.uk> writes:
On Tuesday, 19 February 2013 at 18:45:00 UTC, Benjamin Thaut 
wrote:

 Am 19.02.2013 17:45, schrieb Minas Mina:

  nogc sounds nice, but how could someone use classes(OOP) with 
 this?


 The same way you do in c++. Manual memory management.


But I guess you would like to have OOP as well. Would that be 
possible with  nogc?
Feb 23 2013
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
23-Feb-2013 14:25, Minas Mina пишет:

 On Tuesday, 19 February 2013 at 18:45:00 UTC, Benjamin Thaut wrote:

 Am 19.02.2013 17:45, schrieb Minas Mina:

  nogc sounds nice, but how could someone use classes(OOP) with this?


 The same way you do in c++. Manual memory management.


 But I guess you would like to have OOP as well. Would that be possible
 with  nogc?


std.conv.emplace

It has some bugs presently though I haven't hit a single one but there is.
See e.g. this pull:
https://github.com/D-Programming-Language/phobos/pull/1082

Vote up. Or was that only for bugzilla ? :)

-- 
Dmitry Olshansky
Feb 23 2013
prev sibling parent reply JoeCoder <dnewsgroup2 yage3d.net> writes:
On 2/18/2013 5: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


I very much enjoyed this article.  Hopefully your changes can be applied 
upstream.

A couple of my own ideas, in hopes that those with more knowledge can 
comment:

1.  A  nogc attribute.  This would work similarly to pure/safe/nothrow 
and would check at compile time that annotated functions or any they 
call allocate any memory enforced by the GC.  Then phobos would no 
longer be a "landmine" for those with realtime requirements.

2.  GC.collect(timeout).  This would run a collection only until timeout 
is reached.  It could be called with timeout=remaining frame time, and 
would allow expensive collections to span multiple frames.
Feb 18 2013
next sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 18.02.2013 18:49, schrieb JoeCoder:

 1.  A  nogc attribute.  This would work similarly to pure/safe/nothrow
 and would check at compile time that annotated functions or any they
 call allocate any memory enforced by the GC.  Then phobos would no
 longer be a "landmine" for those with realtime requirements.


I really would love to have that too. The problem with this still would 
be exceptions because D throws by reference and not by value like C++. 
To make this work there would be the need to add a special Exception 
allocator and make the compiler emit delete calls in case the exception 
is caught and not rethrown or something similar.

Kind Regards
Benjamin Thaut
Feb 18 2013
next sibling parent reply "Nicholas Smith" <nmsmith65 gmail.com> writes:
It sounds like it's too easy to leak memory with the GC off at 
the moment. I'd love a  nogc attribute as well, if it can be done.
Feb 18 2013
parent "Rob T" <alanb ucora.com> writes:
On Monday, 18 February 2013 at 22:29:39 UTC, Nicholas Smith wrote:

 It sounds like it's too easy to leak memory with the GC off at 
 the moment. I'd love a  nogc attribute as well, if it can be 
 done.


I'd love to have that too.

The other area where the GC can get in the way is with systems 
level programming.

Rob
Feb 18 2013
prev sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Monday, 18 February 2013 at 18:00:58 UTC, Benjamin Thaut wrote:

 Am 18.02.2013 18:49, schrieb JoeCoder:

 1.  A  nogc attribute.  This would work similarly to 
 pure/safe/nothrow
 and would check at compile time that annotated functions or 
 any they
 call allocate any memory enforced by the GC.  Then phobos 
 would no
 longer be a "landmine" for those with realtime requirements.


 I really would love to have that too. The problem with this 
 still would be exceptions because D throws by reference and not 
 by value like C++. To make this work there would be the need to 
 add a special Exception allocator and make the compiler emit 
 delete calls in case the exception is caught and not rethrown 
 or something similar.

 Kind Regards
 Benjamin Thaut


perhaps a  nogc attribute that forbade everything *except* 
exceptions to use the GC would be still useful. After all, 
exceptions probably aren't going to be used in the normal 
execution path of high performance code.
Feb 19 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
John Colvin:


 perhaps a  nogc attribute that forbade everything *except* 
 exceptions to use the GC would be still useful. After all, 
 exceptions probably aren't going to be used in the normal 
 execution path of high performance code.


There is some discussion here:
http://d.puremagic.com/issues/show_bug.cgi?id=5219

Bye,
bearophile
Feb 19 2013
parent reply JoeCoder <dnewsgroup2 yage3d.net> writes:
On 2/19/2013 7:46 AM, bearophile wrote:

 There is some discussion here:
 http://d.puremagic.com/issues/show_bug.cgi?id=5219

 Bye,
 bearophile


Thanks for the heads-up.  I added a vote.  Is it possible/permissible to 
vote for an issue more than once?
Feb 19 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
JoeCoder:


 Is it possible/permissible to vote for an issue more than once?


I don't think so.

Bye,
bearophile
Feb 22 2013
prev sibling parent "Rob T" <alanb ucora.com> writes:
On Monday, 18 February 2013 at 17:49:28 UTC, JoeCoder wrote:

 On 2/18/2013 5: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


 I very much enjoyed this article.  Hopefully your changes can 
 be applied upstream.

 A couple of my own ideas, in hopes that those with more 
 knowledge can comment:

 1.  A  nogc attribute.  This would work similarly to 
 pure/safe/nothrow and would check at compile time that 
 annotated functions or any they call allocate any memory 
 enforced by the GC.  Then phobos would no longer be a 
 "landmine" for those with realtime requirements.

 2.  GC.collect(timeout).  This would run a collection only 
 until timeout is reached.  It could be called with 
 timeout=remaining frame time, and would allow expensive 
 collections to span multiple frames.


Maybe a DIP should be written up to get this idea on the radar. 
Some means to safely disable the GC without fear of using 
features that perform hidden allocations is a real necessity. 
Even with a better GC, there will still be a requirement to 
disable it for some applications.

--rt
Feb 19 2013
prev sibling next sibling parent reply "Don" <don nospam.com> writes:
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?


CDGC is not abandoned. We've been using it in production code for 
a very long time, in an extremely demanding environment. Luca is 
presenting a talk about it at the D conference.
Feb 19 2013
next sibling parent reply "Nicholas Smith" <nmsmith65 gmail.com> writes:
On Tuesday, 19 February 2013 at 08:11:10 UTC, Don wrote:

 CDGC is not abandoned. We've been using it in production code 
 for a very long time, in an extremely demanding environment. 
 Luca is presenting a talk about it at the D conference.


Is that so? What state is it in? It appears not to have been 
spoken of or worked on for quite a while now.
Feb 19 2013
parent "simendsjo" <simendsjo gmail.com> writes:
On Tuesday, 19 February 2013 at 10:41:38 UTC, Nicholas Smith 
wrote:

 On Tuesday, 19 February 2013 at 08:11:10 UTC, Don wrote:

 CDGC is not abandoned. We've been using it in production code 
 for a very long time, in an extremely demanding environment. 
 Luca is presenting a talk about it at the D conference.


 Is that so? What state is it in? It appears not to have been 
 spoken of or worked on for quite a while now.


It's quite strange. Seems it was included in an experimental 
branch back in 2010: 
http://www.dsource.org/projects/druntime/changeset/418
Feb 19 2013
prev sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Tuesday, 19 February 2013 at 08:11:10 UTC, Don wrote:

 CDGC is not abandoned. We've been using it in production code 
 for a very long time, in an extremely demanding environment. 
 Luca is presenting a talk about it at the D conference.


I wish you Sociomantic guys could be a bit more open about your 
use of D. It would be great for advertising and having more 
feedback from real-world production environments would be good 
for development. But I guess company policy prevents that?

David
Feb 19 2013
prev sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 18 February 2013 at 08:33:41 UTC, Nicholas Smith wrote:

 ...



 I'm not so knowledgable in the theory behind GCs but I know 
 that in natively compiled languages your options are much more 
 limited.

 ...


It is always a question of what semantics a given language has, 
not how it is implemented.

--
Paulo
Feb 19 2013