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

121–130 of 226 posts

Re: Go does not need a Java-style GC

#121

Post by tex0 »

sigmaml wrote: post #115
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.…

Several (about 10) years ago, I submitted essentially the same program. It was one of the fastest of all the implementations across all the languages. However, Isaac rejected it, saying it violated the conditions.

Debian Maintainers doing Debian Things.

Re: Go does not need a Java-style GC

#122

Post by jatone »

jeffbee wrote: post #12

There are very few falsifiable statements in this article but the extant ones are all demonstrably false, starting with this whopper: "This typically causes Java programs to have complete freezes of several hundred milliseconds where objects get moved around" Yeah, i mean, definitely not. The only language I regularly work with that has this property is, surprise, Go. The proof is in the tasting, as they say. Go look…

i've literally experienced worse pauses from java (sometimes surpassing 30s) GC due to allocation. granted it was pre the latest G1 GC. but they absolutely exist and many companies run on older versions of java.

and I doubt you see pauses in golang longer than 30ms. proof please.

Re: Go does not need a Java-style GC

#123

Post by pjmlp »

geodel wrote: post #95
kaba0 wrote: post #90

Earlier quoted context omitted.

Work on Valhalla is not funded as a joke though. They are working on that one.

Ofcourse. The point was about above snarky comment. Go devs took time to implement generics balancing with competing priorities. Java devs taking time to implement value types balancing their competing priorities.

From 1996 point of view it seemed it was a correct decision from the language landscape with Java coming from Smalltalk and Objective-C heritage, where 9 years later all languages had generics, except one created by the same authors of Go, and their newly born language.

Also there have been extensions, and the work to fix it goes back to 2014, after escape analysis proving not being good enough, with IBM and Azul having their own extensions for value types.

Even Dart down the corridor got generics first, during the years they weren't needed for Go.

Re: Go does not need a Java-style GC

#125

Post by NBJack »

TideAd wrote: post #100
munificent wrote: post #30

Earlier quoted context omitted.

> Both are technically possible in Java, but I've never seen them used commonly (though in fairness I've never written performance critical Java.) I don't know about the Java world, but in C#—especially in games written in Unity—object pooling is very common.

Writing High Performance .NET Code ( https://www.writinghighperf.net/ ) has a chapter on this. In C#, time spent collecting depends on the number of still-living objects. That means you want objects you allocate to be short-lived (dead by the time GC happens) or to live forever (they go to the gen 2 heap and stay there). The book suggests object pooling when the lifetime of objects is between those two extremes, or w…

Unity aside, I believe it's useful in a lot of areas of gamedev.

Anecdotally, in a lower-level game engine I wrote at one point in C#, object pooling significantly reduced memory overhead (and IIRC increased framerates on complex scenes) when I scaled well past 1000 dynamic, moderately-lived entities. Particles, objects, projectiles, bad guys, etc. I believe can all benefit from pooling, assuming they aren't long-lived.

I do agree it can be error prone, but I'm convinced it's worth it for several places in gaming.

Re: Go does not need a Java-style GC

#126

Post by WatchDog »

sitkack wrote: post #106
gwbas1c wrote: post #103

Skimmed this and found that a lot of claims are inaccurate and don't have data... Then realized, ugh, it's another Medium post. One particular wrong claim: > In C#, for example, reference objects and value objects live entirely separate lives. Value objects are always passed by value. You cannot take the the address of a value object and pass that around. No, you need to copy the whole object every time. In C#, there…

In general when talking about quantitative subjects, we need to use quantitative measures. I think the author is nearly there, but in general, unless you have data to refute your claims, it should be ignored. I don't say this snarkely, but in a domain where we actually have hard quantitative measures, they should be used and required for argument.

Quantitative measures would be nice, but I would imagine that it's going to be really difficult to quantitatively compare go and java garbage collectors, without a billion other factors about the language/runtime getting in the way.

Re: Go does not need a Java-style GC

#127

Post by bullen »

pjmlp wrote: post #63
sam_bishop wrote: post #36

Earlier quoted context omitted.

I agree. The author seems to know quite a bit about Go and GCs, but doesn't seem to have much experience with Java. As a Java performance engineer, it sounds like he is comparing Go to how he thinks Java works based on what he's read about it.

Additionally he doesn't seem to know that much about C#, which also has advanced GC, while allowing for C++ like memory management, if needed.

It's odd how most people that haven't used a VM with GC are amazed by Go (no VM) and WASM (no GC) but still fail to understand that with a GC _AND_ VM you can code something that doesn't crash even if you make a big mistake!

And they haven't even bothered to try it out!

To use anything other than JavaSE/C# on the server you really need very good arguments!

Re: Go does not need a Java-style GC

#128

Post by Ericson2314 »

yakubin wrote: post #102
Ericson2314 wrote: post #33

This is mostly stupid. Being able to have many GCs is a good thing. The big reason for "value types" is controlling spacial locality in memory, not GCs being bad per-se. Also, they undersell the java/c# situation. C# has "ref, out, or in", but even without those, you can always make a reference wrapper that has the value type as a field. So "reference types suck because coppying" is nonsense garbage.

> The big reason for "value types" is controlling spacial locality in memory, not GCs being bad per-se. Spacial locality is one reason. Another very important reason is not generating unnecessary garbage. If you have a lot of microallocations, then your program is going to be slow regardless of you using manual memory management, RAII or a tracing GC. There is just a lot more stuff to do. With manual memory managemen…

> If you have a lot of microallocations, then your program is going to be slow regardless of you using manual memory management, RAII or a tracing GC.

No, that's no true. Tracing GC is mainly O(f(live stuff)), not O(f(dead stuff)), so there is basically no problem making lot's of garbage if you don't have any exotic latency requirements.

> Another reason is eliminating unnecessary pointer indirection, which helps make sure that instead of loading data with two MOVs from memory polluting the cache, you need only one.

Uh, that is locality, what I started with, no?

> I'm leaning towards a GC-based design that relies a lot on value types.

That sounds good.

Compacting GC makes locality less of a problem than one that would think with the old Java/Haskell style, but yes we in Haskell also want unboxed types (the name I prefer) to have more control.

In cases where if one traverses the parent they almost certainly traverse the child (e.g. from map nodes to their keys (not child maps nodes) they area good fit, as with long live objects.

----

The overall lesson here is that Haskell/Java programs can be surprising fast and not memory thrashing, but for reasons that are quite surprising. Two Haskell and Rust programs can feel similar in what they mean and how they are written, but then be fast for very, very different reasons.

Re: Go does not need a Java-style GC

#129

Post by vardump »

lmm wrote: post #113
marginalia_nu wrote: post #45

Earlier quoted context omitted.

This is a bit of a tangent, but you can get into situations where Java's memory-overhead becomes pretty untenable. I was in a situation of having to keep track of ~1 billion short strings of a median length of maybe 7 characters. In terms of just data, that should clock in at about 10 Gb; in practice it was closer to 24 Gb. I tried going with just byte[]-instances instead, which didn't help a lot. Using long byte[]-i…

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.

Playing a devil's advocate here: a use case might already be hitting the maximum per server RAM.

A factor of 2.4 might mean 2.4 times more hardware. You might need 240 servers instead of 100.

Re: Go does not need a Java-style GC

#130

Post by pjmlp »

bullen wrote: post #127
pjmlp wrote: post #63

Earlier quoted context omitted.

Additionally he doesn't seem to know that much about C#, which also has advanced GC, while allowing for C++ like memory management, if needed.

It's odd how most people that haven't used a VM with GC are amazed by Go (no VM) and WASM (no GC) but still fail to understand that with a GC _AND_ VM you can code something that doesn't crash even if you make a big mistake! And they haven't even bothered to try it out! To use anything other than JavaSE/C# on the server you really need very good arguments!

Or being amazed by Go's compile speed, when Turbo Pascal and Object Pascal compilers were already doing that in the 1980's, or finding WASM innovative when polyglot bytecodes with no GC also go back to the early 1980's, like Amsterdam Compiler Kit EM as one example among many.
Post reply on HN