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

151–160 of 460 posts

Re: For Better Computing, Liberate CPUs from Garbage Collection

#151

Post by barrkel »

geocar wrote: post #113
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. And that's why so much effort has gone into making it fast and low latency, but it was a false dichotomy: We can have memory safety without garbage collection. - Automatic reference counting: Most people know about Objective-C's efforts in this space, but it's admittedly less automatic than programmers wou…

Reference counting is garbage collection. It's part of the mix of potential strategies for automatic collection of memory. As is static analysis of data flow, fwiw.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#152

Post by Hercuros »

mafribe wrote: post #122
Hercuros wrote: post #116

Earlier quoted context omitted.

I think there are essentially two ways of making the compiler statically aware of lifetimes: you can annotate the program with lifetimes, as in Rust, or you can have the compiler infer all of the lifetime information somehow. Adding annotations requires more programmer effort and reduces the level of abstraction of your programming language. Rust takes this approach, but tries to keep the level of annotation somewhat…

possible for the Rust compiler to infer most/all lifetimes) I'd be interested to learn why you think this is possible. As you point out yourself, by Rice's theorem, precise lifetimes are not statically decidable. Rust's lifetimes are essentially based on nesting (think well-balanced brackets) and tracked by enriching the standard Damas-Hindley-Milner approach with a notion of affin-ness which is a weakening of Girard…

I think that for function definitions in Rust you would in principle be able to leave out lifetime annotations on arguments/return values in more cases than is currently allowed by lifetime elision. I believe they don't allow this since it can become very confusing if the lifetimes are not written out when there are multiple references arguments. I'm not entirely sure about this, though.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#153

Post by bullen »

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 you might have missed the point of having software tell you what mistake you made without crashing?

Not to mention seamless hot-deployment or concurrent parallelism that is very hard without a VM.

I think it's hard to convince non-server coders of why VMs are good.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#154

Post by nurettin »

davedx wrote: post #82
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…

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

My first 8-9 years was full of very competitive, bleeding edge C++ and I can tell for sure that your productivity increase was not caused by garbage collection, but by using a more orthogonal language. I feel it in delphi the same way I feel it in go and python.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#155

Post by rbehrends »

dochtman wrote: post #114
pron wrote: post #104

Earlier quoted context omitted.

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…

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…

This is not only a dated paper (a decade and a half old), but it relies on assumptions that do not necessarily hold in practice.

If you test actual allocation performance on actual current day hardware, you may end up with completely different results, e.g.:

https://github.com/rbehrends/btree-alloc

Re: For Better Computing, Liberate CPUs from Garbage Collection

#156

Post by tjoff »

p_l wrote: post #123
tjoff wrote: post #64

Earlier quoted context omitted.

The benefit of not using GC is improved understanding of the code and a better architecture. These things will also lead to better performance. GC was a mistake. The main reason it is still used outside scripting languages is the notion that non-GC languages need to be low level. Which in practice is kind of true just because we haven't had any real competition in that area.

Not having GC in no way improves understanding of architecture or gives better performance. Hordes of C/C++ programmers that don't understand memory management but swear by malloc()/free() are a good example of that. And it's not like C/C++ are only language without GC, they are just popular now . Typical programmer is taught nothing about memory management, till maybe they learn bits and pieces (often by hearsay and…

Not necessarily no. Just as having type information doesn't lead to a better program.

But it helps. And is something you need to reason about regardless. Being explicit about it isn't a huge overhead but has lots of benefits.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#157

Post by pron »

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.

I didn't say it's free, only that it's relatively cheap. That RAM can simply be used for caching is incorrect, though. There are very-non-neglible costs to maintaining caches in distributed systems.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#158

Post by baybal2 »

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…

> The reality is we as developers choose not to give languages enough context to accurately infer the lifetime of objects.

Well, if we force devs to describe context, why not simply make them manage memory manually then?

There is nothing wrong with manual memory management. It is not hard at all.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#159

Post by p0nce »

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…

An idea so bad it has made it into hardware!

Re: For Better Computing, Liberate CPUs from Garbage Collection

#160

Post by DevoidSimo »

tempguy9999 wrote: post #141
ascar wrote: post #133

Earlier quoted context omitted.

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

He mentions Rc and Arc which I assume is what he means by the 20%. I tend to agree, although I'm not sure how you would get rid of them.
Post reply on HN