4 ms·

In the article > The performance side of things I think is still up in the air because ARC certainly does introduce overhead. As you said, they can both intro

In the article > The performance side of things I think is still up in the air because ARC certainly does introduce overhead. As you said, they can both introduce overhead, but the ARC overhead is way worse. Really the only reason to use garbage collection (which is really complex) over ARC (which is simple) is the performance and control you get. Otherwise it would not be worth the implementation cost. The question is not “up in the air” on performance; production-grade GC’s are a clear winner. I would even be doubtful that CoW could make up the difference. But I would be interested to see data suggesting otherwise.

nu11ptr 4y ago
No doubt straight up ARC with refcounting bumps on every function call,etc. vs a good GC with same allocation paths...a good GC will smoke it. No question. But that isn't how I read what Lattner said here, and I've been thinking similar things. Essentially with ARC the goal is to cheat (to be fair with tracing GC it is as well, just in different ways). And you cheat by implementing an ownership/borrow collector type system behind the scenes for getting rid of the need for RC on most of your objects. Once you do that, you have GC competing with stack allocation + some malloc/free scattered in. It becomes a much more interesting fight.
- adgjlsfhk1 4y ago
  note that GCs are starting to cheat too. Julia (for example) is in the process of implementing compile time escape analysis which will be used to (among other things) remove allocations as long as the compiler can prove you won't notice.
  - hayley-patton 4y ago
    Java, Go and JavaScript implementations do escape analysis already.
    - gameswithgo 4y ago
    - adgjlsfhk1 4y ago
      cool! (I gave the example of Julia, but because it's the best GC implementation (it's not), but because it's the implementation I know).
- pizlonator 4y ago
  This “cheating” has been going on in GC’d languages for decades. Java, JavaScript, and probably other language implementations have what they call “escape analysis”.
- hmlongco 4y ago
  "No doubt straight up ARC with refcounting bumps on every function call,etc..." Yeah, but in Swift you don't do that. From what I'm told, the compiler's static analysis has gotten a lot smarter in determining when a ref-count bump is needed, and the increased use of struct-based value types in the language leads more and more to situations where a refcount bump isn't needed at all since there's no object reference in the first place.

nu11ptr 4y ago

No doubt straight up ARC with refcounting bumps on every function call,etc. vs a good GC with same allocation paths...a good GC will smoke it. No question. But that isn't how I read what Lattner said here, and I've been thinking similar things. Essentially with ARC the goal is to cheat (to be fair with tracing GC it is as well, just in different ways). And you cheat by implementing an ownership/borrow collector type system behind the scenes for getting rid of the need for RC on most of your objects. Once you do that, you have GC competing with stack allocation + some malloc/free scattered in. It becomes a much more interesting fight.

adgjlsfhk1 4y ago
note that GCs are starting to cheat too. Julia (for example) is in the process of implementing compile time escape analysis which will be used to (among other things) remove allocations as long as the compiler can prove you won't notice.
- hayley-patton 4y ago
  Java, Go and JavaScript implementations do escape analysis already.
  - gameswithgo 4y ago
  - adgjlsfhk1 4y ago
    cool! (I gave the example of Julia, but because it's the best GC implementation (it's not), but because it's the implementation I know).
pizlonator 4y ago
This “cheating” has been going on in GC’d languages for decades. Java, JavaScript, and probably other language implementations have what they call “escape analysis”.
hmlongco 4y ago
"No doubt straight up ARC with refcounting bumps on every function call,etc..." Yeah, but in Swift you don't do that. From what I'm told, the compiler's static analysis has gotten a lot smarter in determining when a ref-count bump is needed, and the increased use of struct-based value types in the language leads more and more to situations where a refcount bump isn't needed at all since there's no object reference in the first place.