On Sunday, 1 November 2015 at 20:55:00 UTC, Martin Nowak wrote:
> On 11/01/2015 09:51 PM, Martin Nowak wrote:
>> Any hint/numbers showing that this is actually useful?
>
> Also doesn't a good backend optimizer already fuse writes?

Yes but you have this myth flying around that it is necessary for good RC, because language like C++ do implicit sharing, so RC must be done atomically, so the optimizer can't optimize.

On 11/01/2015 03:51 PM, Martin Nowak wrote:
> On 10/27/2015 01:27 PM, Andrei Alexandrescu wrote:
>> Unrelated, and a foreshadowing of the discussion on the lifetime mailing
>> list: the compiler has ample opportunity to fuse incs/decs together, so
>> the signatures of these functions is:
>>
>> void opInc(uint delta);
>> void opDec(uint delta);
>
> Any hint/numbers showing that this is actually useful?

Would be great to collect some, and generally get rigorous about the whole approach.

> Implementing such a cross statement optimization is quite some work. If
> this occurs often enough (in particular for shared classes with atomic
> ref counting) it might be worth the effort.

Most reference counting techniques revolve around reducing mutation of the reference count. See e.g. https://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-2012.pdf.

So we need to show that many refcount updates take it from 1 to larger than 1 and back. According to https://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-2012.pdf, many objects have a reference count of just one; the "eclipse" benchmark has 31.8% objects with a refcount greater than 1.


Andrei

On 11/01/2015 03:54 PM, Martin Nowak wrote:
> On 11/01/2015 09:51 PM, Martin Nowak wrote:
>> Any hint/numbers showing that this is actually useful?
>
> Also doesn't a good backend optimizer already fuse writes?

My understanding is that no, that won't happen in most patterns that matter. -- Andrei

On Sunday, 1 November 2015 at 22:36:46 UTC, Andrei Alexandrescu wrote:
> On 11/01/2015 03:51 PM, Martin Nowak wrote:
>> On 10/27/2015 01:27 PM, Andrei Alexandrescu wrote:
>>> Unrelated, and a foreshadowing of the discussion on the lifetime mailing
>>> list: the compiler has ample opportunity to fuse incs/decs together, so
>>> the signatures of these functions is:
>>>
>>> void opInc(uint delta);
>>> void opDec(uint delta);
>>
>> Any hint/numbers showing that this is actually useful?
>
> Would be great to collect some, and generally get rigorous about the whole approach.
>
>> Implementing such a cross statement optimization is quite some work. If
>> this occurs often enough (in particular for shared classes with atomic
>> ref counting) it might be worth the effort.
>
> Most reference counting techniques revolve around reducing mutation of the reference count. See e.g. https://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-2012.pdf.
>
> So we need to show that many refcount updates take it from 1 to larger than 1 and back. According to https://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-2012.pdf, many objects have a reference count of just one; the "eclipse" benchmark has 31.8% objects with a refcount greater than 1.
>
>
> Andrei

That paper is assuming that you take Java(a language that does *not* have allocation patterns like D such as favoring data on the stack, tightly packed arrays of data, and immutability) rip out its GC, and replace it with a RC-based GC with no concept of unique ownership - no?

On 11/1/15 5:52 PM, rsw0x wrote:
> On Sunday, 1 November 2015 at 22:36:46 UTC, Andrei Alexandrescu wrote:
>> On 11/01/2015 03:51 PM, Martin Nowak wrote:
>>> On 10/27/2015 01:27 PM, Andrei Alexandrescu wrote:
>>>> Unrelated, and a foreshadowing of the discussion on the lifetime
>>>> mailing
>>>> list: the compiler has ample opportunity to fuse incs/decs together, so
>>>> the signatures of these functions is:
>>>>
>>>> void opInc(uint delta);
>>>> void opDec(uint delta);
>>>
>>> Any hint/numbers showing that this is actually useful?
>>
>> Would be great to collect some, and generally get rigorous about the
>> whole approach.
>>
>>> Implementing such a cross statement optimization is quite some work. If
>>> this occurs often enough (in particular for shared classes with atomic
>>> ref counting) it might be worth the effort.
>>
>> Most reference counting techniques revolve around reducing mutation of
>> the reference count. See e.g.
>> https://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-2012.pdf.
>>
>> So we need to show that many refcount updates take it from 1 to larger
>> than 1 and back. According to
>> https://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-2012.pdf,
>> many objects have a reference count of just one; the "eclipse"
>> benchmark has 31.8% objects with a refcount greater than 1.
>>
>>
>> Andrei
>
> That paper is assuming that you take Java(a language that does *not*
> have allocation patterns like D such as favoring data on the stack,
> tightly packed arrays of data, and immutability) rip out its GC, and
> replace it with a RC-based GC with no concept of unique ownership - no?

The class objects we're focusing on for RC support are supposed to be used much like in Java. -- Andrei

On Sunday, 1 November 2015 at 22:04:51 UTC, deadalnix wrote:
> On Sunday, 1 November 2015 at 20:55:00 UTC, Martin Nowak wrote:
>> On 11/01/2015 09:51 PM, Martin Nowak wrote:
>>> Any hint/numbers showing that this is actually useful?
>>
>> Also doesn't a good backend optimizer already fuse writes?
>
> Yes but you have this myth flying around that it is necessary for good RC, because language like C++ do implicit sharing, so RC must be done atomically, so the optimizer can't optimize.

Yes, ARC does the atomic RC too, but ARC is bound by prior focus on manual RC without compiler support and should not be used as an example to be followed.

D could go for a more generic solution with specialized restricted integer types for resource tracking with different capabilites. Same amount of work, but much more versatile.

The library could then use templated RCPointers with the capabilites as parameters which recast the resource tracking integer to the desired type which injects the appropriate assumptions to the optimizer before/after each operation on the integer.

E.g. for the non-transfer-to-other-threads/fiber integer counter type:

1. the optimizer needs to know that below a specific block/stackframe the test "counter==0" always fails.

2. semantics that ensures that  contexts (fiber/thread) only are allowed to subtract a value they already have added. Easy way out is RAII.

On Monday, 2 November 2015 at 09:56:14 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 1 November 2015 at 22:04:51 UTC, deadalnix wrote:
>> On Sunday, 1 November 2015 at 20:55:00 UTC, Martin Nowak wrote:
>>> On 11/01/2015 09:51 PM, Martin Nowak wrote:


http://lists.puremagic.com/cgi-bin/mailman/listinfo/dlang-study


The last post on the study group ended a while ago. Does that mean it is not going forward. It suggest to talk about lifetime. Is that with or without talking about
reference counting simultaneously?

What approach will be taken?


1) Will for every assignment to the object a hidden temporary be created by the compiler to keep the object alive.

RCObject obj = new RCObject();
Item item = obj.items[x];

_temp1 = obj;       //The compiler inserts this automatically and is not seen.
obj=new RCObject();


2) Will you disable the item by some magical way? Item might still be valid.

RCObject obj = new RCObject();
...
Item item = obj.items[x];

obj=new RCObject();
//item is no longer accessible beyond this point.
writeln(item); //error


3) Somehow disable the RCObject for the duration of the borrowing.

with(Item item = RCObject.items[x])
{
  writeln(item)
}


4) Solved by eating pizza or watching a movie ...



Maybe the discussion should be a tree.

On Saturday, 5 December 2015 at 22:06:33 UTC, sclytrack wrote:
> On Monday, 2 November 2015 at 09:56:14 UTC, Ola Fosheim Grøstad wrote:
>> On Sunday, 1 November 2015 at 22:04:51 UTC, deadalnix wrote:
>>> On Sunday, 1 November 2015 at 20:55:00 UTC, Martin Nowak wrote:
>>>> On 11/01/2015 09:51 PM, Martin Nowak wrote:
>
>
> http://lists.puremagic.com/cgi-bin/mailman/listinfo/dlang-study
>
>
> The last post on the study group ended a while ago. Does that mean it is not going forward. It suggest to talk about lifetime. Is that with or without talking about
> reference counting simultaneously?
>

It means that now that all the bikescheding is behind, people can work on the hard problems. And it takes time. Especially when you have goto int he language.

Am 01.11.2015 um 21:47 schrieb Martin Nowak:
> On 10/27/2015 12:41 PM, Andrei Alexandrescu wrote:
> - I'm not a fan of adding yet another attribute but as inference support
>    is currently limited it seems we'd need an explicit attribute for
>    public APIs.

I've very likely missed that part of the discussion - what were the reasons to not use "scope" for this?

On Monday, 7 December 2015 at 07:10:42 UTC, Sönke Ludwig wrote:
> I've very likely missed that part of the discussion - what were the reasons to not use "scope" for this?

Yeah good point, it should be possible to reuse scope as method attribute. I just used @noescape as a placeholder for the discussion.