On Wednesday, 25 February 2015 at 21:44:05 UTC, Andrei Alexandrescu wrote:
>> You seeing this completely one sided. Even if write barries make code
>> slower by 10% its a non issue if the GC collections get faster by 10% as
>> well. Then in average the program will run at the same speed.
>
> Hmmmm... not sure the math works out that way. -- Andrei

Yeah the math are wrong, but the general idea remains.

I don't think it make sens to completely discard the idea of barriers, especially when it come to write barrier on the immutable heap. At least that should certainly pay off.

On 2/25/2015 1:50 PM, deadalnix wrote:
> On Wednesday, 25 February 2015 at 21:44:05 UTC, Andrei Alexandrescu wrote:
>>> You seeing this completely one sided. Even if write barries make code
>>> slower by 10% its a non issue if the GC collections get faster by 10% as
>>> well. Then in average the program will run at the same speed.
>>
>> Hmmmm... not sure the math works out that way. -- Andrei
>
> Yeah the math are wrong, but the general idea remains.
>
> I don't think it make sens to completely discard the idea of barriers,
> especially when it come to write barrier on the immutable heap. At least that
> should certainly pay off.

Part of the equation is D simply does not use GC anywhere near as pervasively as Java does, so the benefit/cost is greatly reduced for D.

On Wed, Feb 25, 2015 at 04:36:22PM -0800, Walter Bright via Digitalmars-d wrote:
> On 2/25/2015 1:50 PM, deadalnix wrote:
> >On Wednesday, 25 February 2015 at 21:44:05 UTC, Andrei Alexandrescu wrote:
> >>>You seeing this completely one sided. Even if write barries make code slower by 10% its a non issue if the GC collections get faster by 10% as well. Then in average the program will run at the same speed.
> >>
> >>Hmmmm... not sure the math works out that way. -- Andrei
> >
> >Yeah the math are wrong, but the general idea remains.
> >
> >I don't think it make sens to completely discard the idea of barriers, especially when it come to write barrier on the immutable heap. At least that should certainly pay off.
> 
> Part of the equation is D simply does not use GC anywhere near as pervasively as Java does, so the benefit/cost is greatly reduced for D.

Do you have data to back that up?

I don't know how typical this is, but in my own D code I tend to use arrays a lot, and they do tend to add significant GC load. A recent performance improvement attempt in one of my projects found that collection cycles take up to 40% of total running time (it's a CPU-bound process). Turning off GC collections and manually triggering them at strategic points with lower frequency gave me huge performance improvements, even though the collection cycles are still pretty slow.

I'm not sure how write barriers would play into this scenario, though. The overall performance outside of GC collections would probably suffer a bit, but it might be more than made up for by more accurate collection cycles that take only a fraction of the time -- most of the scanned data is live, only a small subset needs to be collected. A generational GC would also greatly improve this particular use case, but that seems really remote in D right now. In any case, a bit more investigation into the actual costs/benefits of write barriers might give us more concrete data to base decisions on, instead of just a blanket dismissal of the whole idea.


T

-- 
It always amuses me that Windows has a Safe Mode during bootup. Does that mean that Windows is normally unsafe?

On 2/25/2015 7:12 AM, Manu via Digitalmars-d wrote:
> It does annoy me that I can't comment on the exceptions case,

That problem is easily correctable. But if you aren't interested in doing the homework, you're stuck with accepting what I say about it :-)


> That said, I'd still be surprised if it was a terminal argument
> though. Is it really a hard impasse? Or is it just a big/awkward
> burden on the exceptional path? Surely the performance of the unwind
> path is irrelevant? Does it bleed into the normal execution path?

I've answered these questions to you already. I've also quoted the ObjectiveC compiler document saying the same thing. At some point you're going to either have to spend some time investigating it yourself or cede the point.


> I recognise there is some GC action recently, but I haven't seen any
> activity that changes the fundamental problems?

DIP25.


> COM is also an excellent candidate for consideration. If COM works
> well, then I imagine anything should work.
> Microsoft's latest C++ presents a model for this that I'm generally
> happy with; distinct RC pointer type. We could do better by having
> implicit cast to scope(T*) (aka, borrowing) which C++ can't express;
> scope(T*) would be to T^ and T* like const(T*) is to T* and
> immutable(T*).

Microsoft's Managed C++ had two pointer types, and it went over like a lead zeppelin.


> There have been lots of people come in here and say "I won't use D
> because GC",

None of those people will be satisfied with improvements to the GC.


> This is a bit of a red herring, the roadmap has no mention of ARC, or
> practical substitution for the GC. This discussion was originally
> about ARC over the GC, specifically.

See the refcounted array thread.


> I hope I'm completely wrong. Really!

I suspect you are hoping for a magic switch:

   dmd foo.d -arc

and voila! Everything will be reference counted rather than GC'd.

This is never going to happen with D. I don't see a path to it that does not involve crippling problems and compromises.

However, D will become usable with minimal or no use of the GC, by using components that are allocation agnostic, and selection of types that are RC'd. I suspect most programs will wind up using combinations of GC and RC.


> I wouldn't complain if efficient RC was on the roadmap, but I agree
> it's outside the scope for the immediate future.

Refcounted array thread.


> As I said above, and many many times in the past, I see the @nogc
> effort leading to a place where libraries are firmly divided between 2
> worlds. My criticisms of that kind have never been directly addressed.

I don't buy that. The canonical example is std.algorithm, which is highly useful components that are allocation strategy agnostic. I have since added splitterLines() which replaces the old GC splitLines() function with a component that is agnostic. This is an example of the way forward.

On Thursday, 26 February 2015 at 00:54:57 UTC, Walter Bright wrote:
>
>> COM is also an excellent candidate for consideration. If COM works
>> well, then I imagine anything should work.
>> Microsoft's latest C++ presents a model for this that I'm generally
>> happy with; distinct RC pointer type. We could do better by having
>> implicit cast to scope(T*) (aka, borrowing) which C++ can't express;
>> scope(T*) would be to T^ and T* like const(T*) is to T* and
>> immutable(T*).
>
> Microsoft's Managed C++ had two pointer types, and it went over like a lead zeppelin.
>

Rust currently has four or five pointer types(depending on how you define pointer) and it seems to be quite popular.

On 2/25/2015 4:50 PM, H. S. Teoh via Digitalmars-d wrote:
> On Wed, Feb 25, 2015 at 04:36:22PM -0800, Walter Bright via Digitalmars-d wrote:
>> On 2/25/2015 1:50 PM, deadalnix wrote:
>>> On Wednesday, 25 February 2015 at 21:44:05 UTC, Andrei Alexandrescu wrote:
>>>>> You seeing this completely one sided. Even if write barries make
>>>>> code slower by 10% its a non issue if the GC collections get faster
>>>>> by 10% as well. Then in average the program will run at the same
>>>>> speed.
>>>>
>>>> Hmmmm... not sure the math works out that way. -- Andrei
>>>
>>> Yeah the math are wrong, but the general idea remains.
>>>
>>> I don't think it make sens to completely discard the idea of
>>> barriers, especially when it come to write barrier on the immutable
>>> heap. At least that should certainly pay off.
>>
>> Part of the equation is D simply does not use GC anywhere near as
>> pervasively as Java does, so the benefit/cost is greatly reduced for
>> D.
>
> Do you have data to back that up?

I've written a Java compiler and and a GC for the Java VM (for Symantec, back in the 90's.). I'm familiar with the code generated for Java, and the code generated for D.

Yes, I'm pretty comfortable with the assessment of how often pointers are GC pointers and how often they are not.


> I don't know how typical this is, but in my own D code I tend to use
> arrays a lot, and they do tend to add significant GC load. A recent
> performance improvement attempt in one of my projects found that
> collection cycles take up to 40% of total running time (it's a CPU-bound
> process). Turning off GC collections and manually triggering them at
> strategic points with lower frequency gave me huge performance
> improvements, even though the collection cycles are still pretty slow.

Note that you didn't need write barriers for that.


> I'm not sure how write barriers would play into this scenario, though.
> The overall performance outside of GC collections would probably suffer
> a bit, but it might be more than made up for by more accurate collection
> cycles that take only a fraction of the time -- most of the scanned data
> is live, only a small subset needs to be collected. A generational GC
> would also greatly improve this particular use case, but that seems
> really remote in D right now.

Writing a generational collector for D is possible right now with no language changes, it's just that nobody has bothered to do it. Don't need write barriers for it, either.


> In any case, a bit more investigation into
> the actual costs/benefits of write barriers might give us more concrete
> data to base decisions on, instead of just a blanket dismissal of the
> whole idea.

Except that I've actually written GCs that used write barriers.

I've been there, done that. Of course, I might still be wrong. If you want to prove me wrong, do the work. You don't need compiler changes to prove yourself right, you can code in the write barriers explicitly.

On Thursday, 26 February 2015 at 00:36:26 UTC, Walter Bright wrote:
> On 2/25/2015 1:50 PM, deadalnix wrote:
>> On Wednesday, 25 February 2015 at 21:44:05 UTC, Andrei Alexandrescu wrote:
>>>> You seeing this completely one sided. Even if write barries make code
>>>> slower by 10% its a non issue if the GC collections get faster by 10% as
>>>> well. Then in average the program will run at the same speed.
>>>
>>> Hmmmm... not sure the math works out that way. -- Andrei
>>
>> Yeah the math are wrong, but the general idea remains.
>>
>> I don't think it make sens to completely discard the idea of barriers,
>> especially when it come to write barrier on the immutable heap. At least that
>> should certainly pay off.
>
> Part of the equation is D simply does not use GC anywhere near as pervasively as Java does, so the benefit/cost is greatly reduced for D.

You seems to avoid the important part of my message : write barrier tend to be very cheap on immutable data. Because, as a matter of fact, you don't write immutable data (in fact you do to some extent, but the amount of write is minimal.

There is no reason not to leverage this for D, and java comparison are irrelevant on the subject as java does not have the concept of immutability.

The same way, we can use the fact that TL data are not supposed to refers to each others.

On Thursday, 26 February 2015 at 02:48:15 UTC, Walter Bright wrote:
> Writing a generational collector for D is possible right now with no language changes, it's just that nobody has bothered to do it. Don't need write barriers for it, either.
>

How are you planning to track assignment a pointer to the young generation in the old generation ? Because if you plan to rescan the whole old generation, this is not exactly a generational GC.

On 2/25/2015 5:19 PM, weaselcat wrote:
> Rust currently has four or five pointer types(depending on how you define
> pointer) and it seems to be quite popular.

We'll see. I've already seen some complaints about that aspect.

On 2/25/2015 7:27 PM, deadalnix wrote:
> On Thursday, 26 February 2015 at 02:48:15 UTC, Walter Bright wrote:
>> Writing a generational collector for D is possible right now with no language
>> changes, it's just that nobody has bothered to do it. Don't need write
>> barriers for it, either.
> How are you planning to track assignment a pointer to the young generation in
> the old generation ? Because if you plan to rescan the whole old generation,
> this is not exactly a generational GC.

A lot of benefit simply came from compacting all the remaining used allocations together, essentially defragging the memory.