For Better Computing, Liberate CPUs from Garbage Collection • Hacker News Board

Re: For Better Computing, Liberate CPUs from Garbage Collection

#201

Post by notacoward » Thu, May 09, 2019, 11:36 AM UTC

jillesvangurp wrote: post #132

jondubois wrote: post #85

>> consumes a lot of computational power—up to 10 percent or more of the total time a CPU spends on an application. I stopped reading there. 10% is nothing. For such a useful feature as automatic garbage collection, for the vast majority of applications, I'd gladly give away 50% of the CPU. In terms of ensuring code correctness and robustness, if I had to choose static typing or automatic garbage collection, I'd pick…

Worse, it's a tradeoff and not a constant overhead. As many Java based server products show, things are fine if you do things such that you avoid garbage collection. GC is only problematic if you are doing bad things like constantly creating lots of objects, or worse, keeping them around for too long. E.g. Elasticsearch uses a lot of memory mapped files these days instead of heap memory (which they used more heavily…

> On servers, idling CPUs is the norm.

The competition for "least true statement on HN" is always fierce, but you've just submitted a contender. All the people who have lots of servers work really hard to coalesce workloads and drive up utilization. I know because that's what I do, and it's what everyone around me does. It's why the cloud you use is cost-effective. The machines that are mostly idle are clients, not servers.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#202

Post by xfer » Thu, May 09, 2019, 11:37 AM UTC

CoolGuySteve wrote: post #137

flukus wrote: post #38

Earlier quoted context omitted.

Here's a benchmark that includes an energy comparison: https://thenewstack.io/which-programming-languages-use-the-l... . It's interesting that speed does not directly correlate with energy consumption and the the energy consumption of functional languages was much higher than imperative.

Not sure why you’re getting downvoted when you’re the only response with actual data whereas the other responses are defending clearly less efficient practices with gobbledegook about O(1) memory algorithms and whatnot. I think most of it is coming from overly defensive users of GC languages . Sometime the world you want is not the world that exists.

> Specifically, they used 10 problems from the Computer Language Benchmarks Game

Yeah some "actual data" right there.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#203

Post by maaaats » Thu, May 09, 2019, 11:37 AM UTC

stephc_int13 wrote: post #186

I never understood the need for Garbage Collectors. In my opinion, the difficulties of memory management are extremely overrated. I write code in C/C++ for almost 20 years and I never encountered a difficult bug that would have been avoided with a Garbage Collector. If a coder really has a hard time with manual memory management it means he can't really code, this is a beginner problem...

I only work in GCed languages, so I don't know how manual memory management works, except segfaults in some courses at university. Guess I should quit my job, as you say I apparently can't really code :/ Thanks for letting me and others here know!

Re: For Better Computing, Liberate CPUs from Garbage Collection

#204

Post by eru » Thu, May 09, 2019, 11:41 AM UTC

rbehrends wrote: post #192

eru wrote: post #177

Earlier quoted context omitted.

That's a very fresh repo. I wonder how GHC would fare. I guess I should contribute.

Thanks, but I do not plan to extend this project to other languages. I put it together a while ago as an illustration that conventional wisdom regarding GC cost is not what many people think. If I were to expand it, I'd look at other allocation patterns rather than more languages; I've already good a fairly good cross-section of garbage collectors and malloc() implementations, so I don't really need any more.

Fair enough. Well, too late, I just hacked together a Haskell version based on the OCaml version. It's naive code, but 16 times faster (0.235s vs 3.818s).

So I expect some GHC specific optimizations are kicking in. Eg GHC is probably smart enough never to construct the whole tree at once. Whether that counts as the kind of static analysis static of object lifetimes someones else in this thread talked about or not, I don't know.

Update: I think it's just common subexpression elimination kicking in..

Re: For Better Computing, Liberate CPUs from Garbage Collection

#205

Post by codetrotter » Thu, May 09, 2019, 11:41 AM UTC

fao_ wrote: post #165

geocar wrote: post #113

Earlier quoted context omitted.

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

I think you mean "Automatic Garbage Collection", rather than just "Garbage Collection". The latter is exactly what you do in C when you use `free()`, the former is an automated system that does `free()` on your behalf at runtime. Indeed, the fact that you consider Rust's borrow checker to be part of the non-gc methods of handling memory, make it clear that you do indeed recognise this distinction, even thought it is…

> I think you mean "Automatic Garbage Collection", rather than just "Garbage Collection". The latter is exactly what you do in C when you use `free()`, the former is an automated system that does `free()` on your behalf at runtime.

To me, the difference between garbage collection and other memory management systems is that gc scans memory looking for memory that can be reclaimed. I don’t consider free() to be garbage collection. free() is the final step you do in any memory management scheme, it’s not a specific technique of memory management.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#206

Post by AsyncAwait » Thu, May 09, 2019, 11:47 AM UTC

eru wrote: post #168

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…

C++ code is full of use after free problems. You can avoid those with garbage collection.

Yes, but you can also avoid that and the cost of garbage collection by having an explicit ownership model akin to Rust.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#207

Post by blattimwind » Thu, May 09, 2019, 11:50 AM UTC

geocar wrote: post #176

tempguy9999 wrote: post #135

Earlier quoted context omitted.

You say > but it was a false dichotomy: We can have memory safety without garbage collection. but then say > Automatic reference counting (ARC henceforth). Naive ARC is AFAIK very expensive as it causes a lot of updates at each pointer 'take' even if it's a read only (chasing pointers), trashing caches. Poss. even worse if multithreading is used as a memory barrier may have to be issued. Also it does not collect cycl…

> Naive ARC is AFAIK very expensive as it causes a lot of updates at each pointer... Yes, and I think that's why people shy away from it. Language design can help a lot though: Array languages use reference counting almost exclusively because nesting objects is uncommon. That means no pointers to chase the vast majority of the time. > if ARC is what you think it is, how is it not an implementation of GC? Garbage Coll…

> Garbage Collection involves crawling live objects from roots to determine what's still alive.

> If you're not doing that, you might still be doing automatic memory management, but you're not doing GC.

Whether GC and automatic memory management are [significantly] different terms depends on who you ask, I don't think there is a consensus on that. In many cases however people tend to say GC as shorthand for tracing GC.

I think in many cases we see ARC is "good enough", and in a JIT scenario you could remove many RC changes by effectively collapsing/merging scopes. OTOH it is quite clear that for the same workload tracing inevitably performs better.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#208

Post by mort96 » Thu, May 09, 2019, 11:55 AM UTC

fao_ wrote: post #165

geocar wrote: post #113

Earlier quoted context omitted.

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

I think you mean "Automatic Garbage Collection", rather than just "Garbage Collection". The latter is exactly what you do in C when you use `free()`, the former is an automated system that does `free()` on your behalf at runtime. Indeed, the fact that you consider Rust's borrow checker to be part of the non-gc methods of handling memory, make it clear that you do indeed recognise this distinction, even thought it is…

I think the most widely accepted definition for "garbage collection" is something which frees memory automatically, as opposed to manually freeing memory (or other memory management schemes). In fact, the second paragraph of Wikipedia's page on garbage collection[1] says that "Garbage collection is essentially the opposite of manual memory management, which requires the programmer to specify which objects to deallocate and return to the memory system".

[1]: https://en.wikipedia.org/wiki/Garbage_collection_(computer_s...

Re: For Better Computing, Liberate CPUs from Garbage Collection

#209

Post by AsyncAwait » Thu, May 09, 2019, 11:57 AM UTC

titzer wrote: post #180

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…

IMO manual memory management is the epitome of sunk cost fallacy. Sixty years of good programmer effort thrown at a bad idea that has produced an endless stream of security bugs and performance problems that have only hidden the cost of memory management behind non-obvious barriers and done severe violence to systems languages with an absurd obsession with custom allocators and baked ownership into otherwise straight…

I think he was simplifying to make a point.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#210

Post by tomp » Thu, May 09, 2019, 11:57 AM UTC

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…

This comment is just bad and misinformed all over.

(1) Automatic Reference Counting doesn't work; its equivalent in interpreted languages is, well, reference counting, which can be optimized quite a lot (though has some issues with multithreading), but cannot collect cycles.

(2) therefore, if you want reference counting, you have to either also have GC (for cycles), or program carefully to avoid creating cycles (which is then only marginally better than C++)

(3) your comment on Python vs Perl5 is just nonsense, Python uses reference counting as well (along with the occasional GC to collect cycles)

(4) linear / uniqueness types (not exactly the same, but both can be used to ensure safe memory management) impose significant mental overhead on programmers as they prohibit many common patterns

(5) Rust features a lot of "cheating" - pointers that allow mutation from multiple threads, reference-counted pointers, etc. - so obviously just ownership&borrowing isn't good enough

conclusion: you can't have your cake and eat it too (at least according to current cutting edge research and implementations) - you either have GC or you have to be very careful/restricted when writing code