5 ms·

Yeah. I find it a haughty article because he's not acknowledging the elephant in the room, which is that GC is not a solved problem despite all the whiz-bang te

by jblow 10y ago

Yeah. I find it a haughty article because he's not acknowledging the elephant in the room, which is that GC is not a solved problem despite all the whiz-bang techniques ... and that the Go people aren't being dishonest or ignorant of these techniques, but rather, judging those techniques not to be so useful for the class of programs they care about.

Locke1689 10y ago
The following statement from the article addresses this: As Go is a relatively ordinary imperative language with value types, its memory access patterns are probably comparable to C# where the generational hypothesis certainly holds and thus .NET uses a generational collector. I think that's reasonable. I would say it is on the Go developers to point out why they think Go would have seriously different performance characteristics from similar C# network applications using Task-based asynchrony (similar to goroutine + channel based asynchrony in Go).
- Merovius 10y ago
  I don't think this is an actual claim made by go developers. Their arguments for choosing the algorithm they did was (at least as far as I remember, feel free to point me to a source) a) go for implementation simplicity, readability and clarity first then b) once you figure out where it needs improvement, do that. They didn't choose mark-and-sweep because they thought other algorithms are worse, go has special needs or anything else. At least this would be the first time I've heard about it. The same goes, from what I've seen, for most of the arrogance ascribed to them (in this article and elsewhere); it usually hinges on making up or misrepresenting things they've allegedly said.
  - Locke1689 10y ago
    I think the only point being made by the article is that their focus seems to be on pause times above all else.
    - Merovius 10y ago
      a) I wasn't replying to the article, but to a particular comment about it. b) I disagree with that summary of the article. I believe it's first paragraph should be an adequate indication of what it's point is, that's how you usually write articles, and it's distinctively not making that point. And lastly, c) I also don't believe that this statement, if it were the point, is at all true. At best it's hyperbole, but even on the surface, of the list of 15 design criteria for a GC mentioned in the article, at least 7 are explicitly taken into account and considered an optimization goal for the go GC (not all on equal footing and some in a different way than the author might prefer, but claiming they were ignored is just false). I can definitely say that for pause times, pause distribution, compaction, concurrency, scaling, tuning and portability.
      - davecb 10y ago
        I keep seeing papers with the lede paragraph and sometimes the conclusions written in a different voice that the rest of the paper. I suspect "men of good faith but limited understanding" are contributing to the editing (;-))
- geodel 10y ago
  Here is from Techempower benchmark C# vs Go[1]. To me C# is not looking very impressive. For memory I do not have a better reference than[2]. Here again C# seems to use 2-10 times more memory than Go. 1. https://www.techempower.com/benchmarks/#section=data-r13&hw=cl&test=json&l=4ft5h9 https://www.techempower.com/benchmarks/#section=data-r13&hw=... 2. http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=csharpcore http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
  - Locke1689 10y ago
    These tests don't seem to specifically test GC, so it doesn't seem to be a good comparison. Comparing Go and C# as languages don't seem to be the goal of this exercise, either. Instead, the article was making the point that the garbage characteristics have generational components. This is true of C#, so I would expect it to be true of Go as well. If that is the case, whatever Go's current performance numbers are, they could probably be made better by a generational GC.
    - geodel 10y ago
      Isn't GC in some part defines application performance characteristics? Why would pure GC benchmarks be useful if an application with better GC performs worse than application with worse GC?
      - Locke1689 10y ago
        You don't seem to understand how performance benchmarking works. Unless you seek to optimize a single application, a benchmark is meant to be broadly representative of a wide category of applications whose performance is dominated by the component being benchmarked. For instance, an application which allocates no memory is a poor benchmark of the memory allocator, and it is also a poor general representative of program performance if most programs' performance is dominated by memory management.
sambe 10y ago
Most of the article is about GC being a set trade-offs. I don't think that's an elephant here. The official promotional wording around Go is being criticised for not acknowledging the drawbacks of the approach.
- geodel 10y ago
  Strange argument in the article. As I do not see Official Java materials are telling us about Java's massive memory bloat in typical data structures as this: https://www.cs.virginia.edu/kim/publicity/pldi09tutorials/memory-efficient-java-tutorial.pdf https://www.cs.virginia.edu/kim/publicity/pldi09tutorials/me...
  - mike_hearn 10y ago
    I suppose it depends what you consider official Java materials, but the presentations about Project Valhalla and the future of the JVM (by the official Java team) do discuss that sort of thing extensively. However, this discussion is about GC, not generics specialisation. Java has a guidebook explaining the tradeoffs and how to configure your collector: https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/toc.html https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gc...
    - geodel 10y ago
      In this case official would be like Oracle release new version of Java with statements in release news like "We continue to have significant memory bloat in standard Java Collection data structures. We added a higher overhead and slower G1 GC which will be default going forward. In Java 9 we also hope to break many user programs which depends on Sun internal APIs" Now this sounds ridiculous because announcement of major product/feature are suppose to highlight advantages just like Go's new GC announcement blog. Tradeoffs are discussed in mailing lists and bug trackers.
- _ak 10y ago
  Oh, they have acknowledged drawbacks from the very beginning, they just never deemed them nearly as important as the author of this blog post.

by jblow 10y ago

Locke1689 10y ago

The following statement from the article addresses this: As Go is a relatively ordinary imperative language with value types, its memory access patterns are probably comparable to C# where the generational hypothesis certainly holds and thus .NET uses a generational collector. I think that's reasonable. I would say it is on the Go developers to point out why they think Go would have seriously different performance characteristics from similar C# network applications using Task-based asynchrony (similar to goroutine + channel based asynchrony in Go).

Merovius 10y ago
I don't think this is an actual claim made by go developers. Their arguments for choosing the algorithm they did was (at least as far as I remember, feel free to point me to a source) a) go for implementation simplicity, readability and clarity first then b) once you figure out where it needs improvement, do that. They didn't choose mark-and-sweep because they thought other algorithms are worse, go has special needs or anything else. At least this would be the first time I've heard about it. The same goes, from what I've seen, for most of the arrogance ascribed to them (in this article and elsewhere); it usually hinges on making up or misrepresenting things they've allegedly said.
- Locke1689 10y ago
  I think the only point being made by the article is that their focus seems to be on pause times above all else.
  - Merovius 10y ago
    a) I wasn't replying to the article, but to a particular comment about it. b) I disagree with that summary of the article. I believe it's first paragraph should be an adequate indication of what it's point is, that's how you usually write articles, and it's distinctively not making that point. And lastly, c) I also don't believe that this statement, if it were the point, is at all true. At best it's hyperbole, but even on the surface, of the list of 15 design criteria for a GC mentioned in the article, at least 7 are explicitly taken into account and considered an optimization goal for the go GC (not all on equal footing and some in a different way than the author might prefer, but claiming they were ignored is just false). I can definitely say that for pause times, pause distribution, compaction, concurrency, scaling, tuning and portability.
    - davecb 10y ago
      I keep seeing papers with the lede paragraph and sometimes the conclusions written in a different voice that the rest of the paper. I suspect "men of good faith but limited understanding" are contributing to the editing (;-))
geodel 10y ago
Here is from Techempower benchmark C# vs Go[1]. To me C# is not looking very impressive. For memory I do not have a better reference than[2]. Here again C# seems to use 2-10 times more memory than Go. 1. https://www.techempower.com/benchmarks/#section=data-r13&hw=cl&test=json&l=4ft5h9 https://www.techempower.com/benchmarks/#section=data-r13&hw=... 2. http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=csharpcore http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
- Locke1689 10y ago
  These tests don't seem to specifically test GC, so it doesn't seem to be a good comparison. Comparing Go and C# as languages don't seem to be the goal of this exercise, either. Instead, the article was making the point that the garbage characteristics have generational components. This is true of C#, so I would expect it to be true of Go as well. If that is the case, whatever Go's current performance numbers are, they could probably be made better by a generational GC.
  - geodel 10y ago
    Isn't GC in some part defines application performance characteristics? Why would pure GC benchmarks be useful if an application with better GC performs worse than application with worse GC?
    - Locke1689 10y ago
      You don't seem to understand how performance benchmarking works. Unless you seek to optimize a single application, a benchmark is meant to be broadly representative of a wide category of applications whose performance is dominated by the component being benchmarked. For instance, an application which allocates no memory is a poor benchmark of the memory allocator, and it is also a poor general representative of program performance if most programs' performance is dominated by memory management.

sambe 10y ago

Most of the article is about GC being a set trade-offs. I don't think that's an elephant here. The official promotional wording around Go is being criticised for not acknowledging the drawbacks of the approach.

geodel 10y ago
Strange argument in the article. As I do not see Official Java materials are telling us about Java's massive memory bloat in typical data structures as this: https://www.cs.virginia.edu/kim/publicity/pldi09tutorials/memory-efficient-java-tutorial.pdf https://www.cs.virginia.edu/kim/publicity/pldi09tutorials/me...
- mike_hearn 10y ago
  I suppose it depends what you consider official Java materials, but the presentations about Project Valhalla and the future of the JVM (by the official Java team) do discuss that sort of thing extensively. However, this discussion is about GC, not generics specialisation. Java has a guidebook explaining the tradeoffs and how to configure your collector: https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/toc.html https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gc...
  - geodel 10y ago
    In this case official would be like Oracle release new version of Java with statements in release news like "We continue to have significant memory bloat in standard Java Collection data structures. We added a higher overhead and slower G1 GC which will be default going forward. In Java 9 we also hope to break many user programs which depends on Sun internal APIs" Now this sounds ridiculous because announcement of major product/feature are suppose to highlight advantages just like Go's new GC announcement blog. Tradeoffs are discussed in mailing lists and bug trackers.
_ak 10y ago
Oh, they have acknowledged drawbacks from the very beginning, they just never deemed them nearly as important as the author of this blog post.