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

31–40 of 460 posts

Re: For Better Computing, Liberate CPUs from Garbage Collection

#31

Post by aidenn0 »

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

Garbage collection is mostly an issue of latency, not overall CPU usage. malloc and free are not O(1) anymore than garbage collection is.

[edit]

I forgot memory usage as a third resource. The search space of GC algorithms can be considered on a triangle of throughput, latency, and RAM usage. You can make one of these better by making one or both of the other worse.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#32

Post by mailslot »

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

Sure, if you’re using pre-1990’s memory management. Best practices have evolved far beyond the explicit use of malloc & free and unsafe string handling.

Most popular dynamic languages don’t use garbage collection under the hood anyway. In Python and many other runtimes, it’s primarily reference counted.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#33

Post by xenadu02 »

aidenn0 wrote: post #24
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.

Not really though you may want to. The main CPU could compact memory if it felt fragmentation was high enough to warrant it. By its nature the traffic is asynchronous so the CPU won't do a perfect compaction (it won't have processed all the inbound messages to mark garbage as free) but it would probably be close enough.

The big win here is making it all async. No need to stop the world, issue write barriers to application activity, or otherwise synchronize for GC. You'd have a bigger highwater mark for used memory but otherwise the main CPU can pickup the "the memory from x to y is now free" messages on any thread and whenever it is convenient.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#34

Post by gizmo686 »

AnimalMuppet wrote: post #28
gizmo686 wrote: post #10

Earlier quoted context omitted.

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.

How much does it need to interface with main memory? If the external chip has its own memory then it can maintain its own view of the object graph. The software can update it when references are made/deleted and query it when an allocation needs to be made.

There is still the overhead of communicating when references are made/deleted, but you need that anyway, as something that only looks at memory doesn't know what is a pointer, or the size of objects.

The communication overhead is then linear in with respect to the amount of updates to the object graph, not the size of the object graph.

You could even go so far as to not put the chip on the memory bus at all.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#35

Post by aero142 »

exabrial wrote: post #9

Azul Systems has asked Intel to do this once... but instead created their own processors with interesting memory barrier properties for awhile that greatly sped up JVMs beyond what was capable (at the time) on x86-32/ppc/sparc. Eventually they gave up and became a purely software company, but their "Java Mainframe" product was many times faster than the Intels of the age executing the same code despite much slower CP…

I feel like Amazon is going to bring back custom hardware like this. Imagine if this was an instance type.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#36

Post by p_l »

_bxg1 wrote: post #21

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

We wrote latency-sensitive and high-performance code in GCed languages back in 1980s - avoiding pauses or having predictable latencies (in fact, more predictable than usual manual memory management!) are more of "we don't teach people how to program" rather than issue with GC.

As for energy savings, many garbage collectors have amortized energy use lower than malloc/free. Even pretty simple ones (some of the simplest I've seen beat it so hard it's not competition, but they are specific to their application)

Re: For Better Computing, Liberate CPUs from Garbage Collection

#37

Post by seandougall »

Eric_WVGG wrote: post #16
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.

doesn’t seem cool to admire Apple technologies, but ARC seems to work amazingly well with zero CPU overhead

It’s not zero — those -retain and -release calls still exist when necessary and have a small penalty — but it does minimize them well, and is lower overhead and vastly more predictable than GC.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#38

Post by flukus »

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

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.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#39

Post by Scramblejams »

CoolGuySteve wrote: post #14
exabrial wrote: post #12

Earlier quoted context omitted.

So... Rust, basically

I didn't want to start a language war but yeah, basically. Swift and/or ObjC + ARC seem to be attacking the same problems on the embedded side out of necessity. It's too bad Apple is so apathetic about Linux servers. Even just replacing Python with Go might save a massive amount of KWh consumed.

I'm more interested in optimizing the client side, at least where the web is concerned. I keep wondering when Google is going to start generating energy ratings for the top few thousand sites on the web. It would shame the low performers into producing front ends that are no longer glacial. I was loading wunderground.com's 10 day forecast for the umpteenth time lately and reflecting on how horribly slow and inefficient it is... Surely website energy ratings must be in the works somewhere, right?

Re: For Better Computing, Liberate CPUs from Garbage Collection

#40

Post by ygra »

mailslot wrote: post #32
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

Sure, if you’re using pre-1990’s memory management. Best practices have evolved far beyond the explicit use of malloc & free and unsafe string handling. Most popular dynamic languages don’t use garbage collection under the hood anyway. In Python and many other runtimes, it’s primarily reference counted.

Python still uses mark and sweep occasionally to clean up structures where reference counting fails.
Post reply on HN