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

Re: For Better Computing, Liberate CPUs from Garbage Collection

#421

Post by maxxxxx » Thu, May 09, 2019, 9:53 PM UTC

mcguire wrote: post #368

maxxxxx wrote: post #226

Earlier quoted context omitted.

I think C++ could get most GC usability benefits if there was a better/simpler syntax for shared_ptr and unique_ptr. I have written code with extensive shared_ptr usage and it was quite pleasant if you ignore the ugly syntax. On the other hand even after years of C# I still miss deterministic destructors.

One downside of reference counting is the long delete delay you get when you remove the last reference to a large data structure. That's pretty easy to fix, but then you lose deterministic destructors.

That would be a really large structure get a noticeable delay :-)

Re: For Better Computing, Liberate CPUs from Garbage Collection

#422

Post by ernst_klim » Thu, May 09, 2019, 9:59 PM 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…

> Automatic reference counting

> Rust's borrow checker/tracker makes ownership explicit

So no compaction, no pointer-bump allocations? You have to reimplement these manually, aka reinvent GC while having ref-counter/region-based-mm overhead?

Re: For Better Computing, Liberate CPUs from Garbage Collection

#423

Post by reitzensteinm » Thu, May 09, 2019, 10:24 PM UTC

jandrewrogers wrote: post #269

reitzensteinm wrote: post #244

Earlier quoted context omitted.

I'm a bit confused by your phrasing. Non-shared mutability makes perfect sense (and is not the thing I believe needs to go), but at some point you have to share the results of a computation. If not shared immutability, how is this done in the systems you're describing? I assume message passing, queues or similar?

Sorry, I wasn't clear. There are two common software architecture schools for scaling practical concurrency. The first is the copy-on-mutate style commonly used in functional programming paradigms. This is what I assumed was meant by "shared immutability". As you surmised, in the second model individual threads own all mutable state, and operations on that state are requested via message passing (usually SPSC queues…

That's interesting to hear, thanks!

My rant was only really aimed at shared mutable memory; passing a piece of it around with one owner at a time is totally fine. One writer, multiple readers has its uses too.

I am a fan of persistent data structures and I think that as we keep slapping on cores they're going to be more appealing for general purpose computing, but they're certainly not one size fits all, and the performance tax is substantial.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#424

Post by CoolGuySteve » Thu, May 09, 2019, 10:26 PM UTC

p_l wrote: post #30

CoolGuySteve wrote: post #8

From an environmental perspective, I wonder how much energy is consumed (and emissions generated) for garbage collection and interpreters. These things exist to make programming easier but are then duplicated across thousands of servers. If everyone used some compiled language that was just a little simpler, a little safer, had just a little better memory management/tooling, or like here, had better hardware support,…

By energy use, Garbage Collection is generally better than typical manual approach, except for when "GC" is actually a naive refcount. Exact results depend on what metrics are you targeting - a stop the world pause can result in very efficient (in total time and power use) system, but one that has problematic latencies. A metronome style approach will have lower efficiencies but timings more predictable than reasonab…

> By energy use, Garbage Collection is generally better than typical manual approach, except for when "GC" is actually a naive refcount.

This is such an extraordinary claim that I'm going to need data before I believe it.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#425

Post by TGR44 » Thu, May 09, 2019, 10:49 PM UTC

soup10 wrote: post #195

p_l wrote: post #125

Earlier quoted context omitted.

if you believe that then you have no idea how Garbage Collectors work, period.

Please explain why half of optimizing java involves statically pre-allocating memory and trying to avoid the automatic memory management then

This...isn’t true.

Could you give any examples of common use cases and ways that people perform these “optimisations”?

Re: For Better Computing, Liberate CPUs from Garbage Collection

#426

Post by cyphar » Thu, May 09, 2019, 10:59 PM UTC

apta wrote: post #411

cyphar wrote: post #268

Earlier quoted context omitted.

Right, but I think their main complaint is that RefCell is implemented using "unsafe" -- hence my point about "unsafe".

It's API is not `unsafe` though. Otherwise, every safe API depends on some `unsafe` call down the call graph.

I think we're both in agreement, I was phrasing things in a manner which I thought would better reference how GP thinks of unsafe. Obviously the API itself is safe, but the "cheating" GP was referring to was the fact that Rust requires "unsafe" under the hood in order to implement some safe operations (because the memory model doesn't cover all cases). You and I agree that this isn't a problem.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#427

Post by flukus » Thu, May 09, 2019, 11:50 PM UTC

TGR44 wrote: post #425

soup10 wrote: post #195

Earlier quoted context omitted.

Please explain why half of optimizing java involves statically pre-allocating memory and trying to avoid the automatic memory management then

This...isn’t true. Could you give any examples of common use cases and ways that people perform these “optimisations”?

Not necessarily common because garbage collected languages tend to not get used for high performance tasks, but a huge amount of modern optimization is in improving contiguous memory access and avoiding pointer chasing to use CPU cache more effectively, in java allocating arrays of primitives type is about the only way to do that. Similarly in c# they added spans to achieve this with better ergonomics, but both basically come down to avoiding the garbage collector for better performance.

Another big one is trying to allocate as much as possible on the stack, either through the language like c/c++/c# or by using local variables and hoping the compiler will do the right thing for you with java. A lot of the work gone into java vm's over the decades have been trying to improve this. Even java sacrifices it's OO purity to make integers and floats value types on the stack, that was to get non-laughable performance.

> This...isn’t true.

It's not even remotely controversial, saying garbage collection is slower is like saying water is wet.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#428

Post by fouric » Fri, May 10, 2019, 1:06 AM UTC

JudgeWapner wrote: post #350

lossolo wrote: post #287

Earlier quoted context omitted.

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

When will a correctly-implemented GC ever alter your program's functional correctness, aside from timing-related bugs that aren't fixed by manual memory management either?

Re: For Better Computing, Liberate CPUs from Garbage Collection

#429

Post by kllrnohj » Fri, May 10, 2019, 1:12 AM UTC

favorited wrote: post #395

kllrnohj wrote: post #319

Earlier quoted context omitted.

That just lets it release earlier, not retain/release less often. ARC can't do anything magic here vs. something like really careful use of std::move & const references.

ARC optimizations do let it retain/release less often. For example, instead of a callee adding the return value to an autorelease pool then having the caller immediately retain the returned value, the autorelease+retain pair can be elided entirely.

> For example, instead of a callee adding the return value to an autorelease pool then having the caller immediately retain the returned value, the autorelease+retain pair can be elided entirely.

Are you just referring to standard RVO? If you return a std::shared_ptr in C++ today you won't get the equivalent of retain+release, either, RVO avoids that.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#430

Post by cyphar » Fri, May 10, 2019, 1:54 AM UTC

wbl wrote: post #295

cyphar wrote: post #255

Earlier quoted context omitted.

> (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. This is what weakrefs (or better data structures) are for. The Linux kernel uses reference counting incredibly effectively for almost every structure. I think that pretty much discounts any arg…

Reference counting is a garbage collection algorithm. It just isn't a very good one compared to semi space because its runtime is the number of dead objects not live objects.

Refefence counting is barely classifiable as garbage collection. The runtime is O(1) because you free the object immediately when it dies, there's no stage where you start looping over dead objects.