Swift does away with pointers == pervasive ARC

[w0rp via Digitalmars-d]

On Tuesday, 17 June 2014 at 00:22:55 UTC, Manu via Digitalmars-d 
wrote:
> On 17 June 2014 10:08, deadalnix via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>> On Monday, 16 June 2014 at 15:16:44 UTC, Manu via 
>> Digitalmars-d wrote:
>>>
>>> What say you to that, Walter?
>>>
>>> Apple have committed to pervasive ARC, which you consistently 
>>> argue is
>>> not feasible...
>>> Have I missed something, or is this a demonstration that it is
>>> actually practical?
>>
>>
>> http://stackoverflow.com/questions/24101718/swift-performance-sorting-arrays
>>
>> Does it answer the question ?
>
> -Ofast seems to perform the same as C++. -Ofast allegedly does
> basically what '-release -noboundscheck' does. You'd never try 
> and
> benchmark D code without those flags.

The thing which slowed his loop down was the compiler not 
removing the retain and release calls for ARC in that case. As he 
says.

> With -O3 I get something that was beyond my wildest 
> imagination. The inner loop spans 88 lines of assembly code. I 
> did not try to understand all of it, but the most suspicious 
> parts are 13 invocations of "callq _swift_retain" and another 
> 13 invocations of "callq _swift_release". That is, 26 
> subroutine calls in the inner loop!

Obviously they can optimise these retain and release calls away. 
However, I don't believe it will work with the right 
optimisations in place for hot code. I think the only thing which 
can work reliably in hot code is memory you manage yourself. I 
don't think there's an automatic memory management scheme which 
will do all of the work for you in most situations without 
incurring some additional runtime cost.