5 ms·

From everything I've read Swift is still slow relative to Rush because it uses ARC and so there are increments and decrements of usage counts all over the place

From everything I've read Swift is still slow relative to Rush because it uses ARC and so there are increments and decrements of usage counts all over the place. To put it another way, Swift handles memory safety at runtime, Rust handles it at compile time? There is/was talk of trying to either do escape analysis or add some hints so the compiler can get rid of those checks but AFAIK that hasn't happened yet?

zozbot234 6y ago
Rust has Arc<> too, but it's optional. And it only increments and decrements wrt. Arc references that might affect when the object is dropped; it doesn't need to do so with references that are outlived by some existing Arc reference. I think this is what you're calling 'escape analysis' in your comment, but Rust does it statically and the 'hints' are ordinary Rust syntax.
skohan 6y ago
It's a bit more complex than "swift is slow". As you say, ARC can lead to some performance cliffs when using reference types (class), but Swift manages memory statically for value types (struct, enum). Modern idiomatic swift uses reference types quite sparingly, and Swift can be quite performant, but usually requires prolific use of profiling and optimization to get there. Best case performance for Rust will probably always be better, because even for statically managed types, Swift leans more heavily toward copying values where Rust tries to leave them in place whenever possible.
- zozbot234 6y ago
  "ARC can lead to performance cliffs" is quite optimistic. Obligate reference counting ala Swift has even lower performance than obligate GC, at least wrt. throughput. It's pretty much a dead end in many ways.
  - skohan 6y ago
    Yeah but it depends on the structure of the program right? Many swift programs might have a handful of reference counted objects which are not used in the performance-critical section of the program so the ARC penalty is negligible. I agree that ARC is probably an obstacle for Swift to overcome in the long term. There have been some interesting discussions in the Swift forums around this, and there may be some solutions, like for instance the compiler being smarter about knowing when ARC is truly necessary, and replacing it with simple RC when, for instance, an object never leaves the thread where it was created, which is probably true of a majority of objects. Probably this can be addressed when Swift's ownership model is more mature, and when the concurrency model has been formally defined.

zozbot234 6y ago

Rust has Arc<> too, but it's optional. And it only increments and decrements wrt. Arc references that might affect when the object is dropped; it doesn't need to do so with references that are outlived by some existing Arc reference. I think this is what you're calling 'escape analysis' in your comment, but Rust does it statically and the 'hints' are ordinary Rust syntax.

skohan 6y ago

It's a bit more complex than "swift is slow". As you say, ARC can lead to some performance cliffs when using reference types (class), but Swift manages memory statically for value types (struct, enum). Modern idiomatic swift uses reference types quite sparingly, and Swift can be quite performant, but usually requires prolific use of profiling and optimization to get there. Best case performance for Rust will probably always be better, because even for statically managed types, Swift leans more heavily toward copying values where Rust tries to leave them in place whenever possible.

zozbot234 6y ago
"ARC can lead to performance cliffs" is quite optimistic. Obligate reference counting ala Swift has even lower performance than obligate GC, at least wrt. throughput. It's pretty much a dead end in many ways.
- skohan 6y ago
  Yeah but it depends on the structure of the program right? Many swift programs might have a handful of reference counted objects which are not used in the performance-critical section of the program so the ARC penalty is negligible. I agree that ARC is probably an obstacle for Swift to overcome in the long term. There have been some interesting discussions in the Swift forums around this, and there may be some solutions, like for instance the compiler being smarter about knowing when ARC is truly necessary, and replacing it with simple RC when, for instance, an object never leaves the thread where it was created, which is probably true of a majority of objects. Probably this can be addressed when Swift's ownership model is more mature, and when the concurrency model has been formally defined.