3 ms·

One thing for which I can't get a clear answer: Swift uses automatic reference counting. It seems that it needs atomic operations that are expensive. Does this

One thing for which I can't get a clear answer: Swift uses automatic reference counting. It seems that it needs atomic operations that are expensive. Does this allow somehow to sidestep this? Since the data is all thread-local, it should be possible to use non-atomic counters?

dizlexic 1y ago
Never done it, but I hope this helps. https://stackoverflow.com/questions/25542416/swift-with-no-arc https://stackoverflow.com/questions/25542416/swift-with-no-a...
liuliu 1y ago
Only "class" object is reference counted (to some extents, class-like objects too). Int / struct (value-semantics) objects are not reference counted. These are copied eagerly. Swift introduced bunch of ownership keywords to help you to use value objects for most of the needs to sidestep reference-counting and minimize copying. Of course, to my understanding, "actor" in Swift is a "class"-like object, so it will be reference-counted. But I fail to see how that is different from other systems (as actor itself has to be mutable, hence, a reference object anyway).
- brandonasuncion 1y ago
  And for times you need a fast heap-allocated type, Swift's Noncopyable types have been pretty great in my experience. Especially so for graph data structures, where previously retains/releases would be the biggest slowdown. Example here: https://forums.swift.org/t/noncopyable-generics-in-swift-a-code-walkthrough/70862 https://forums.swift.org/t/noncopyable-generics-in-swift-a-c... An added plus is that the Swift compiler seems to stack-promote a lot more often, compared to class/ManagedBuffer implementations.
llm_nerd 1y ago
The Swift compiler does lifetime and ownership analysis to eliminate many/most ARC overhead, beyond when things are truly shared between threads and the like. https://g.co/gemini/share/51670084cd0f https://g.co/gemini/share/51670084cd0f - lame, but it references core concepts.
- cyberax 1y ago
  I'm not sure how it can detect that outside of trivial cases. Any object that is passed into a library function can escape the current thread, unless the compiler can analyze all the binary at once.
  - slavapestov 1y ago
    > Any object that is passed into a library function can escape the current thread, In Swift 6 this is only true if the value’s type is Sendable.
  - llm_nerd 1y ago
    Many (and increasingly most) Swift libraries are largely Swift modules delivered as SIL (Swift Intermediate Language). The compiler can indeed trace right into those calls and determine object lifetime and if it escapes. It is far more comprehensive than often presumed. Though the vast majority of cases where ARC would come into play are of the trivial variety.
    - elpakal 1y ago
      username checks out
Someone 1y ago
In addition to what others said, even if counts have to be updated, that need not always use atomic operations. See https://dl.acm.org/doi/10.1145/3243176.3243195 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.“ (I don’t know whether Swift uses this at the moment)

dizlexic 1y ago

Never done it, but I hope this helps. https://stackoverflow.com/questions/25542416/swift-with-no-arc https://stackoverflow.com/questions/25542416/swift-with-no-a...

liuliu 1y ago

Only "class" object is reference counted (to some extents, class-like objects too). Int / struct (value-semantics) objects are not reference counted. These are copied eagerly. Swift introduced bunch of ownership keywords to help you to use value objects for most of the needs to sidestep reference-counting and minimize copying. Of course, to my understanding, "actor" in Swift is a "class"-like object, so it will be reference-counted. But I fail to see how that is different from other systems (as actor itself has to be mutable, hence, a reference object anyway).

brandonasuncion 1y ago
And for times you need a fast heap-allocated type, Swift's Noncopyable types have been pretty great in my experience. Especially so for graph data structures, where previously retains/releases would be the biggest slowdown. Example here: https://forums.swift.org/t/noncopyable-generics-in-swift-a-code-walkthrough/70862 https://forums.swift.org/t/noncopyable-generics-in-swift-a-c... An added plus is that the Swift compiler seems to stack-promote a lot more often, compared to class/ManagedBuffer implementations.

llm_nerd 1y ago

The Swift compiler does lifetime and ownership analysis to eliminate many/most ARC overhead, beyond when things are truly shared between threads and the like. https://g.co/gemini/share/51670084cd0f https://g.co/gemini/share/51670084cd0f - lame, but it references core concepts.

cyberax 1y ago
I'm not sure how it can detect that outside of trivial cases. Any object that is passed into a library function can escape the current thread, unless the compiler can analyze all the binary at once.
- slavapestov 1y ago
  > Any object that is passed into a library function can escape the current thread, In Swift 6 this is only true if the value’s type is Sendable.
- llm_nerd 1y ago
  Many (and increasingly most) Swift libraries are largely Swift modules delivered as SIL (Swift Intermediate Language). The compiler can indeed trace right into those calls and determine object lifetime and if it escapes. It is far more comprehensive than often presumed. Though the vast majority of cases where ARC would come into play are of the trivial variety.
  - elpakal 1y ago
    username checks out

Someone 1y ago

In addition to what others said, even if counts have to be updated, that need not always use atomic operations. See https://dl.acm.org/doi/10.1145/3243176.3243195 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.“ (I don’t know whether Swift uses this at the moment)