On Sun, 2015-02-22 at 10:21 +0100, Benjamin Thaut via Digitalmars-d wrote:
> Am 22.02.2015 um 03:13 schrieb Walter Bright:
> >
> > Nobody thinks GC is suitable for hard realtime.
> 
> I think you should know manu good enough by now that you know he is not talking about hard realtime but soft realtime instead. (e.g. games) There are GCs which handle this situation pretty well but D's GC is not one of them.

If the D GC really is quite so bad, why hasn't a cabal formed to create a new GC that is precise, fast and efficient?

I suspect Python's RC/GC approach is one architecture, whilst Java G1 is another. (Ignore all previous GCs in OpenJDK, they "suck". Sadly the GCs other than G1 that are interesting on the JVM are proprietary.)

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Sunday, 22 February 2015 at 09:48:16 UTC, Russel Winder wrote:
> On Sun, 2015-02-22 at 10:21 +0100, Benjamin Thaut via Digitalmars-d
> wrote:
>> Am 22.02.2015 um 03:13 schrieb Walter Bright:
>> >
>> > Nobody thinks GC is suitable for hard realtime.
>> 
>> I think you should know manu good enough by now that you know he is not talking about hard realtime but soft realtime instead. (e.g. games) There are GCs which handle this situation pretty well but D's GC is not one of them.
>
> If the D GC really is quite so bad, why hasn't a cabal formed to create
> a new GC that is precise, fast and efficient?
>
> I suspect Python's RC/GC approach is one architecture, whilst Java G1 is
> another. (Ignore all previous GCs in OpenJDK, they "suck". Sadly the GCs
> other than G1 that are interesting on the JVM are proprietary.)

GCs are difficult.

I don't think they're as bad for soft realtime as some people would lead you to believe though. A nice advantage of GCs is that you can hold off all collections, and soft realtime(games) frequently have pauses long enough for collections.

The issue I found with D's GC by default is that it runs far too often and it's _much_ more efficient to do large collections infrequently than frequent small collections. IIRC this is completely adjustable in 2.067.

Just my 2 cents.

Also, .NET's GC is under MIT now AFAIK(?). I don't even know what the quality of it is, but .NET is and has been Microsoft's darling.

On 2015-02-22 03:23, Walter Bright wrote:

> - RC has further performance and code bloat problems when used with
> exception handling

Exceptions in Objective-C are basically like Errors in D. Should not be caught and should terminate the applications.

Swift doesn't event have exceptions.

-- 
/Jacob Carlborg

On 2015-02-22 10:48, Russel Winder via Digitalmars-d wrote:

> If the D GC really is quite so bad, why hasn't a cabal formed to create
> a new GC that is precise, fast and efficient?

It's like with everything else that hasn't been done. No one has cared enough do to something about it.

There are some issues that makes it harder to implement a good GC in D:

* D allows to do unsafe operations like unions, casts, pointer arithmetic

* D needs to be able to interface with C

* Most good GC implementations need some kind of barrier (read or write, don't remember which). If I recall there are several people against this in the community

-- 
/Jacob Carlborg

On Sunday, 22 February 2015 at 00:43:47 UTC, Manu wrote:
> D's GC is terrible, and after 6 years hanging out in this place, I
> have seen precisely zero development on the GC front.

You must have missed RTInfo, Rainer's precise heap scanner and Sociomantic's concurrent GC.

On Sunday, 22 February 2015 at 00:43:47 UTC, Manu wrote:
> On 22 February 2015 at 05:20, JN via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> https://developer.apple.com/news/?id=02202015a
>>
>> Interesting...
>>
>> Apple is dropping GC in favor of automatic reference counting. What are the
>> benefits of ARC over GC? Is it just about predictability of resource
>> freeing? Would ARC make sense in D?
>
> D's GC is terrible, and after 6 years hanging out in this place, I
> have seen precisely zero development on the GC front.

There has been a flood of GC improvements in druntime from Martin Nowak and Rainer Schuetze over the last few months. Probably nothing that would satisfy your requirements, but it looks like some sizeable speedups nonetheless.

Am 22.02.2015 um 10:48 schrieb Russel Winder via Digitalmars-d:
> On Sun, 2015-02-22 at 10:21 +0100, Benjamin Thaut via Digitalmars-d
> wrote:
>> Am 22.02.2015 um 03:13 schrieb Walter Bright:
>>>
>>> Nobody thinks GC is suitable for hard realtime.
>>
>> I think you should know manu good enough by now that you know he is not
>> talking about hard realtime but soft realtime instead. (e.g. games)
>> There are GCs which handle this situation pretty well but D's GC is not
>> one of them.
>
> If the D GC really is quite so bad, why hasn't a cabal formed to create
> a new GC that is precise, fast and efficient?

There have been countless dicussions about D's GC and how bad it is, and how to improve it. But it always turns out that it would be a ton of work or someone doesn't like the consequences. The key points always are:

1) We need full percise pointer discovery, even for pointers on the stack.
2) We need write barriers.

1) Is a really complex task for a language like D. There is a reason why java has so a small feature set.
2) For some reason nobody likes write barries because the general fear is, that they will cost performance, so it was decided to not implement them. (Without actually measuring performance impact vs GC improvement)

The problem is that, to implement a non stop-the-world-GC you need 2) and to implement a GC which is on par with Java or C# you need 1).

So until there is no implementation for any of the both mentioned points, there will be no better GC in D. You can fake 2) with fork on linux, thats what the CDGC did (see the DConf talk). This works because fork has copy on write semantics, but there is no equivalent on Windows. Experiments by Rainer Schuetze to implement similar copy on write semantics on Windows have shown to have major overhead which is most likely even worse then implementing write barries themselfs. Experiments implementing a Heap-percise GC, again by Rainer Schuetze, have schon that percicse heap scanning is slower compared to impercise scanning.

In my opinion the key problem is, that D was designed in a way that requires a GC but D was not designed in a way to propperly support a GC. (shared, immutable and other things basically prevent thread local pools).

Kind Regards
Benjamin

On Sunday, 22 February 2015 at 12:55:17 UTC, Benjamin Thaut wrote:
> 1) We need full percise pointer discovery, even for pointers on the stack.
> 2) We need write barriers.
>
> 1) Is a really complex task for a language like D. There is a reason why java has so a small feature set.

Worse than complex, you need a strongly typed language. D's type system is ad hoc, aka broken.

> 2) For some reason nobody likes write barries because the general fear is, that they will cost performance, so it was decided to not implement them. (Without actually measuring performance impact vs GC improvement)

Barriers in a loop is not good...

3. you need to get rid of destructors et al from GC.

> The problem is that, to implement a non stop-the-world-GC you need 2) and to implement a GC which is on par with Java or C# you need 1).

Fortunately you can make do with "stop the GC threads" and still have good real time responsiveness. But that requires:

1. minimal scanning (implies significant language and compiler changes)

2. non-polluting cache friendly scanning (implies tunable or slow scan in favour of real time non-gc threads)

On 22 February 2015 at 12:13, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 2/21/2015 4:43 PM, Manu via Digitalmars-d wrote:
>>
>> D's GC is terrible, and after 6 years hanging out in this place, I have seen precisely zero development on the GC front. Nobody can even imagine, let alone successfully implement a GC that covers realtime use requirements.
>
>
> Nobody thinks GC is suitable for hard realtime.
>
>
>> On the other hand, if 'scope' is implemented well, D may have some of the best tools in town for quality ARC implementation. There is a visible way forward for quality RC in D, and I think we could do better than Apple.
>
>
> With 'return ref', which is now implemented, you can create a memory safe RefCounted type. However, nobody has bothered. Are you up for it? :-)

I can't overload on 'scope'. How can I create a scope constructor/destructor/postblit that doesn't perform the ref fiddling?

On a tangent, can I pass rvalues to ref args now? That will massively sanitise linear algebra (matrix/vector) code big time!

On 22 February 2015 at 13:53, Daniel Murphy via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> "Manu via Digitalmars-d"  wrote in message news:mailman.7037.1424565826.9932.digitalmars-d@puremagic.com...
>
>> I personally think ARC in D is the only way forwards. That is an unpopular opinion however... although I think I'm just being realistic ;)
>
>
> A big part of why it's unpopular is that nobody, including you, wants to implement it to see if it's viable.

I have no idea where to start. But I think there's a more significant inhibiting factor; even if I were to spend months learning how to have a go at such a thing, I'm already convinced it would be rejected in principle. Why would anyone waste the time while it's so clearly off the table?