4 ms·

> - No garbage collector ARC is a GC, and a slower one than most traditional tracing GC's.

by vips7L 2y ago

MBCook 2y ago
Reference counting and garbage collection are different. They’re both forms automatic memory management, but they work in very different ways.
- vips7L 2y ago
  No they're not. Reference counting is a garbage collection algorithm. Its even described as such in most literature on garbage collection.
- kibwen 2y ago
  Reference counting and garbage collection are different, yes. But in terms of classifying "no garbage collection" under "things that Swift took from Rust", Swift's pervasive reference counting is much closer to classic tracing GC than it is to Rust's system of single ownership.
- pcwalton 2y ago
  Automatic memory management is a synonym for garbage collection. Reference counting is a form of garbage collection.
mannuch 2y ago
First of all, traditional (tracing) GCs require more expensive runtimes and consume much more memory. ARCs are also much more predictable in their behavior and pave the way for greater compile time optimizations. ARC is key in providing Swift its ability to maintain its low memory footprint compared to, say, Java. Second, yes, ARC is a GC method. But when the language says "no garbage collector", they just mean no traditional (tracing) GC runtime because, for better or worse, tracing GC is what people think of when they hear "garbage collector".
- vips7L 2y ago
  > traditional (tracing) GCs require more expensive runtimes and consume much more memory Not really no. Look at go, D, nim, or any ahead of time compiled language. > ARC is key in providing Swift its ability to maintain its low memory footprint compared to, say, Java Again not really. Java has other issues. Like lack of value types, conservative escape analysis, needing extra memory for profiling and the jit, and HotSpot’s GCs are focused on server applications and are designed not to release memory until they’re about to run out. Even if this were true ARC trades memory for execution speed. I can’t find the exact paper right now but the ixy implementations showed that you end up spending an unhealthy amount of time just counting references when you stay in pure swift code. I think it was somewhere > 30%.
  - saagarjha 2y ago
    The ixy examples were definitely nowhere near being idiomatic code.
    - vips7L 2y ago
      Right. They spend a lot of time in pure swift and not within its C++ runtime, but when you want to compare garbage collection algorithms that doesn't really matter. The fact is that ARC is slow and you spend a ton of time counting references. Something an alternative algorithm wouldn't have to do.

> - No garbage collector ARC is a GC, and a slower one than most traditional tracing GC's.

by vips7L 2y ago

> - No garbage collector ARC is a GC, and a slower one than most traditional tracing GC's.

Reference counting and garbage collection are different. They’re both forms automatic memory management, but they work in very different ways.

vips7L 2y ago
No they're not. Reference counting is a garbage collection algorithm. Its even described as such in most literature on garbage collection.
kibwen 2y ago
Reference counting and garbage collection are different, yes. But in terms of classifying "no garbage collection" under "things that Swift took from Rust", Swift's pervasive reference counting is much closer to classic tracing GC than it is to Rust's system of single ownership.
pcwalton 2y ago
Automatic memory management is a synonym for garbage collection. Reference counting is a form of garbage collection.

mannuch 2y ago

First of all, traditional (tracing) GCs require more expensive runtimes and consume much more memory. ARCs are also much more predictable in their behavior and pave the way for greater compile time optimizations. ARC is key in providing Swift its ability to maintain its low memory footprint compared to, say, Java. Second, yes, ARC is a GC method. But when the language says "no garbage collector", they just mean no traditional (tracing) GC runtime because, for better or worse, tracing GC is what people think of when they hear "garbage collector".

vips7L 2y ago
> traditional (tracing) GCs require more expensive runtimes and consume much more memory Not really no. Look at go, D, nim, or any ahead of time compiled language. > ARC is key in providing Swift its ability to maintain its low memory footprint compared to, say, Java Again not really. Java has other issues. Like lack of value types, conservative escape analysis, needing extra memory for profiling and the jit, and HotSpot’s GCs are focused on server applications and are designed not to release memory until they’re about to run out. Even if this were true ARC trades memory for execution speed. I can’t find the exact paper right now but the ixy implementations showed that you end up spending an unhealthy amount of time just counting references when you stay in pure swift code. I think it was somewhere > 30%.
- saagarjha 2y ago
  The ixy examples were definitely nowhere near being idiomatic code.
  - vips7L 2y ago
    Right. They spend a lot of time in pure swift and not within its C++ runtime, but when you want to compare garbage collection algorithms that doesn't really matter. The fact is that ARC is slow and you spend a ton of time counting references. Something an alternative algorithm wouldn't have to do.