RFC: reference counted Throwable

[Walter Bright via Digitalmars-d]

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.