On Saturday, 20 September 2014 at 16:52:59 UTC, Paulo Pinto wrote:
> As it seems, RC with GC for cycle collection was more common than I thought of.

I once read a paper that suggested optimizing GC by having RC on all objects and stop inc/dec ref counting when it reached 5 or something. I guess the idea was to get rid of short lived objects to make the GC run less often while cutting RC overhead.

On Saturday, 20 September 2014 at 16:55:08 UTC, Andrei Alexandrescu wrote:
> The language will change in major ways, and this is the warmup before that. -- Andrei

Ugh. I'm very concerned about the direction this is going, replacing a system that works with something that offers little benefit and a lot of risk.

On Saturday, 20 September 2014 at 16:41:20 UTC, Andrei Alexandrescu wrote:
> On 9/20/14, 2:05 AM, ponce wrote:
>> On Friday, 19 September 2014 at 15:32:38 UTC, Andrei Alexandrescu wrote:
>>> Please chime in with thoughts.
>>
>> Coudln't we throw value types instead? (like in C++)
>
> My knee-jerk reaction is we shouldn't. If considered, that would need to be well argued. We've derived good benefits from using polymorphic exceptions. -- Andrei

What do you think of the solution briefly outlined here:
http://forum.dlang.org/post/iqenumncmczqvprwutmg@forum.dlang.org

On 9/20/2014 3:00 AM, Ola Fosheim Grostad wrote:
> On Saturday, 20 September 2014 at 08:39:41 UTC, Walter Bright wrote:
>>> E.g. TSX is coming even if there is
>>> a bug in lower end CPUs. Suggest making performance oriented prototypes on
>>> different architectures before concluding.
>>
>> I'd love to see it.
>
> A 128 bit CAS instruction is at about 19-25 cycles, but a transaction on the
> other hand can by using xbegin/xend cover both refcounting, locking and rollback
> of multiple objects so you need cooperation from code gen. Basically all changes
> between xbegin/xend are kept in cache and written to memory upon success. On
> failure you have a slower fallback.
>
> I don't know what that leads to in amortized cost reduction, but 30-70% might be
> possible if it is done right.

Please show me the inc/dec optimized x86 code.



>> As soon as you pass a reference to a function, that all goes out the window.
>> There's a reason why Rust has invested so much effort in the notion of a
>> "borrowed" pointer.
>
> The pure @nogc crowd care less about safety, but you should be able to track
> this using dataflow?

Suppose I pass a pointer to:

   void foo(T* p);

How do I do dataflow?


>>> 3. True, but you can keep the refcount at a negative offset for new-based
>>> allocations. Besides it only affects those who do @nogc and they should know
>>> what they are doing.
>>
>> If this is so simple, why doesn't everyone do it?
>
> Never said performance and thread safe RC was easy. It is probably difficult to
> get below 10 cycles for inc/dec pairs even with excellent code gen...? And
> probably closer to 40 cycles for regular code gen. Just guessing.

The question was about mixing RC'd and non-RC'd objects.

On 9/20/2014 8:59 AM, Andrei Alexandrescu wrote:
> 4. Using the GC inadvertently goes undetected.
>
> I disagree that (4) is good for everyone.

We've already implemented @nogc.

On 9/20/2014 5:27 AM, Jacob Carlborg wrote:
> Assuming this would eventually be implemented for regular classes, it would be
> nice if it could be made compatible with Objective-C ARC [1].
>
> [1] http://clang.llvm.org/docs/AutomaticReferenceCounting.html
>

There was a long thread about that a year back or so. It wasn't looking good.

On 9/20/2014 5:27 AM, Jacob Carlborg wrote:
> On 2014-09-19 17:32, Andrei Alexandrescu wrote:
>
>> Whenever a reference to a Throwable is copied about, passed to
>> functions, the compiler inserts appropriately calls to e.g. incRef and
>> decRef. (Compiler may assume they cancel each other for optimization
>> purposes.
>
> Assuming this would eventually be implemented for regular classes, it would be
> nice if it could be made compatible with Objective-C ARC [1].
>
> [1] http://clang.llvm.org/docs/AutomaticReferenceCounting.html


http://www.digitalmars.com/d/archives/digitalmars/D/draft_proposal_for_ref_counting_in_D_211885.html

On Saturday, 20 September 2014 at 18:18:05 UTC, Walter Bright wrote:
>
> Please show me the inc/dec optimized x86 code.

There's no optimization of the inc/dec, you use regular inc/dec within a larger xbegin/xend block.

You amortize the cost over all the lock-prefixed instructions you would otherwise have executed in that block. There is no locking, there is a transaction instead. Only if the transaction fails do you execute the locking fallback code.

> Suppose I pass a pointer to:
>
>    void foo(T* p);
>
> How do I do dataflow?

You mean a separate compilation unit that the compiler don't have access to? You don't, obviously.

> The question was about mixing RC'd and non-RC'd objects.

Well, if you are talking about negative offset for ref counts, then people do it. E.g. there are examples of systems that provide C-compatible strings with length at offset -4 and ref count at -8.

If you need to distinguish you can either use address-space info or keep a negative int in the non-RC'd object.

On 9/20/14, 10:50 AM, Adam D. Ruppe wrote:
> On Saturday, 20 September 2014 at 16:55:08 UTC, Andrei Alexandrescu wrote:
>> The language will change in major ways, and this is the warmup before
>> that. -- Andrei
>
> Ugh. I'm very concerned about the direction this is going, replacing a
> system that works with something that offers little benefit and a lot of
> risk.

Fasten your seatbelt, it's gonna be a bumpy ride! :o)

Andrei

On 9/20/14, 11:17 AM, ponce wrote:
> On Saturday, 20 September 2014 at 16:41:20 UTC, Andrei Alexandrescu wrote:
>> On 9/20/14, 2:05 AM, ponce wrote:
>>> On Friday, 19 September 2014 at 15:32:38 UTC, Andrei Alexandrescu wrote:
>>>> Please chime in with thoughts.
>>>
>>> Coudln't we throw value types instead? (like in C++)
>>
>> My knee-jerk reaction is we shouldn't. If considered, that would need
>> to be well argued. We've derived good benefits from using polymorphic
>> exceptions. -- Andrei
>
> What do you think of the solution briefly outlined here:
> http://forum.dlang.org/post/iqenumncmczqvprwutmg@forum.dlang.org

The short answer is I wouldn't advise pursuing it. -- Andrei