Live data from Hacker News

Go GC: Solving the Latency Problem in Go 1.5

sourcegraph.com

61–70 of 132 posts

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

#61

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…

With ARC sharing objects across threads becomes trickier. First of all, in the general case you'll have to do atomic increments and decrements which tend to be fairly expensive, and they'll be sitting right in the middle your core application logic. Secondly, if you're sharing objects amongst threads, you cannot simply do:

  Thread1:
  Obj = Heap->field;
  Heap->field = null;
  // reduced a reference so:
  if (AtomicDecrement(Obj->refcount) == 0) {
    free(Obj);
  }
Since you'll be racing with

  Thread2:
  Obj = Heap->field;
  // stalls, and Thread1 deletes Obj
  AtomicIncrement(Obj->refcount)
The only satisfactory solution to this that I'm aware of is to use hazard pointers, and that is a fairly complex bit of logic. Maybe there's a better solution to this, but I've not come across one.

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

#62
post #27
post #12

Earlier quoted context omitted.

Yes, I have. We used go in a system that had to keep track of essentially large hashes containing popularity / scoring information, in addition to what were effectively routing tables, and ran into >500ms pauses. At scale, it seemed the largest part of the complexity of go was manipulating data structures and code to avoid gc pauses. With sufficient work we may have been able to decrease the pauses sufficiently, but…

If it's possible, and you're interested in trying, it would be interesting to pull that code out and try it again with Go 1.5, if it's easy. If you've got a C++ solution, I would not suggest under any circumstances short of Go suddenly and frankly mysteriously blowing the doors off of C++ that you switch ... I'm just saying it would be an interesting comparison.

I'll be recommending we try it in a lab with go 1.5, absolutely.

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

#63
post #12

Earlier quoted context omitted.

Yes, I have. We used go in a system that had to keep track of essentially large hashes containing popularity / scoring information, in addition to what were effectively routing tables, and ran into >500ms pauses. At scale, it seemed the largest part of the complexity of go was manipulating data structures and code to avoid gc pauses. With sufficient work we may have been able to decrease the pauses sufficiently, but…

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

About half a gig resident memory.

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

#64

Earlier quoted context omitted.

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…

With ARC sharing objects across threads becomes trickier. First of all, in the general case you'll have to do atomic increments and decrements which tend to be fairly expensive, and they'll be sitting right in the middle your core application logic. Secondly, if you're sharing objects amongst threads, you cannot simply do: Thread1: Obj = Heap->field; Heap->field = null; // reduced a reference so: if (AtomicDecrement(…

[deleted]

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

#65
post #23

Earlier quoted context omitted.

Well if I asked your average brain-dead Java developer it would be to make your code more "generic" so you don't have to change a single line of code when requirements change, just tweak some XML somewhere! And if there is one thing that Java developers are not, it is productive. I will usually be finishing off a project in Python while they are still coding getters/setters on their AbstractProxyFactoryFactory class.

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.

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

#66

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.

I think the advantage of ARC is not the potential for longer pause times but the fact that things are predictable & somewhat easier to debug.

I think it's too bad that the GC/ARC choice also implies a language choice. For e.g. if we had the ability to choose between GC & ARC in Java, we would be able to get a better understanding of which memory model developers of Java enterprise software end up preferring.

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

#67
post #40

Earlier quoted context omitted.

When you consider that most applications are just CRUD processors for some business logic that very rarely hit performance issues, the use case becomes obvious. GC saves developer time, which is the most significant cost for anything that isn't large scale. The clerk at the front desk isn't meaningfully impacted if the backed has to GC for 350ms once in a while. But the clerk is impacted when his/her software is miss…

> 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?

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

#68

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?

Why shouldn't you? One of the best parts of software development is the diversity of ideas. Learning a new way of doing things adds to your potential techniques.

My main job is in a garbage collected language but I'm learning rust and know swift.

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

#69

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 memory overhead and complexity of refcounts with malloc to a non-semi-space GC, you'll be surprised. malloc is more complex and worse in it's CPU overhead, refcounts in every data cell are a huge overhead. GC's got it better.

Where GC's have a memory overhead (copying collectors), they do it on purpose, on machines which do have enough memory. Those copying collectors are the fastest, but cannot be used on small devices. With not enough RAM, you just use a trivial Mark&Sweep, which is much more trivial than your malloc implementation and manual refcounts.

The only real field where you cannot use a GC is, when you cannot tolerate pauses, as in real-time, latency critical apps. But even there exist incremental GC's (like boehm) with real-time characteristics. And when you need immediate destruction of objects, when they go out of scope, and not when the GC decides to destroy them later on. This can be solved by the compiler, but usually isn't.

Of course people always walk away from GC and avoid it like a plague. GC people on the other hand feel memory is too important to be trusted to programmers. We had these discussion for decades.

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

#70
post #18

Was the presentation more in-depth that this summary? I'd love to read or hear more about the changes.

The summary pretty much covers it in terms of what was presented. There definitely would not have been enough time to discuss the changes they made at length.
Post reply on HN