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

Re: For Better Computing, Liberate CPUs from Garbage Collection

#341

Post by cblades » Thu, May 09, 2019, 5:04 PM UTC

simias wrote: post #332

cblades wrote: post #316

Earlier quoted context omitted.

>he caller will then either use it and drop it immediately or store it somewhere to be dropped later, either on its own or as part of the structure it belongs to. You're glossing over a lot of complexity there. That's the entire point of GC, you don't have to think about when it's dropped. Also, I wasn't arguing for the blanket necessity of GC in all contexts and for all problems.

Can you point out a specific example then? I'm genuinely not trying to play dumb. I very honestly not see that complexity that should be obvious to me given that I spend most of my time writing code in non-GC languages. Maybe it's just Stockholm syndrome and I'm so used to working that way that I don't even see the problem anymore but there are now a long string of replies talking abstractly about the overhead of pro…

>store it somewhere to be dropped later, either on its own or as part of the structure it belongs to.

Wherever you're storing the reference, you have to eventually free the memory. That propagates memory-management code throughout your codebase, and is error-prone.

I totally agree that if you're allocating on the stack it's a non-issue. If you're returning a reference and always freeing in the caller, that's pretty easy too, but you have to have that logic in every single caller. If you're storing a reference on the heap somewhere, you suddenly have dynamic lifetimes with indeterminate reference counts, and it gets quite hard to 1) correctly manage memory and 2) verify that you're correctly managing memory.

The alternative is that in all three instances in a GC language, I don't have to care about memory management. Barring unusual edge cases, I can't forget to deallocate something and end up with a memory leak.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#342

Post by babyloneleven » Thu, May 09, 2019, 5:05 PM UTC

bunderbunder wrote: post #252

jandrewrogers wrote: post #230

Earlier quoted context omitted.

I tend to take the position that arguments about the merits of GCs are proxies for a different issue at a higher level of abstraction that is rarely tackled directly. One of the correctly argued advantages of GC is that it automatically handles some difficult edge cases like ambiguous lifetimes and cyclical references. In my opinion, there is an interesting discussion to be had around why these edge cases need to be…

This hits on something I've been wondering about lately: For those of us who might want some of the performance characteristics of Rust, but not to the extent that we're willing to take on all of the strictures it imposes, what's the feasibility of building a compiler that can avoid GC for objects whose lifetime can be determined statically, while still retaining GC for the rest? My (wild) guess is that it wouldn't a…

Compilers of managed languages already do this optimization when they can prove that a variable has a static lifetime. Look up scape analysis.

The trouble is, this is hard to do for non-trivial code (and in the general case is uncomputable).

Re: For Better Computing, Liberate CPUs from Garbage Collection

#343

Post by babyloneleven » Thu, May 09, 2019, 5:06 PM UTC

babyloneleven wrote: post #342

bunderbunder wrote: post #252

Earlier quoted context omitted.

This hits on something I've been wondering about lately: For those of us who might want some of the performance characteristics of Rust, but not to the extent that we're willing to take on all of the strictures it imposes, what's the feasibility of building a compiler that can avoid GC for objects whose lifetime can be determined statically, while still retaining GC for the rest? My (wild) guess is that it wouldn't a…

Compilers of managed languages already do this optimization when they can prove that a variable has a static lifetime. Look up scape analysis. The trouble is, this is hard to do for non-trivial code (and in the general case is uncomputable).

I'm not finding how to edit, but, it's called escape analysis

Re: For Better Computing, Liberate CPUs from Garbage Collection

#344

Post by mcguire » Thu, May 09, 2019, 5:16 PM UTC

blub wrote: post #325

coldtea wrote: post #283

Earlier quoted context omitted.

> Really, manual memory management is not rocket science folks, just error prone Doesn't have to be rocket science to be a cognitive burden. And we want to eliminate "error prone" factors...

And we did eliminate them. But no one can seriously claim that GC is a magic bullet, because it's only clearly winning against plain C. Carefully designed, popular languages are choosing RAII and reference counting implementations and those are very competitive.

?

C++ and Objective C inherited C's memory model and thus don't have a good memory management option. Rust is explicitly a systems language, meaning stronger memory models are out of scope, and then inherited most of C++'s idioms.

Other than those, what popular languages are specifically choosing reference counting as a primary GC method?

Re: For Better Computing, Liberate CPUs from Garbage Collection

#345

Post by pron » Thu, May 09, 2019, 5:17 PM UTC

benchaney wrote: post #286

pron wrote: post #157

Earlier quoted context omitted.

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.

It’s not clear what you mean by a distributed system in this context, but RAM is used for caching, costs or no.

My point is that you can't increase the cache size indefinitely to get performance improvements, because you also have to handle cache invalidation. There is an optimal working set.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#346

Post by steveklabnik » Thu, May 09, 2019, 5:20 PM UTC

mcguire wrote: post #344

blub wrote: post #325

Earlier quoted context omitted.

And we did eliminate them. But no one can seriously claim that GC is a magic bullet, because it's only clearly winning against plain C. Carefully designed, popular languages are choosing RAII and reference counting implementations and those are very competitive.

? C++ and Objective C inherited C's memory model and thus don't have a good memory management option. Rust is explicitly a systems language, meaning stronger memory models are out of scope, and then inherited most of C++'s idioms. Other than those, what popular languages are specifically choosing reference counting as a primary GC method?

Swift.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#347

Post by kazinator » Thu, May 09, 2019, 5:22 PM UTC

I'm skeptical; GC is closely tied to programming language run-times. How is some accelerator going to know which pointers in an object are references to other GC objects and which are non-GC-domain pointers (like handles to foreign objects and whatnot)? How does the accelerator handle weak references and finalization?

People aren't going to massively rewrite their language run-times to target a boutique GC accelerator.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#348

Post by kazinator » Thu, May 09, 2019, 5:23 PM UTC

jhayward wrote: post #282

daemin wrote: post #170

One talking point I'd like to ask is: For small short lived scripts and applications, do we even need to free any memory these days? For example you write a script which takes several seconds to execute, moves files, computes stuff with strings, etc. Should we really invest time and effort in the script interpreter to free the memory, where instead we can just exit normally and let the OS handle the clean up. I would…

"exec() is the world's most efficient garbage collector." [1] This idea is both worthy, and old. [1] DJB, paraphrased, when responding to a criticism of the design of qmail, which rapidly forked very small processes which did a simple task and exit. Unable to find a link to the mailing list.

Hardly; it leaves file descriptors open that are not marked close-on-exec.

exit() is the world's most efficient garbage collector.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#349

Post by jokoon » Thu, May 09, 2019, 5:24 PM UTC

It reminds me of the days I was reading Knuth's quote "97% of the time premature optimisation blabla" every time someone was trying to make something faster.

CPUs are not getting faster, yet it seems using tools that makes things run faster are somehow taboo.

Wirth's law:

Wirth's law is an adage on computer performance which states that software is getting slower more rapidly than hardware becomes faster.

Why is java taught in university, and why is this language considered like some kind of standard? Most OSes are written in C, yet most of silicon valley frowns upon writing C because of arrays. Even C++ is getting a bad reputation.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#350

Post by JudgeWapner » Thu, May 09, 2019, 5:26 PM UTC

lossolo wrote: post #287

simias wrote: post #267

Earlier quoted context omitted.

I don't see your point. Of course sometimes the lifetime of an object is not tied to code scope but actually to something dynamic. Let's say for instance when you close a tab in your browser you expect the resources to be freed (ignoring caching to simplify the argument). Clearly somewhere in your code you have to explicitly handle tab closing and break the references to allow the GC to do its job. Why not free the r…

> Clearly somewhere in your code you have to explicitly handle tab closing and break the references to allow the GC to do its job. Why not free the resources here while you're at it? You are missing the point. The main point behind GC is removing the complexity of writing the software. Writing your own destructors, thinking about when to free your memory or writing lifetime annotations, needing to design your app in…

> mental overhead that is removed by GC

and it is replaced by GC when your program behaves unexpectedly because, whoopsie, that's the one time the GC decided to run. Good luck debugging or even reproducing that.