4 ms·

This is not really an article about "How the D garbage collector works", rather an article "How to avoid garbage in D". I think the latter is of greater intere

This is not really an article about "How the D garbage collector works", rather an article "How to avoid garbage in D". I think the latter is of greater interest to the general programmer, however. Initial hubris seems to be the rule for new tools in programming, and in retrospect, this seems to have been true for GC technology. The original motivation was to offload the most painful part of memory management work from the coder, but it somehow morphed into, "Takes care of everything to do with memory management." This resulted in a misguided quest for a "magical" GC that had super throughput, or super low latency. (Or somehow both.) This in turn resulted in numerous GC knobs that were hard to understand and tune. A recent trend seems to take the approach that GC allows development to get to a correctly running program faster, at which point, good profiling and language/library tools can be used to minimize memory churn. To this end, GC should be optimized by default for latency -- as this is the most likely optimization for a better development environment.

pcwalton 10y ago
> The original motivation was to offload the most painful part of memory management work from the coder, but it somehow morphed into, "Takes care of everything to do with memory management." I don't understand the difference. GC was invented for Lisp. Lisp was fully automatically memory managed, just as GC'd languages are today. John McCarthy never conceived of Lisp as a language with malloc and free. > To this end, GC should be optimized by default for latency -- as this is the most likely optimization for a better development environment. I don't see how that follows. Throughput is just as important as latency in most scenarios, development included. There's nothing about development that makes latency more desirable than throughput—if anything, I would think the opposite would be true, as running batch testing jobs usually demands good throughput.
- stcredzero 10y ago
  Throughput is just as important as latency in most scenarios, development included. There's nothing about development that makes latency more desirable than throughput Having sluggish, unresponsive, wonky tools, and a sluggish, unresponsive, wonky prototype just sucks. All of those little uncomfortable pauses wear you down and nickel-and-dime you to death. I would think the opposite would be true, as running batch testing jobs usually demands good throughput. Running batch testing is exactly the kind of scenario where profiling and optimization can score big wins -- and most often, those wins also apply to the production version. IMO, making your development environment uncomfortable for edit/test/debug just so you can have faster batch testing is a misguided reversal of priorities! Not having the latter provides you with less timely information, but is easily fixed. Not having the former is constantly fatiguing!
  - pcwalton 10y ago
    > Having sluggish, unresponsive, wonky tools, and a sluggish, unresponsive, wonky prototype just sucks. All of those little uncomfortable pauses wear you down and nickel-and-dime you to death. I agree. That's why you don't usually want extreme low-latency collectors that make your program slow by sacrificing throughput over latency. > Running batch testing is exactly the kind of scenario where profiling and optimization can score big wins -- and most often, those wins also apply to the production version. And that's why you should have a GC that balances throughput and latency.
    - stcredzero 10y ago
      That's why you don't usually want extreme low-latency collectors that make your program slow by sacrificing throughput over latency. Of course you know there's a difference between a slow program and a sluggish/unresponsive one. A user will forgive the former, but will abhor the latter. As a programmer, you're a kind of user. However, I note that many programmers have a kind of un-self-awareness when it comes to their own creations and favored, highly customized tools. If a programmer thinks something is nifty for another reason, they will often excuse much more latency than an ordinary user ever would. This is one of the biggest UX blind spots programmers have, generally. Also, with an environment where it's easy to fix throughput, why not mostly eliminate latency? Fixing throughput is usually more straightforward and easier than fixing latency. (Pareto principle) And that's why you should have a GC that balances throughput and latency. In practice, due to programmer hubris and bias against perceiving flaws in our own creations, one has often ended up with GC that has better than needed throughput numbers to alleviate speed criticisms while having latency that is a little bit uncomfortable. I think it's a common programmer blindness with regards to UX.
      - pcwalton 10y ago
        > Fixing throughput is usually more straightforward and easier than fixing latency. (Pareto principle) No, because improving throughput requires a generational GC, which is something you need to design from the beginning. Once you do, it tends to be a massive win. > In practice, due to programmer hubris and bias against perceiving flaws in our own creations, one has often ended up with GC that has better than needed throughput numbers to alleviate speed criticisms while having latency that is a little bit uncomfortable. I think it's a common programmer blindness with regards to UX. Or maybe you don't notice any throughput problems because most mature GCs have good throughput, leading to the incorrect conclusion that throughput is unimportant. I highly suspect that if all apps were using extreme low-latency GCs, you would notice throughput problems. Take JS, for instance: you know how JS-heavy apps are criticized all the time on HN for being slow to load? That's a throughput problem.

pcwalton 10y ago

> The original motivation was to offload the most painful part of memory management work from the coder, but it somehow morphed into, "Takes care of everything to do with memory management." I don't understand the difference. GC was invented for Lisp. Lisp was fully automatically memory managed, just as GC'd languages are today. John McCarthy never conceived of Lisp as a language with malloc and free. > To this end, GC should be optimized by default for latency -- as this is the most likely optimization for a better development environment. I don't see how that follows. Throughput is just as important as latency in most scenarios, development included. There's nothing about development that makes latency more desirable than throughput—if anything, I would think the opposite would be true, as running batch testing jobs usually demands good throughput.

stcredzero 10y ago
Throughput is just as important as latency in most scenarios, development included. There's nothing about development that makes latency more desirable than throughput Having sluggish, unresponsive, wonky tools, and a sluggish, unresponsive, wonky prototype just sucks. All of those little uncomfortable pauses wear you down and nickel-and-dime you to death. I would think the opposite would be true, as running batch testing jobs usually demands good throughput. Running batch testing is exactly the kind of scenario where profiling and optimization can score big wins -- and most often, those wins also apply to the production version. IMO, making your development environment uncomfortable for edit/test/debug just so you can have faster batch testing is a misguided reversal of priorities! Not having the latter provides you with less timely information, but is easily fixed. Not having the former is constantly fatiguing!
- pcwalton 10y ago
  > Having sluggish, unresponsive, wonky tools, and a sluggish, unresponsive, wonky prototype just sucks. All of those little uncomfortable pauses wear you down and nickel-and-dime you to death. I agree. That's why you don't usually want extreme low-latency collectors that make your program slow by sacrificing throughput over latency. > Running batch testing is exactly the kind of scenario where profiling and optimization can score big wins -- and most often, those wins also apply to the production version. And that's why you should have a GC that balances throughput and latency.
  - stcredzero 10y ago
    That's why you don't usually want extreme low-latency collectors that make your program slow by sacrificing throughput over latency. Of course you know there's a difference between a slow program and a sluggish/unresponsive one. A user will forgive the former, but will abhor the latter. As a programmer, you're a kind of user. However, I note that many programmers have a kind of un-self-awareness when it comes to their own creations and favored, highly customized tools. If a programmer thinks something is nifty for another reason, they will often excuse much more latency than an ordinary user ever would. This is one of the biggest UX blind spots programmers have, generally. Also, with an environment where it's easy to fix throughput, why not mostly eliminate latency? Fixing throughput is usually more straightforward and easier than fixing latency. (Pareto principle) And that's why you should have a GC that balances throughput and latency. In practice, due to programmer hubris and bias against perceiving flaws in our own creations, one has often ended up with GC that has better than needed throughput numbers to alleviate speed criticisms while having latency that is a little bit uncomfortable. I think it's a common programmer blindness with regards to UX.
    - pcwalton 10y ago
      > Fixing throughput is usually more straightforward and easier than fixing latency. (Pareto principle) No, because improving throughput requires a generational GC, which is something you need to design from the beginning. Once you do, it tends to be a massive win. > In practice, due to programmer hubris and bias against perceiving flaws in our own creations, one has often ended up with GC that has better than needed throughput numbers to alleviate speed criticisms while having latency that is a little bit uncomfortable. I think it's a common programmer blindness with regards to UX. Or maybe you don't notice any throughput problems because most mature GCs have good throughput, leading to the incorrect conclusion that throughput is unimportant. I highly suspect that if all apps were using extreme low-latency GCs, you would notice throughput problems. Take JS, for instance: you know how JS-heavy apps are criticized all the time on HN for being slow to load? That's a throughput problem.