Live data from Hacker News

For Better Computing, Liberate CPUs from Garbage Collection

spectrum.ieee.org

71–80 of 460 posts

Re: For Better Computing, Liberate CPUs from Garbage Collection

#71
post #69
post #67

Earlier quoted context omitted.

Could that not be hardware implemented / augmented?

It could be, but then after investing a billion dollars what happens when someone develops another algorithm? What happens when a programming language with different gc requirements become popular?

Seems to be one of the main risks for any specialized circuits, if I understand you correctly. You always have to guess "will this really be relevant long enough to invest the money to bake it into hardware?" .. and if you guess wrong you just wasted a part of your silicon budget for something no one will use.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#73
post #35
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.

I think everyone is about to make custom hardware.

A recent custom chip project I have been a part of for basically a decade is nearing production.

Made on a fairly large, old process. Despite this, many custom features have been added. For many tasks, the performance will be competetive with much more complex, resource intensive devices. It is built in a way that allows for efficient, multi core computing, concurrent or parallel, sans an OS.

People will write those, but many will just grab the pieces they want, put them on cores, then write their target app on top. The prior version, Propeller 1, made doing that a lot easier than one might think.

What struck me was the combination of very well planned silicon, coupled with software, can really perform. It reminds me of the custom chips we saw in early computing. Amiga, SGI, many others made adapter cards to get things done.

All of that stuff nailed the tasks cold, would always perform. As CPUs got quicker, more could be move to software of course.

But now that is hard again

Software plus purpose built silicon is going to deliver peak performance.

Always has.

In that project, it took years, but a great many use cases were considered, FPGA simulations ran, code written, and then augmented with hardware, special instructions and sub systems intended to maximize performance while retaining a lot of flexibility.

The way I see it, general purpose computers may just end up back where they were before.

In 8 bit times, an Apple 2 was an all software machine. People bought and made cards to do specific things very well. Other computers had custom chips that focused on games, etc...

In the later era, Amiga, SGI made great hardware that was focused on specific things, while the PC was more like the Apple 2.

We are currently leaving a long era where general purpose computing made sense for most cases, and software got refined, things got faster, and we saw many good cycles.

Soon, more efficient CPU designs, often with well tuned instructions for given tasks may be directing a lot of purpose built silicon. Phones and tablets vs laptops give us a tiny look at one part of how it might go.

GPU instances, specialized network maybe filesystem CPUs with highly optimized instruction sets already exist.

More will come.

Many use cases can benefit from real time or just faster performance per watt. Software plus custom silicon will nail that, and it is getting easier to do.

RISC V has plans for specialized instructions baked in. It may well be that "one to bind them all", nudging out the more expensive ARM, for example. And maybe not. ARM is lean and mean and mature. Who knows?

All I know is the drive to do more per watt as well as the drive to improve peak sequential compute, because there are still too many use cases where doing that makes sense, given either the nature of the problem space, or accumulates software warrant the effort.

We are already seeing the GPU idea expanded on.

Gonna be interesting and more difficult times ahead.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#74
post #36

Earlier quoted context omitted.

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…

Could you explain further or give links to more information? I'd love to read about old-timey techniques for programming in GCed languages.

His point is it's not rocket science. Preallocate and pool what you might need, don't call new in your tight loop. Change the GC algorithm to something that never runs unexpectedly. If you're still allocating such that you need GC eventually, manually GC at an appropriate time like a load screen.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#75
post #36
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…

”As for energy savings, many garbage collectors have amortized energy use lower than malloc/free”

For those wondering: that’s because malloc/free ‘visits’ every dead object, while garbage collection visits the live ones (another way to say that: free collects garbage, the moment it is created, GC collects non-garbage, periodically) and there typically is way more garbage than non-garbage.

I haven’t seen energy usage comparisons that include extra energy use due to GC’s higher memory usage, though. That possibly is because it is hard to quantify. On current technology, you pay for your RAM’s energy usage the moment you power it on, whether you need it or not)

Re: For Better Computing, Liberate CPUs from Garbage Collection

#76
post #71
post #69

Earlier quoted context omitted.

It could be, but then after investing a billion dollars what happens when someone develops another algorithm? What happens when a programming language with different gc requirements become popular?

Seems to be one of the main risks for any specialized circuits, if I understand you correctly. You always have to guess "will this really be relevant long enough to invest the money to bake it into hardware?" .. and if you guess wrong you just wasted a part of your silicon budget for something no one will use.

Right. Got it.

There may still be room for specialized GC assist circuits.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#77

Ok, so saving 15 percent of 10 percent of power use by changing both how we build processors and how we write software. Doesn't seem worth it.

Seems worth it if the software developed is a fraction of all software written. Sure your VM/runtime will have to be refactored, but not the millions of programs that run on it.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#78
post #40

Earlier quoted context omitted.

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

It has optional cycle detection, yep. But... you could also just spend a couple of minutes to not have cyclic references.

"A couple of minutes"

Just a little bit overconfident.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#79

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…

It really comes down to whether reading this coprocessor is faster than the cache miss.

Hard to say but I can't imagine why it could be faster than normal core to core communication. In that case it's equivalent to a parallel GC, right?

Re: For Better Computing, Liberate CPUs from Garbage Collection

#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 smarter languages and compilers (Rust is a start, but not an end) we'd be better off as developers and as people. Garbage collection is just plain bad. I for one am glad we're finally ready to consider moving on.

Think about it, instead of finding a way of expressing when we're done with instances, we have a giant for loop that iterates over all of memory over and over and over to guess when we're done with things. What a mess! If your co-worker proposed this as a solution you'd probably slap them. This article proposes hardware accelerating that for loop. It's like a horse-drawn carriage accelerated by rockets. It's the fastest horse.

Post reply on HN