Swift does away with pointers == pervasive ARC

Manu via Digitalmars-d digitalmars-d at puremagic.com
Tue Jun 17 04:36:09 PDT 2014


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. 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.
We agree ARC isn't acceptable without compiler support. That's never
been on debate.
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.

I believe your explanations, but that's not where I'm hung up. In most
cases I can visualise, there is significant opportunity for the
compiler to eliminate redundant work, and in the remaining cases, I
can imagine numerous very simple approaches to remove the bumps from
hot code without interfering very much at all.
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.

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.


More information about the Digitalmars-d mailing list