Hacker News Reader

Comment by skybrian | Hacker News Reader

Mike Hearn criticizes the Go implementers for making misleading claims about building a "garbage collector for the next decade", but I don't see them making claims that they are solving garbage collection for any language other than Go?

There's an underlying assumption (both in the article and in comments here) that the results of garbage collection research are generally applicable across languages. It's not obvious that this is true. While you can certainly get a lot of ideas from previous research, memory allocation and access patterns can differ significantly between languages (due to different language features and common idioms), and what seemed like a win for one language might not actually apply for a different one.

View on HN

I didn't get that at all. I read two main criticisms, both of which aren't explicit in the Go implementors' claims but are strongly implied by the language and style:

1) they've solved for Go 2) this is comparatively better (almost mockingly so) than other VMs because of the advanced nature of their implemtation

The post suggest that 1) is overreaching and misleading: GC is always about trade-offs. It suggests that 2) is also false, because their implementation is not particularly advanced and just follows from the trade-offs they made in 1).

It does rather seem like over-marketing what they've done, regardless of whether it useful in many Go use-cases.

Article has lot of guess work about Go's GC. However in comments section some shortcomings of his claims are pointed out including one by Go GC implementer, he added more guesses about his assumptions. This may all be very valid but there are no numbers for that in this piece.

There's not "a lot" of guess work. It's quite clear to read that it is mostly about GC trade-offs and technologies in the general sense, not especially critical of Go's implementation. There are very few absolute claims of good/bad, if any. A poster on a Go forum admits that the latency improvement cost 20% CPU usage, and the article doesn't call this necessarily bad.

You're making a very uncharitable interpretation, and unjustifyably calling them guesses only makes it more so.

It is lot of guess because there are no memory usage numbers or throughput numbers to get general sense of how Go GC is worse for applications.

Even in the thread about 20% CPU usage increase mentions that Go implementer considers this much higher than expected and is likely a bug. But author make it sound in article as Go guys are calling it reasonable tradeoff for low latency.

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.

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

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.

I think the only point being made by the article is that their focus seems to be on pause times above all else.

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.

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 (;-))

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

2. http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

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.

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?

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.

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.

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

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

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.

Oh, they have acknowledged drawbacks from the very beginning, they just never deemed them nearly as important as the author of this blog post.

Go is a pretty ordinary language in most respects: it's not all that different from other imperative languages. It's not like Haskell where the entire evaluation model, compilation approach and set of basic algorithms changes.

Also, I should note that I've never heard of a language specific GC algorithm. The closest I can think of would be conservative collection which is a variant of non-generational non-compacting mark/sweep for the case where you don't have pointer maps. Usually that means C++. In a conservative GC any memory contents that looks like it might be a pointer is treated as if it is. It turns out that integers that look like pointers but aren't are pretty rare, so whilst this type of GC can actually leak memory (!), in practice it is still very useful.

The algorithms don't need to be different for the results to be different. A lot of GC language research is based on Java, for example, where it's harder to avoid creating garbage, and therefore generational GC is a large win. It's not clear if that result applies to languages where typical code creates less garbage.

Early versions of Go used the Boehm garbage collector which worked okay for a 64 bit architecture but not as well for 32 bits since false pointers are more likely - another example of how a smallish language change can have big effects.

I'm not a GC researcher but I've had enough trouble getting reliable benchmark results to be skeptical of drawing any general conclusions from cross-language benchmarks. Performance tends to depend on implementation details.

Reply on news.ycombinator.com