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

Re: For Better Computing, Liberate CPUs from Garbage Collection

#21

Post by _bxg1 » Thu, May 09, 2019, 4:08 AM UTC

> globally this represents a large amount of computing resources.

Much of which would just sit idle otherwise, on client machines. Of course, the energy savings still apply.

> He also points out that many garbage collection mechanisms can result in unpredictable pauses, where the computer system stops for a brief moment to clean up its memory.

This is more of a hard barrier that's being solved.

All in all pretty cool idea, but I think the impact would be different from what's discussed here. Truly high-performance computing is already written in non-GC languages. This hardware would give medium-intensity GC programs (read: web servers on JVM, .NET, Node, Ruby) a boost, and could also allow some higher-but-not-peak intensity software to be written with GC where it might not be today (games come to mind), although that could actually encourage more energy usage than what it would save.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#22

Post by soup10 » Thu, May 09, 2019, 4:08 AM UTC

SmooL wrote: post #20

flukus wrote: post #18

Earlier quoted context omitted.

It's not a hard limitation, the fallback is some degree of manual memory management.

Which has been shown time and time again to be the source of many serious software bugs and exploits

oooo manual memory management scary. the absolute state of web programmers today

Re: For Better Computing, Liberate CPUs from Garbage Collection

#23

Post by p_l » Thu, May 09, 2019, 4:08 AM UTC

mailslot wrote: post #13

Seems like we could just as easily stop using garbage collection. ... or even go back to reference counting / smart pointers and just live with the “limitation” that we can’t have circular references.

Reference counting nor "manual" memory management are not faster than GC by themselves. Both tend to have pretty bad slowdowns that tend to result in optimizations... By batching operations similar to "GC pass", because there are different metrics of performance and occasional pause appears to be good compromise for most.

Personally I'm partial to deterministic schemes akin to IBM Metronome, where GC runs in bounded static time.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#24

Post by aidenn0 » Thu, May 09, 2019, 4:09 AM UTC

jhallenworld wrote: post #19

So my idea for GC is to offload it to a separate machine through a communications channel. The main CPU sends messages to the co-processor whenever it allocates memory, or whenever it mutates (whenever it writes a pointer to allocated memory or to the root set- there could be special versions of the move instructions which send these messages as a side-effect). There is a hardware queue for these messages and the mai…

That would seem to eliminate all moving GC algorithms though.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#25

Post by aidenn0 » Thu, May 09, 2019, 4:10 AM UTC

mailslot wrote: post #13

Seems like we could just as easily stop using garbage collection. ... or even go back to reference counting / smart pointers and just live with the “limitation” that we can’t have circular references.

Many tracing GC algorithms are considerably faster than reference counting.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#26

Post by _bxg1 » Thu, May 09, 2019, 4:13 AM UTC

flukus wrote: post #18

ZitchDog wrote: post #17

Earlier quoted context omitted.

Why scare quote "limitation"? It literally is a limitation, since it prevents me from doing something in code that can be useful at times. It certainly has tradeoffs.

It's not a hard limitation, the fallback is some degree of manual memory management.

[obligatory Rust plug]

Re: For Better Computing, Liberate CPUs from Garbage Collection

#27

Post by aidenn0 » Thu, May 09, 2019, 4:13 AM UTC

soup10 wrote: post #22

SmooL wrote: post #20

Earlier quoted context omitted.

Which has been shown time and time again to be the source of many serious software bugs and exploits

oooo manual memory management scary. the absolute state of web programmers today

I have over a decade of professional experience entirely in C and C++. I believe that manual memory management is the wrong choice for the vast majority of applications. It is error prone and often slower than garbage collection.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#28

Post by AnimalMuppet » Thu, May 09, 2019, 4:14 AM UTC

gizmo686 wrote: post #10

etaioinshrdlu wrote: post #5

It does seem like just doing it in hardware may be a linear gain but isn't a fundamentally better algorithm. There's a proof that you do need to pause your program eventually, if you want to be sure you get all the garbage.

Hardware is fundamentally parallel, CPUs are fundamentally serial; it is possible for a hardware solution to have a super-linear speedup in time. As a simple example, what is the time complexity of zeroing out n bytes of memory. With a CPU, this is O(n). However, with proper hardware support, this can be done in O(1) time. For a simple garbage collecting example (no idea how their chip does it), consider a simple mar…

But hardware that has to interface with the main memory can't be fundamentally parallel, because of memory bandwidth limitations. If you want to make this part of the memory, then my objection does not apply. But if it's an external chip to the memory, you still are fundamentally serial.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#29

Post by mailslot » Thu, May 09, 2019, 4:15 AM UTC

hnaccy wrote: post #15

mailslot wrote: post #13

Seems like we could just as easily stop using garbage collection. ... or even go back to reference counting / smart pointers and just live with the “limitation” that we can’t have circular references.

Why limitation in quotes? Do you feel it is not one in practice?

I argue that some limitations, like clear resource ownership, are good... but there are still workarounds that aren’t too arduous. Weak pointers and the like are decent enough abstractions to handle the rare case... or just going manual. It’s not a limitation in practice, no.

It hasn’t been a problem for me in over a decade in a multitude of languages. On Java codebases? I’ve witnessed some frightening levels of sloppiness that are only solvable with a profiler.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#30

Post by p_l » Thu, May 09, 2019, 4:15 AM UTC

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 reasonably optimized malloc()/free()