5 ms·

Reference counting is garbage collection, just a different strategy - and all these strategies tend to blur to the same methods eventually, eventually offering

by yyyk 4y ago

Reference counting is garbage collection, just a different strategy - and all these strategies tend to blur to the same methods eventually, eventually offering a latency-optimized GC or a throughput-optimized GC. Swift is inferior here because it uses reference counting GC without much work towards mitigating its drawbacks like cycles (judging by some recent posts, some of its fans apparently aren't even aware RC has drawbacks), while more established GC languages had much more time to mitigate their GC drawbacks - e.g. Java's ZGC mitigates latency by being concurrent.

fingerlocks 4y ago
What do you mean? Potential reference cycles are a compile time error in Swift. That’s the whole point of the @escaping annotation
- yyyk 4y ago
  So this[0] wasn't current despite being edited half a year ago? I guess I'm guilty of the same mistake the post had: criticizing without understanding the state of the art on the other side (at least I didn't miss it by 20 years and on an entire subfield of Computer Science). [0] https://stackoverflow.com/questions/32262172/how-can-identify-strong-reference-cycles-in-swift https://stackoverflow.com/questions/32262172/how-can-identif...
  - jumhyn 4y ago
    No, the SO post is accurate—it’s trivially easy to create strong reference cycles in Swift and @escaping annotation is only of limited use in detecting strong reference cycles. Though Swift also broadly pushes towards the use of value types for which creating reference cycles of any kind is impossible since they’re values, not references!
musicale 4y ago
Maybe Apple just hires mediocre developers (I certainly have lots of complaints about their software and UI issues, but I would probably suspect management/priorities/schedules rather than the technical staff) but they implemented GC and Automatic Reference Counting for ObjC and found that the latter resulted in better and more consistent responsiveness, which is probably what most users care about in apps. (Apps still get compressed or paged out which can lead to annoying pauses.) My anecdata indicate that Java apps are not as responsive as ObjC/Swift for the most part.
- yyyk 4y ago
  ARC is a perfectly respectable choice by itself. What's annoying me is ignoring the improvements other GC strategies and other languages have made in the last 20 years. There's a certain section of Apple users that thinks that every choice Apple makes is the only good way to do things.
- kaba0 4y ago
  And RC might be the correct choice for their devices (due to them not having much RAM, and latency being more important than throughput). But that is not true everywhere, I would even say that a good tracing GC is a better default.
- pjmlp 4y ago
  https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages The real reason why a tracing GC was a failure in Objective-C was due to the interoperability with the underlying C semantics, where anything goes. The implementation was never stable enough beyond toy examples. Naturally automating the Cocoa release/retain calls made more sense, given the constraints. In typical Apple fashion they pivoted into it, gave the algorithm a fancy name, and then in a you're holding it wrong style message, sold their plan B as the best way in the world to manage memory. When Swift came around, having the need to easily interop with the Objective-C ecosystem naturally meant to keep the same approach, otherwise they would need the same machinery that .NET uses (RCW/CCW) to interop with COM AddRef/Release. What Apple has is excellent marketing.
  - mamcx 4y ago
    > What Apple has is excellent marketing. Whoa! Marketing? Interop with C is a MASSIVE use-case. And iOS is A LOT faster and more responsive than android. That is, right there, total proof that can't denied. I do both, and the speed of apple way and the simplicity of bridge the C-abi is not a joke.
    - yyyk 4y ago
      The android/iOS comparison has many more factors than GC type. I suspect the main difference is processor type - Qualcomm ARM has been very disappointing so far, and GC type doesn't even come into it.
KerrAvon 4y ago
Your first paragraph is only true if malloc/free counts as GC. I have seen people try to claim that free() is just manual GC. You can say that if you want, but it renders the terminology meaningless. Any true GC strategy (== one that collects cycles) will fundamentally touch and allocate more memory than malloc/free, where reference counting is pretty close to malloc/free performance; it doesn’t need to touch any memory not involved. At OS scale, that’s a huge performance advantage. You can scope down the memory involved in GC using advanced, modern GC techniques, but you’re still going to be behind malloc/free in overall efficiency — cache efficiency, memory maintenance overhead, and additional memory required for bookkeeping. And reference counting will be pretty darn close to malloc/free.
- pjmlp 4y ago
  Chapter 5, https://gchandbook.org/ https://gchandbook.org/
- bruce343434 4y ago
  It puts that "extra memory" inside the very objects it tracks with a... reference count.
viktorcode 4y ago
Putting both under the same term is meaningless. Reference counting and Garbage Collection have very clear difference: when the referenced objects are destroyed (not deallocated). In RC it happens when the count reaches zero. In GC it happens some time later. That difference is crucial for having or not having deterministic performance in your program.
- Animats 4y ago
  > In GC it happens some time later. Yes. In languages with destructors/finalizers called from the garbage collector, things can get very complicated. C# and Java have this problem. Go avoids it by having scope-based "defer" rather than destructors.
  - pjmlp 4y ago
    Java has scope based defer since version 7, while C# has it since version 4, with the improvement on version 8 to be syntactically like defer. With a bit of generics and lambdas, they can be made to even be more defer like.
- brabel 4y ago
  Is the Pony language's GC a GC then? It runs at determinate times, namely when a behaviour (an actors' receive function, basically) finishes running... and because actors cannot share mutable state, and immutable values with more than one owner can be handled easily by a simple common parent actor, each actor's GC is completely independent of each other. Things are rarely as clear cut as we would want to believe.
  - viktorcode 4y ago
    > Is the Pony language's GC a GC then? It runs at determinate times, namely when a behaviour (an actors' receive function, basically) finishes running... It is. It might run when a behaviour finishes running, according to their docs.
- pjmlp 4y ago

by yyyk 4y ago

fingerlocks 4y ago

What do you mean? Potential reference cycles are a compile time error in Swift. That’s the whole point of the @escaping annotation

yyyk 4y ago
So this[0] wasn't current despite being edited half a year ago? I guess I'm guilty of the same mistake the post had: criticizing without understanding the state of the art on the other side (at least I didn't miss it by 20 years and on an entire subfield of Computer Science). [0] https://stackoverflow.com/questions/32262172/how-can-identify-strong-reference-cycles-in-swift https://stackoverflow.com/questions/32262172/how-can-identif...
- jumhyn 4y ago
  No, the SO post is accurate—it’s trivially easy to create strong reference cycles in Swift and @escaping annotation is only of limited use in detecting strong reference cycles. Though Swift also broadly pushes towards the use of value types for which creating reference cycles of any kind is impossible since they’re values, not references!

musicale 4y ago

Maybe Apple just hires mediocre developers (I certainly have lots of complaints about their software and UI issues, but I would probably suspect management/priorities/schedules rather than the technical staff) but they implemented GC and Automatic Reference Counting for ObjC and found that the latter resulted in better and more consistent responsiveness, which is probably what most users care about in apps. (Apps still get compressed or paged out which can lead to annoying pauses.) My anecdata indicate that Java apps are not as responsive as ObjC/Swift for the most part.

yyyk 4y ago
ARC is a perfectly respectable choice by itself. What's annoying me is ignoring the improvements other GC strategies and other languages have made in the last 20 years. There's a certain section of Apple users that thinks that every choice Apple makes is the only good way to do things.
kaba0 4y ago
And RC might be the correct choice for their devices (due to them not having much RAM, and latency being more important than throughput). But that is not true everywhere, I would even say that a good tracing GC is a better default.
pjmlp 4y ago
https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages The real reason why a tracing GC was a failure in Objective-C was due to the interoperability with the underlying C semantics, where anything goes. The implementation was never stable enough beyond toy examples. Naturally automating the Cocoa release/retain calls made more sense, given the constraints. In typical Apple fashion they pivoted into it, gave the algorithm a fancy name, and then in a you're holding it wrong style message, sold their plan B as the best way in the world to manage memory. When Swift came around, having the need to easily interop with the Objective-C ecosystem naturally meant to keep the same approach, otherwise they would need the same machinery that .NET uses (RCW/CCW) to interop with COM AddRef/Release. What Apple has is excellent marketing.
- mamcx 4y ago
  > What Apple has is excellent marketing. Whoa! Marketing? Interop with C is a MASSIVE use-case. And iOS is A LOT faster and more responsive than android. That is, right there, total proof that can't denied. I do both, and the speed of apple way and the simplicity of bridge the C-abi is not a joke.
  - yyyk 4y ago
    The android/iOS comparison has many more factors than GC type. I suspect the main difference is processor type - Qualcomm ARM has been very disappointing so far, and GC type doesn't even come into it.

KerrAvon 4y ago

Your first paragraph is only true if malloc/free counts as GC. I have seen people try to claim that free() is just manual GC. You can say that if you want, but it renders the terminology meaningless. Any true GC strategy (== one that collects cycles) will fundamentally touch and allocate more memory than malloc/free, where reference counting is pretty close to malloc/free performance; it doesn’t need to touch any memory not involved. At OS scale, that’s a huge performance advantage. You can scope down the memory involved in GC using advanced, modern GC techniques, but you’re still going to be behind malloc/free in overall efficiency — cache efficiency, memory maintenance overhead, and additional memory required for bookkeeping. And reference counting will be pretty darn close to malloc/free.

pjmlp 4y ago
Chapter 5, https://gchandbook.org/ https://gchandbook.org/
bruce343434 4y ago
It puts that "extra memory" inside the very objects it tracks with a... reference count.

viktorcode 4y ago

Putting both under the same term is meaningless. Reference counting and Garbage Collection have very clear difference: when the referenced objects are destroyed (not deallocated). In RC it happens when the count reaches zero. In GC it happens some time later. That difference is crucial for having or not having deterministic performance in your program.

Animats 4y ago
> In GC it happens some time later. Yes. In languages with destructors/finalizers called from the garbage collector, things can get very complicated. C# and Java have this problem. Go avoids it by having scope-based "defer" rather than destructors.
- pjmlp 4y ago
  Java has scope based defer since version 7, while C# has it since version 4, with the improvement on version 8 to be syntactically like defer. With a bit of generics and lambdas, they can be made to even be more defer like.
brabel 4y ago
Is the Pony language's GC a GC then? It runs at determinate times, namely when a behaviour (an actors' receive function, basically) finishes running... and because actors cannot share mutable state, and immutable values with more than one owner can be handled easily by a simple common parent actor, each actor's GC is completely independent of each other. Things are rarely as clear cut as we would want to believe.
- viktorcode 4y ago
  > Is the Pony language's GC a GC then? It runs at determinate times, namely when a behaviour (an actors' receive function, basically) finishes running... It is. It might run when a behaviour finishes running, according to their docs.
pjmlp 4y ago