On 6/17/2014 4:36 AM, Manu via Digitalmars-d wrote:
On 17 June 2014 18:18, Walter Bright via Digitalmars-d
<[email protected]> 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.
