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

71–80 of 132 posts

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

#71

Post by mseepgood »

felixgallo wrote: post #54
arcticbull wrote: post #52

Earlier quoted context omitted.

The thing with ARC is that you mostly only have to use the weak keyword for delegates (and in certain data structures, etc); it becomes totally second nature and intuitive, you only have to think about it once in a blue moon. It's actually just as productive. And worst case with ARC (while admittedly unbounded) is you forget a weak keyword and you leak some memory. The problem is that you're asserting it's significan…

ARC is pretty great, but it's still very possible to leak memory, and you can actually cause longer pauses when references go out of scope than well-tuned modern GCs can. So there's pluses and minuses, as in all things.

The "A" in ARC is a bit of an euphemism. You basically move the coding of your memory management into the type signatures, which don't write themselves automatically either. The amout of thoughts you have to make during development is the same.

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

#72

Post by pcwalton »

rurban wrote: post #69
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 just don't really understand why people continue to work on garbage collection. > ... but I think it's time to walk away from GC Well, look at the arguments. GC advantages: * less memory (unless you use a semi-space GC) * faster * can handle cyclic refs (graphs, not only trees and linked lists) * trivial to use, less programmer errors What you got wrong: significant memory and CPU overhead. If you compare the mem…

Most of the complexity of a good malloc (jemalloc/tcmalloc) is going to be in its thread-local caches and in its placement heuristics, both of which are also necessary for a good GC (for the tenured generation, in the latter case). Accounting necessary for the tenured generation is also comparable to accounting for a malloc implementation. Fragmentation also isn't much of an issue anymore with modern allocation schemes. When you add in the complexity and overhead of tri-color marking and write/read barriers, the overhead often isn't in GC's favor, compared to a well-tuned program that uses the stack where possible and a good malloc implementation for long-lived objects only.

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

#73

Post by nulltype »

arcticbull wrote: post #55
nulltype wrote: post #44

Earlier quoted context omitted.

Do you think ARC is a viable alternative? I'm uncertain how the performance compares to GC for most applications.

Totally! Or RAII, but that requires much more re-thinking of how your program is put together to do it well. Performance depends on a lot of things. For instance, if you have 'unlimited' memory, GC will be way faster because most likely the collector will never run, and allocations are extremely fast since you can just hack off a slice and hand it out. But in that world, relying on something like a finalizer is impos…

I am convinced that GC can cause issues with object lifetimes and pauses (at least without a pauseless GC).

Like sanjoy points out though: https://news.ycombinator.com/item?id=9856234 RC could involve atomic increment/decrement. I haven't seen any macro benchmarks about ARC performance vs manual memory management and/or GC.

I've seen anecdotes like http://stackoverflow.com/questions/12527286/are-there-any-co... or microbenchmarks (from the same page) but nothing at a larger scale.

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

#74

Post by crafn »

rurban wrote: post #69
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 just don't really understand why people continue to work on garbage collection. > ... but I think it's time to walk away from GC Well, look at the arguments. GC advantages: * less memory (unless you use a semi-space GC) * faster * can handle cyclic refs (graphs, not only trees and linked lists) * trivial to use, less programmer errors What you got wrong: significant memory and CPU overhead. If you compare the mem…

From gamedev perspective:

Every time I've prototyped something on a GC'd language (java, actionscript, javascript, ..) I soon find myself optimizing memory allocations and not making the game because the GC causes too much overhead and/or causes too long pauses and therefore makes the game feel miserable. It doesn't matter if there are some theoretical GC models which have Nowadays I prefer to use C not because I like malloc, but because it makes handling different memory allocation schemes trivial (unlike C++). Furthermore, in this semi-real-time case the performance of malloc is irrelevant because when you want to be fast and low-latency, you pre-allocate everything and use lightweight functions to further distribute memory from those blocks.

In conclusion, I've found that manual memory management lets me focus more on the task I have in hand while GC don't.

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

#76

Post by pron »

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…

> non-deterministic pauses

Modern GC can provide deterministic pauses (see Azul's pauselss GC, and various real-time Java GCs).

> I'm curious, is there something I'm missing?

I think so. Consider modern servers with plenty of cores and plenty of RAM. The only way to make efficient use of that RAM is to store as much program data in it as possible, and the only way to provide really efficient access to all that data is without forcing sharding, and the only way to do that is with GCs.

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

#77

Post by pron »

pcwalton wrote: post #42
kasey_junk wrote: post #36

Earlier quoted context omitted.

> The only true benefit I can think of is reducing heap fragmentation Unless something has changed recently in the literature, concurrent data structures, especially lock free ones are super difficult to get right without garbage collection. Further, lock free structures are one of the most straight forward paths to large non-contended concurrent in memory data sets becoming the norm rather than the exception. I'm am…

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?

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

#78

Post by masklinn »

dilap wrote: post #59
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.

Yup, you're right. I just meant that to have a program composed of many processes that can be stopped & collected independently, those processes have to communicate 'functionally', i.e., without shared mutable memory. (So this isn't a viable approach for languages like Go where all the goroutines share memory.)

> So this isn't a viable approach for languages like Go where all the goroutines share memory.

Something Go has been criticised for since it was originally unveiled back in 2009.

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

#79

Post by chaotic-good »

vezzy-fnord wrote: post #50
dilap wrote: post #48

Earlier quoted context omitted.

This works for erlang 'cuz it's functional. Not gunna work for something like Go. Something like ARC would work for Go though (right?), & I agree it's a really nice approach, and I don't really get why it's not more widely used.

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.

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

#80

Post by [deleted] »

michel-slm wrote: post #65
bitmapbrother wrote: post #58

Earlier quoted context omitted.

Yes, Java developers still hand code their getters and setters. What era are you from, again? Also, those "brain dead" Java developers still write code that smoke your dog slow Python code regardless of how meticulously you hand crafted your code. So yeah, I would be bitter too.

I'd say the need to use IDE-generated code implies there are missing language features. That's why Kotlin looks really exciting.

[deleted]
Post reply on HN