I think many also find its syntax more approachable compared to that of Rust. It's got a lot of bells and whistles, but newcomers don't have to use them right away and can pick up more advanced bits as they become comfortable with doing so.
> I think many also find its syntax more approachable compared to that of Rust.
Chris Lattner (of LLVM fame) did design the language with the goal of hiding complexity until it is needed.
> The concept of progressive disclosure in Swift, where you can start with something very simple and then learn complexity as you go, was totally driven by making it teachable. I personally spent a lot of time trying to make sure that the introduction to Swift could just be print("Hello World"). No semicolons, no \ns, none of that public static void main stuff. Making it simple and approachable was a strong goal, and not in a weird way where in a teaching environment there is this “Swift Prime” language that’s similar but different.
You might be surprised (I was). Most of the benchmarks I’ve seen place it more in the neighborhood of golang and v8, rather than the C, C++, rust neighborhood you might expect.
Another commenter in this thread highlighted that the ref-counting GC is what keeps it out of the C / Rust performance neighborhood.
Ref-counting GC is pretty slow. It’s great for avoiding stop-the-world pauses, which can be really important for UI stuff like what Swift is used for, but you won’t win any throughput awards.
Swift doesn't have a GC. The automatic reference counting is a feature that just inserts retain/release statements at compile time, so there is no additional process that handles that. I would suspect that the performance hits originate from other things.
> From what I've seen the ref counting can cause a big performance hit.
Apple has been writing OS components in Swift for a while now. It certainly doesn't seem to be producing the performance issues we saw when Google attempted to write components for Fuchsia in Go or Microsoft's effort to create new features for Longhorn in .NET.
But it's mostly replacing Objective-C code which was already not particularly fast – as opposed to the C++ or C code used more often in performance- or memory-sensitive areas.
My experience with Swift is somewhat limited, because every time I've tried to use it, I've run into glaring performance issues and had to switch language. It might be reasonably performant compared to Go or .NET, but it's nothing like Rust.
What kind of stuff were you doing in Swift to notice performance issues? I've been developing macOS and iOS apps for a while now and it doesn't seem much slower than Objective-C.
It was discussed here when they decided their networking stack in Go would need to be rewritten for performance reasons, and banned the future use of Go for Fuchsia system components.
Apple has always been preferential to reference counting (see Objective C) and it seems like they may have spent a fair bit of effort optimizing Apple Silicon for it.
> it seems like they may have spent a fair bit of effort optimizing Apple Silicon for it
According to information released when the M1 came out: retaining and releasing an NSObject takes ~30 nanoseconds on current gen Intel, and ~6.5 nanoseconds on an M1
It's good to reduce the cache hot best case time of course but isnt the more fundamental sin of RC in the extra read/write memory traffic, cache footprint and cross core cache line ping pong when incrementing object refcount fields.
(or if going with BRC, correspondingly there shouldn't be a advantages for this custom CPU feature)
Reference counting is slow because it has an additional increment/decrement operator on each lifetime of a scope.
Add a little bit of salt to insult you need it to be atomic if you want it to run on SMP. This means for each time you have create/release the lifetime of an object you will make a lot of memory barriers, and create a lot of cache contention.
But in practice the overhead is actually nought, and most of the time you rather deal with I/O bound problem more than an additional atomic increment operation. Modern processor is fast enough to deal with them in few cycles in around the order of 10 nanoseconds
Swift's refcounting is atomic (as is objc's). As long as you're not under contention most benchmarks I've seen show negligible overhead (from the addition of atomicity, the refcount overhead is still there) for uncontended access. But IME if you do have many threads walking the same data structure you end up spending stupid amounts of time fighting the refcounting. This applies even if the data structure is immutable and has guaranteed lifetime as swift's type system doesn't seem to allow that to be expressed, and as a result it seems to do a lot of ref churn we'd consider unnecessary.
“BRC is based on the observation that most objects are only accessed by a single thread, which allows most RC operations to be performed non-atomically. BRC leverages this by biasing each object towards a specific thread, and keeping two counters for each object --- one updated by the owner thread and another updated by the other threads. This allows the owner thread to perform RC operations non-atomically, while the other threads update the second counter atomically.
We implement BRC in the Swift programming language runtime, and evaluate it with client and server programs. We find that BRC makes each RC operation more than twice faster in the common case. As a result, BRC reduces the average execution time of client programs by 22.5%, and boosts the average throughput of server programs by 7.3%.”
I remember reading that this made it into Swift, but cannot find it, so I’m not sure anymore.
And of course, the Swift compiler tries to avoid unnecessary refcount updates.
On apple hardware, uncontended refcounting (swift or objc) has the same perf as non-atomic refcounting. The cost exists, but it isn't terrible, once there's contention between threads the perf drops through the floor. The real killer is there are a bunch of places where the swift evaluation model means they're forced to ref churn, which comes up 100% typical workloads like the million triangle objects in my swift raytracer, all being hit by numerous threads :D
IME Swift’s refcounting is either incredibly inconsequential or a dealbreaker, with very little in between. They’ve done a very good job of optimizing it to the point where it’s barely measurable even in perf sensitive code… until you hit the scenarios where it completely murders performance and there’s nothing you can do about it.
Hopefully the upcoming ownership functional will help in those cases.