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

Go GC: Solving the Latency Problem in Go 1.5

sourcegraph.com

Post reply on HN
Print view View original

111–120 of 132 posts

Re: Go GC: Solving the Latency Problem in Go 1.5

#111

Post by MrBuddyCasino »

osi wrote: post #110
MrBuddyCasino wrote: post #96

Earlier quoted context omitted.

Also, Azul Systems solved that issue - the proprietary C4 GC has no pauses, and the heap can be huge, like hundreds of GB. If that tech would become common place, maybe this discussion would be obsolete. But I think C4 requires kernel support, and the first attempt to get a patch accepted didn't go well.

To clarify, Azul's Zing does have pauses, but they optimized the crap out of them (the pauses are more time-to-safepoint rather than GC pauses). GC time wrt application stopped time is constant regardless of heap size. (I'm an Azul customer and Zing user)

Thanks, the marketing implies its pause-less. What are typical application stop times?

Re: Go GC: Solving the Latency Problem in Go 1.5

#112

Post by endymi0n »

blub wrote: post #94
endymi0n wrote: post #67

Earlier quoted context omitted.

No, why should I? In Go I've finally found a language that's pragmatic, both fast to run and fast to think and write in. While evreyone's discussing its obvious shortcomings, I'm churning out working code faster than ever. Now somebody who isn't me is putting in big resources into making the language even better. Where's the reason to complain?

The reason to complain for the other commenters is that you're criticizing something you've never used, while being familiar with only one method of doing things. Your criticism is not legitimate.

Who said I've never dealt with malloc or ARC (which I think is ill-suited for concurrency)? I basically replied to the OC, giving some good reasons for developing better GC strategies for a language with great support, libraries and a vibrant ecosystem, rather than moving to the next shiny thing. We're developing a latency sensitive real time bidder and I'm more than happy we can do it in Go now, just like the rest of our APIs, thanks to Go 1.5

Re: Go GC: Solving the Latency Problem in Go 1.5

#113

Post by rayiner »

arcticbull wrote: post #32

I've worked with garbage collected languages (ruby, Java, Objective-C in the bad old days), automatic reference counting (Objective-C and Swift), in the Rust model and manual reference counting/ownership in C over about 15 years now. Having thought about this a lot, I just don't really understand why people continue to work on garbage collection. Non-deterministic lifecycle of objects/resources, non-deterministic pau…

GC is a lot faster throughput wise for programs that create a lot of short lived objects. ARC will call malloc and free for each object, which is actually fairly expensive. A good GC will bump a pointer for each object and do nothing for each one that dies before the next GC cycle. Java programs allocate objects at rates that the host malloc simply could not sustain in many cases.

Re: Go GC: Solving the Latency Problem in Go 1.5

#114

Post by vezzy-fnord »

chaotic-good wrote: post #79
vezzy-fnord wrote: post #50

Earlier quoted context omitted.

It works for Erlang because of its process model. I don't think it has anything to do with it being functional.

In erlang old data structures can't reference new data. This simplifies GC a lot.

Immutability is orthogonal to FP as a whole.

Re: Go GC: Solving the Latency Problem in Go 1.5

#115

Post by osi »

MrBuddyCasino wrote: post #111
osi wrote: post #110

Earlier quoted context omitted.

To clarify, Azul's Zing does have pauses, but they optimized the crap out of them (the pauses are more time-to-safepoint rather than GC pauses). GC time wrt application stopped time is constant regardless of heap size. (I'm an Azul customer and Zing user)

Thanks, the marketing implies its pause-less. What are typical application stop times?

My mean pauses are a few hundred micros. Standard deviation is slightly more (300-500 micros), with a max of a millisecond or two.

Re: Go GC: Solving the Latency Problem in Go 1.5

#117

Post by fauigerzigerk »

rurban wrote: post #106
fauigerzigerk wrote: post #95

Earlier quoted context omitted.

Can you point me to the source of your claim about memory overhead? The Go team specifically states their goals for the 1.5 garbage collector as follows: "Hardware provisioning should allow for in-memory heap sizes twice as large as reachable memory and 25% of CPU cycles". http://llvm.cc/t/go-1-4-garbage-collection-plan-and-roadmap-... As far as I know, that collector is not a copying collector. I also know that all…

They are still using a simple and slow GC, non-copying, tri-color M&S, but at least incremental. So they need to scan the complete heap, while a good copying collector (e.g. a two-finger Cheney with forwarding pointers) would only need to scan the stack and some roots. My GC needs ~4ms on normal heap sizes, the fastest M&S GC's need ~150ms. But I haven't found a good version besides the Azul one, which works fine thr…

>Memory overhead: A non-copying GC has none

Do you have any idea what could make the Go folks ask for "in-memory heap sizes twice as large as reachable memory"? This seems to be completely at odds with what you are saying.

Re: Go GC: Solving the Latency Problem in Go 1.5

#118

Post by rurban »

fauigerzigerk wrote: post #117
rurban wrote: post #106

Earlier quoted context omitted.

They are still using a simple and slow GC, non-copying, tri-color M&S, but at least incremental. So they need to scan the complete heap, while a good copying collector (e.g. a two-finger Cheney with forwarding pointers) would only need to scan the stack and some roots. My GC needs ~4ms on normal heap sizes, the fastest M&S GC's need ~150ms. But I haven't found a good version besides the Azul one, which works fine thr…

>Memory overhead: A non-copying GC has none Do you have any idea what could make the Go folks ask for "in-memory heap sizes twice as large as reachable memory"? This seems to be completely at odds with what you are saying.

Why? Reserving virtual memory has nothing to do with actual memory usage.

Re: Go GC: Solving the Latency Problem in Go 1.5

#119

Post by pcwalton »

pron wrote: post #77
pcwalton wrote: post #42

Earlier quoted context omitted.

They are easier with GC, yes. But hazard pointers work reasonably well as a substitute. (Note that you need generics for lock-free data structures to be ergonomic.)

... and I'll ask you the same question I always do: in that case, adding predictable, low latency arenas to GC languages is much easier than using hazard pointers (which are really a form of GC) to non-GC languages. Why should RC ever be the default?

> in that case, adding predictable, low latency arenas to GC languages is much easier than using hazard pointers (which are really a form of GC) to non-GC languages.

I disagree with that. I haven't seen "opt-out GC" work that well in practice. People use memory pools in GC'd environments to work around slow GCs, sure, but they're limited and have poor safety/ergonomics, as nobody wants to have to explicitly free data. They also don't really provide one of the greatest advantages of manual memory management, which is the ability to use stack allocation aggressively. (By "aggressively" I mean "in ways that an intraprocedural analysis with no knowledge of data lifetimes—i.e. an escape analysis—could not prove safe".)

Hazard pointers are a small feature, localized to exactly where you need them (concurrent data structures). Those who need concurrent data structures have to pay for the feature; those who don't don't have to. A pervasive GC, however, imposes its costs and benefits on the entire language ecosystem.

Re: Go GC: Solving the Latency Problem in Go 1.5

#120

Post by pcwalton »

pjmlp wrote: post #85
arcticbull wrote: post #32

I've worked with garbage collected languages (ruby, Java, Objective-C in the bad old days), automatic reference counting (Objective-C and Swift), in the Rust model and manual reference counting/ownership in C over about 15 years now. Having thought about this a lot, I just don't really understand why people continue to work on garbage collection. Non-deterministic lifecycle of objects/resources, non-deterministic pau…

> I'm curious, is there something I'm missing? Working in large teams with disparate skill levels and high attrition, e.g. typical corporate jobs. Manual memory management never works, because there is always someone that does the wrong thing that leads either to blow ups or security exploits, that take experts days to weeks to track down. ARC is one step up, but requires deep knowledge of the code, where to place we…

> Manual memory management never works, because there is always someone that does the wrong thing that leads either to blow ups or security exploits, that take experts days to weeks to track down.

This only applies to unsafe manual memory management. Not all manual memory management is unsafe.

> Lifecyle of resources is very deterministic in GC languages, provided one uses the proper language constructs, such as using/with/try/scope/defer or high order functions.

Only for objects that have lexically scoped lifetimes. It doesn't help with prompt reclamation of objects with dynamic lifetimes (e.g. a file that two threads are holding onto, which you want to close when both threads shut down).

Post reply on HN