Swift does away with pointers == pervasive ARC

[Walter Bright via Digitalmars-d]

On 6/17/2014 4:36 AM, Manu via Digitalmars-d wrote:
> On 17 June 2014 18:18, Walter Bright via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>> On 6/16/2014 10:02 PM, Manu via Digitalmars-d wrote:
>>
>>> I can't imagine exceptions would appear in hot code very often/ever?
>>
>>
>> I've tried to explain this to you for months. You don't believe my
>> explanations, we just go round in circles. I strongly suggest you write some
>> code with shared_ptr<T> and try it out. Disassemble the result. Benchmark
>> it. Use Microsoft C++, so I won't be sabotaging your results and it won't be
>> because I write crappy compilers :-)
>
> ARC is useless without compiler support.

It is not possible to understand the tradeoffs with ARC without understanding 
the cost of the DEC.


> If we can't experiment with
> the compiler's ability to eliminate redundant RC related work, then we
> aren't 'experimenting' with anything of interest.

That is assuming that a sufficiently smart compiler can eliminate all costs 
associated with ARC, so there is no need to understand those costs. This really 
is a faulty assumption. No compiler has achieved this, or come even close.


> I have no way of testing whether the compiler is able to produce
> acceptable results in C or D today. shared_ptr will demonstrate what
> we already know is not acceptable, not whether the results of compiler
> support for RC optimisation is satisfactory.

What shared_ptr will demonstrate to you is the cost of a dec, which you do not 
believe to be significant, and how that is affected by exception handling, which 
you stated that you do not understand.

I don't think it is possible to make appropriate tradeoffs without understanding 
these costs, and when/why they are incurred. Nor does it make it possible to 
understand the tradeoffs in relation to the design decisions made by Rust/Swift.

To advocate ARC for D means understanding this stuff. It'll only take a few 
minutes of your time.


> Andrei's detailed document from months ago demonstrating a good RC
> implementation was encouraging, although he somehow presented it as
> evidence against RC, which I never understood.

Please, take some time to try out RC and disassemble the code.


> It's all about the compilers ability to eliminate the redundant work,
> and it's possible that in some instances, that might result in
> slightly different usage or access patterns, which is a relevant part
> of the experiment. I don't see how I can do any meaningful experiment
> with shared_ptr, since the bumps will never go away no matter how
> they're arranged.

If compilers were smart enough to remove the ref counts, you'd be right. But 
they aren't - not even close. Hence there are big time penalties for those 
bumps, and to understand the tradeoffs it is necessary to understand the height 
of them.