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

61–70 of 460 posts

Re: For Better Computing, Liberate CPUs from Garbage Collection

#61

Post by dimatura »

Scramblejams wrote: post #39
CoolGuySteve wrote: post #14

Earlier quoted context omitted.

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

I'd be surprised if gmail.com wasn't one of the worst performers on this hypothetical list.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#62

Post by banachtarski »

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

I'd be willing to wager you use plenty of software, codecs, games, and more that would not function nearly half as well without carefully managed memory.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#63

Post by Jweb_Guru »

legulere wrote: post #57
exabrial wrote: post #12

Earlier quoted context omitted.

So... Rust, basically

There’s actually a nice article about improving performance in rust with a bump allocator, which is conceptually similar to garbage collection: https://hacks.mozilla.org/2019/03/fast-bump-allocated-virtua...

It's only conceptually similar to the "bump allocation in the nursery" part of garbage collection, IMO, as it skips the whole tracing part that makes RC, GC, and even RAII substantially less efficient than stack allocation. When people talk about GC having great performance compared to manual memory management they are very often only considering objects that die before the first major collection.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#64

Post by tjoff »

chmod775 wrote: post #60
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 is already slower than having a GC in most practical applications, not to mention that having no circular references may make the code where you need 'em either slower or means you'll have to write a workaround, which is often also overhead and makes things more complicated.

The benefit of not using GC is improved understanding of the code and a better architecture. These things will also lead to better performance.

GC was a mistake. The main reason it is still used outside scripting languages is the notion that non-GC languages need to be low level. Which in practice is kind of true just because we haven't had any real competition in that area.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#65

Post by vlovich123 »

kllrnohj wrote: post #50
Eric_WVGG wrote: post #16

Earlier quoted context omitted.

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

It's not at all zero CPU overhead, not even close. retain & release are thread-safe, meaning atomic ref count. Very comparable in cost to std::shared_ptr or Rust's Arc . Both of which also automatically insert the calls to inc & dec ref counts. It's cool that you don't need to bother with specifying the type as being std::shared_ptr or Arc , but it's not particularly novel, either. It's "just" syntax sugar (or lack o…

Almost but not quite. Clang has very special rules around ARC that allow it to perform additional optimizations that would otherwise be illegal [1].

[1] https://clang.llvm.org/docs/AutomaticReferenceCounting.html#...

Re: For Better Computing, Liberate CPUs from Garbage Collection

#66

Post by hasahmed »

tjoff wrote: post #64
chmod775 wrote: post #60

Earlier quoted context omitted.

Reference counting is already slower than having a GC in most practical applications, not to mention that having no circular references may make the code where you need 'em either slower or means you'll have to write a workaround, which is often also overhead and makes things more complicated.

The benefit of not using GC is improved understanding of the code and a better architecture. These things will also lead to better performance. GC was a mistake. The main reason it is still used outside scripting languages is the notion that non-GC languages need to be low level. Which in practice is kind of true just because we haven't had any real competition in that area.

Gc was a mistake? On what possible authority can you make such a claim?

Re: For Better Computing, Liberate CPUs from Garbage Collection

#67

Post by ddingus »

fooker wrote: post #52
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 had a mentor who worked at Intel labs when this was happening. The reason this died was because someone invented a gc algorithm which consistently outperformed this, leading Intel to drop their hardware gc plans.

Could that not be hardware implemented / augmented?

Re: For Better Computing, Liberate CPUs from Garbage Collection

#68

Post by [deleted] »

ddingus wrote: post #67
fooker wrote: post #52

Earlier quoted context omitted.

I had a mentor who worked at Intel labs when this was happening. The reason this died was because someone invented a gc algorithm which consistently outperformed this, leading Intel to drop their hardware gc plans.

Could that not be hardware implemented / augmented?

[deleted]

Re: For Better Computing, Liberate CPUs from Garbage Collection

#69

Post by fooker »

ddingus wrote: post #67
fooker wrote: post #52

Earlier quoted context omitted.

I had a mentor who worked at Intel labs when this was happening. The reason this died was because someone invented a gc algorithm which consistently outperformed this, leading Intel to drop their hardware gc plans.

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?

Re: For Better Computing, Liberate CPUs from Garbage Collection

#70

Post by gdwatson »

p_l wrote: post #36
_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…

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