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

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=20http://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.

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.

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

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

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

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*".

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!

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.