Swift does away with pointers == pervasive ARC

[via Digitalmars-d]

On Tuesday, 17 June 2014 at 05:52:37 UTC, Nick Sabalausky wrote:
> Well, I think interesting part we're trying to look at here is 
> the ARC's impact on speed.

ARC without deep whole program analysis is bound to be slow. It 
turns reads into writes. You even have to do writes to access 
read-only data-structures that will never be freed, due to 
separate compilation units.

ARC with multi-threading (and without language level 
transactions) is even worse. If you restrict ARC to thread-only 
then you might as well try to implement thread-local GC too.

Sure, with single thread restrictions, deep semantic analysis and 
heavy "templating" of functions you can get low overhead by 
inferring "borrowed pointer semantics" in the call tree, after 
taking ownership of an object, and let it propagate down the call 
chain.  But to get there you also need to deal with aggregates 
and arrays, so you need to take "over-reaching" ownership (e.g. 
take ownership of the entire array, graph or large struct) to 
avoid ref-counting every single pointer in the array/aggregate.

> We already know bounds-/overflow-checks can slow things down, 
> so I'm not sure the -O3 and -O0 timings are relevant to the 
> analysis of ARC's impact. (If anything, I have a hunch they're 
> more indicative of Swift's current immaturity.)

I somehow suspect that Apple is content if they can bring Swift 
within 10-20% of Objective-C's performance, which isn't 
impressive to begin with. The goal is to get programmers more 
productive, having a REPL etc. Swift's main competitors are 
ECMAScript6, Dart, HTML5 and cross-platform mobile scripting 
frameworks. JITs are now at about 40-20% of raw C speed, with 
multiple JITs to get fast spin-up time, that's good enough for 
most apps and even most of the code in an  average mobile game.

When devs go that route, in order to cut costs, then iOS loose 
out on iOS-only apps. The surge in mobile CPU/GPU processing 
power makes that a real threat since a yesterdays C app that runs 
on a 2-4x faster CPU can be implemented in a scripting language 
with comparable performance.

So Apple needs to cut dev costs for apps and Swift is a very 
attractive solution. Swift will probably never get the speed 
enhancements that involve challenging semantics due to the desire 
to keep the language simple (so businesses can hire cheaper 
programmers). That's the main motivation for having ARC 
everywhere IMO.

With Swift Apple can provide better tooling, not C/C++ level 
performance.