5 ms·

The post kind of does: > The benefit of sticking to RC is much-reduced memory consumption. It turns out that for a tracing GC to achieve performance comparable

The post kind of does: > The benefit of sticking to RC is much-reduced memory consumption. It turns out that for a tracing GC to achieve performance comparable with manual allocation, it needs several times the memory (different studies find different overheads, but at least 4x is a conservative lower bound). It implies that ref-counting is more economical in terms of wasted memory than GC, with the tradeoff being performance. This is solved thanks to the M1.

masklinn 6y ago
Apple’s runtimes have always used rc, this is not a change between Intel and arm.
- pjmlp 6y ago
  Nope, they also tried a tracing GC for Objective-C on the desktop, but it was a failure due to interoperability across libraries compiled in different modes alongside C semantics. Then they pivoted into automating retain/release patterns from Cocoa and sold it, Apple style, as a victory of RC over tracing GC, while moving the GC related docs and C related workarounds into the documentation archive.
  - masklinn 6y ago
    > Nope, they also tried a tracing GC for Objective-C on the desktop Operative word: tried. GC was an optional desktop-only component deprecated in Mountain Lion, which IIRC has not been accepted on MAS since 2015 was removed entirely from Sierra. Without going into irrelevant weeds, "apple has always used refcounting everywhere" is a much closer approximation.
    - pjmlp 6y ago
      Operative word: failed. Which then in Apple style ("you are holding it wrong") turned it around in a huge marketing message, while hiding away the tracing GC efforts.
      - masklinn 6y ago
        > Operative word: failed. That's not exactly relevant to the subject at hand of what memory-management method software usually uses on macos. > Which then in Apple style ("you are holding it wrong") turned it around in a huge marketing message, while hiding away the tracing GC efforts. Hardly? And people are looking to refcounting as a reason why apple software is relatively light on memory, which is completely fair and true and e.g. generally assumed as one of the reasons why ios devices fare well with significantly less ram than equivalent android devices. GCs have significant advantages, but memory overhead is absolutely one of the drawbacks.
        pjmlp 6y ago
        Nope, as proven by performance tests, https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages And the fact that M1 has special instructions dedicated to optimize RC, https://blog.metaobject.com/2020/11/m1-memory-and-performance.html https://blog.metaobject.com/2020/11/m1-memory-and-performanc... Memory overhead in languages with tracing GC (RC is a GC algorithm) only happens in languages like Java without support for value types. If the language supports value types, e.g. D, and there is still memory overhead versus RC, then fire the developers or they better learn to use the language features available on their plate.
        yakubin 6y ago
        > Nope, as proven by performance tests, > https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages This shows latency, not memory consumption, as far as I can tell. > If the language supports value types, e.g. D, and there is still memory overhead versus RC, then fire the developers or they better learn to use the language features available on their plate. Memory overhead of certain types of garbage collectors (notably generational ones) is well-known and it's specified relative to the size of the heap that they manage. Using value types is of course a valid point, regarding how you should use the language, but it doesn't change the overhead of the GC, it just keeps the heap it manages smaller. If the overhead was counted against the total memory use of a program, then we wouldn't be talking about the overhead of the garbage collector, but more about how much the garbage collector is actually used. Note that I'm not arguing against tracing GCs, only trying to keep it factual.

masklinn 6y ago

Apple’s runtimes have always used rc, this is not a change between Intel and arm.

pjmlp 6y ago
Nope, they also tried a tracing GC for Objective-C on the desktop, but it was a failure due to interoperability across libraries compiled in different modes alongside C semantics. Then they pivoted into automating retain/release patterns from Cocoa and sold it, Apple style, as a victory of RC over tracing GC, while moving the GC related docs and C related workarounds into the documentation archive.
- masklinn 6y ago
  > Nope, they also tried a tracing GC for Objective-C on the desktop Operative word: tried. GC was an optional desktop-only component deprecated in Mountain Lion, which IIRC has not been accepted on MAS since 2015 was removed entirely from Sierra. Without going into irrelevant weeds, "apple has always used refcounting everywhere" is a much closer approximation.
  - pjmlp 6y ago
    Operative word: failed. Which then in Apple style ("you are holding it wrong") turned it around in a huge marketing message, while hiding away the tracing GC efforts.
    - masklinn 6y ago
      > Operative word: failed. That's not exactly relevant to the subject at hand of what memory-management method software usually uses on macos. > Which then in Apple style ("you are holding it wrong") turned it around in a huge marketing message, while hiding away the tracing GC efforts. Hardly? And people are looking to refcounting as a reason why apple software is relatively light on memory, which is completely fair and true and e.g. generally assumed as one of the reasons why ios devices fare well with significantly less ram than equivalent android devices. GCs have significant advantages, but memory overhead is absolutely one of the drawbacks.
      - pjmlp 6y ago
        Nope, as proven by performance tests, https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages And the fact that M1 has special instructions dedicated to optimize RC, https://blog.metaobject.com/2020/11/m1-memory-and-performance.html https://blog.metaobject.com/2020/11/m1-memory-and-performanc... Memory overhead in languages with tracing GC (RC is a GC algorithm) only happens in languages like Java without support for value types. If the language supports value types, e.g. D, and there is still memory overhead versus RC, then fire the developers or they better learn to use the language features available on their plate.
        yakubin 6y ago
        > Nope, as proven by performance tests, > https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages This shows latency, not memory consumption, as far as I can tell. > If the language supports value types, e.g. D, and there is still memory overhead versus RC, then fire the developers or they better learn to use the language features available on their plate. Memory overhead of certain types of garbage collectors (notably generational ones) is well-known and it's specified relative to the size of the heap that they manage. Using value types is of course a valid point, regarding how you should use the language, but it doesn't change the overhead of the GC, it just keeps the heap it manages smaller. If the overhead was counted against the total memory use of a program, then we wouldn't be talking about the overhead of the garbage collector, but more about how much the garbage collector is actually used. Note that I'm not arguing against tracing GCs, only trying to keep it factual.