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

241–250 of 460 posts

Re: For Better Computing, Liberate CPUs from Garbage Collection

#241

Post by renox »

arcticbull wrote: post #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…

Maybe, but you forgot something: memory fragmentation, if this HW solution enable a "bup the pointer" allocation and also allow "real time" deallocation (I don't know I cannot access the paper), the result could produce better latency than "normal" manual memory management and better resource usage than "allocate everything at the beginning" than "real time" software use.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#242

Post by MrEldritch »

jerf wrote: post #236
StreamBright wrote: post #220

Earlier quoted context omitted.

It is weird, I do not feel restricted when I write non-GC code. Btw. you still need to pay attention with GCd languages no to leak references that cannot be GCd. Java has this sort of problems. Rust made it easy and simple to deal with memory in a non-malloc level while not having GC. Erlang on the other hand has a VM that makes GC much faster than in other languages. I can live with that because if you do it right i…

"I can live with that because if you do it right it does not impact end user latency." The vast majority of GC use does not impact end user latency. Thinking otherwise is either the availability heuristic at work, or you work in AAA videogames or another ultra-high-real-time-performance industry and don't realize you're not in the center of programming work, you're on an extreme. (A perfectly valid and sizeable extre…

"Downvote as disagreement" is such a pervasive pattern that I Find myself doing it automatically even when I know that's not what downvote is "supposed" to be for. I suspect it's because I'm more likely to view posts that I disagree with as being poorly thought-out.

This even extends to platforms where downvoting is not a thing - witness 4chan's struggles with "sage is not a downvote" ("sage" being a function which allowed you to reply to a thread without bumping it to the top and extending its lifespan - again, intended to mark a thread as low qualit) until they finally gave up and made saging invisible.

Given how thoroughly inescapable downvoting-to-disagree seems, I wonder if it might not be better to just declare defeat, allow downvotes and upvotes to mean nothing beyond a signal of protest or agreement, and have a separate "this comment is low quality / this comment is high quality" buttons.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#243

Post by alexhutcheson »

lioeters wrote: post #212
daemin wrote: post #170

One talking point I'd like to ask is: For small short lived scripts and applications, do we even need to free any memory these days? For example you write a script which takes several seconds to execute, moves files, computes stuff with strings, etc. Should we really invest time and effort in the script interpreter to free the memory, where instead we can just exit normally and let the OS handle the clean up. I would…

> For small short lived scripts and applications, do we even need to free any memory these days? ..we can just exit normally and let the OS handle the clean up. That makes me think: why couldn't larger programs be composed of many such small, short-lived scripts/processes that give up all allocated memory upon exit? I suppose there could be accumulated overhead for starting many such processes, and also the issue of…

That’s essentially what happens if you use region-based allocation (aka arena allocation): https://en.wikipedia.org/wiki/Region-based_memory_management

Re: For Better Computing, Liberate CPUs from Garbage Collection

#244

Post by reitzensteinm »

jandrewrogers wrote: post #234
reitzensteinm wrote: post #92

Earlier quoted context omitted.

In my opinion, shared memory mutability is the actual bad idea that's going to eventually die. It's not just error prone, it doesn't scale; try mutating the same cache line from two threads on an Intel desktop chip and see how that goes. Let alone across mesh buses, chiplets, dual sockets or (God forbid) the network. Garbage collection on immutable data is vastly easier; it's intrinsically non blocking, concurrent an…

In high-performance systems, software architectures have actually been moving toward non-shared mutability. Shared immutability tends to waste a performance-limiting resource (memory bandwidth).

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?

Re: For Better Computing, Liberate CPUs from Garbage Collection

#245

Post by [deleted] »

tomp wrote: post #210
geocar wrote: post #113

Earlier quoted context omitted.

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

This comment is just bad and misinformed all over. (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. (2) therefore, if you want reference counting, you have to either also have GC (for cycles), or program carefully to avoid creating cycles (whi…

[deleted]

Re: For Better Computing, Liberate CPUs from Garbage Collection

#246

Post by fjeremic »

kev009 wrote: post #44
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…

IBM POWER, Z, and Oracle SPARC silicon have instructions designed explicitly for GC and other common managed runtime tasks.

Indeed, OpenJ9's Pause-less GC is implemented using IBM z14 guarded load instructions and is able to outperform software by 10x in pause times and 3.4x in throughput for a given SLA [1].

[1] https://blog.openj9.org/2019/03/25/concurrent-scavenge-garba...

Re: For Better Computing, Liberate CPUs from Garbage Collection

#247

Post by CoolGuySteve »

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

A Hummer isn’t any more O(n) than a Prius in terms of fuel used per n miles but that constant will still kill you.

In practice, no one has ever demonstrated a garbage collected language that was more efficient than Rust/C/C++ other than in very specific cases.

https://thenewstack.io/which-programming-languages-use-the-l...

Re: For Better Computing, Liberate CPUs from Garbage Collection

#248

Post by Symmetry »

flukus wrote: post #38
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.

That's more a measure of indirection than of garbage collection.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#249

Post by CoolGuySteve »

xfer wrote: post #202
CoolGuySteve wrote: post #137

Earlier quoted context omitted.

Not sure why you’re getting downvoted when you’re the only response with actual data whereas the other responses are defending clearly less efficient practices with gobbledegook about O(1) memory algorithms and whatnot. I think most of it is coming from overly defensive users of GC languages . Sometime the world you want is not the world that exists.

> Specifically, they used 10 problems from the Computer Language Benchmarks Game Yeah some "actual data" right there.

If you have a better Rosetta Stone of computer languages I’d like to see it.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#250

Post by norswap »

arcticbull wrote: post #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…

Ridiculous.

The problem is not that you don't know when/where the lifetime will end — that can usually be characterized by a terse "English" description. The problem is that this lifetime is dynamic in nature.

The end of the lifetime of an object may coincide with some user input, for instance.

At this point, either you go back to manual management, with the potential for errors (and for what it's worth, I think manual management is fine in many cases) ... or .... or what, exactly?

Even Rust doesn't solve that problem at all. If your objects can survive outside of a "linear" execution, which is the case in interactive or multi-threaded programs, you're falling back on reference counting — garbage collection.

No one has ever devised a scheme that lets you specify very dynamic lifetimes AND statically checks that no leak can occur.

I'd stake a lot on that being impossible in general, and the best we can hope for being an AI that searches a way to insert the manual memory management calls (mostly, "free" and a minimal set of reference counts) assorted with a proof that this change will not cause any leaks or invalid accesses. We're a long way off that yet.

Post reply on HN