5 ms·

> globally this represents a large amount of computing resources. Much of which would just sit idle otherwise, on client machines. Of course, the energy saving

by _bxg1 8y ago

> globally this represents a large amount of computing resources. Much of which would just sit idle otherwise, on client machines. Of course, the energy savings still apply. > He also points out that many garbage collection mechanisms can result in unpredictable pauses, where the computer system stops for a brief moment to clean up its memory. This is more of a hard barrier that's being solved. All in all pretty cool idea, but I think the impact would be different from what's discussed here. Truly high-performance computing is already written in non-GC languages. This hardware would give medium-intensity GC programs (read: web servers on JVM, .NET, Node, Ruby) a boost, and could also allow some higher-but-not-peak intensity software to be written with GC where it might not be today (games come to mind), although that could actually encourage more energy usage than what it would save.

p_l 8y ago
We wrote latency-sensitive and high-performance code in GCed languages back in 1980s - avoiding pauses or having predictable latencies (in fact, more predictable than usual manual memory management!) are more of "we don't teach people how to program" rather than issue with GC. As for energy savings, many garbage collectors have amortized energy use lower than malloc/free. Even pretty simple ones (some of the simplest I've seen beat it so hard it's not competition, but they are specific to their application)
- gdwatson 8y ago
  Could you explain further or give links to more information? I'd love to read about old-timey techniques for programming in GCed languages.
  - jayd16 8y ago
    His point is it's not rocket science. Preallocate and pool what you might need, don't call new in your tight loop. Change the GC algorithm to something that never runs unexpectedly. If you're still allocating such that you need GC eventually, manually GC at an appropriate time like a load screen.
    - vbarrielle 8y ago
      > Preallocate and pool what you might need, don't call new in your tight loop. This piece of advice is also valid in languages without GC. In C++ it's well known one should avoid allocating memory in tight loops, and it's strongly advised to call e.g. `reserve` on vectors to avoid allocating.
      - p_l 8y ago
        The point is that you lose not only in tight loops. (Tight loop allocating with good GC is actually well known good [1] case, it's deallocation that is PITA). free() as well as malloc() and related have significantly complex algorithms behind them, unless one can simplify base memory management in certain ways - and those ways tend to also allow region-enabled GC to outperform them anyway. [1] Allocating memory in many Garbage Collected systems can be down to one instruction, and if using per-thread heap, it can be atomic add without CAS
  - p_l 8y ago
    A good "keyword" to search is "non-consing code", from lisp lore meaning it doesn't construct (allocate) new space. As sibling comment says, it often involved object caches and static allocations. Interestingly enough, similar rules are necessary with malloc()/free where dynamic allocation is often forbidden for latency critical code (or safety critical one)
  - p_l 8y ago
    Also - I really, really recommend reading the classic GC book ( http://gchandbook.org/ http://gchandbook.org/) and related sources. I stopped complaining too much about developers when I noticed pretty much Noone gets taught how memory management works - either manual or GC
- Someone 8y ago
  ”As for energy savings, many garbage collectors have amortized energy use lower than malloc/free” For those wondering: that’s because malloc/free ‘visits’ every dead object, while garbage collection visits the live ones (another way to say that: free collects garbage, the moment it is created, GC collects non-garbage, periodically) and there typically is way more garbage than non-garbage. I haven’t seen energy usage comparisons that include extra energy use due to GC’s higher memory usage, though. That possibly is because it is hard to quantify. On current technology, you pay for your RAM’s energy usage the moment you power it on, whether you need it or not)
jcranmer 8y ago
Looking at the underlying paper, I'm actually skeptical that there's any practical performance/energy boosts from this accelerator. The best case they're giving is something like a ~3-5× boost on GC (which is generally ~10% of total time, much of it hopefully idle time anyways if you're tuning GC well), with a 15% power reduction, assuming your collector is a stop-the-world, non-concurrent collector (and you rewrite your object layout). There's no measurement of the energy cost of the idling core, nor of the cost of extra memory and cache traffic trundling objects to and from the accelerator rather than sticking on the core. Those costs are likely to be even worse if you try to adapt this into incremental and concurrent collectors. Especially when you ask the question "is it better to spend the area/power budget on a highly-specialized accelerator, or to give it over to another full core that can do other things when it's not collecting garbage," it's hard to motivate this kind of accelerator.
nsuser3 8y ago
> also allow some higher-but-not-peak intensity software to be written with GC where it might not be today (games come to mind), although that could actually encourage more energy usage than what it would save. Just look at Minecraft for that (it's written in Java). A recent version created up to 200 MB of garbage per second!
- VLM 8y ago
  Definitely a problem with modded minecraft. One weird solution to the problem is due to some design decisions its pragmatically single core because there's a primary loop that does 99% of the work, freeing up plenty of cores to do side issues and garbage collection.

by _bxg1 8y ago

p_l 8y ago

We wrote latency-sensitive and high-performance code in GCed languages back in 1980s - avoiding pauses or having predictable latencies (in fact, more predictable than usual manual memory management!) are more of "we don't teach people how to program" rather than issue with GC. As for energy savings, many garbage collectors have amortized energy use lower than malloc/free. Even pretty simple ones (some of the simplest I've seen beat it so hard it's not competition, but they are specific to their application)

gdwatson 8y ago
Could you explain further or give links to more information? I'd love to read about old-timey techniques for programming in GCed languages.
- jayd16 8y ago
  His point is it's not rocket science. Preallocate and pool what you might need, don't call new in your tight loop. Change the GC algorithm to something that never runs unexpectedly. If you're still allocating such that you need GC eventually, manually GC at an appropriate time like a load screen.
  - vbarrielle 8y ago
    > Preallocate and pool what you might need, don't call new in your tight loop. This piece of advice is also valid in languages without GC. In C++ it's well known one should avoid allocating memory in tight loops, and it's strongly advised to call e.g. `reserve` on vectors to avoid allocating.
    - p_l 8y ago
      The point is that you lose not only in tight loops. (Tight loop allocating with good GC is actually well known good [1] case, it's deallocation that is PITA). free() as well as malloc() and related have significantly complex algorithms behind them, unless one can simplify base memory management in certain ways - and those ways tend to also allow region-enabled GC to outperform them anyway. [1] Allocating memory in many Garbage Collected systems can be down to one instruction, and if using per-thread heap, it can be atomic add without CAS
- p_l 8y ago
  A good "keyword" to search is "non-consing code", from lisp lore meaning it doesn't construct (allocate) new space. As sibling comment says, it often involved object caches and static allocations. Interestingly enough, similar rules are necessary with malloc()/free where dynamic allocation is often forbidden for latency critical code (or safety critical one)
- p_l 8y ago
  Also - I really, really recommend reading the classic GC book ( http://gchandbook.org/ http://gchandbook.org/) and related sources. I stopped complaining too much about developers when I noticed pretty much Noone gets taught how memory management works - either manual or GC
Someone 8y ago
”As for energy savings, many garbage collectors have amortized energy use lower than malloc/free” For those wondering: that’s because malloc/free ‘visits’ every dead object, while garbage collection visits the live ones (another way to say that: free collects garbage, the moment it is created, GC collects non-garbage, periodically) and there typically is way more garbage than non-garbage. I haven’t seen energy usage comparisons that include extra energy use due to GC’s higher memory usage, though. That possibly is because it is hard to quantify. On current technology, you pay for your RAM’s energy usage the moment you power it on, whether you need it or not)

jcranmer 8y ago

Looking at the underlying paper, I'm actually skeptical that there's any practical performance/energy boosts from this accelerator. The best case they're giving is something like a ~3-5× boost on GC (which is generally ~10% of total time, much of it hopefully idle time anyways if you're tuning GC well), with a 15% power reduction, assuming your collector is a stop-the-world, non-concurrent collector (and you rewrite your object layout). There's no measurement of the energy cost of the idling core, nor of the cost of extra memory and cache traffic trundling objects to and from the accelerator rather than sticking on the core. Those costs are likely to be even worse if you try to adapt this into incremental and concurrent collectors. Especially when you ask the question "is it better to spend the area/power budget on a highly-specialized accelerator, or to give it over to another full core that can do other things when it's not collecting garbage," it's hard to motivate this kind of accelerator.

nsuser3 8y ago

> also allow some higher-but-not-peak intensity software to be written with GC where it might not be today (games come to mind), although that could actually encourage more energy usage than what it would save. Just look at Minecraft for that (it's written in Java). A recent version created up to 200 MB of garbage per second!

VLM 8y ago
Definitely a problem with modded minecraft. One weird solution to the problem is due to some design decisions its pragmatically single core because there's a primary loop that does 99% of the work, freeing up plenty of cores to do side issues and garbage collection.