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

141–150 of 460 posts

Re: For Better Computing, Liberate CPUs from Garbage Collection

#141

Post by tempguy9999 »

ascar wrote: post #133
tempguy9999 wrote: post #111

Earlier quoted context omitted.

> If we do, the compiler can just make instances disappear statically when we're done with them -- not dynamically! Not possible generally. It would be easy to create a situation where some kind of refcount is a necessary final fallback. > The truth is with most of the Rust I write, I don't have to worry about allocation and deallocation of objects, and it happens. If Rust is the answer, why are you pushing for new l…

> If Rust is the answer, why are you pushing for new langs when Rust is sufficient? Something doesn't add up here. Maybe because he said, twice, that Rust is not all the way there?

You're quite right, thank you, upvoted.

However if he says "Rust gets us 80% of the way there" as you point out then he is obliged, IMO, to point out explicitly the 20% where it fails or we can't even begin to discuss it.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#142

Post by amelius »

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…

> If your co-worker proposed this as a solution you'd probably slap them.

So instead you'd suggest to research better languages? What would you say to your boss when he asks you about a time estimate?

Re: For Better Computing, Liberate CPUs from Garbage Collection

#143

Post by mafribe »

lispm wrote: post #138
mafribe wrote: post #120

Earlier quoted context omitted.

Thirty years of good research Historical aside: the first paper on GC is [1] which was written in 1963, by Minsky, who's now famous for AI research. So we have GC research for > 50 years. [1] M. L. Minsky, A LISP Garbage Collector Algorithm Using Serial Secondary Storage. https://dspace.mit.edu/bitstream/handle/1721.1/6080/AIM-058....

See the chapter 6.3 'The Free-Storage List and the Garbage Collector' in the LISP I Programmer's manual from March 1960. http://bitsavers.org/pdf/mit/rle_lisp/LISP_I_Programmers_Man...

Thanks. That's amazing. I always though GC must have been in Lisp from Day 1, but the Minsky article used to be the oldest one I was aware of. Has anybody dug into the original LISP sources (do they still exist?) to see when working GC first arrived?

Re: For Better Computing, Liberate CPUs from Garbage Collection

#144

Post by gpderetta »

pron wrote: post #117
dochtman wrote: post #114

Earlier quoted context omitted.

Good throughput with GC seems to come with significant extra memory use: "We compare explicit memory management to both copying and non-copying garbage collectors across a range of benchmarks using the oracular memory manager, and present real (non-simulated) runs that lend further validity to our results. These results quantify the time-space tradeoff of garbage collection: with five times as much memory, an Appel-s…

> Good throughput with GC seems to come with significant extra memory use Of course. RAM is the price we pay for GC. Good thing it's so cheap on servers. BTW, just note that the paper doesn't compare GC (never mind that the algorithms have much improved since then) to real explicit memory management, but to an oracle (i.e. explicit memory management by an all-knowing God). Paying nothing other than for 3x RAM to get…

Memory you are wasting for GC is Memory you are not using, for example, for caching which directly impacts performance.

Mind you, I think GC is great, but saying that RAM is free is misguided.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#146

Post by gpderetta »

xxs wrote: post #98
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…

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

FWIW, Herlihy has examples of ABA issues on algorithms implemented in Java.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#147

Post by imtringued »

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…

I bet you complain about interpreted languages too. The trade off of computer vs developer time happens by design.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#148

Post by imtringued »

gpderetta wrote: post #144
pron wrote: post #117

Earlier quoted context omitted.

> Good throughput with GC seems to come with significant extra memory use Of course. RAM is the price we pay for GC. Good thing it's so cheap on servers. BTW, just note that the paper doesn't compare GC (never mind that the algorithms have much improved since then) to real explicit memory management, but to an oracle (i.e. explicit memory management by an all-knowing God). Paying nothing other than for 3x RAM to get…

Memory you are wasting for GC is Memory you are not using, for example, for caching which directly impacts performance. Mind you, I think GC is great, but saying that RAM is free is misguided.

Using RAM for "caching" sounds extremely wasteful. There could be applications that want to use it for something more useful than a 1% performance improvement.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#149

Post by Patient0 »

apta wrote: post #140
Patient0 wrote: post #136

Earlier quoted context omitted.

In the ~15 years I spent building software in C++ I don't recall a single time that I wished for garbage collection. By using RAII techniques, it was always possible (nay, easy!) to write code that cleaned up after itself automatically. I always found it easier to reason about and debug programs because I knew when something was supposed to be freed, and in which thread. The only time that use of simple reference cou…

While RAII is a very good technique, it is not the solution to all issues here. I read that some concurrent datastructure implementations would not be possible without a GC. Furthermore, when a project reaches a certain level of complexity, it ends up implementing GC anyway (see Unreal engine).

I agree that RAII does not solve everything - in particular, issues with memory fragmentation. However, I prefer the direction being taken by Rust and suggested by the top level poster: rather than having to run a separate thread which tries to infer which resources are no longer needed, with potentially large runtime costs, instead augment the language semantics with a clear ownership model, and thereby give the compiler enough information to generate code that runs in a stable, predictable memory footprint.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#150

Post by cpach »

pron wrote: post #104
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…

I think that garbage collection has proven to be the best idea in programming languages in the past decades, and probably the only one that has made an impact at all. It's getting so good these days that few are willing to consider "moving on." In terms of throughput, it beats manual memory management (in fact, in principle, the cost of GC can be made arbitrarily low; a famous Andrew Appel paper shows how it can be c…

If anyone is interested in reading the paper, it’s available at this FTP server: ftp://ftp.cs.princeton.edu/reports/1986/045.pdf
Post reply on HN