On Thursday, 17 July 2014 at 09:57:09 UTC, currysoup wrote:
> It's not about "acceptance", it's about the reality that a GC is not a universal solution to memory management.
>
> Just from watching a few of the DConf 2014 talks, if you want performance you avoid the GC at all costs (even if that means allocating into huge predefined buffers). Once you're going to these lengths to avoid garbage collection it begs the question, why are you even using this language? Within this community the question is rhetorical but to outsiders I feel it's a major concern.


If D came without GC, it would have replaced C++ a long time ago!

On Thursday, 17 July 2014 at 11:15:10 UTC, Chris wrote:
>
> Don't know if it's really a "major concern" or the favorite weak spot that C++ et. al guys like to flog to death in order to distract from the many strengths that D has (in comparison with C++ et al.) The answer is always "D has GC, it's the Devil, don't touch it!" Also, let's put a little faith in the brilliant developers behind D, I'm sure there's a huge performance boost for D around the corner.

I'm not here to hate on D, the reason I read these forums is because I love the language.

I feel it is a major concern, if I'm starting a project with low latency requirements* I certainly think twice about using D. I think this could apply especially to people outside the community who might not have experienced the benefits D provides. The issue is not there is a GC, it's that the GC is viewed as bad. If the GC was as good as Azul's C4 GC then D would be perfect. I'm not sure if D's memory model supports such a collector though.

*According to Don Clugston's talk the default GC can pause for ~250ms which is totally insane for any kind of interactive or near-real-time system. If their concurrent version of the GC could reduce this to 10ms it shows the GC implementation is fairly naive.

On Thursday, 17 July 2014 at 13:30:15 UTC, currysoup wrote:
> On Thursday, 17 July 2014 at 11:15:10 UTC, Chris wrote:
>>
> *According to Don Clugston's talk the default GC can pause for ~250ms which is totally insane for any kind of interactive or near-real-time system. If their concurrent version of the GC could reduce this to 10ms it shows the GC implementation is fairly naive.

The sequencer that I use executes a loop every 10 ms.

On Thursday, 17 July 2014 at 13:29:18 UTC, John wrote:
> If D came without GC, it would have replaced C++ a long time ago!

That's overly optimistic I think, but I believe that the adoption rate would have been far greater for a D without GC, or perhaps with a more GC friendly design, as the GC comes up first or close in every D discussion with prospective adopters.

However, it's way too late to change that now. IMO, the way forward involves removing all or most hidden allocations from the D libraries, making programming sans GC easier (@nogc everywhere, a compiler switch, documentation for how to work around the lack of GC, etc.) and a much better, precise GC as part of the D release. Any spec changes necessary to support precision should be in a fast path.

> I feel it is a major concern, if I'm starting a project with low latency requirements* I certainly think twice about using D. I think this could apply especially to people outside the community who might not have experienced the benefits D provides. The issue is not there is a GC, it's that the GC is viewed as bad. If the GC was as good as Azul's C4 GC then D would be perfect. I'm not sure if D's memory model supports such a collector though.

It doesn't.

On Thursday, 17 July 2014 at 14:05:02 UTC, Brian Rogoff wrote:
> On Thursday, 17 July 2014 at 13:29:18 UTC, John wrote:
>> If D came without GC, it would have replaced C++ a long time ago!
>
> That's overly optimistic I think, but I believe that the adoption rate would have been far greater for a D without GC, or perhaps with a more GC friendly design, as the GC comes up first or close in every D discussion with prospective adopters.
>
> However, it's way too late to change that now. IMO, the way forward involves removing all or most hidden allocations from the D libraries, making programming sans GC easier (@nogc everywhere, a compiler switch, documentation for how to work around the lack of GC, etc.) and a much better, precise GC as part of the D release. Any spec changes necessary to support precision should be in a fast path.

Yeah. Best avoid GC in the first place. If GC can stop the world for ~250ms, wouldn't it be possible (just an innocent thought) to tell the GC only to work, if it can guarantee to stay below a certain threshold, and do the rest later (or in a parallel thread)?

On Thursday, 17 July 2014 at 13:29:18 UTC, John wrote:
> On Thursday, 17 July 2014 at 09:57:09 UTC, currysoup wrote:
>> It's not about "acceptance", it's about the reality that a GC is not a universal solution to memory management.
>>
>> Just from watching a few of the DConf 2014 talks, if you want performance you avoid the GC at all costs (even if that means allocating into huge predefined buffers). Once you're going to these lengths to avoid garbage collection it begs the question, why are you even using this language? Within this community the question is rhetorical but to outsiders I feel it's a major concern.
>
>
> If D came without GC, it would have replaced C++ a long time ago!

The only thing that would have been replaced is the complaints that D has a garbage collector with complaints that D doesn't have the tools and existing libraries of C++. If C++ users were sincere in their claims that they really want to use D, they'd have disabled the garbage collector and used it.

I think the GC issue is eating resources that would be better spent elsewhere.

On Thursday, 17 July 2014 at 15:19:59 UTC, bachmeier wrote:
> On Thursday, 17 July 2014 at 13:29:18 UTC, John wrote:
>> On Thursday, 17 July 2014 at 09:57:09 UTC, currysoup wrote:
>>> It's not about "acceptance", it's about the reality that a GC is not a universal solution to memory management.
>>>
>>> Just from watching a few of the DConf 2014 talks, if you want performance you avoid the GC at all costs (even if that means allocating into huge predefined buffers). Once you're going to these lengths to avoid garbage collection it begs the question, why are you even using this language? Within this community the question is rhetorical but to outsiders I feel it's a major concern.
>>
>>
>> If D came without GC, it would have replaced C++ a long time ago!
>
> The only thing that would have been replaced is the complaints that D has a garbage collector with complaints that D doesn't have the tools and existing libraries of C++. If C++ users were sincere in their claims that they really want to use D, they'd have disabled the garbage collector and used it.
>
> I think the GC issue is eating resources that would be better spent elsewhere.

+1

On Thursday, 17 July 2014 at 12:37:10 UTC, w0rp wrote:

> For improving the GC to an acceptable level, I believe collection only needs to execute fast enough such that it will fit within a frame comfortably. So for something rendering at 60FPS you have 1 second / 60 frames ~= 16.6 milliseconds of computation you can do without resulting in a single dropped frame. That means you need to get collection down to something in the 1ms to 2ms region.

That's easy, just make sure your heap never grows over 0.4 MB.
Seriously, 200 MB of small object in heap = 1 second.
That's how bad it is now.
And here Walter says it won't get much better. Ever.
http://www.reddit.com/r/programming/comments/2avdod/dconf_2014_realtime_big_data_in_d_by_don_clugston/

On 7/17/14, 2:57 AM, currysoup wrote:
> On Thursday, 17 July 2014 at 09:26:38 UTC, Chris wrote:
>> On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via
>> Digitalmars-d wrote:
>>> It appears still to be a general meme that performance required no GC
>>> and GC mean poor performance. The debate has been restarted on the Go
>>> mailing list under the banner "go without garbage collector". The
>>> response to will Go remove the garbage collector was somewhat
>>> unequivocal: nope.
>>
>> That's good news in a way. If a big company accepts GC and the Go
>> crowd go with it (pardon the pun), then it will find more acceptance
>> (as Paulo pointed out in a different thread).
>
> It's not about "acceptance", it's about the reality that a GC is not a
> universal solution to memory management.
>
> Just from watching a few of the DConf 2014 talks, if you want
> performance you avoid the GC at all costs (even if that means allocating
> into huge predefined buffers).

Not at all costs! warp creates a little litter during e.g. command line preprocessing and other inconsequential tasks. The core of it is careful to not allocate frequently in inner loops.

> Once you're going to these lengths to
> avoid garbage collection it begs the question, why are you even using
> this language? Within this community the question is rhetorical but to
> outsiders I feel it's a major concern.

I agree there's a perception issue.


Andrei