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

391–400 of 460 posts

Re: For Better Computing, Liberate CPUs from Garbage Collection

#391

Post by klodolph »

simen wrote: post #164

They're comparing to an in-order CPU. Given that most CPUs are out-of-order (at least of the non-embedded variety, and GC is less used in such applications anyway), it would be better and more intellectually honest to actually compare to a typical CPU that performs GC. They kind of address this in the paper but only in a short aside: "Note that previous research [1] showed that out-of-order CPUs, while moderately fas…

I think an interesting comparison here is GPU cores, where a core will get blocked on a memory access and it will switch out its state for another. It looks like this is the approach here, which is a bit more aggressive than ordinary out-of-order approach. It's less ordered.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#392

Post by klodolph »

k__ wrote: post #390

Hasn't Rust basically solved that problem? But yeah, legacy stuff could profit from this.

No, because it is in general intractable to figure out object lifetime at compile time. Rust has just solved the problem for more cases than, say, C++ does, or perhaps just with more rigor.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#393

Post by klodolph »

fwip wrote: post #284
DenisM wrote: post #264

Objective-C ARC (automatic reference counting) solved the problem neatly for my iOS apps. Is there some overhead? Maybe, but it's neatly spread out through the entire application life time, so there is rarely[1] a UI-freezing stutter associated with GC. To reduce the overhead I turned off thread-safety and simply never access the same objects from more than one thread (object has to be "handed off" first if it comes…

ARC is just garbage collection that doesn't always work (circular references).

True! And ARC in Rust suffers from the same problem (note that while ARC in Rust and ARC in Swift are the same thing, the "A" happens to stand for different words in each case).

Re: For Better Computing, Liberate CPUs from Garbage Collection

#394

Post by abalone »

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…

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

What about Swift? Automatic Reference Counting avoids the typical problems of mark and sweep garbage collection. Has its own trade offs of course but the benefits include more consistent latency, efficient memory usage and cache friendliness. Like Rust it uses a smarter compiler (LLVM).

Really interesting stuff happing on the server side of Swift right now. It’s early days but I’d keep a close eye on it. Long tail latency is a big big server problem.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#395

Post by favorited »

kllrnohj wrote: post #319
vlovich123 wrote: post #65

Earlier quoted context omitted.

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

That just lets it release earlier, not retain/release less often. ARC can't do anything magic here vs. something like really careful use of std::move & const references.

ARC optimizations do let it retain/release less often. For example, instead of a callee adding the return value to an autorelease pool then having the caller immediately retain the returned value, the autorelease+retain pair can be elided entirely.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#396

Post by DenisM »

kllrnohj wrote: post #322
DenisM wrote: post #257

Earlier quoted context omitted.

>retain & release are thread-safe That's optional tho, and I never use it that way.

Do you have a link to what you're referring to? Apple's docs clearly state retain/release are thread safe. Are you using your own implementation of retain & release or something?

For sure. It's entirely stock:

  @property (strong, nonatomic) UIView* unselectedTabsView;
"nonatomic" means avoid synchronization code. This code is not thread safe for that reason, but I never do cross-thread access anyways.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#397

Post by favorited »

seandougall wrote: post #37
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 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.

It's a little better than that, because the overhead of ObjC method dispatch is avoided. There are no calls to -retain or -release (if the receiver hasn't overridden those methods), it's just a C function call to objc_release et al. No objc_msgSend involved.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#398

Post by DenisM »

NobodyNada wrote: post #377
DenisM wrote: post #264

Objective-C ARC (automatic reference counting) solved the problem neatly for my iOS apps. Is there some overhead? Maybe, but it's neatly spread out through the entire application life time, so there is rarely[1] a UI-freezing stutter associated with GC. To reduce the overhead I turned off thread-safety and simply never access the same objects from more than one thread (object has to be "handed off" first if it comes…

> I do make an occasional slip, which is where I need to rely on Instruments, and I do wish I had better tools than that, something more automatic that would catch me in the act. Xcode's debug toolbar has a "debug memory graph" button that will visualize the object graph for your entire program. Reference cycles are automatically detected and listed in the issue navigator. https://developer.apple.com/library/archive/…

I did not know that! Thank you.

Re: For Better Computing, Liberate CPUs from Garbage Collection

#399

Post by Shikadi »

kazinator wrote: post #354
simias wrote: post #267

Earlier quoted context omitted.

I don't see your point. Of course sometimes the lifetime of an object is not tied to code scope but actually to something dynamic. Let's say for instance when you close a tab in your browser you expect the resources to be freed (ignoring caching to simplify the argument). Clearly somewhere in your code you have to explicitly handle tab closing and break the references to allow the GC to do its job. Why not free the r…

> Why not free the resources here while you're at it? Because you do not have an exclusive reference to all of them; we could be freeing something that is still in use somewhere. So why not reference-count? Because reference counting is slow, and must be meticulously maintained (here, languages help with constructs like smart pointers), and doesn't handle cycles in the object structure. > I find RAII a lot easier to…

RAII has nothing to do with reference counting, it stands for resource acquisition is initialization. In C++ that means the lifetime of a resource is tied to the creation and destruction of an object. Often when people talk about RAII and C++ they are also referring to destructors being called when an object goes out of scope, so if an object that contains an object containing some allocated resource goes out of scope, the resource is released as the destructor path is called.

If an object with a smart pointer goes out of scope, then of course there's the overhead of the smart pointer, but the previous comment wasn't referring to that situation

Re: For Better Computing, Liberate CPUs from Garbage Collection

#400

Post by favorited »

DenisM wrote: post #396
kllrnohj wrote: post #322

Earlier quoted context omitted.

Do you have a link to what you're referring to? Apple's docs clearly state retain/release are thread safe. Are you using your own implementation of retain & release or something?

For sure. It's entirely stock: @property (strong, nonatomic) UIView* unselectedTabsView; "nonatomic" means avoid synchronization code. This code is not thread safe for that reason, but I never do cross-thread access anyways.

That means reads of/writes to the property are nonatomic. Certain (not all) ARC refcount functions are required to be atomic no matter what.
Post reply on HN