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.
