7 ms·

I know this might be opening a can of worms, but technically doesn’t Swift do reference counting? Which is faster than “mark and sweep” GC but will never compar

I know this might be opening a can of worms, but technically doesn’t Swift do reference counting? Which is faster than “mark and sweep” GC but will never compare to manual management (like C/C++ and rust ownership) I assume that’s the big reason.

convolvatron 4y ago
indeed. RC isn't universally faster than GC - it depends on workload
rat9988 4y ago
reference counting is not necessarily faster.
- lll-o-lll 4y ago
  It’s not faster in the normal case, it’s generally quite a bit slower. It is more predictable however (you can actually use it with real-time constraints!), and performs better under memory pressure. Whether this is a net benefit depends on what hardware you’re running on and what the app is supposed to be doing.
Jweb_Guru 4y ago
Reference counting is not faster than tracing GC for general purpose workloads, at least not without a lot of extensive tuning that includes stuff like using tracing and moving GC for the young generation (prior to the first collection), deferring reference count increment/decrements using write barriers, limiting reference count bits (and reclaiming stuck objects with some variant of full heap tracing), and so on. Many of these benefits cannot be effectively realized if you insist on prompt execution of finalizers, either. Languages like Rust and C++ gain their performance benefits not from using reference counting or immediate reclamation, but from avoiding creating garbage in the first place by stack allocating most stuff, creating large objects by-value and within vectors to reduce pointer chasing, using direct interior references into data structures in ways that it would be difficult to trace efficiently, and using data structures like arenas to emulate the benefits of generational GC in controlled contexts where a maximum lifetime can be statically determined. My personal feeling is that it's very hard to directly compare manual memory management and GC from a performance perspective because so many of the techniques that make tracing fast involve moving pointers, which is very costly to combine with many of the techniques that make manual memory management fast which rely on values not moving in memory. I think any such solution that is efficient for both kinds of memory will probably require the programmer to have very tight control over when the garbage collector can execute, whether pointers can move at particular times, etc., and the complexity of maintaining that kind of control (and getting it right!) seems so high that I'm not sure it would ever be usable for general purpose programming.
- BulgarianIdiot 4y ago
  The Swift compiler does some of the optimizations/techniques you mention Rust does. It won't reference count, when the setup is possible to analyze statically and elide ref count. Swift also has widely used complex value types, which are stored on the stack. It will also even put some reference types on the stack after doing escape analysis etc. I don't know which benchmark to trust anymore, but for some reason iOS software tends to seemingly overperform comparable ART (GC) code.
  - saagarjha 4y ago
    Value types are stored wherever appropriate. If they escape they’re going on the heap like everything else.
    - BulgarianIdiot 4y ago
      If they are very large and implement copy-on-write, sure, parts of them may be on the heap. But they don't need to be on the heap if they escape if they're just returned by copy.
      - saagarjha 4y ago
        s/very large/a couple of words/
nicoburns 4y ago
I think you’re missing the context that people are choosing Rust over Swift even in domains like backend web development which should theoretically be a good fit for Swift. And this is largely because the Swift ecosystem outside of Apple is pretty minimal.
- xedrac 4y ago
  And frankly, I have zero confidence that Apple will sufficiently invest in the language outside of their ecosystem. That's just not how Apple operates.
karmakaze 4y ago
After using Rust for my own personal tryouts, I liked it more than expected, and though I see the value in the borrow-checker don't work in areas where it's warranted. In most of my uses, I would be fine always using Rc/Arc which would make Rust equivalent to using Swift. As a language though, I much prefer Rust to Swift.
jchw 4y ago
That's certainly a reason, but Go doesn't have the adoption issues that Swift has despite Google's reputation. Go's GC may be fast, and on some workloads maybe even competitive against ARC - But, I really don't think that has anything to do with why Swift isn't seeing widespread adoption outside of the Apple ecosystem. Here's my personal opinion for why. Bear with me for a second. I just searched "Swift programming language" on my search engine and the first result looks promising: > https://developer.apple.com/swift/ https://developer.apple.com/swift/ OK. It's a language by Apple, so it's not surprising that it's on Apple's website, even though I think if you want people to get the idea that it's a serious independent project you probably should give it its own top-level site personally. (edit: Yes, I know it does. This is my honest first impression. Please keep reading.) > Swift is a powerful and intuitive programming language for iOS, iPadOS, macOS, tvOS, and watchOS. Alright, we're only talking about Apple platforms. Technically it doesn't say that it can't work outside of these OSes, but it's clear that Apple is not marketing Swift as a general purpose operating system. From Apple's marketing PoV, it's an operating system that is made for Apple platforms and anything else is incidental. > Download Xcode and learn how to build apps using Swift with documentation and sample code. No download links for users of other operating systems. But if you go to that link, all the way at the bottom, you get: > Swift is developed in the open. To learn more about the open source Swift project and community, visit Swift.org. Finally, you might notice that Swift is actually available outside of macOS. It's available for Windows and Linux, but not BSD as far as I can ascertain. The platform support of Swift is excellent when it comes to Apple devices, but it lags far behind other options when it comes to other platforms and architectures. My perception is that Apple hasn't really made a serious enough investment into making Swift a general purpose programming language outside of its own ecosystem. That's honestly fair, as doing so is no doubt extremely expensive and time-consuming, and it's an on-going investment. What they're doing now appears to kick it to the community, who has done a lot, including as far as I can tell, make Swift work on RISC-V. But Apple is literally the world's biggest technology company, so it's not exactly desirable to put a bunch of community effort into giving it the on-going support that it needs to feel "first-class" outside of Apple platforms. Even just the optics here are quite bad, and I think the fact that it's still like this is going to haunt the long-term prospects of Swift outside of Apple platforms. All of this is aside from its technical merits. Normally, I'd like to stick to purely just technical merits, but unfortunately this stuff does matter. It's part of the reason why Go is still a solid choice today even though Rust has a lot of technical advantages on paper.
jasmer 4y ago
That's definitely the elephant in the room. And the fact that it does not have clean and easy C integration. If you could do direct memory stuff and control the ARC stuff, and easily integrate with C ... ... and the docs were clean, and you could easily use something other than XCode ... Then Swift would be huge. It's a neat language but it's just not designed to go beyond Mac. The entire C++ world would move away in an instant to something clean and flexible. Rust is just too specific for most things, and Swift is just about outside. So sad.
- myko 4y ago
  Using VSCode instead of Xcode should work fairly well: https://www.swift.org/blog/vscode-extension/ https://www.swift.org/blog/vscode-extension/ https://marketplace.visualstudio.com/items?itemName=sswg.swift-lang https://marketplace.visualstudio.com/items?itemName=sswg.swi...
- sweetjuly 4y ago
  I've found Swift->C to interop very well with Swift. Yes, you get absolutely buried in UnsafeXXX wrapped types but it does do exactly what you expected. Going the other way is somewhat "herebe dragons" since @_cdecl is technically non-standardized (though there is a movement to standardize it [1]) but it definitely works fine. [1] https://forums.swift.org/t/formalizing-cdecl/40677/7 https://forums.swift.org/t/formalizing-cdecl/40677/7
- galangalalgol 4y ago
  What do you mean about rust being too specific for most things? It seems like a fairly obvious choic for c++ replacement in a new project, the issue is large c++ codebases already exist, and that migration is painful in my experience. Autocxx type support is still largely missing or in work, diplomat seems reasonable, but I haven't had an opportunity to use it for something real yet.
  - xedrac 4y ago
    I think for Rust to truly replace C++, it needs a better dynamic linking story. I wish they would make their ABI stable within a given edition. That would make it much easier for people to rely on dynamic linking, similar to how C++ does it. Without it, Rust binaries are quite huge.
pkulak 4y ago
If reference counting was faster, Java would do it. It’s better for UIs and lower latency, but a modern, generational GC can beat C in throughput (because allocations get a lot faster).
- mr_00ff00 4y ago
  Genuine question, but if that were true then why does High Frequency Trading and Performance critical applications use C if GCs can beat it?
  - zaphar 4y ago
    The two biggest languages I'm aware of in that space are Java and C++. I don't think I've heard of any shop using C. Java seems to be keeping up with C++ there as far as I know. Do you have evidence to the contrary?
    - mr_00ff00 4y ago
      Yeah I guess I used C and C++ interchangeably, but I believe C++ is the language of HFT. Do you have evidence to the contrary?
      - pjmlp 4y ago
        "Why we chose Java for our High-Frequency Trading application" https://medium.com/@jadsarmo/why-we-chose-java-for-our-high-frequency-trading-application-600f7c04da94 https://medium.com/@jadsarmo/why-we-chose-java-for-our-high-...
        mr_00ff00 4y ago
        I don’t think your article makes the claim Java keeps up with C++. That article seems to be about getting latency low and consistent so Java can compete with C++.
        4y ago

convolvatron 4y ago

indeed. RC isn't universally faster than GC - it depends on workload

rat9988 4y ago

reference counting is not necessarily faster.

lll-o-lll 4y ago
It’s not faster in the normal case, it’s generally quite a bit slower. It is more predictable however (you can actually use it with real-time constraints!), and performs better under memory pressure. Whether this is a net benefit depends on what hardware you’re running on and what the app is supposed to be doing.

Jweb_Guru 4y ago

Reference counting is not faster than tracing GC for general purpose workloads, at least not without a lot of extensive tuning that includes stuff like using tracing and moving GC for the young generation (prior to the first collection), deferring reference count increment/decrements using write barriers, limiting reference count bits (and reclaiming stuck objects with some variant of full heap tracing), and so on. Many of these benefits cannot be effectively realized if you insist on prompt execution of finalizers, either. Languages like Rust and C++ gain their performance benefits not from using reference counting or immediate reclamation, but from avoiding creating garbage in the first place by stack allocating most stuff, creating large objects by-value and within vectors to reduce pointer chasing, using direct interior references into data structures in ways that it would be difficult to trace efficiently, and using data structures like arenas to emulate the benefits of generational GC in controlled contexts where a maximum lifetime can be statically determined. My personal feeling is that it's very hard to directly compare manual memory management and GC from a performance perspective because so many of the techniques that make tracing fast involve moving pointers, which is very costly to combine with many of the techniques that make manual memory management fast which rely on values not moving in memory. I think any such solution that is efficient for both kinds of memory will probably require the programmer to have very tight control over when the garbage collector can execute, whether pointers can move at particular times, etc., and the complexity of maintaining that kind of control (and getting it right!) seems so high that I'm not sure it would ever be usable for general purpose programming.

BulgarianIdiot 4y ago
The Swift compiler does some of the optimizations/techniques you mention Rust does. It won't reference count, when the setup is possible to analyze statically and elide ref count. Swift also has widely used complex value types, which are stored on the stack. It will also even put some reference types on the stack after doing escape analysis etc. I don't know which benchmark to trust anymore, but for some reason iOS software tends to seemingly overperform comparable ART (GC) code.
- saagarjha 4y ago
  Value types are stored wherever appropriate. If they escape they’re going on the heap like everything else.
  - BulgarianIdiot 4y ago
    If they are very large and implement copy-on-write, sure, parts of them may be on the heap. But they don't need to be on the heap if they escape if they're just returned by copy.
    - saagarjha 4y ago
      s/very large/a couple of words/

nicoburns 4y ago

I think you’re missing the context that people are choosing Rust over Swift even in domains like backend web development which should theoretically be a good fit for Swift. And this is largely because the Swift ecosystem outside of Apple is pretty minimal.

xedrac 4y ago
And frankly, I have zero confidence that Apple will sufficiently invest in the language outside of their ecosystem. That's just not how Apple operates.

karmakaze 4y ago

After using Rust for my own personal tryouts, I liked it more than expected, and though I see the value in the borrow-checker don't work in areas where it's warranted. In most of my uses, I would be fine always using Rc/Arc which would make Rust equivalent to using Swift. As a language though, I much prefer Rust to Swift.

jchw 4y ago

That's certainly a reason, but Go doesn't have the adoption issues that Swift has despite Google's reputation. Go's GC may be fast, and on some workloads maybe even competitive against ARC - But, I really don't think that has anything to do with why Swift isn't seeing widespread adoption outside of the Apple ecosystem. Here's my personal opinion for why. Bear with me for a second. I just searched "Swift programming language" on my search engine and the first result looks promising: > https://developer.apple.com/swift/ https://developer.apple.com/swift/ OK. It's a language by Apple, so it's not surprising that it's on Apple's website, even though I think if you want people to get the idea that it's a serious independent project you probably should give it its own top-level site personally. (edit: Yes, I know it does. This is my honest first impression. Please keep reading.) > Swift is a powerful and intuitive programming language for iOS, iPadOS, macOS, tvOS, and watchOS. Alright, we're only talking about Apple platforms. Technically it doesn't say that it can't work outside of these OSes, but it's clear that Apple is not marketing Swift as a general purpose operating system. From Apple's marketing PoV, it's an operating system that is made for Apple platforms and anything else is incidental. > Download Xcode and learn how to build apps using Swift with documentation and sample code. No download links for users of other operating systems. But if you go to that link, all the way at the bottom, you get: > Swift is developed in the open. To learn more about the open source Swift project and community, visit Swift.org. Finally, you might notice that Swift is actually available outside of macOS. It's available for Windows and Linux, but not BSD as far as I can ascertain. The platform support of Swift is excellent when it comes to Apple devices, but it lags far behind other options when it comes to other platforms and architectures. My perception is that Apple hasn't really made a serious enough investment into making Swift a general purpose programming language outside of its own ecosystem. That's honestly fair, as doing so is no doubt extremely expensive and time-consuming, and it's an on-going investment. What they're doing now appears to kick it to the community, who has done a lot, including as far as I can tell, make Swift work on RISC-V. But Apple is literally the world's biggest technology company, so it's not exactly desirable to put a bunch of community effort into giving it the on-going support that it needs to feel "first-class" outside of Apple platforms. Even just the optics here are quite bad, and I think the fact that it's still like this is going to haunt the long-term prospects of Swift outside of Apple platforms. All of this is aside from its technical merits. Normally, I'd like to stick to purely just technical merits, but unfortunately this stuff does matter. It's part of the reason why Go is still a solid choice today even though Rust has a lot of technical advantages on paper.

jasmer 4y ago

That's definitely the elephant in the room. And the fact that it does not have clean and easy C integration. If you could do direct memory stuff and control the ARC stuff, and easily integrate with C ... ... and the docs were clean, and you could easily use something other than XCode ... Then Swift would be huge. It's a neat language but it's just not designed to go beyond Mac. The entire C++ world would move away in an instant to something clean and flexible. Rust is just too specific for most things, and Swift is just about outside. So sad.

myko 4y ago
Using VSCode instead of Xcode should work fairly well: https://www.swift.org/blog/vscode-extension/ https://www.swift.org/blog/vscode-extension/ https://marketplace.visualstudio.com/items?itemName=sswg.swift-lang https://marketplace.visualstudio.com/items?itemName=sswg.swi...
sweetjuly 4y ago
I've found Swift->C to interop very well with Swift. Yes, you get absolutely buried in UnsafeXXX wrapped types but it does do exactly what you expected. Going the other way is somewhat "herebe dragons" since @_cdecl is technically non-standardized (though there is a movement to standardize it [1]) but it definitely works fine. [1] https://forums.swift.org/t/formalizing-cdecl/40677/7 https://forums.swift.org/t/formalizing-cdecl/40677/7
galangalalgol 4y ago
What do you mean about rust being too specific for most things? It seems like a fairly obvious choic for c++ replacement in a new project, the issue is large c++ codebases already exist, and that migration is painful in my experience. Autocxx type support is still largely missing or in work, diplomat seems reasonable, but I haven't had an opportunity to use it for something real yet.
- xedrac 4y ago
  I think for Rust to truly replace C++, it needs a better dynamic linking story. I wish they would make their ABI stable within a given edition. That would make it much easier for people to rely on dynamic linking, similar to how C++ does it. Without it, Rust binaries are quite huge.

pkulak 4y ago

If reference counting was faster, Java would do it. It’s better for UIs and lower latency, but a modern, generational GC can beat C in throughput (because allocations get a lot faster).

mr_00ff00 4y ago
Genuine question, but if that were true then why does High Frequency Trading and Performance critical applications use C if GCs can beat it?
- zaphar 4y ago
  The two biggest languages I'm aware of in that space are Java and C++. I don't think I've heard of any shop using C. Java seems to be keeping up with C++ there as far as I know. Do you have evidence to the contrary?
  - mr_00ff00 4y ago
    Yeah I guess I used C and C++ interchangeably, but I believe C++ is the language of HFT. Do you have evidence to the contrary?
    - pjmlp 4y ago
      "Why we chose Java for our High-Frequency Trading application" https://medium.com/@jadsarmo/why-we-chose-java-for-our-high-frequency-trading-application-600f7c04da94 https://medium.com/@jadsarmo/why-we-chose-java-for-our-high-...
      - mr_00ff00 4y ago
        I don’t think your article makes the claim Java keeps up with C++. That article seems to be about getting latency low and consistent so Java can compete with C++.
        4y ago