4 ms·

The Go runtime is really starting to look sexy. 20 ms GC pauses on 200+ GB heaps! I remember a thread discussing a pauseless GC on the dev mailing-list; where

by BenoitP 11y ago

The Go runtime is really starting to look sexy. 20 ms GC pauses on 200+ GB heaps! I remember a thread discussing a pauseless GC on the dev mailing-list; where Gil Tene, of Azul C4's fame, commented on having a clear policy on safepoints from the beginning was paramount to having a good GC. It looked like the community is very biased towards doing the fundamental things well, and attracting the right people. And on top of that we're get BLAS and LAPACK bindings from https://github.com/gonum https://github.com/gonum

rhodysurf 11y ago
Oh wow thanks for pointing out gonum! Definitely going to be playing around with this.
deleted 11y ago
[deleted]
amelius 11y ago
The only thing missing is a good binding to a javascript engine, for code that has to run on both client and server.
- nulltype 11y ago
  If you need to write code that runs on your go server and on the client, there's always https://github.com/gopherjs/gopherjs https://github.com/gopherjs/gopherjs
  - amelius 11y ago
    That is nice. But I hope that you understand that such a solution is not always preferred in every situation. For example, for performance reasons, it is always better to code in the native language.
mike_hearn 11y ago
You have to be very careful about these sorts of GC statistics. Things are often not quite what they seem and they depend a lot on the type of app you run. The first thing to be aware of is that with modern collectors (I have no idea how modern Go's new collector is though), GC pause time depends on how much live data there is in the young generation. So you can easily have enormous heaps with very low pause times if all your objects die young and hardly ever make it into the old generations, because then you never really need to collect the rest of the heap at all. Of course, outside of synthetic benchmarks, many apps don't show such pleasant behaviour, and often GC algorithms face difficult tradeoffs that are only really knowable by the developers. For instance, do you want low pause times, or less CPU used by the collector (higher throughput)? It turns out that's a fundamental tradeoff and the right answer usually depends whether your app is a user facing server (needs low pause times) or a batch job (better to pause for long periods but complete faster). No runtime can know that, which is why the JVM has tons of tuning knobs. Left to its own devices you can theoretically get away with only tweaking a single knob which is target pause time (in G1). Set it lower and CPU usage of the collector goes up but it'll try and pause for less time. Set it higher and the collector gets more efficient. Or you can just buy Zing and get rid of GC pauses entirely. So a stat by itself like "20ms GC pauses on 200GB heaps" doesn't mean much by itself. You can get very low pause times with huge heaps out of the JVM as well: http://www.slideshare.net/HBaseCon/dev-session-7-49202969 but of course, you have to pay the piper somehow ... assuming non-weird heap usage the program will run slower overall.
- eloff 11y ago
  Go doesn't use a generational GC AFAIK.
- _ph_ 11y ago
  The GO gc is not generational, those 20ms are for a full gc. Certainly the details of the heap usage of the application is going to affect gc times, but this is not the time for just a nursery collection.
  - mike_hearn 11y ago
    OK, the tradeoff they're making that I missed is that it's not a compacting collector. So eventually your heap can fragment to the point where allocation gets expensive or impossible. Unusual design choice.

by BenoitP 11y ago

rhodysurf 11y ago

Oh wow thanks for pointing out gonum! Definitely going to be playing around with this.

deleted 11y ago

[deleted]

amelius 11y ago

The only thing missing is a good binding to a javascript engine, for code that has to run on both client and server.

nulltype 11y ago
If you need to write code that runs on your go server and on the client, there's always https://github.com/gopherjs/gopherjs https://github.com/gopherjs/gopherjs
- amelius 11y ago
  That is nice. But I hope that you understand that such a solution is not always preferred in every situation. For example, for performance reasons, it is always better to code in the native language.

mike_hearn 11y ago

You have to be very careful about these sorts of GC statistics. Things are often not quite what they seem and they depend a lot on the type of app you run. The first thing to be aware of is that with modern collectors (I have no idea how modern Go's new collector is though), GC pause time depends on how much live data there is in the young generation. So you can easily have enormous heaps with very low pause times if all your objects die young and hardly ever make it into the old generations, because then you never really need to collect the rest of the heap at all. Of course, outside of synthetic benchmarks, many apps don't show such pleasant behaviour, and often GC algorithms face difficult tradeoffs that are only really knowable by the developers. For instance, do you want low pause times, or less CPU used by the collector (higher throughput)? It turns out that's a fundamental tradeoff and the right answer usually depends whether your app is a user facing server (needs low pause times) or a batch job (better to pause for long periods but complete faster). No runtime can know that, which is why the JVM has tons of tuning knobs. Left to its own devices you can theoretically get away with only tweaking a single knob which is target pause time (in G1). Set it lower and CPU usage of the collector goes up but it'll try and pause for less time. Set it higher and the collector gets more efficient. Or you can just buy Zing and get rid of GC pauses entirely. So a stat by itself like "20ms GC pauses on 200GB heaps" doesn't mean much by itself. You can get very low pause times with huge heaps out of the JVM as well: http://www.slideshare.net/HBaseCon/dev-session-7-49202969 but of course, you have to pay the piper somehow ... assuming non-weird heap usage the program will run slower overall.

eloff 11y ago
Go doesn't use a generational GC AFAIK.
_ph_ 11y ago
The GO gc is not generational, those 20ms are for a full gc. Certainly the details of the heap usage of the application is going to affect gc times, but this is not the time for just a nursery collection.
- mike_hearn 11y ago
  OK, the tradeoff they're making that I missed is that it's not a compacting collector. So eventually your heap can fragment to the point where allocation gets expensive or impossible. Unusual design choice.