Hacker News Reader

Comment by GeekyBear | Hacker News Reader

> just... completely don't understand the appeal of Swift beyond it being Apple's in-house language.

It's like Rust in that it offers memory safety by default without a big performance hit.

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.

https://oleb.net/blog/2017/06/chris-lattner-wwdc-swift-panel...

I did the Swift tutorial a short while ago and it was a breeze. I found it more approachable than Rust (I do like Rust).

> without a big performance hit.

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.

I remember seeing a few benchmarks where v8 and go were competitive or sometimes even slightly more performant.

So not even sure that GC has always a perf cost is always true.

Not saying it doesn't in some cases, just so that we are clear but the truth seems to be more nuanced.

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.

So well engineered for its use case. Was Go optimized for throughput?

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.

I don’t see a lot of utility in policing an overly narrow definition of what constitutes garbage collection.

ARC is a type of GC though.

From what I've seen the ref counting can cause a big performance hit. Maybe this has improved in the last couple years?

> 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.

Was probably due to FFI for Go I'd assume.

Do you have a reference somewhere I can read up?

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.

https://news.ycombinator.com/item?id=22409838

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.

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.

> Swift's refcounting is atomic (as is objc's)

Most of the time it’s possible to avoid atomic instructions and still be thread-safe. https://dl.acm.org/doi/10.1145/3243176.3243195:

“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

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 on Objective-C was plan B, after the failure of implementing a safe tracing GC in a language with C's semantics.

So they went with plan B, having the compiler automate the retain/release messages used by the Cocoa framework.

Everywhere else in Objective-C, the memory is still manually managed, or via memory pools.

Reply on news.ycombinator.com