4 ms·

> reference counting is faster than garbage collection lol, not taking the bait

dathinab 6y ago
But reference counting is (potentially) faster then garbage collection. At least under some circumstances: - modern architecture having fast atomic fetch_add/sub - weak memory ordering making atomic fetch_add/sub even faster (if Acquire/Release ordering is used) - optimize the usage of reference counting by eliminating pointless reference counting, e.g. as done by Objective-C/Swift automatic reference counting (ARC). Or e.g. done when using borrows in rust for everything except the places you know you really need to clone the Atomic Reference Counter (also ARC but a different one ;=) ). Reference counting was for a long time basically guaranteed to be slower then garbage collection because of slower atomics, no weak memory ordering and "naive" usage of reference counting introducing a lot of unnecessary reference counter increased and decreases. But with modern hardware and compilers it's no longer as clear cut, at least in practice wrt. to modern hardware.
- WSSP 6y ago
  the bait is that reference counting is (often considered to be) a type of garbage collection, and that correction is frequently made in comment threads and hey, here we are
- lern_too_spel 6y ago
  Reference counting cannot be faster than naive manual memory management because it does the same thing with the additional overhead of reference counting. Even a very simple generational GC beats naive explicit memory management on most nontrivial workloads given enough memory. https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf
  - skellington 6y ago
    You are misunderstanding this paper deeply. Quoted summary from the paper itself: >>>We use this framework to compare the time-space performance of a range of garbage collectors to explicit memory management with the Lea memory allocator. Comparing runtime, space consumption, and virtual memory footprints over a range of benchmarks, we show that the runtime performance of the best-performing garbage collector is competitive with explicit memory management when given enough memory. In particular, when garbage collection has five times as much memory as required, its runtime performance matches or slightly exceeds that of explicit memory management. However, garbage collection’s performance degrades substantially when it must use smaller heaps. With three times as much memory, it runs 17% slower on average, and with twice as much memory, it runs 70% slower. Garbage collection also is more susceptible to paging when physical memory is scarce. In such conditions, all of the garbage collectors we examine here suffer order-of-magnitude performance penalties relative to explicit memory management.<<< GC is "competitive" when is has 5x as much memory according to the authors. Well, probably this is because GCs are fast when they have low to no memory pressure. They simply don't need to garbage collect anything. In fact, a non-collecting, non-managed, memory approaches can be faster than any memory management. That is, you have a short lived application that just allocates what it needs, never frees anything, then dies when done. But this is not apples to apples. The paper also says that with 2x more memory than manual management, GC is 70% slower and under paging scenarios GC can suffer "order-or-magnitude performance penalties relative to explicit memory management." Except under unusual conditions, there is no case where GC is faster than manual.
    - lern_too_spel 6y ago
      I understood that part completely. You misunderstood my point, which is that with enough memory, generational GC outperforms naive explicit memory management, which is impossible with reference counting. > Except under unusual conditions, there is no case where GC is faster than manual. Their simple generational GC outperforms manual memory management in every single workload in that paper given enough memory, so that statement is clearly false. A production quality GC does so with less memory. > Well, probably this is because GCs are fast when they have low to no memory pressure. They simply don't need to garbage collect anything. This is wrong. It's because generational GCs start to look like arena allocators when they have enough memory, with cheap bump allocation and bulk deallocation. On most of their workloads, their simple generational GC already outperforms naive explicit memory management with less than 3x the memory, and this would certainly be better with explicit tuning or a production GC.
      - quotemstr 6y ago
        Isn't it amazing how your well-informed comments get downvoted?

But reference counting is (potentially) faster then garbage collection. At least under some circumstances: - modern architecture having fast atomic fetch_add/sub - weak memory ordering making atomic fetch_add/sub even faster (if Acquire/Release ordering is used) - optimize the usage of reference counting by eliminating pointless reference counting, e.g. as done by Objective-C/Swift automatic reference counting (ARC). Or e.g. done when using borrows in rust for everything except the places you know you really need to clone the Atomic Reference Counter (also ARC but a different one ;=) ). Reference counting was for a long time basically guaranteed to be slower then garbage collection because of slower atomics, no weak memory ordering and "naive" usage of reference counting introducing a lot of unnecessary reference counter increased and decreases. But with modern hardware and compilers it's no longer as clear cut, at least in practice wrt. to modern hardware.

WSSP 6y ago
the bait is that reference counting is (often considered to be) a type of garbage collection, and that correction is frequently made in comment threads and hey, here we are
lern_too_spel 6y ago
Reference counting cannot be faster than naive manual memory management because it does the same thing with the additional overhead of reference counting. Even a very simple generational GC beats naive explicit memory management on most nontrivial workloads given enough memory. https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf
- skellington 6y ago
  You are misunderstanding this paper deeply. Quoted summary from the paper itself: >>>We use this framework to compare the time-space performance of a range of garbage collectors to explicit memory management with the Lea memory allocator. Comparing runtime, space consumption, and virtual memory footprints over a range of benchmarks, we show that the runtime performance of the best-performing garbage collector is competitive with explicit memory management when given enough memory. In particular, when garbage collection has five times as much memory as required, its runtime performance matches or slightly exceeds that of explicit memory management. However, garbage collection’s performance degrades substantially when it must use smaller heaps. With three times as much memory, it runs 17% slower on average, and with twice as much memory, it runs 70% slower. Garbage collection also is more susceptible to paging when physical memory is scarce. In such conditions, all of the garbage collectors we examine here suffer order-of-magnitude performance penalties relative to explicit memory management.<<< GC is "competitive" when is has 5x as much memory according to the authors. Well, probably this is because GCs are fast when they have low to no memory pressure. They simply don't need to garbage collect anything. In fact, a non-collecting, non-managed, memory approaches can be faster than any memory management. That is, you have a short lived application that just allocates what it needs, never frees anything, then dies when done. But this is not apples to apples. The paper also says that with 2x more memory than manual management, GC is 70% slower and under paging scenarios GC can suffer "order-or-magnitude performance penalties relative to explicit memory management." Except under unusual conditions, there is no case where GC is faster than manual.
  - lern_too_spel 6y ago
    I understood that part completely. You misunderstood my point, which is that with enough memory, generational GC outperforms naive explicit memory management, which is impossible with reference counting. > Except under unusual conditions, there is no case where GC is faster than manual. Their simple generational GC outperforms manual memory management in every single workload in that paper given enough memory, so that statement is clearly false. A production quality GC does so with less memory. > Well, probably this is because GCs are fast when they have low to no memory pressure. They simply don't need to garbage collect anything. This is wrong. It's because generational GCs start to look like arena allocators when they have enough memory, with cheap bump allocation and bulk deallocation. On most of their workloads, their simple generational GC already outperforms naive explicit memory management with less than 3x the memory, and this would certainly be better with explicit tuning or a production GC.
    - quotemstr 6y ago
      Isn't it amazing how your well-informed comments get downvoted?