Hacker News Reader

Comment by cellularmitosis | Hacker News Reader

Swift will never win against Rust for a much simpler reason: performance. Invariably, rust is chosen where performance is critical, and Swift’s reference counting GC ensures it will never compete with Rust in those scenarios.

View on HN

Slight correction: Swift‘s ARC is not a GC (the compiler just inserts retain/release calls where it’s necessary), and one can write very performant code by steering clear of reference counted types, and Objective-C types (dynamic dispatch is really slow). Value types with copy-on-write shouldn’t impose much overhead. Automatic inlining is progressing nicely AFAIK, and recently introduced concurrency can collapse callstack frames (not sure Rust does that).

> dynamic dispatch is really slow

This is false. People believe it on faith without measuring:

https://mikeash.com/pyblog/friday-qa-2016-04-15-performance-...

I have never used IMP caching, and don't think the average developer uses this (aside from indirect use of Apple's frameworks). Otherwise:

> A normal Objective-C message send is a bit slower, as we'd expect. Still, the speed of objc_msgSend continues to astound me. Considering that it performs a full hash table lookup followed by an indirect jump to the result, the fact that it runs in 2.6 nanoseconds is amazing. That's about 9 CPU cycles. In the 10.5 days it was a dozen or more, so we've seen a nice improvement. To turn this number upside down, if you did nothing but Objective-C message sends, you could do about 400 million of them per second on this computer.

So it's 9 cycles vs what, one?

Or 0, given not using dynamic dispatch allows for inlining or even the compiler optimizing the call away entirely.

> So it's 9 cycles vs what, one?

I'm not sure what you're asking? What are you trying to compare?

I’m comparing a message send with a statically linked function call (or inlining, as mentioned by sibling comment).

This has the feel of premature optimization. These are the fastest operations. Their running time starts to get overwhelmed by the slower operations as you go down the list of things tested. Making the fastest operations a few times faster doesn't necessarily have any noticeable effect on your program.

You made me think, thanks for your input. I agree that it’s not a big or unsolvable problem.

It is definitely one per CS definition of automatic memory mangement algorithms.

Compiler optimizations are exactly that, optimizations that any automatic memory mangement implementation usually takes advantage of.

I stand corrected, thanks!

Rust is pretty often chosen also in places where performance is not that critical. It has a good ecosystem, a good type system, native builds and great performace. Those factors make it a good choice in places where you'd be just fine even if it was slightly slower. If Swift loses by a small margin — and Swift is a high performance language too — it could very well edge out Rust with ergonomics.

Also great build tool and IDE support. Cargo and rust-analyzer by themselves make me not miss a GC that much.

You don't need ultra performant memory management for most of your code. Swift compiles to machine code and ARC is fine for most use cases and you can use unsafe raw pointers etc for your occasional hot code path where you want to optimize memory management.

I would love to see what this looks like in practice if you can point me to a link.

(I’m now curious if the unowned keyword would have similar performance characteristics)

https://github.com/apple/swift-evolution/blob/main/proposals...

Replying to both comments at once: I understood “win” to mean “be a viable replacement for C / C++”. A viable replacement has to meet _everyone’s_ needs, not just the needs of those for whom performance isn’t critical. And to be more specific about the performance, it isn’t by a small margin (unfortunately I no longer have the links handy, but the general trend was that Rust, C and C++ were in the same performance group, then Java, then Go, then Swift, then JavaScript. It was something like 3 to 5x slower).

I should also perhaps mention that Swift is my favorite language to develop in. I’m not trying to be antagonistic, just realistic about its prospects against Rust.

Reply on news.ycombinator.com