5 ms·

> 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

> 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.
      - stcredzero 10y ago
- kibwen 10y ago
  > All of those little uncomfortable pauses But low-latency collectors have more pauses than low-throughput collectors, as well as spending more overall time collecting than low-throughput collectors. They also have a tendency towards higher memory pressure in the long run (though it's far less spiky than low-throughput collectors).
  - stcredzero 10y ago
    But low-latency collectors have more pauses than low-throughput collectors, But if you never notice any of the pauses because you're very well optimized for latency, then no harm, no foul. as well as spending more overall time collecting than low-throughput collectors. But too-low throughput is usually only a problem in production, whereas too-high latency can increase cost (in harder to quantify ways) everywhere, including in development. Too-low throughput is also usually much easier to fix. If you need high throughput, you need high throughput, but for most programmers, the correct default is low latency. High throughput for most programmers is like 150 mph top speed on a US sports car. In most cases, people are never going to need it, but if you need it (like, if you actually go to a track) it's relatively straightforward to implement. Whereas having unresponsive programs is like having an unreliable car that has squeaky brakes -- you're going to notice that relatively quickly, it's going to be a constant bother, and it's not so straightforward to correct.
    - pcwalton 10y ago
      No, most programs require a balance of throughput and latency. This stuff was all heavily studied in the 90s and earlier, you know. The conclusions that researchers and engineers came to are equally valid today.
      - qznc 10y ago
        GC has mostly been studied in languages, where you cannot avoid the GC: Java, Smalltalk, Lisp, etc. If you can avoid the GC and you pick the low hanging fruits, the circumstances for the garbage collector might be very different than all this previous research. D is not popular enough so far, so there will not be much research invested into its GC. When Java gets value types, it might become interesting.

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.
    - stcredzero 10y ago
kibwen 10y ago
> All of those little uncomfortable pauses But low-latency collectors have more pauses than low-throughput collectors, as well as spending more overall time collecting than low-throughput collectors. They also have a tendency towards higher memory pressure in the long run (though it's far less spiky than low-throughput collectors).
- stcredzero 10y ago
  But low-latency collectors have more pauses than low-throughput collectors, But if you never notice any of the pauses because you're very well optimized for latency, then no harm, no foul. as well as spending more overall time collecting than low-throughput collectors. But too-low throughput is usually only a problem in production, whereas too-high latency can increase cost (in harder to quantify ways) everywhere, including in development. Too-low throughput is also usually much easier to fix. If you need high throughput, you need high throughput, but for most programmers, the correct default is low latency. High throughput for most programmers is like 150 mph top speed on a US sports car. In most cases, people are never going to need it, but if you need it (like, if you actually go to a track) it's relatively straightforward to implement. Whereas having unresponsive programs is like having an unreliable car that has squeaky brakes -- you're going to notice that relatively quickly, it's going to be a constant bother, and it's not so straightforward to correct.
  - pcwalton 10y ago
    No, most programs require a balance of throughput and latency. This stuff was all heavily studied in the 90s and earlier, you know. The conclusions that researchers and engineers came to are equally valid today.
    - qznc 10y ago
      GC has mostly been studied in languages, where you cannot avoid the GC: Java, Smalltalk, Lisp, etc. If you can avoid the GC and you pick the low hanging fruits, the circumstances for the garbage collector might be very different than all this previous research. D is not popular enough so far, so there will not be much research invested into its GC. When Java gets value types, it might become interesting.