> On Saturday, 12 September 2015 at 06:23:12 UTC, Jonathan M Davis wrote:
>> Aside from the few classes in Phobos, its GC usage is almost entirely restricted to when it allocates arrays or when it has to allocate a closure for a delegate, which can happen in some cases when passing predicates to range-based algorithms. Avoiding functions that need to allocate arrays avoids that source of allocation, and using functors or function pointers as predicates avoids having to allocate closures. So, you _can_ end up with GC allocations accidentally in Phobos if you're not careful, but on the whole, the assertion that Phobos uses the GC heavily is FUD - or at least a misunderstanding. But as we make more of the functions use lazy ranges rather than arrays (particularly with regards to strings), and we make more of the code @nogc, it becomes even clearer that the GC isn't involved. Also, improvements to how lambdas are handled should reduce how often closures have to be allocated for them.

Thank you for this.  How large is the allocation for closure for a delegate?  Just a pair of pointers?

On Saturday, 12 September 2015 at 13:42:44 UTC, Prudence wrote:
> I don't think it's that simple.
>
> Saying that it doesn't use it most of the time is not an answer/solution. Using it at all is a problem because one doesn't know when and where. I realize there is a switch now(-vgc), and maybe that is the solution, but you say "well, phobos only uses 0.01% on the GC", yet since you either don't, can't, or won't know where that is, then it might as well be 100% if you would like to potentially get off the GC one day.
>
> It's like playing Russian roulette. It doesn't matter if only 1/6 times will kill you. It's totally different than 0/6.

But if you hardly use the GC, how long is it really going to take to run?

On Saturday, 12 September 2015 at 13:42:44 UTC, Prudence wrote:
> Saying that it doesn't use it most of the time is not an answer/solution. Using it at all is a problem because one doesn't know when and where. I realize there is a switch now(-vgc), and maybe that is the solution, but you say "well, phobos only uses 0.01% on the GC", yet since you either don't, can't, or won't know where that is, then it might as well be 100% if you would like to potentially get off the GC one day.

"you either don't, can't, or won't know where that is"

just check the signature, no ? eg

http://dlang.org/phobos/std_string.html
pure nothrow @nogc @system inout(char)[] fromStringz(inout(char)* cString);
             ^^^^^

On Saturday, 12 September 2015 at 22:36:00 UTC, Laeeth Isharc wrote:
> Thank you for this.  How large is the allocation for closure for a delegate?  Just a pair of pointers?

It depends on what the delegate needs to capture. It makes a copy of the local variables the function is referencing. (Usually pretty small I'd gamble; how big are your typical function's arguments and local vars?)

On Saturday, 12 September 2015 at 13:42:44 UTC, Prudence wrote:
> Using it at all is a problem because one doesn't know when and where.

It is called when the collect function is called and where it was called from.

D's garbage collector isn't magic, it is just a function that frees memory when the pool runs low.

> It's like playing Russian roulette. It doesn't matter if only 1/6 times will kill you. It's totally different than 0/6.

The big difference is the garbage collector doesn't actually kill you.

Memory corruption, use-after-free, and double-free bugs on the other hand often do terminate your process.

On Friday, 11 September 2015 at 17:29:47 UTC, Prudence wrote:
> I don't care about "maybe" working. Since the array is hidden inside a class I can control who and how it is used and deal with the race conditions.

Looks like destruction slipped out of your control. That is solved by making array an instance member of wrapper singleton, then you will control its lifetime:

> class MySharedArrayWrapper
> {
>     private Array!(int) a;
>
> }
>
> and instead I use
>
> static shared MySharedArrayWrapper;

You will have one static instance of wrapper and it will have one instance of the array.

On Saturday, September 12, 2015 13:42:42 Prudence via Digitalmars-d-learn wrote:
> On Saturday, 12 September 2015 at 06:23:12 UTC, Jonathan M Davis wrote:
> > On Friday, September 11, 2015 23:29:05 Laeeth Isharc via Digitalmars-d-learn wrote:
> >> On Friday, 11 September 2015 at 21:58:28 UTC, Adam D. Ruppe wrote:
> >> > [...]
> >>
> >> Seems to be quite a lot of FUD wrt use of standard library and GC, which means also perhaps we don't communicate this point very well as a community.  Making Phobos GC-optional perhaps is an ultimate answer.  But people seem to think that you're back to C without the GC.
> >
> > Aside from the few classes in Phobos, its GC usage is almost entirely restricted to when it allocates arrays or when it has to allocate a closure for a delegate, which can happen in some cases when passing predicates to range-based algorithms. Avoiding functions that need to allocate arrays avoids that source of allocation, and using functors or function pointers as predicates avoids having to allocate closures. So, you _can_ end up with GC allocations accidentally in Phobos if you're not careful, but on the whole, the assertion that Phobos uses the GC heavily is FUD - or at least a misunderstanding. But as we make more of the functions use lazy ranges rather than arrays (particularly with regards to strings), and we make more of the code @nogc, it becomes even clearer that the GC isn't involved. Also, improvements to how lambdas are handled should reduce how often closures have to be allocated for them.
> >
>
> I don't think it's that simple.
>
> Saying that it doesn't use it most of the time is not an answer/solution. Using it at all is a problem because one doesn't know when and where. I realize there is a switch now(-vgc), and maybe that is the solution, but you say "well, phobos only uses 0.01% on the GC", yet since you either don't, can't, or won't know where that is, then it might as well be 100% if you would like to potentially get off the GC one day.
>
> It's like playing Russian roulette. It doesn't matter if only 1/6 times will kill you. It's totally different than 0/6.

If someone wants to avoid the GC entirely, then they need to use @nogc and -vgc to verify that they didn't miss marking something with @nogc somewhere whether they're using Phobos or not. But regardless, it's still FUD to claim that Phobos uses the GC heavily. And the reality of the matter is that the vast majority of programs will have _no_ problems with using the GC so long as they don't use it heavily. Programming like you're in Java and allocating everything on the heap will kill performance, but idiomatic D code doesn't do that, and Phobos doesn't do that. Far too many programmers freak out at the thought of D even having a GC and overreact thinking that they have to root it out completely, when there really is no need to. Plenty of folks how written highly performant code in D using the GC. You just have to avoid doing a lot of allocating and make sure you track down unwanted allocations when you have a performance problem.

@nogc will help folks avoid allocations that they don't intend to have, and other improvements to Phobos like rangifying most of the array/string-based stuff such that very little functionality actually needs to operate on arrays and instead is able to operate on lazy ranges will help as well. But the idea that your average D program is going to run into problems with the GC while using Phobos is just plain wrong. The folks who need to care are the rare folks who need extreme enough performance that they can't afford for the GC to _ever_ stop the world. And anyone who cares that much is simply going to have to avoid using new anywhere in their code, and if they use any code that they don't write - Phobos included - they will need to verify whether the GC is being used or not by that coding @nogc or by using -vgc. That's not going to change no matter what we do with Phobos. And it doesn't change the fact that it's just plain wrong to claim that Phobos requires the GC. _Some_ of its functionality does. The vast majority of it doesn't, and anyone who cares enough to make sure that they don't use the GC while using Phobos can mark their code with @nogc to make sure that they don't accidentally use something in Phobos which could allocate on the GC heap.

- Jonathan M Davis

On Sunday, 13 September 2015 at 15:35:07 UTC, Jonathan M Davis wrote:
> But the idea that your average D program is going to run into problems with the GC while using Phobos is just plain wrong. The folks who need to care are the rare folks who need extreme enough performance that they can't afford for the GC to _ever_ stop the world.

Even in that case not all threads need to be real-time and you can do threads without GC.

Honestly I think only people using microcontrollers or really constrained environments and don't have the memory have that problem.

I suspect preciously few of the GC haters actually have those requirements or misrepresents the ways to avoid GC-related problems.

Same arguments but there is a solution for everything:

"Don't want memory overhead" => minimize heap usage, use -vgc / -profile=gc
"Don't want pauses" => unregister thread + @nogc
"Want shorter pauses" => minimize heap usage, use -vgc / -profile=gc
"Want determinism" => ways to do that

GC is basically ok for anything soft-realtime, where you already spend a lot of time to go fast enough. And if you want hard-realtime, well you wouldn't want malloc either.

It's a non-problem.

On Sunday, 13 September 2015 at 15:35:07 UTC, Jonathan M Davis wrote:
> the GC heavily. And the reality of the matter is that the vast majority of programs will have _no_ problems with using the GC so long as they don't use it heavily. Programming like you're in Java and allocating everything on the heap will kill performance, but idiomatic D code doesn't do that, and Phobos doesn't do that. Far too many programmers freak out at the thought of D even having a GC and overreact thinking that they have to root it out completely, when there really is no need to. Plenty of folks how written highly performant code in D using the GC. You just have to avoid doing a lot of allocating and make sure you track down unwanted allocations when you have a performance problem.

I don't understand this argument. Even if the GC heap only contains a single live object, you still have to scan ALL memory that contains pointers.

So how does programming like you do in Java affect anything related to the GC?

Or are you saying that finalization is taking up most of the time?

On Sunday, 13 September 2015 at 16:53:20 UTC, ponce wrote:
> GC is basically ok for anything soft-realtime, where you already spend a lot of time to go fast enough. And if you want hard-realtime, well you wouldn't want malloc either.
>
> It's a non-problem.

If this was true then Go would not have a concurrent collector.

On Sunday, 13 September 2015 at 16:58:22 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 13 September 2015 at 15:35:07 UTC, Jonathan M Davis wrote:
>> the GC heavily. And the reality of the matter is that the vast majority of programs will have _no_ problems with using the GC so long as they don't use it heavily. Programming like you're in Java and allocating everything on the heap will kill performance, but idiomatic D code doesn't do that, and Phobos doesn't do that. Far too many programmers freak out at the thought of D even having a GC and overreact thinking that they have to root it out completely, when there really is no need to. Plenty of folks how written highly performant code in D using the GC. You just have to avoid doing a lot of allocating and make sure you track down unwanted allocations when you have a performance problem.
>
> I don't understand this argument. Even if the GC heap only contains a single live object, you still have to scan ALL memory that contains pointers.
>
> So how does programming like you do in Java affect anything related to the GC?
>
> Or are you saying that finalization is taking up most of the time?

The problem is that these people arguing that the GC is the holy grail simply use statistics for their reasoning. They pigeon everyone in the same box they exist in, and you find out it's useless to argue with them because their logic is flawed.

What if I happen to write a RT app that happens to use a part of phobo's that happens to heavily rely on the GC? Am I suppose to use -vgs all the time to avoid that? Do I avoid phobo's because 3 functions in it use the GC? Am I suppose to memorize a table of all the places phobo's uses the GC and then roll my own to avoid them?

The fact is, that the proponents of the GC such as JMD do not write RT apps and could care less bout that aspect. This is why they make such easy claims. For them, RT is just theoretical mumbo jumbo that doesn't exist in the real world. The GC is, also, for them, a safety blanket so they can be lazy and not have to keep track of all the things they should be. This type of mentality seems to run rampet in the contributors of D. They simply cannot understand the perspective of the other side(or refuse to).

Statistics has nothing to do with facts. The fact is, for a hard real time app, the GC and it's stop the world behavior is a no go. As long as the mentality exists that the GC is good enough because it 99% of phobo's doesn't use it or 99% of apps don't need RT, or whatever, D will never be as powerful as it can be.

Basically, I know you need your snotty safety blanket and it works for you, but I don't want to use it! Don't force me! I won't force you to give up your blanket but don't force me to use it. The road goes both ways, stop trying to make it one way.
(The argument is fundamentally different. They want to exclude, I want to include)

Of course, the real issue is, that it will take someone that has the opposite point of view from them to actually do anything about it, because it's obvious they won't work the direction they think is a waste. So, ultimately, it's people like me that have to step up and actually do the work. I am hesitant because it's always an uphill battle with such people. Instead of working together, they have to make it a struggle. (it's always "Why are you trying to take my safety blanket away!!! wa, wa wa" and tears follow)