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

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.
1 2 3 4
Top | Discussion index | About this forum | D home