3 ms·
> The decision to use Go was deliberate, because we needed something that had lower latency than Java (where garbage collection pauses are an issue) and is more
by geodel 10y ago
> The decision to use Go was deliberate, because we needed something that had lower latency than Java (where garbage collection pauses are an issue) and is more productive for developers than C, while also handling tens of thousands of client connections. Go fits this space well.
This is interesting. There haven't been many instances yet where Go's memory/GC performance is compared directly and favorably to Java's performance.
- gshulegaard 10y agoI think the bigger thing is the deliberate design of go for parallel processing. I feel like the Go GC is still an issue, although getting better every day, but the benefits in regards to "handling tens of thousands of client connections" potentially make the GC easier to swallow than Java. But that's is just my outside looking in take on it.
- geodel 10y agoIf you check this link: http://benchmarksgame.alioth.debian.org/u64q/go.html http://benchmarksgame.alioth.debian.org/u64q/go.html Java uses about 2-10 times more memory most of time compare to Go. So I'd think Java's GC has to be at least 10 times better/sophisticated than Go's. Though I doubt if it is really 10 times better.
- gohrt 10y agohttps://blog.golang.org/concurrency-is-not-parallelism https://blog.golang.org/concurrency-is-not-parallelism
- gshulegaard 10y agoAs a Python programmer, I am intimately familiar with the distinction between concurrency (Coroutines) and Parallelism...and additionally the difference between multi-threaded and multi-processing within Parallelism. It was my understanding that Go's center around concurrency made parallelism also easier to approach than most languages: https://golang.org/doc/effective_go.html#parallel https://golang.org/doc/effective_go.html#parallel Although there are still additional challenges with parallel vs. simple concurrent programming.
- faizshah 10y agoIn this case I don't think it's the raw performance they are looking for but rather freedom from the unpredictable GC pauses. Although I think they should have explained why they didn't use Azul Zing for this, I realize it's expensive but this seems like the exact use case for it. Found some interesting discussion here about this: https://news.ycombinator.com/item?id=10149961 https://news.ycombinator.com/item?id=10149961
- geodel 10y agoZing needs heavily over provisioned machines like 64+ GB RAM to make those GC guarantees.
- faizshah 10y agoCan you provide a source? I haven't used Zing (only read about it) but my understanding is that it should work for low memory and high memory JVMs.
- geodel 10y agoI got a pdf link in a google search sometime back. That document mentions that. You should try searching.
- faizshah 10y agoI ask because the pdf you're probably referring to seems to imply the opposite. I only skimmed though but heres what I found that seems to imply the opposite: "An entire Java heap (large or small) can be marked consistently without falling behind and resorting to long garbage collection pauses because the C4 employs: • Single pass completion to avoid the possibility of applications changing references faster than the mark phase can revisit them • “Self-healing” traps that ensure a finite workload and avoid unnecessary overhead • Parallel marking threads to provide scalability that can support large applications and large dataset sizes" Maybe I'm looking at the wrong pdf can you provide a source for your claim? It's something useful to know if it's true.