Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go does not need a Java-style GC

erik-engheim.medium.com

Post reply on HN
Print view View original

201–210 of 226 posts

Re: Go does not need a Java-style GC

#201

Post by marginalia_nu »

sitkack wrote: post #104
marginalia_nu wrote: post #61

Earlier quoted context omitted.

Huh, I didn't really have a problem solving the problem as it came up. Like many scaling problems, it wasn't a problem until it was. Then I fixed it. Now I have a solution that can deal with ten times as many strings as before. If I grow out of that one, I'll come up with a better design. I could have gotten 10 times as much hardware instead, but that would be an incredible waste of money compared to just spending a…

I have addressed similar problems using a typed array of contiguous memory and another array of lengths.

I did try exactly that, but the GC overhead was still prohibitively high for my use case, made because big arrays in practice are composed from shorter non-contiguous arrays to make garbage collection even remotely possible.

Re: Go does not need a Java-style GC

#202

Post by azth »

geodel wrote: post #197
azth wrote: post #181

Earlier quoted context omitted.

That's because Java is used to run huge systems (dare I say, "enterprise scale"), whereas golang, especially today with microservices" is not seen in such areas. However, we still see issues in golang like * https://blog.discord.com/why-discord-is-switching-from-go-to... * https://news.ycombinator.com/item?id=21670110

I hope it is joke. Endless Java GC problems with any large system (cassandra, hadoop, websphere and so on and on) despite decades of work from top major vendors like Oracle, SAP, IBM etc tells a different story. I have seen enough "Enterprise Scale" java systems which would die of Out of memory error before even "hello world" is served. Though "Java runs huge systems" type thing work for those who wouldn't know most…

Because that's the nature of those systems. If you wrote them in golang they'd almost surely run into similar issues.

Re: Go does not need a Java-style GC

#203

Post by tossaway32 »

azth wrote: post #183
tossaway32 wrote: post #86

Earlier quoted context omitted.

Look at the Go benchmark program: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Needs to be faster? Use a pool like the C benchmark programs, but super simple: just a slice, local to the goroutine. Trivially make the Go program 10x faster, 5 minutes of work, a few edits: type Tree struct { Left int Right int } func itemCheck(id int, pool []Tree) uint32 { tree := &pool[id] if tree.Left != -1 && tree.…

Now do the same in Java and it will be as fast, if not faster. The point is the benchmark is looking at GC performance. In large real world programs, it is not trivial to make such changes.

Do it. Show me that Java can avoid allocating/collecting the Tree objects. Go has no indirection for the Tree objects, in this example. The Trees are contiguous in memory.

Measure the performance.

I have no garbage collection performance problems in the various large Go projects I have worked on. But I am also a competent programmer, so "your mileage may vary".

Re: Go does not need a Java-style GC

#204

Post by titzer »

jatone wrote: post #178
ohgodplsno wrote: post #176

Earlier quoted context omitted.

Random Go dev suddenly more of an expert than the literal best-in-class GC experts that have been working on G1GC, ZGC, Shenandoah, Parallel, ConcMarkSweep and others. GCs are a matter of tradeoffs. Always optimizing for latency is Go's solution, but there are reasons for everything. It's the very reason why the JVM has so many knobs. Yes, it requires a PhD to know what to tune, but there are many parameters for the…

rolls eyes I've tuned java's GC for highly available and massive throughput systems. pretty familiar with the trade offs. java's problem isn't GC (in general) its problem is memory layout and the fact it can't avoid generating a metric shit ton of garbage. G1GC was a good improvement and I stopped paying attention at that point because I no longer had to deal with its problems (left the ecosystem). I'm not asserting…

> it can't avoid generating a metric shit ton of garbage.

IMHO this is an often-overlooked aspect of Java and I get flak for pointing out that Java programs are often full of defensive copying because the Java style encourages it. The JDK is very trashy and highly biased against reusing objects or doing anything in-place without creating garbage. You can't, for example, parse an integer out of the middle of a string.

15 years ago when I wrote a lot more Java, I could get away with avoiding JDK libraries to write tight and small Java code (yeah, omg, mutable non-private fields). That was how I got my AVR microcontroller emulator to beat its C competitors. Nowadays if you write that kind of code you get a beatdown.

JVMs work really hard to deal with trashy Java code. Generics make everything worse, too; more hidden casts and adapter methods, etc.

Re: Go does not need a Java-style GC

#206

Post by azth »

tossaway32 wrote: post #203
azth wrote: post #183

Earlier quoted context omitted.

Now do the same in Java and it will be as fast, if not faster. The point is the benchmark is looking at GC performance. In large real world programs, it is not trivial to make such changes.

Do it. Show me that Java can avoid allocating/collecting the Tree objects. Go has no indirection for the Tree objects, in this example. The Trees are contiguous in memory. Measure the performance. I have no garbage collection performance problems in the various large Go projects I have worked on. But I am also a competent programmer, so "your mileage may vary".

For the time being, until Valhalla is finalized, Java can emulate this approach simply by using an int array.

After making the modifications, on my local machine, Java ran as low as ~820ms, compared to golang's ~932ms.

golang's GC is no silver bullet as we see here:

* https://blog.discord.com/why-discord-is-switching-from-go-to...

* https://news.ycombinator.com/item?id=21670110

Re: Go does not need a Java-style GC

#207

Post by lmm »

marginalia_nu wrote: post #161
lmm wrote: post #113

Earlier quoted context omitted.

A factor of 2.4 is extremely unlikely to be what makes the difference between a program being viable and not. You have to be in an extremely fine-tuned situation for that to make the difference, and unless your usage level is unusually static it's probably only going to make the difference for a few weeks or months.

So for some context, I'm running a search engine on consumer hardware. Coaxing power out of limited hardware is sort of my bread and butter. How many of these strings I can keep in memory limits how many documents I can index. Doubling that number is quite significant. This number is orthogonal to how many searches I can serve, that is already a solved problem (through similar craftiness). Multiple searches per secon…

The time of someone who can do that kind of crafty tuning is almost certainly worth more than the hardware. If nothing else, I'd think having you do a week or two of consultancy and buy more hardware with the proceeds would be more efficient in terms of getting things done. (I appreciate that nonprofits have a lot of particular constraints that mean that that's probably not a practical way forward).

Re: Go does not need a Java-style GC

#208

Post by Jweb_Guru »

sigmaml wrote: post #149
lifthrasiir wrote: post #139

Earlier quoted context omitted.

Of course. The problem description [1] specifically calls for the following: When possible, use default GC; otherwise use per node allocation or use a library memory pool. As a practical matter, the myriad ways to tune GC will not be accepted. As a practical matter, the myriad ways to custom allocate memory will not be accepted. Please don't implement your own custom "arena" or "memory pool" or "free list" - they wil…

My submission did violate the conditions. I was just recollecting what happened; it is not a complaint. I am at variance with those conditions, though. I refer to the benchmarks suite itself, broadly. When programs dip into GMP, PCRE, etc. , we are no longer comparing the speeds of the different language implementations per se . Now, they are mixed with FFI speeds of those implementations, the choices of the foreign…

The point of this benchmark (that you're deliberately ignoring) is actually to have at least one program that realistically shows how bad a language's GC is. Go performs terribly because its GC makes lousy tradeoffs, which is the only reason you're annoyed at its requirements. It's actually probably the best benchmark in the whole set on that site.

Re: Go does not need a Java-style GC

#209

Post by Jweb_Guru »

jayd16 wrote: post #109

Did Go ever fix that problem where short term high memory usage can cause large empty heaps because of the lack of compaction? I remember a rash of articles about this phenomena a while back. This article seems to think its not an issue so I'm wondering when it was fixed.

No, it was never fixed and probably never will be, because it would make Go perform worse in the latency-sensitive microbenchmarks it wants to do well in.

Re: Go does not need a Java-style GC

#210

Post by native_samples »

jatone wrote: post #177
native_samples wrote: post #163

Earlier quoted context omitted.

Only in some kinds of apps, like web servers where all the heavy lifting is being done by the database anyway. Consider a compiler. It's not infinitely scalable to multiple cores. It may not even be multi-threaded at all. It also doesn't care about pause times - for that you want Parallel GC.

depends on the compiler and language. golang seems to counter point your position quite handedly. having one of the fastest compile times and being highly concurrent. if your application is so simple it doesn't use concurrency then 99% of the time you can completely remove the need for GC by preallocating slabs.

The Go compiler is fast because it doesn't do very much, not because Go's GC is good for throughput oriented jobs.

Go has repeatedly tied itself in knots over the years because they have a goal of not making the compiler slower, yet, the GC needs of the compiler are diametrically opposed to the needs of the HTTP servers Go is normally used for.

https://go.dev/blog/ismmkeynote

"As you can see if you have ROC on and not a lot of sharing, things actually scale quite nicely. If you don’t have ROC on it wasn’t nearly as good ... At that point there was a lot of concern about our compiler and we could not slow down our compilers. Unfortunately the compilers were exactly the programs that ROC did not do well at. We were seeing 30, 40, 50% and more slowdowns and that was unacceptable. Go is proud of how fast its compiler is."

Post reply on HN