7 ms·

While the web is one place where GCs have been well proven and a non-problem, are there actually any cases at all with Go where the GC became a problem? It seem

by personZ 12y ago

While the web is one place where GCs have been well proven and a non-problem, are there actually any cases at all with Go where the GC became a problem? It seems like this GC advocacy is based upon a checkmark more than a reality. My experience has been that Go has very lightweight GC. The compiler intelligently turns a significant number of allocations into stack allocations (the same allocations would be heap allocations in .NET and Java, by comparison). It, by design, minimizes the amount of work that the GC needs to do, and in most real projects it just becomes a complete non-issue.

pcwalton 12y ago
> It seems like this GC advocacy is based upon a checkmark more than a reality. There are many domains in which GC is a deal-breaker, simply because you lose the fine-grained control over memory that you require: for example, games, embedded systems, kernels, and browser engines. (Go does not give you control over memory in the same way that C++, for example, does; consider map elements or closure upvars.) > The compiler intelligently turns a significant number of allocations into stack allocations (the same allocations would be heap allocations in .NET and Java, by comparison). No, .NET and Java do escape analysis as well. The difference is that the JVM and CLR have generational garbage collectors with a copying nursery, so heap allocations are essentially as cheap as stack allocations: just a pointer bump. In the JVM (in contrast to Go) escape analysis is mainly used for eliding locks; allocation is so cheap that promoting heap allocations to stack allocations barely matters.
- personZ 12y ago
  There are many domains in which GC is a deal-breaker Sure. That encompasses a very small set of code. 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. 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?), but it's interesting that you did exactly what I said -- it's just a checkmark. "GC baaaaaaad". Having developed a number of solutions with Go, and been involved in the solutions of others, interestingly the GC has never -- literally never -- been an issue with the platform. It has never, once, come up as a weakness with the language. Now I'm not using Go to make a real-time nuclear power plant controller, nor would I ever use Rust for that. No, .NET and Java do escape analysis as well. .NET does not do escape analysis: Every reference allocation starts as a generation 0 heap allocation, and every collection is just as complex as any GC collection. Java mostly performs it for, as you mention, lock eliding. so heap allocations are essentially as cheap as stack allocations: just a pointer bump When comparing stack versus GC heap, the allocation is irrelevant. It's the clean-up that is the difference: The fundamental mechanism of how GC works guarantees it cannot possibly even come remotely close to approaching the speed of stack freeing.
  - pcwalton 12y ago
    > 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.
    - fulafel 12y ago
      But still some of the most popular game platforms use GC, like Unity (C#) and iOS.
      - Ygg2 12y ago
        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.
        eridius 12y ago

by personZ 12y ago

pcwalton 12y ago

> It seems like this GC advocacy is based upon a checkmark more than a reality. There are many domains in which GC is a deal-breaker, simply because you lose the fine-grained control over memory that you require: for example, games, embedded systems, kernels, and browser engines. (Go does not give you control over memory in the same way that C++, for example, does; consider map elements or closure upvars.) > The compiler intelligently turns a significant number of allocations into stack allocations (the same allocations would be heap allocations in .NET and Java, by comparison). No, .NET and Java do escape analysis as well. The difference is that the JVM and CLR have generational garbage collectors with a copying nursery, so heap allocations are essentially as cheap as stack allocations: just a pointer bump. In the JVM (in contrast to Go) escape analysis is mainly used for eliding locks; allocation is so cheap that promoting heap allocations to stack allocations barely matters.

personZ 12y ago
There are many domains in which GC is a deal-breaker Sure. That encompasses a very small set of code. 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. 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?), but it's interesting that you did exactly what I said -- it's just a checkmark. "GC baaaaaaad". Having developed a number of solutions with Go, and been involved in the solutions of others, interestingly the GC has never -- literally never -- been an issue with the platform. It has never, once, come up as a weakness with the language. Now I'm not using Go to make a real-time nuclear power plant controller, nor would I ever use Rust for that. No, .NET and Java do escape analysis as well. .NET does not do escape analysis: Every reference allocation starts as a generation 0 heap allocation, and every collection is just as complex as any GC collection. Java mostly performs it for, as you mention, lock eliding. so heap allocations are essentially as cheap as stack allocations: just a pointer bump When comparing stack versus GC heap, the allocation is irrelevant. It's the clean-up that is the difference: The fundamental mechanism of how GC works guarantees it cannot possibly even come remotely close to approaching the speed of stack freeing.
- pcwalton 12y ago
  > 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.
  - fulafel 12y ago
    But still some of the most popular game platforms use GC, like Unity (C#) and iOS.
    - Ygg2 12y ago
      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.
      - eridius 12y ago