Hacker News Reader

Comment by littlestymaar | Hacker News Reader

This is a good illustration that Go isn't as simple as its proponents like to praise[1]. When you face complex engineering challenges, you need tools with a certain amount of complexity.

[1] especially when comparing to Java when it comes to GC customization.

View on HN

Funny what different people get from these things.

I was most impressed that he managed to get very close to perfect scalability by twiddling the one knob on offer.

Java GC customisation is an art. This analysis was entirely mechanical. If the author wasn't just lucky i.e. that this is sufficient for a large number of workload profiles, then that's very good news.

The problem of software knobs is that the one that helps you is almost never there, and you usually can't get similar functionality from mixing the ones that are there.

That said, there are exceptions. I don't think GC is something simple enough to be an exception, but those exist.

The main problem is that it isn't a very good knob for this use case, as "ratio of freshly allocated data to live data remaining" is only incidental to the goal of the person writing the program. Therefore you'd expect to have to retune it due to unrelated changes, like if you allocated a big chunk of static memory to hold results.

I expect Go's current behaviour is right for memory-intensive programs, where "limit the wasted memory as a ratio of the actual working set" is a reasonable high-level goal. For a CPU intensive program you might have preferred a "max x% CPU overhead" knob, but just a minimum memory size would work, as this is mostly an artifact of the very small memory usage of benchmark program.

Java's G1 has "max pause delay" as their preferred knob, but Go has stuck that knob on low since around version 1.6, which is a good choice for what is essentially a language for network services.

Interesting! IMO it showed that garbage collection isn't some silver bullet (of course), but that with a kick to a quite coarse control it's possible to achieve very good performance indeed.

I am surprised that the difference is so great - and that the GC seems to think it's a good idea to keep collecting 4 MB of data at a time - but I guess the Go team have been tuning heavily for interactive performance i.e. small pauses.

I guess in a situation like this you'd prefer something more like 'server' GC - maybe wait until you've allocated 1 GB then run through and collect everything you can.

In games, I wonder if you'd like to turn the GC off during frame rendering then collect while presenting the frame/waiting for VSync.

For soft real-time audio - synthesizing a few samples at a time - what would you do? OpenAL wants you to queue up thousands or tens of thousands of samples, but that sucks if you need to react very quickly.

If anyone has any ideas, please say. I'd love to do soft real-time audio in a thread even in e.g. C#. (Edit: Maybe JIT some code that doesn't allocate? Or even have a separate interpreter written in C that has a constant-ish upper performance bound & no malloc.)

I don't know. That seemed like a fairly simple exploration of the problem and an easy library function to solve it. Would it be much simpler in any other language?

Simpler would be "just work like I expect".

Doesn't work with GCs.

As another comment in this thread explained, GCs have CPU and Memory tradeoffs and you can easily make a GC that would work excellent in the OP benchmark but would suffer severely under other workloads.

I think the expectation the Go lot have been working towards is the expectation that individual pauses are very short. Contrast to a Java server GC, aiming towards overall efficiency. (Tell me if I'm wrong, I'm no expert.)

Yes, Go optimizes for low latency and Java for high throughput.

Depends on the Java GC being used.

Granted, but the stock GC is optimized for throughput.

The stock GC on OpenJDK, there are other JVMs to choose from.

What about the use cases where what you expect is not what I expect? GC is, as a sibling comment says, about compromises around memory safety.

As another commented posted elsewhere, GC is all about tradeoffs, and for a govern set of GC tradeoffs there will always be pathological cases. Another GC might work out of the box for this workload, but perform very badly for a workload at which Go's GC excels. As others have already mentioned, the fact that he was so easily able to tune the GC is a testament to Go's simplicity.

There are lots of good criticisms of Go to be had, but it's runtime is pretty remarkable, in my opinion.

It's a simple problem with a simple fix, from a very simple benchmark - but it's already reaching the limits of how much tuning Go offers. If even such a basic benchmark needed one GC tuning knob, that seems suggestive that maybe a larger and more complex program really would need all the knobs that Java offers, the ones that Go claims are unnecessary.

Or maybe not - maybe that one knob really can solve all the problems. But I really was surprised that anyone would ever need to actively configure a GC for such a simple use case, so I've learnt something at least.

I think most pathological cases can be reduced to similarly simple examples. I'm sure these exist for other GCs as well.

Yes, the take-away here is not that Go is particularly bad, but that GCs are problematic. Notably, GC != automatic memory management.

> Notably, GC != automatic memory management.

Actually, GC == automatic memory management, just not automatic performant memory management

That's not a reasonable conclusion to draw. You would need to preallocate to maximize performance regardless of GC in this case, and in other cases, the performance and determinism gaps between GC languages and non-GC languages is almost entirely due to tertiary factors. For example, GC languages are more likely to prioritize friendliness over raw performance in other areas--language features, compiler optimizations, standard library design, etc. Non-GC languages really only need to appeal to the high-performance and high-determinism crowds.

"more complex program really would need all the knobs that Java offers, the ones that Go claims are unnecessary." - but that is really a move in the wrong direction... it's meta programming with Env variables, allocation sizes, command lines, and JDK versions. Sure, Go will probably eventually have all that, to support more tuning, but at that point, ti feels the war for "simple, predictable, low-overhead GC" has been lost, yet again.

> Sure, Go will probably eventually have all that, to support more tuning, but at that point, ti feels the war for "simple, predictable, low-overhead GC" has been lost, yet again.

Well, it seems we don't have a simple GC that performs well in all cases, and really why would we expect to? So choosing simplicity means leaving performance on the table, at least for now, and while there are languages that do that (Python) it doesn't seem like a good fit for Go.

> "it seems we don't have a simple GC that performs well in all cases" Exactly, and after 20+ years, it may be that it's not possible to have such a GC.

If you need the machinery Java has, you're already fucked. To a first approximation, no one knows how to tune a JVM. Whole books have been written multiple times on the subject, and everywhere I've been that used large-scale Java applications, tuning failures are still at or near the top of the list of most common production issues.

We don't appear to be much better off than we were with C. I guess the server melting is probably preferable to an exploitable smashed stack, but prevention of both issues appears to be to hire geniuses who don't make mistakes while doing enormously mistake-prone work.

> We don't appear to be much better off than we were with C. I guess the server melting is probably preferable to an exploitable smashed stack, but prevention of both issues appears to be to hire geniuses who don't make mistakes while doing enormously mistake-prone work.

"Everyone gets correctness, you need geniuses to get maximum performance" is a huge improvement over the reverse.

Except I see tons of outages caused by things like VM and application server tuning. Software that isn't working isn't correct or performing well.

Not running at all, while not ideal, is a lot better than silent data corruption.

Having worked with Java GC it's just a nightmare to tune. I prefer languages that have almost no options for GC tuning.

On Java 8+, you can use G1 GC which has very few knobs. On the other hand, CMS GC has a lot of knobs you can tune depending on your workload. JVM (Hotspot in this case) believes in flexibility over a one-size fits all. YMMV.

In other words, there are actually knobs that have you choose the GC, and then choose settings within the GC.

Tuning is a hassle, but when the alternative is rewriting my important code over and over until I hit the right tradeoff between fast and readable, I'll take it.

Reply on news.ycombinator.com