6 ms·

> Even better would be a way to compare vs methods of "manual" memory management (manual alloc/free, RAII/scope based alloc/free, arena allocation, etc.). Unfor

> Even better would be a way to compare vs methods of "manual" memory management (manual alloc/free, RAII/scope based alloc/free, arena allocation, etc.). Unfortunately, non-GC memory management is very application specific, so I'm not sure if a generalized analysis would be super useful. I've personally found Rust to be a very difficult language to learn and become productive in. In contrast, I was able to jump into Swift and become productive very quickly. Swift isn't GC, but is reference counted. Reference cycles will lead to leaked memory. So what's interesting is to know GC's overhead relative to what: Reference counted languages like Swift? Or languages like Rust? More importantly: Is the overhead worth it? Developer time is valuable; thus leading to the critical question: What's cheaper, extra developer time or a more powerful computer?

chrisseaton 5y ago
> Swift isn't GC, but is reference counted GC is often an umbrella term that includes reference counting. Almost all serious tracing GCs include some aspect of reference counting, and almost all serious reference counting GCs include some aspect of tracing.
- gwbas1c 5y ago
  No, it's not. Garbage collection and reference counting are "automatic memory management." With reference counting there are no pauses, and memory is reclaimed immediately. It allows for strongly coupling deallocation with resource cleanup. (The consequence is higher overhead maintaining counts, and leaked reference cycles.) In a garbage collected language you need to explicitly release your resources. (IE, the Dispose pattern that's common in C#)
  - Sindisil 5y ago
    [citation needed] Reference counting is widely considered one strategy of garbage collection (https://en.wikipedia.org/wiki/Garbage_collection_(computer_science) https://en.wikipedia.org/wiki/Garbage_collection_(computer_s...). For that matter, some GCs that are primarily tracing also use ref counts for some portion of the heap, as an optimization (just as some primarily refcounting GCs also run a trace to clean up cycles). Also, reference counting can certainly result in pauses, when large graphs of interconnected objects are reclaimed. On the upside, you know when a pause might happen. You still don't know for certain without explicitly keeping track of what is about to be freed, which would add additional overhead, and indeed may not be practical or even feasible.
  - wgd 5y ago
    > With reference counting there are no pauses, and memory is reclaimed immediately You can't guarantee both of these properties at once, in the general case. Consider a very large tree of objects which are referenced through a single root node, and then that root node becomes eligible for reclamation. For a sufficiently large object graph, either reclamation will require a noticeable pause or some portion of the work will have to be deferred until later.
    - ncmncm 5y ago
      In such uses, if it matters you don't rely on RC to reclaim the storage. You allocate from an arena, and drop the whole graph as a unit. Using pointers to make up a graph is a choice. It is a thing taught in CS classes, so it may feel comfortably familiar; that does not make it good. I never do.
      - ahtihn 5y ago
        How is this different than working around a GC? There are lots of things you can do in GCed language to avoid allocations and avoid running the GC when it matters.
        ncmncm 5y ago
        Often it is your SRE who has to do that work.
    - pkolaczk 5y ago
      There is a difference between pausing a single thread in a known, predictable point and pausing all threads at random point in time. Tracing GCs do the latter. It is way easier to avoid long pauses with recounting than with tracing GC.
      - Skinney 5y ago
        Java’s ZGC has a constant (O(1)) sub-milliaecond pause-time. GC runs concurrently with the app
  - pjmlp 5y ago
    I advise reading a couple of CS books on the subject.
  - chrisseaton 5y ago
    > With reference counting there are no pauses How are you reclaiming cycles with no pauses?
    - ncmncm 5y ago
      I have had no occasion in the past three decades to make cycles. It smacks of poor discipline, or poor design.
      - deathanatos 5y ago
        While I also haven't ever had a cycle in my decades as an engineer, it doesn't really answer the parent's question about pauses w.r.t. ref counting. Ref counting, in the general, isn't free. (Also, in the sense of releasing a cycle, that would be pretty quick, since a typical RC implementation is just going to leak it. Its where a large graph resource graph is successfully ref-counted to 0 that can cause a pause, theoretically, although that's another case I've not seen.)
        ncmncm 5y ago
        The usual method is to have strategically placed "weak" references.
        deathanatos 5y ago
        … yes (and I know), but that has nothing to do with the point being made here, which is about the compute time required to manage the memory.
      - chrisseaton 5y ago
        Well good for you I guess - but that’s not a general solution for language implementation as it’s not sound for a language like Python. Which is why in practice most RCs include tracing. And the reverse as well - most tracers include a degree of RC. That’s the pragmatic solution in practice.
  - colejohnson66 5y ago
    > With reference counting there are no pauses... Same with GC. "Stop the world" may be a characteristic of a simple GC, but it's entirely possible to have GC that works by "coloring" objects. > In a garbage collected language you need to explicitly release your resources. (IE, the Dispose pattern that's common in C#) You only need to implement IDisposable if you are dealing with unmanaged resources (ie. non-GC objects). But it's the same with C/C++: you have to call `free()` or `delete`; The difference is that managed resources are auto-released for you.
  - munificent 5y ago
    These days, "garbage collection" is the umbrella term that includes ref counting and other forms. "Tracing garbage collection" the term for GC that doesn't include ref counting. > With reference counting there are no pauses You can still have pauses of arbitrary duration with ref counting. When the last reference to an object that is the sole owner of a large graph of other objects gets decremented, the entire object graph must be immediately deallocated. It's possible for a single dereference to trigger an unbounded amount of deallocation. > and memory is reclaimed immediately. Most production-quality ref counting implementations defer tracking references on the stack to minimize ref count churn. That significantly improves performance but it means you can no longer claim that the system always reclaims memory "immediately". > In a garbage collected language you need to explicitly release your resources. (IE, the Dispose pattern that's common in C#) Managing non-memory resources is orthogonal to tracing versus ref counting. If you choose to tie a resource's lifetime to a piece of memory's lifetime then, yes, the memory manager's deallocation policy becomes user-visible. I think you would get a lot out of reading "A Unified Theory of Garbage Collection".
    - SomeCallMeTim 5y ago
      > When the last reference to an object that is the sole owner of a large graph of other objects gets decremented, the entire object graph must be immediately deallocated. It's possible for a single dereference to trigger an unbounded amount of deallocation. Two things: 1. Unbounded may be technically true, but it's really not a hard problem to ensure that time-critical runtime deallocations either rarely happen or are simply never huge chains of objects that release each other. Source: Used C++ & boost::shared_ptr/boost::weak_ptr extensively in game development and never had unexpected jank due to deallocations. 2. There's no actual reason that the full deallocation needs to happen immediately in all reference counting implementations. If you have hard time or latency constraints you could queue up the actual dereferencing and ensure that you only dereference a certain number of objects per time period. Yes, #2 changes some assumptions about when objects will be dereferenced; in C++ one might rely on guarantees that objects are immediately released along with associated resources. But if you go into a project knowing that it needed to support deferred reference counting, manually releasing critical resources is hardly the worst thing you'd need to do.
  - spullara 5y ago
    Reference counting absolutely has pauses. Try allocating millions of objects in a block and then exiting that block. Hell, even malloc pauses when fragmentation gets too high.
    - mirekrusin 5y ago
      I'll show in profiler straight away. With tracing gc it won't.
      - spullara 5y ago
        What do you think won't show up in a profiler with GC? With the right profiler I can see the entire heap as well as where every object was allocated and all those deallocations are basically free. With a modern collector like ZGC, max pause times are now sub-millisecond for collections. Also easy to measure the total GC cost in the profiler as well. The modern GC story is extremely good. The biggest issue with GC in my opinion is that it uses more memory than you strictly need.
        mirekrusin 5y ago
        It won't show what we're talking about in this thread - deallocations of large number of allocations when they loose last root reference at once.
        spullara 5y ago
        It absolutely will show them because they cost nothing. 0 will show up in the profiler which is how much deallocations cost with GC.
        mirekrusin 5y ago
        Magic. In rc/arc you can achieve the same by making release a no-op.
        5y ago
  - pron 5y ago
    Reference counting and tracing are the two main approaches for garbage collection. See, for example, https://courses.cs.washington.edu/courses/cse590p/05au/p50-bacon.pdf https://courses.cs.washington.edu/courses/cse590p/05au/p50-b... While tracing is considered to have better throughput and reference counting to have a lower footprint, as the liked paper shows, they are really on a spectrum of techniques with different tradeoffs.
  - throwaway894345 5y ago
    > No, it's not. Garbage collection and reference counting are "automatic memory management. In strict computer science parlance, refcounting is a kind of GC, but to most people GC refers to "tracing GC" specifically. It's fairly pedantic. > In a garbage collected language you need to explicitly release your resources. I assume "resources" here must mean "non-memory resources"? Even still, GC can apply to any kind of resource, it's just most popularly applied to memory (you could have a GC for file handles, for example). Also, so you know, the user you're replying to knows a thing or two about programming languages.
- dreamcompiler 5y ago
  > Almost all serious tracing GCs include some aspect of reference counting I don't know about the Java world but in Common Lisp GC there's no reference counting whatsoever.
  - chrisseaton 5y ago
    Common Lisp is a specification, not an implementation. It doesn't make sense to say that the GC is implemented in any particular way, because that's not part of the specification - it's up to the implementation. I would bet my house that some implementation of Common Lisp somewhere has a GC that uses card marking, which is a form of reference counting.
    - dreamcompiler 5y ago
      I should have been more precise: The four CL implementations I'm familiar with (ACL, LW, CCL, SBCL) don't do reference counting and they probably comprise the vast majority of the market.
  - lispm 5y ago
    Interlisp used reference counting. Don't know if that is still the case -> interlisp.org . It includes a Common Lisp implementation.
hedora 5y ago
GC shifts human work from development time to deployment / ops time. So the question is whether one-off developer time is cheaper than SRE time for the useful lifetime of the service. However, it gets worse for GC: depending on the application, developing for a GC can be much more difficult / expensive than manual memory management (or reference counting). The canonical examples are low latency (with SLAs on the order of a disk or network I/O, so 10-100 microseconds) and applications that need to use bounded memory. On top of that, there are confounding factors that hurt the case for GC. I don't know of an imperarive GCed language with a reasonably expressive type system (all the JVM languages I know of use type erasure). For experienced developers, rich type systems with actual runtime guarantees are a huge productivity boost.
- titzer 5y ago
  C#? F#? Go (now with generics)? Virgil...
- gwbas1c 5y ago
  > The canonical examples are low latency (with SLAs on the order of a disk or network I/O, so 10-100 microseconds) and applications that need to use bounded memory. Well, in those cases extra developer time is cheaper than a more powerful computer! Will you get ROI building a stereotypical web application with manual memory management? Doubtful. Edit: > GC shifts human work from development time to deployment / ops time. I've never had to tune a garbage collector in deployment. I've heard of other people having to do it; but I've never heard of anyone saying, "yes, I'm so happy I built my website with C++."
  - Sindisil 5y ago
    All the world is not a web application.
    - Spivak 5y ago
      True but it’s not really about web and more about “problem domains where GC pauses are significant, matter, and you can’t throw more compute and memory at the problem” which is not nothing but on the dart board of all SWE jobs good money is on hitting one where it isn’t even if you’re aiming for one.
Sindisil 5y ago
Yes, both. Indeed, the fundamental question is whether the costs of automatic memory management (be it tracing GC or refcount GC) are "worth it". But it's not always as simple as a monetary consideration, and even when it is, the monetary cost often involves way more than just dev time vs cost of computer (e.g., power, cooling, distributed cost over many end users, market applicability because of system requirements).
pjmlp 5y ago
Reference counting is a GC algorithm as per any worthwhile CS book on GC algorithms.
zozbot234 5y ago
Rust can also use reference counting when necessary. Many Rust novices don't realize this, and run into needless trouble when trying to learn Rust. Rc<RefCell<T>> and Arc<Mutex<T>> are not "unidiomatic" other than in a very weak sense. Sometimes they are even unavoidable.
- throwaway894345 5y ago
  It's still pretty painful to deal in Rc<...> and friends in Rust. I was expecting it to be a few extra keystrokes around my types, but I still ended up having to deal with the borrow checker when I would put something into an Rc or take it out to pass into some other function. It was nowhere near as easy as a GC or refcounted language.
  - woodruffw 5y ago
    > I was expecting it to be a few extra keystrokes around my types, but I still ended up having to deal with the borrow checker when I would put something into an Rc or take it out to pass into some other function. I'd be interested to hear where you experienced difficulty, specifically. `Rc<T>` is `Deref<T>`, so you should never have any problems calling borrowing APIs. Owning APIs require an explicit borrow-and-clone, but that's just two calls (`as_ref().clone()`).
- gwbas1c 5y ago
  They're significantly more time-consuming, for the developer, to work with. Think of using something like a lambda to start a thread: You have to explicitly clone your Rc<Whatever> into another variable, and then use the second variable in your lambda. The compiler won't implicitly clone your RC<Whatever> for you. IMO, it's one of the biggest drawbacks in Rust.
pkulak 5y ago
Reference counting is GC. There are no pauses, but incrementing and decrementing a counter on every touch isn’t free either.
- ygra 5y ago
  Well, the pauses are somewhat predictable in that they may appear when the count of an object reaches zero. I had a very expensive closing brace in (admittedly not well-written) C++ code once.
sharpneli 5y ago
One must also remember to differentiate the deployment targets. Not every piece of software is deployed in your own machine. Let's take games as an example. You cannot say to users "Just buy more powerful compute/phone". And even if they would you may have literally millions of machines, due to having millions of users. In which case saving 1 dollar worth of machine per user is savings of millions which is worth a lot of developer time. Naturally you as a dev won't really be paying this, so the incentive is not directly there. But the incentive comes from people just not buying a game that runs like crap. In these cases GC is nice and dandy at start but then you run into the inevitable "Why does my game stutter?", after which object pools are introduced and even then some annoying "leaks" may remain. If the amount of time had been used from the get go to actually think about memory management the whole issue could have been avoided.
- native_samples 5y ago
  Yes, but GC and object re-use aren't mutually exclusive. Sometimes people argue as if they are, which is understandable because the overlap between semi-FP programming styles and GCd languages is fairly strong, and the FP world pushes immutable state as almost a matter of moral principle. If you tried to do functional programming with purely manual memory management you'd see high overheads too simply because there'd be so many small allocations and copies. In practice though, people tend to think harder about in-place mutation when they don't have a GC to clean up after them.
  - kragen 5y ago
    They aren't mutually exclusive, but if you're using a tracing garbage collector this millennium you're probably using a generational copying collector, and if you're using a generational copying collector you have a write barrier, and the write barrier means that allocating and initializing a new object is less expensive than overwriting all the fields of an existing object, probably by a factor of several. Also, if your reused object is only referenced from the nursery, and it references other objects in the nursery, those objects ought to be collected on a minor collection, but they won't be; instead they'll be promoted, possibly through several generations, until they reach the generation where your reused object is, which will finally allow them to die. Balanced against this you have less frequent minor collections — none at all during times when you're allocating no new objects. So, with a tracing GC, introducing an object pool will usually make your program slower, not faster. (This is not true with reference counting.)

chrisseaton 5y ago

> Swift isn't GC, but is reference counted GC is often an umbrella term that includes reference counting. Almost all serious tracing GCs include some aspect of reference counting, and almost all serious reference counting GCs include some aspect of tracing.

gwbas1c 5y ago
No, it's not. Garbage collection and reference counting are "automatic memory management." With reference counting there are no pauses, and memory is reclaimed immediately. It allows for strongly coupling deallocation with resource cleanup. (The consequence is higher overhead maintaining counts, and leaked reference cycles.) In a garbage collected language you need to explicitly release your resources. (IE, the Dispose pattern that's common in C#)
- Sindisil 5y ago
  [citation needed] Reference counting is widely considered one strategy of garbage collection (https://en.wikipedia.org/wiki/Garbage_collection_(computer_science) https://en.wikipedia.org/wiki/Garbage_collection_(computer_s...). For that matter, some GCs that are primarily tracing also use ref counts for some portion of the heap, as an optimization (just as some primarily refcounting GCs also run a trace to clean up cycles). Also, reference counting can certainly result in pauses, when large graphs of interconnected objects are reclaimed. On the upside, you know when a pause might happen. You still don't know for certain without explicitly keeping track of what is about to be freed, which would add additional overhead, and indeed may not be practical or even feasible.
- wgd 5y ago
  > With reference counting there are no pauses, and memory is reclaimed immediately You can't guarantee both of these properties at once, in the general case. Consider a very large tree of objects which are referenced through a single root node, and then that root node becomes eligible for reclamation. For a sufficiently large object graph, either reclamation will require a noticeable pause or some portion of the work will have to be deferred until later.
  - ncmncm 5y ago
    In such uses, if it matters you don't rely on RC to reclaim the storage. You allocate from an arena, and drop the whole graph as a unit. Using pointers to make up a graph is a choice. It is a thing taught in CS classes, so it may feel comfortably familiar; that does not make it good. I never do.
    - ahtihn 5y ago
      How is this different than working around a GC? There are lots of things you can do in GCed language to avoid allocations and avoid running the GC when it matters.
      - ncmncm 5y ago
        Often it is your SRE who has to do that work.
  - pkolaczk 5y ago
    There is a difference between pausing a single thread in a known, predictable point and pausing all threads at random point in time. Tracing GCs do the latter. It is way easier to avoid long pauses with recounting than with tracing GC.
    - Skinney 5y ago
      Java’s ZGC has a constant (O(1)) sub-milliaecond pause-time. GC runs concurrently with the app
- pjmlp 5y ago
  I advise reading a couple of CS books on the subject.
- chrisseaton 5y ago
  > With reference counting there are no pauses How are you reclaiming cycles with no pauses?
  - ncmncm 5y ago
    I have had no occasion in the past three decades to make cycles. It smacks of poor discipline, or poor design.
    - deathanatos 5y ago
      While I also haven't ever had a cycle in my decades as an engineer, it doesn't really answer the parent's question about pauses w.r.t. ref counting. Ref counting, in the general, isn't free. (Also, in the sense of releasing a cycle, that would be pretty quick, since a typical RC implementation is just going to leak it. Its where a large graph resource graph is successfully ref-counted to 0 that can cause a pause, theoretically, although that's another case I've not seen.)
      - ncmncm 5y ago
        The usual method is to have strategically placed "weak" references.
        deathanatos 5y ago
        … yes (and I know), but that has nothing to do with the point being made here, which is about the compute time required to manage the memory.
    - chrisseaton 5y ago
      Well good for you I guess - but that’s not a general solution for language implementation as it’s not sound for a language like Python. Which is why in practice most RCs include tracing. And the reverse as well - most tracers include a degree of RC. That’s the pragmatic solution in practice.
- colejohnson66 5y ago
  > With reference counting there are no pauses... Same with GC. "Stop the world" may be a characteristic of a simple GC, but it's entirely possible to have GC that works by "coloring" objects. > In a garbage collected language you need to explicitly release your resources. (IE, the Dispose pattern that's common in C#) You only need to implement IDisposable if you are dealing with unmanaged resources (ie. non-GC objects). But it's the same with C/C++: you have to call `free()` or `delete`; The difference is that managed resources are auto-released for you.
- munificent 5y ago
  These days, "garbage collection" is the umbrella term that includes ref counting and other forms. "Tracing garbage collection" the term for GC that doesn't include ref counting. > With reference counting there are no pauses You can still have pauses of arbitrary duration with ref counting. When the last reference to an object that is the sole owner of a large graph of other objects gets decremented, the entire object graph must be immediately deallocated. It's possible for a single dereference to trigger an unbounded amount of deallocation. > and memory is reclaimed immediately. Most production-quality ref counting implementations defer tracking references on the stack to minimize ref count churn. That significantly improves performance but it means you can no longer claim that the system always reclaims memory "immediately". > In a garbage collected language you need to explicitly release your resources. (IE, the Dispose pattern that's common in C#) Managing non-memory resources is orthogonal to tracing versus ref counting. If you choose to tie a resource's lifetime to a piece of memory's lifetime then, yes, the memory manager's deallocation policy becomes user-visible. I think you would get a lot out of reading "A Unified Theory of Garbage Collection".
  - SomeCallMeTim 5y ago
    > When the last reference to an object that is the sole owner of a large graph of other objects gets decremented, the entire object graph must be immediately deallocated. It's possible for a single dereference to trigger an unbounded amount of deallocation. Two things: 1. Unbounded may be technically true, but it's really not a hard problem to ensure that time-critical runtime deallocations either rarely happen or are simply never huge chains of objects that release each other. Source: Used C++ & boost::shared_ptr/boost::weak_ptr extensively in game development and never had unexpected jank due to deallocations. 2. There's no actual reason that the full deallocation needs to happen immediately in all reference counting implementations. If you have hard time or latency constraints you could queue up the actual dereferencing and ensure that you only dereference a certain number of objects per time period. Yes, #2 changes some assumptions about when objects will be dereferenced; in C++ one might rely on guarantees that objects are immediately released along with associated resources. But if you go into a project knowing that it needed to support deferred reference counting, manually releasing critical resources is hardly the worst thing you'd need to do.
- spullara 5y ago
  Reference counting absolutely has pauses. Try allocating millions of objects in a block and then exiting that block. Hell, even malloc pauses when fragmentation gets too high.
  - mirekrusin 5y ago
    I'll show in profiler straight away. With tracing gc it won't.
    - spullara 5y ago
      What do you think won't show up in a profiler with GC? With the right profiler I can see the entire heap as well as where every object was allocated and all those deallocations are basically free. With a modern collector like ZGC, max pause times are now sub-millisecond for collections. Also easy to measure the total GC cost in the profiler as well. The modern GC story is extremely good. The biggest issue with GC in my opinion is that it uses more memory than you strictly need.
      - mirekrusin 5y ago
        It won't show what we're talking about in this thread - deallocations of large number of allocations when they loose last root reference at once.
        spullara 5y ago
        It absolutely will show them because they cost nothing. 0 will show up in the profiler which is how much deallocations cost with GC.
        mirekrusin 5y ago
        Magic. In rc/arc you can achieve the same by making release a no-op.
        5y ago
- pron 5y ago
  Reference counting and tracing are the two main approaches for garbage collection. See, for example, https://courses.cs.washington.edu/courses/cse590p/05au/p50-bacon.pdf https://courses.cs.washington.edu/courses/cse590p/05au/p50-b... While tracing is considered to have better throughput and reference counting to have a lower footprint, as the liked paper shows, they are really on a spectrum of techniques with different tradeoffs.
- throwaway894345 5y ago
  > No, it's not. Garbage collection and reference counting are "automatic memory management. In strict computer science parlance, refcounting is a kind of GC, but to most people GC refers to "tracing GC" specifically. It's fairly pedantic. > In a garbage collected language you need to explicitly release your resources. I assume "resources" here must mean "non-memory resources"? Even still, GC can apply to any kind of resource, it's just most popularly applied to memory (you could have a GC for file handles, for example). Also, so you know, the user you're replying to knows a thing or two about programming languages.
dreamcompiler 5y ago
> Almost all serious tracing GCs include some aspect of reference counting I don't know about the Java world but in Common Lisp GC there's no reference counting whatsoever.
- chrisseaton 5y ago
  Common Lisp is a specification, not an implementation. It doesn't make sense to say that the GC is implemented in any particular way, because that's not part of the specification - it's up to the implementation. I would bet my house that some implementation of Common Lisp somewhere has a GC that uses card marking, which is a form of reference counting.
  - dreamcompiler 5y ago
    I should have been more precise: The four CL implementations I'm familiar with (ACL, LW, CCL, SBCL) don't do reference counting and they probably comprise the vast majority of the market.
- lispm 5y ago
  Interlisp used reference counting. Don't know if that is still the case -> interlisp.org . It includes a Common Lisp implementation.

hedora 5y ago

GC shifts human work from development time to deployment / ops time. So the question is whether one-off developer time is cheaper than SRE time for the useful lifetime of the service. However, it gets worse for GC: depending on the application, developing for a GC can be much more difficult / expensive than manual memory management (or reference counting). The canonical examples are low latency (with SLAs on the order of a disk or network I/O, so 10-100 microseconds) and applications that need to use bounded memory. On top of that, there are confounding factors that hurt the case for GC. I don't know of an imperarive GCed language with a reasonably expressive type system (all the JVM languages I know of use type erasure). For experienced developers, rich type systems with actual runtime guarantees are a huge productivity boost.

titzer 5y ago
C#? F#? Go (now with generics)? Virgil...
gwbas1c 5y ago
> The canonical examples are low latency (with SLAs on the order of a disk or network I/O, so 10-100 microseconds) and applications that need to use bounded memory. Well, in those cases extra developer time is cheaper than a more powerful computer! Will you get ROI building a stereotypical web application with manual memory management? Doubtful. Edit: > GC shifts human work from development time to deployment / ops time. I've never had to tune a garbage collector in deployment. I've heard of other people having to do it; but I've never heard of anyone saying, "yes, I'm so happy I built my website with C++."
- Sindisil 5y ago
  All the world is not a web application.
  - Spivak 5y ago
    True but it’s not really about web and more about “problem domains where GC pauses are significant, matter, and you can’t throw more compute and memory at the problem” which is not nothing but on the dart board of all SWE jobs good money is on hitting one where it isn’t even if you’re aiming for one.

Sindisil 5y ago

Yes, both. Indeed, the fundamental question is whether the costs of automatic memory management (be it tracing GC or refcount GC) are "worth it". But it's not always as simple as a monetary consideration, and even when it is, the monetary cost often involves way more than just dev time vs cost of computer (e.g., power, cooling, distributed cost over many end users, market applicability because of system requirements).

pjmlp 5y ago

Reference counting is a GC algorithm as per any worthwhile CS book on GC algorithms.

zozbot234 5y ago

Rust can also use reference counting when necessary. Many Rust novices don't realize this, and run into needless trouble when trying to learn Rust. Rc<RefCell<T>> and Arc<Mutex<T>> are not "unidiomatic" other than in a very weak sense. Sometimes they are even unavoidable.

throwaway894345 5y ago
It's still pretty painful to deal in Rc<...> and friends in Rust. I was expecting it to be a few extra keystrokes around my types, but I still ended up having to deal with the borrow checker when I would put something into an Rc or take it out to pass into some other function. It was nowhere near as easy as a GC or refcounted language.
- woodruffw 5y ago
  > I was expecting it to be a few extra keystrokes around my types, but I still ended up having to deal with the borrow checker when I would put something into an Rc or take it out to pass into some other function. I'd be interested to hear where you experienced difficulty, specifically. `Rc<T>` is `Deref<T>`, so you should never have any problems calling borrowing APIs. Owning APIs require an explicit borrow-and-clone, but that's just two calls (`as_ref().clone()`).
gwbas1c 5y ago
They're significantly more time-consuming, for the developer, to work with. Think of using something like a lambda to start a thread: You have to explicitly clone your Rc<Whatever> into another variable, and then use the second variable in your lambda. The compiler won't implicitly clone your RC<Whatever> for you. IMO, it's one of the biggest drawbacks in Rust.

pkulak 5y ago

Reference counting is GC. There are no pauses, but incrementing and decrementing a counter on every touch isn’t free either.

ygra 5y ago
Well, the pauses are somewhat predictable in that they may appear when the count of an object reaches zero. I had a very expensive closing brace in (admittedly not well-written) C++ code once.

sharpneli 5y ago

One must also remember to differentiate the deployment targets. Not every piece of software is deployed in your own machine. Let's take games as an example. You cannot say to users "Just buy more powerful compute/phone". And even if they would you may have literally millions of machines, due to having millions of users. In which case saving 1 dollar worth of machine per user is savings of millions which is worth a lot of developer time. Naturally you as a dev won't really be paying this, so the incentive is not directly there. But the incentive comes from people just not buying a game that runs like crap. In these cases GC is nice and dandy at start but then you run into the inevitable "Why does my game stutter?", after which object pools are introduced and even then some annoying "leaks" may remain. If the amount of time had been used from the get go to actually think about memory management the whole issue could have been avoided.

native_samples 5y ago
Yes, but GC and object re-use aren't mutually exclusive. Sometimes people argue as if they are, which is understandable because the overlap between semi-FP programming styles and GCd languages is fairly strong, and the FP world pushes immutable state as almost a matter of moral principle. If you tried to do functional programming with purely manual memory management you'd see high overheads too simply because there'd be so many small allocations and copies. In practice though, people tend to think harder about in-place mutation when they don't have a GC to clean up after them.
- kragen 5y ago
  They aren't mutually exclusive, but if you're using a tracing garbage collector this millennium you're probably using a generational copying collector, and if you're using a generational copying collector you have a write barrier, and the write barrier means that allocating and initializing a new object is less expensive than overwriting all the fields of an existing object, probably by a factor of several. Also, if your reused object is only referenced from the nursery, and it references other objects in the nursery, those objects ought to be collected on a minor collection, but they won't be; instead they'll be promoted, possibly through several generations, until they reach the generation where your reused object is, which will finally allow them to die. Balanced against this you have less frequent minor collections — none at all during times when you're allocating no new objects. So, with a tracing GC, introducing an object pool will usually make your program slower, not faster. (This is not true with reference counting.)