Hacker News Reader

Hacker News

Comment by Thaxll | Hacker News Reader

Parent Full thread

Thaxll

I'm not sure what qualified for an advanced GC but Go is the leading GC with Java and C# so ...

https://blog.golang.org/ismmkeynote

View on HN

If you are interested on that topic these two posts are a must read:

- https://blog.plan99.net/modern-garbage-collection-911ef4f8bd...

- https://blog.plan99.net/modern-garbage-collection-part-2-1c8...

The main takeaway is that saying that Go is the leading GC is just a (somewhat dishonest) PR move, and Go's team made a pretty good GC given there project constraints, even of it is not at the state of the art at the moment.

I never said that it was state of the art or "the" leading, my point is Go GC is currently a good all-arround GC, and I've read that article, I think the author is bias against Go and currently there is no article even proving that the 2 new Java GC are faster than the Go one. ( or even faster than G1 )

You know when you end your article with "Overall, it looks to me like the Java guys are winning the low latency game." when none of those GC are actually production ready ... Go GC low latency has been stable and used for some time now.

Out of the box Go GC is very good and doesn't need all the memory or the tunning from G1. ( I spend years tunning GC for Java application it's a nightmare )

This doesn't actually refute anything in Mike Hearn's posts.

And isn't Shenandoah included by default in OpenJDK 12+?

In non-Oracle builds, yes, along with ZGC.

Oracle chooses to build with only ZGC enabled.

This is must read only for GC theory enthusiasts. Java GC is advanced and better performing but that is adjusted by Java program's heavy garbage generation. So overall gain by advanced GC is little if any in Java.

Java is getting value types. It will be interesting to see how performance improves once it does.

Do we know that Java programs generate more garbage than Go programs? This is often stated, but I've never seen any actual measurements of it. Remember that Java HotSpot has escape analysis just as Go does.

I would not be surprised if the difference in amount of "garbage"—as measured in either bytes or object count/mark time—were a lot smaller than people think.

The page you link to does not compare Go's GC to Java's or C#'s

I don't know if it's a consequence of their GC, but go is significantly slower than Java or C#.

You're mistaken, Go is on part with both languages, usually faster.

My understanding is that it has lower latency but also lower throughput.

Although most of the benchmarks I've seen are at lease 2 years old. It would be nice to see some updated benchmarks that also compare against the Shenandoah and ZGC garbage collectors for the JVM.

Java is getting two new low latency collectors. golang is stuck with a GC that favors latency over throughput, making it not suited for high throughput processing.

By stuck you mean Go devs made the sensible decision to have only one, zero configuration, ultra low latency, Garbage Collector that suits Go's common use cases instead of trying to be jack of all trades having many GC's each with their pletora of knobs to adjust.

It means that golang is relegated to simple server side tools, and not suited for a broader range of programs like the JVM is.

Yep. Go has a focus.

That's how you get from zero to heavy usage in companies like Uber, Twitter, Cloudflare, BBC, Basecamp, Canonical etc... in less than a decade.

You'd be surprised at the extent hype influences decision making when it comes to choosing which language to use (even in companies you mentioned), at a significant cost down the line. I'll just say I know people at one of the companies you mentioned, and the amount of friction and cost due to them using golang is quite remarkable.

No offense but I'd rather trust the engineers of all these companies combined over an anecdote on the internet.

Not to mention technology change always generate friction. You just can't please everyone.

Assuming those engineers were making sound decisions and not pimping up the CVs at employers' expense.

Exactly what happened at the company I'm talking about.

The same kind of companies that were all hyped up on Ruby on Rails, and then moved to Java when performance mattered.

Hype driven development is a thing.

Given a large enough sample size, there will always be companies which ditched technology X for Y.

Unless technology X is irrelevantant.

This is not a sensible decision, it is an idealistic one, and Go will backtrack on it if it lives long enough. People have different use cases, and they will be more than willing to turn a few knobs if it saves them millions of dollars.

For real world, non-trivial programs, golang lags behind Java/JVM.

Well, on the benchmarckgame (internet reference for microbenchmarks), you're mostly right, go is faster than Java but slower than c#.

But real-world applications performance needs fine tuned libraries that scales and this is where Java destroy both go and c#.

Take the benchmarkgames site with a big grain of salt. They're running on an old processor, and that biases results a lot. For example, someone submitted a patch that significantly sped up a Java benchmark by using `Math.fma()`. However, because the processor the benchmarks site is running on is old and does not support the underlying instruction that `Math.fma()` uses, it ended up way slower.

I ran several benchmarks locally on a CPU that's a few years old where the benchmarks site shows golang being faster than Java, without changing the code, and I got the opposite result (Java was faster). Especially the longer the program ran. For example, the site shows that golang is faster in the spectral norm benchmark. Running it locally with a larger input parameter:

golang:

    time ./test 30000
    1.274224153
           18.81 real        70.19 user         0.38 sys

Java:

    time java spectralnorm1 30000
    1.274224153
           16.18 real       105.95 user         0.45 sys

Or with the nbody benchmark:

golang:

    time ./nbody 60000000
    -0.169075164
    -0.169012474
            6.09 real         6.04 user         0.02 sys

Java:

    time java nbody 60000000
    -0.169075164
    -0.169012474
            6.04 real         5.94 user         0.06 sys

FastHTTP destroys Netty, isn't Netty a fined tuned library?

I'm not sure - I don't use either go or Java much these days - but some cursory googling implies that light-4j/undertow core is to fasthttp as netty is to net/http?

https://github.com/networknt/light-4j/

FastHTTP is a low allocation HTTP library in golang. Netty is a low level event driven framework for writing networking applications and protocols. It's used in many libraries and frameworks which build on top of it like Vertx, Spring webflux, and more recently Undertow.

Things should get more interesting once Java gets green threads, which would make it easier to implement high performance concurrent servers without needing to drop down to event driven code unless for specific needs. That, and with value types, should push the performance bar forward.

Apples to oranges comparison. Netty is a general purpose event driven networking library. FastHTTP is specialized to HTTP. Even given that, Vertx (which uses Netty) ranks above FastHTTP in the Techempower benchmarks, even though they have to be taken with a grain of salt.

Netty is not tuned. It handles large stream of small messages very inefficiently: too many synchronization per message, no automatic batching to avoid expensive write syscalls. At least it was so two years ago.

Reply on news.ycombinator.com