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

11–20 of 460 posts

Re: For Better Computing, Liberate CPUs from Garbage Collection

#11

Post by Wowfunhappy »

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

> These things exist to make programming easier but are then duplicated across thousands of servers.

I think about this kind of thing, but more in regard to Electron et al.

Garbage collection, by contrast, seems like a more worthwhile trade-off, because there's a great argument to be made that garbage collection isn't just easier for programmers but safer for users, in terms of security. Since it mostly removes an major class of vulnerabilities.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#12

Post by exabrial »

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

So... Rust, basically

Re: For Better Computing, Liberate CPUs from Garbage Collection

#14

Post by CoolGuySteve »

exabrial wrote: post #12
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,…

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.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#15

Post by hnaccy »

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?

Re: For Better Computing, Liberate CPUs from Garbage Collection

#16

Post by Eric_WVGG »

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

Re: For Better Computing, Liberate CPUs from Garbage Collection

#17

Post by ZitchDog »

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

Re: For Better Computing, Liberate CPUs from Garbage Collection

#18

Post by flukus »

ZitchDog wrote: post #17
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 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.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#19

Post by jhallenworld »

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 main processor stalls if it's full (if it's getting ahead of the co-processor).

The co-processor then maintains a reference graph any way it likes in its own memory. It determines when memory can be freed using any of the classic algorithms, and sends messages back to the main processor to indicate which memory regions can be freed.

This has some nice characteristics: the co-processor does not necessarily disturb the cache of the main processor (it can have its own memory). Garbage collection is transparent as long as the co-processor can process mutations at a faster rate than the main processor can produce them. The queue handles cases where the mutation rate is temporarily faster than this.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#20

Post by SmooL »

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.

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