3 ms·

The reason they are not used is not the circular reference problem, it's performance. Single-threaded ARC is passable, but thread-safe ARC is really, really slo

The reason they are not used is not the circular reference problem, it's performance. Single-threaded ARC is passable, but thread-safe ARC is really, really slow. It basically hits all the worst performance pitfalls of modern CPUs.

zozbot234 7y ago
Performance is really bad if you use Arc for practically everything, as with Swift. If you can deal with the simplest (tree-like) allocation patterns statically as Rust does, and use refcounting only where it's actually needed, you can outperform tracing GC.
- Razengan 7y ago
  > Performance is really bad if you use Arc for practically everything, as with Swift. Do you have examples where Swift suffers compared to other languages solely because of ARC? Also, is this something that Apple might theoretically make up for by optimizing their custom CPUs for it, without changing Swift?
  - pjmlp 7y ago
    Yes, here it arrives always last. https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages Since the Xerox PARC workstations and Genera Lisp Machines, all hardware specific instructions for memory management have proven to be worse than doing it eventually in software.
    - Razengan 7y ago
      How does that compare to SwiftNIO? https://github.com/apple/swift-nio https://github.com/apple/swift-nio
      - pjmlp 7y ago
        SwiftNIO is not high-speed network driver to start with. As for memory management impact in overall performance, a similar set of benchmarks would be needed.
  - Tuna-Fish 7y ago
    > Do you have examples where Swift suffers compared to other languages solely because of ARC? Literally all of them. Every single program where the ARC system is actually widely used. Swift otherwise generates really good code, and should be meeting/beating Java most of the time, but if the ARC system is used, performance instantly takes a massive hit. This is very visible in the small synthetic benchmarks at: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/swift.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... In every benchmark where it was possible to write the program so that no references are updated in the hot loop, Swift comes out really impressive, beating Java. In benchmarks where reference updates are unavoidable, performance is more in line with Python. > Also, is this something that Apple might theoretically make up for by optimizing their custom CPUs for it, without changing Swift? There are various theoretical ideas that have been bounced about for decades, but so far none of those has panned out. While Apple might do that too, at this point they seem to be chasing the opposite approach: https://github.com/apple/swift/blob/master/docs/OwnershipManifesto.md https://github.com/apple/swift/blob/master/docs/OwnershipMan... Essentially, nicking the ownership/lifetimes system out of Rust, to avoid updating references wherever possible. The main difference from Rust will be that the current way of doing things will still be possible and the default, but programmers can opt into more performance by decorating their types with lifetimes. I am cautiously optimistic for this approach: I love Rust, but learning it did definitely feel like being tossed right into the deep end. Which was filled with sharks. If Swift can succeed in a softer approach of introducing lifetimes, that might help the wider introduction of the concept.
    - mpweiher 7y ago
      > Every single program where the ARC system is actually widely used. Interestingly enough, the semi-automatic reference counting mechanism used previously was reasonably fast if used as-is and could be made very fast with a bit of thought.

zozbot234 7y ago

Performance is really bad if you use Arc for practically everything, as with Swift. If you can deal with the simplest (tree-like) allocation patterns statically as Rust does, and use refcounting only where it's actually needed, you can outperform tracing GC.

Razengan 7y ago
> Performance is really bad if you use Arc for practically everything, as with Swift. Do you have examples where Swift suffers compared to other languages solely because of ARC? Also, is this something that Apple might theoretically make up for by optimizing their custom CPUs for it, without changing Swift?
- pjmlp 7y ago
  Yes, here it arrives always last. https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages Since the Xerox PARC workstations and Genera Lisp Machines, all hardware specific instructions for memory management have proven to be worse than doing it eventually in software.
  - Razengan 7y ago
    How does that compare to SwiftNIO? https://github.com/apple/swift-nio https://github.com/apple/swift-nio
    - pjmlp 7y ago
      SwiftNIO is not high-speed network driver to start with. As for memory management impact in overall performance, a similar set of benchmarks would be needed.
- Tuna-Fish 7y ago
  > Do you have examples where Swift suffers compared to other languages solely because of ARC? Literally all of them. Every single program where the ARC system is actually widely used. Swift otherwise generates really good code, and should be meeting/beating Java most of the time, but if the ARC system is used, performance instantly takes a massive hit. This is very visible in the small synthetic benchmarks at: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/swift.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... In every benchmark where it was possible to write the program so that no references are updated in the hot loop, Swift comes out really impressive, beating Java. In benchmarks where reference updates are unavoidable, performance is more in line with Python. > Also, is this something that Apple might theoretically make up for by optimizing their custom CPUs for it, without changing Swift? There are various theoretical ideas that have been bounced about for decades, but so far none of those has panned out. While Apple might do that too, at this point they seem to be chasing the opposite approach: https://github.com/apple/swift/blob/master/docs/OwnershipManifesto.md https://github.com/apple/swift/blob/master/docs/OwnershipMan... Essentially, nicking the ownership/lifetimes system out of Rust, to avoid updating references wherever possible. The main difference from Rust will be that the current way of doing things will still be possible and the default, but programmers can opt into more performance by decorating their types with lifetimes. I am cautiously optimistic for this approach: I love Rust, but learning it did definitely feel like being tossed right into the deep end. Which was filled with sharks. If Swift can succeed in a softer approach of introducing lifetimes, that might help the wider introduction of the concept.
  - mpweiher 7y ago
    > Every single program where the ARC system is actually widely used. Interestingly enough, the semi-automatic reference counting mechanism used previously was reasonably fast if used as-is and could be made very fast with a bit of thought.