Go GC: Solving the Latency Problem in Go 1.5 • Hacker News Board

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

#91

Post by Skinney » Thu, Jul 09, 2015, 9:04 AM UTC

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…

Two things you get wrong here:

1. Collection cannot happen at any time. It's not like the GC just decides to do a collection. It happens on allocation. If you don't allocate, you don't collect.

2. Most garbage collectors don't scan the entire heap. You don't scan dead objects. You could have the larges heap in the world, but if you, at collection time, only use 100mb worth of ram, you only ever scan 100mb. Copying collectors also gives you memory defragmentation for free, which ensures quick allocation times, something ARC cannot do.

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

#92

Post by Skinney » Thu, Jul 09, 2015, 9:09 AM UTC

eggnet wrote: post #63

nulltype wrote: post #14

Earlier quoted context omitted.

Ah, too bad. Do you know what sort of heap sizes you got those pauses at?

About half a gig resident memory.

So Go's GC spent 1ms per MB?

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

#93

Post by jules » Thu, Jul 09, 2015, 9:11 AM UTC

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…

Compared to GC the other options have several important disadvantages.

Rust style memory management:

- Additional complexity in the language and in your code

- You need unsafe blocks for code that does something interesting with pointers

- Can leak unreachable memory even in safe code

- Still has pauses due to deallocating large reference chains, or puts them on a deferred free list in which case you no longer have prompt deallocation

Refcounting with weak refs:

- Unsafe

- A little bit of extra work

- Can easily introduce memory leaks, especially with closures - Refcounts have overhead in time and memory

- High contention on the refcounts in multithreaded code, or can't share data among threads at all (or need hazard pointers or RCU)

- Still has pauses due to deallocating large reference chains, or puts them on a deferred free list in which case you no longer have prompt deallocation

Most code is actually fine with GC, and some code is significantly simpler with GC, such as lock free data structures.

Moreover some of the problems with GC are not fundamental, and can be fixed:

- Pause times can be much lower, e.g. realtime GC's and Azul GC

- The main problem with languages like Java is that they have pointers and heap allocation everywhere. If you used the same data in a refcounted language it would be horribly slow as well. In C# with support for value types this is a bit better but still not ideal.

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

#94

Post by blub » Thu, Jul 09, 2015, 9:18 AM UTC

endymi0n wrote: post #67

Negitivefrags wrote: post #53

Earlier quoted context omitted.

> the use case becomes obvious It's only obvious if you assume that writing code without a GC is harder or takes longer. Have you used a language that supports automatic memory management but without a GC for any length of time? It's actually very nice.

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.

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

#95

Post by fauigerzigerk » Thu, Jul 09, 2015, 9:21 AM UTC

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…

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 JDK GCs have significant memory overhead (not sure about the Azul one).

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

#96

Post by MrBuddyCasino » Thu, Jul 09, 2015, 9:29 AM UTC

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…

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.

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

#97

Post by blub » Thu, Jul 09, 2015, 9:34 AM UTC

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…

YES, if you take all the pluses form multiple types of GC, it's gonna look awesome. In reality you have one GC; if you're lucky maybe your toolchain supports multiple and you can swap them.

So discussion about "GC" in the abstract are useless, discussion about the GC in Go 1.5 are absolutely worth it, and then you can find real-world stories about GC failures.

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

#98

Post by perlgeek » Thu, Jul 09, 2015, 9:35 AM UTC

alexbock wrote: post #4

> ...there has been a virtuous cycle between software and hardware development. CPU hardware improves, which enables faster software to be written, which in turn... This is the exact opposite of the experience I've had with (most) software. A new CPU with a higher clock speed makes existing software faster, but most new software written for the new CPU will burn all of the extra CPU cycles on more layers of abstracti…

> This is the exact opposite of the experience I've had with (most) software. A new CPU with a higher clock speed makes existing software faster, but most new software written for the new CPU will burn all of the extra CPU cycles on more layers of abstraction or poorly written code until it runs at the same speed that old code ran on the old CPU.

You could also see it in a positive light: the higher processor speed allows more abstraction layers, which makes development easier and faster (if done right, of course).

ORMs and web frameworks make it much, much faster to develop a CRUD web app then the alternative of writing everything yourself. Of course, you pay with performance, but you gain in time to delivery, which in turn translates to more features in the same time.

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

#99

Post by hit8run » Thu, Jul 09, 2015, 9:48 AM UTC

"Go programs will get a little bit slower in exchange for ensuring lower GC latencies."

How much slower are Go1.5 programs compared to their Go1.4 version? Is this relevant for web apps?

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

#100

Post by lmm » Thu, Jul 09, 2015, 9:49 AM UTC

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.

I agree that IDE-generated code is a bad sign (though honestly a lot of use of getters/setters is brain-dead - they make sense for a library but in application code public fields are fine). But Kotlin means paying all the costs of using Scala (which is already production-ready and more widely supported) but getting very few of the benefits.