February 18, 2013
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
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
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
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
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
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
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
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
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
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.