Comment by pcwalton | Hacker News Reader

Comment by pcwalton | Hacker News Reader

Parent Full thread

> Indeed, it's interesting that you mentioned games given that most game engines now are a relatively small non-GC engine, layered atop with GC technologies.

Ask major game developers whether they would be OK with pervasive GC. (We have, and the answer is near unanimous.) You simply need control over each and every allocation.

As a browser developer, I would certainly not be OK with pervasive GC in a browser engine, which are millions of lines of code at this point. The performance competition is just too brutal.

> You are a rather heavy advocate of Rust, and for whatever bizarre reason the Rust crew has decided that they need to aggressively attack Go (I'd recommend you maybe focus on delivering a production product first?)

I'm not attacking Go; I think it's a fine language. I'm taking issue with the idea that GC doesn't matter. The fact that this is happening in the context of Go is a side effect of the unfortunate fact that half of the comments on any Rust thread are about Go, and I would have the same arguments in the context of Java (since I don't think Java and Go are fundamentally that different in their reliance on GC anyhow).

> The fundamental mechanism of how GC works guarantees it cannot possibly even come remotely close to approaching the speed of stack freeing.

Sure, but minor collections are really, really fast. In a proper generational copying garbage collector I doubt this matters; the JVM looked at escape analysis for promoting heap allocations to stack allocations and found it didn't help very much.

> As a browser developer, I would certainly not be OK with pervasive GC in a browser engine, which are millions of lines of code at this point. The performance competition is just too brutal.

FWIW, when Xcode (on OS X) switched from GC to ARC (automated reference counting), it got a massive performance boost.

But still some of the most popular game platforms use GC, like Unity (C#) and iOS.

Yeah, but Unity is very Indie oriented, no?

I haven't seen an AAA or AA title that used Unity, they mostly make their own, use Ogre, Crytek or Unreal.

Unreal is defacto industry standard.

iOS, has ARC IIRC, not sure it has true GC like Java or C#. ARC is a super primitive GC.

ARC is not GC. It's automated reference counting. It's not a "super primitive GC" because it's a completely different approach to memory management. Notably, it has predictable behavior/performance characteristics, is suitable for realtime work (inasmuch any object-oriented approach with allocation/deallocation is; basically, it doesn't pause like GC does), and is fast. The downside is it is vulnerable to reference cycles.

The question was about precise control over memory allocations. Arc hides it like other forms of GC. You can tread carefully to avoid pauses with GC, but it is more fragile than explicitly manual mem management. Ref counting does pause, you get cascading deallocations. More deterministic than other GC though.

Neither ARC nor GC hide memory allocations. They automate the process of deallocating memory. And ARC does not hide that either. Values get released when they go out of scope, and they get deallocated when the last reference disappears. It's a very explicit process, the only "hiding" is the fact that there is no `[foo release]` line anymore. But it's no more hidden than C++ destructors are.

> Ref counting does pause, you get cascading deallocations.

That's not pausing. That's it doing work, upon request (i.e. when the object is released). If you have a single object that roots a massive object graph, and you release that single object, yes, it will have to destruct that entire object graph. But that's not the fault of ARC in the slightest, and would happen just the same with manual memory management.

> More deterministic than other GC though.

It's not GC, so what do you mean by "other GC"?

---

ARC has the exact same performance characteristics as manual memory management, except it's all automated so you can't screw it up (e.g. over-releasing or under-retaining). But it's subject to optimizations too (such as skipping the autorelease pool), which actually makes it faster than MRR in a lot of cases.

Top 5 Google hits for reference counting agree with me and say rc is a form of GC.

GC pauses are because of work in other forms of GC too.

As for explicitness... no. that's not explicit in my book.

Yeah, the error is on my part. Meant to say 'ARC is like a super primitive GC'. It gives a very small amount of automatism over manually freeing memory, but must be done by hand.

It's a super primitive in a same way an abacus is a super primitive computer.

Yeah, no, you aren't helping your case at all. ARC is, again, not like a super primitive GC. And it most certainly is not "done by hand". That completely contradicts the "Automated" part of "Automated Reference Counting".

Yeah, no - is a very bad linguistic form. Try to avoid it. I speak from experience.

Also, it is like a super primitive GC, in that it's a much more primitive and much more performant automatic memory management system (like GC). It's just a different level of abstraction we're talking here.

It's no different than saying how is polygon is like a super primitive circle.

GC and ARC are two very different approaches to memory management. Neither is more "primitive" than the other. They have different characteristics, different goals, different strengths & weaknesses.

Guess I was wrong about 'like', it's 'is'. ARC is GC, what you call GC is a tracing GC. Any automated memory managment is garbage collection.

http://www.memorymanagement.org/glossary/g.html#glossary-g

iOS does not have GC. Obj-C GC never made the jump from OS X to iOS.

Various embedded languages could have GC (e.g. Lua has a GC), but the only GC that's shipped in iOS itself is in JavaScriptCore.

Reply on news.ycombinator.com