Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

For Better Computing, Liberate CPUs from Garbage Collection

spectrum.ieee.org

Post reply on HN
Print view View original

91–100 of 460 posts

Re: For Better Computing, Liberate CPUs from Garbage Collection

#91

Post by p_l »

gdwatson wrote: post #70
p_l wrote: post #36

Earlier quoted context omitted.

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…

Could you explain further or give links to more information? I'd love to read about old-timey techniques for programming in GCed languages.

Also - I really, really recommend reading the classic GC book ( 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

Re: For Better Computing, Liberate CPUs from Garbage Collection

#92

Post by reitzensteinm »

arcticbull wrote: post #80

IMO garbage collection is the epitome of sunk cost fallacy. Thirty years of good research thrown at a bad idea. The reality is we as developers choose not to give languages enough context to accurately infer the lifetime of objects. Instead of doing so we develop borderline self-aware programs to guess when we're done with objects. It wastes time, it wastes space, it wastes energy. If we'd spent that time developing…

In my opinion, shared memory mutability is the actual bad idea that's going to eventually die. It's not just error prone, it doesn't scale; try mutating the same cache line from two threads on an Intel desktop chip and see how that goes. Let alone across mesh buses, chiplets, dual sockets or (God forbid) the network.

Garbage collection on immutable data is vastly easier; it's intrinsically non blocking, concurrent and parallel. You can build a garbage collected immutable data store over arbitrary numbers of computers.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#93

Post by Dylan16807 »

etaioinshrdlu wrote: post #5

It does seem like just doing it in hardware may be a linear gain but isn't a fundamentally better algorithm. There's a proof that you do need to pause your program eventually, if you want to be sure you get all the garbage.

Can you find this proof? I haven't had any luck. And it's a pretty surprising result to me, assuming "all the garbage" means garbage that was created before the collection cycle started; it's a trivial and useless proof that garbage created 1 nanosecond ago still exists.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#94

Post by nsuser3 »

_bxg1 wrote: post #21

> 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…

> 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!

Re: For Better Computing, Liberate CPUs from Garbage Collection

#95

Post by vbarrielle »

jayd16 wrote: post #74
gdwatson wrote: post #70

Earlier quoted context omitted.

Could you explain further or give links to more information? I'd love to read about old-timey techniques for programming in GCed languages.

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.

> 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.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#96

Post by Dylan16807 »

banachtarski wrote: post #62
SmooL wrote: post #20

Earlier quoted context omitted.

Which has been shown time and time again to be the source of many serious software bugs and exploits

I'd be willing to wager you use plenty of software, codecs, games, and more that would not function nearly half as well without carefully managed memory.

Carefully managing memory often means using a language feature that handles the bulk for you. Neither manual nor GC. And you can be careful about how you use memory even in the presence of a GC, getting the same kind of optimization without any safety risks. It's not a tradeoff between manual management and "who cares?".

Re: For Better Computing, Liberate CPUs from Garbage Collection

#97

Post by arcticbull »

reitzensteinm wrote: post #92
arcticbull wrote: post #80

IMO garbage collection is the epitome of sunk cost fallacy. Thirty years of good research thrown at a bad idea. The reality is we as developers choose not to give languages enough context to accurately infer the lifetime of objects. Instead of doing so we develop borderline self-aware programs to guess when we're done with objects. It wastes time, it wastes space, it wastes energy. If we'd spent that time developing…

In my opinion, shared memory mutability is the actual bad idea that's going to eventually die. It's not just error prone, it doesn't scale; try mutating the same cache line from two threads on an Intel desktop chip and see how that goes. Let alone across mesh buses, chiplets, dual sockets or (God forbid) the network. Garbage collection on immutable data is vastly easier; it's intrinsically non blocking, concurrent an…

Am I wrong in thinking that a system comprised of entirely immutable memory doesn't even need a garbage collector? If you built such a system in Rust would not all memory just be deallocated once no longer utilized? The rust principal is (many readers XOR one writer) leads to fully static memory management. This is my point. We need to go back and re-think our language design principals keeping memory management in mind instead of pretending it's a solved problem.

IMO you make a good case.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#98

Post by xxs »

arcticbull wrote: post #80

IMO garbage collection is the epitome of sunk cost fallacy. Thirty years of good research thrown at a bad idea. The reality is we as developers choose not to give languages enough context to accurately infer the lifetime of objects. Instead of doing so we develop borderline self-aware programs to guess when we're done with objects. It wastes time, it wastes space, it wastes energy. If we'd spent that time developing…

Garbage collection is godsend when it comes to concurrency algorithms.

Determine liveness is hard on its own, ABA issues are totally eliminated by GC enabled setups.

As for energy costs, I'd bet generation/copy collectors are cheaper than malloc/free. They are way cheaper than ref. counting which requires deeper pipelines + branch predictor extra load; ref. counting with concurrency requires atomics, cache coherency traffic, flushing of the write queue and memory barriers.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#99

Post by dan-robertson »

arcticbull wrote: post #80

IMO garbage collection is the epitome of sunk cost fallacy. Thirty years of good research thrown at a bad idea. The reality is we as developers choose not to give languages enough context to accurately infer the lifetime of objects. Instead of doing so we develop borderline self-aware programs to guess when we're done with objects. It wastes time, it wastes space, it wastes energy. If we'd spent that time developing…

Knowing when you’ll be finished with an object solves the issue of knowing which objects to free but not the issue of heap fragmentation.

The main reason that eg C programs don’t suffer so much from heap fragmentation is that writing a C program which uses ephemeral objects in the way a GC’d language might is so incredibly painful that one mostly avoids the convenient programming techniques which lead to fragmentation.

The usual solution in a language like C (or a safe language like rust) to data where it is hard to know when it should be freed is to use reference counting yet reference counting is typically slower than an actual gc, especially on a multithreaded system (but this needs a quite advanced gc) where reference counting needs atomics. This leads some C programs to use gc when allocating and tracking these objects because it is cheaper than the overhead of malloc and reference counting.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#100

Post by jules »

arcticbull wrote: post #83
davedx wrote: post #82

Earlier quoted context omitted.

> It wastes time, it wastes space, it wastes energy. But all of these are much cheaper than developer labour and reputation damage caused by leaky/crashy software. The economics make sense. Anecdotally, I spent the first ~6 years of my career working with C++, and when I started using languages that did have GC, it made my job simpler and easier. I'm more productive and less stressed due to garbage collection. It's o…

> But all of these are much cheaper than developer labour and reputation damage caused by leaky/crashy software. The economics make sense. Of course, with traditional languages, that's the trade-off we're being asked to make. That's my point! We need to develop languages that accurately encapsulate lifetimes statically so that we can express that to the compiler. If we do, the compiler can just make instances disappe…

It isn't clear that what you're asking for is even theoretically possible, and it's far from obvious that the end result would be comparable to GC in terms of productivity.
Post reply on HN