4 ms·

Still slowish. Far far from "solved." The charts they zoom in on only go to about 500MB in heap, showing 2 ms pause times. It makes me suspicious that the nice

Still slowish. Far far from "solved." The charts they zoom in on only go to about 500MB in heap, showing 2 ms pause times. It makes me suspicious that the nice linear trend he's showing doesn't hold up under more reasonable values -- my IDE takes up 500 MB and my web browser over a GB. So if by his possibly rosy calculations, a basic 3GB heap is still pausing 6 ms. God forbid I use a 500 GB heap and now we're into the one second range again. This is assuming the linear relationship holds up, but given his choice of graph domain, I have a suspicion that there are issues to the right. This seems typical of Google technology. They say they care about performance, but I have yet to see a piece of Google tech that is actually useful if you care about performance. People automatically assume Google is synonymous with performance, but it definitely isn't. Remember, he says this improved GC pause time is going to come at the expense of Go top-line speed. You Go will get slower, and you sill will have second pauses with any serious work.

desdiv 11y ago
>my IDE takes up 500 MB and my web browser over a GB. >So if by his possibly rosy calculations, a basic 3GB heap is still pausing 7 ms. How did you arrive at 3GB? Heap spaces of different processes don't add up, you know?
- deleted 11y ago
  [deleted]
- jnordwick 11y ago
  I just said typically for about an low-end estimate for what we use at work. We used to be constrained by Java 32-bit since 64-bit was slow so coded for that range. With compressed OOPS we were able to expand, but still have a lot of code on that low side. Now hundred GB heaps are much more the norm.
mseepgood 11y ago
The first chart goes up to 20 GB heap size. > This is assuming the linear relationship holds up Their goal for 1.6 is to make it constant, not linear: "Zooming in, there is still a slight positive correlation between heap size and GC pauses. But they know what the issue is and it will be fixed in Go 1.6." https://sourcegraph.com/blog/live/gophercon2015/123574706480 https://sourcegraph.com/blog/live/gophercon2015/123574706480
- jnordwick 11y ago
  His version of "slight" to me isn't so slight. He's brushing under the rug that Go isn't suitable for many of the low latency, memory hungry domains that comprise modern systems.
  - bostik 11y ago
    > many of the low latency, memory hungry domains that comprise modern systems. I would say it really depends on the situation, and especially what you consider low-latency. It also depends very much on what your definition of low-latency is. For background: we run a betting exhange. Customers will notice and complain if any action with their money takes more than ~100ms. This threshold aligns quite well with old research about human response times [0]. On the other hand, if we were running an interactive chat/forum system, it would be acceptable to have >500ms latencies from click to comment display. When it comes to communications, reliable persistence tends to be more important to raw latency. (Or to put it another way: it is okay to delay displaying of a fresh comment until it has been stored. That way the user knows they do not need to rewrite their contribution.) I personally have a background in embedded systems, where hard latency limits are the norm for user experience. Developers, end users and companies are all willing to sacrifice throughput for near-immediate feedback .. and doubly so when the system in question happens to control a vehicle dashboard. At 60 frames per second, one frame refresh is about 17ms. When you need to provide visibly immediate feedback to the user, you have at most 6 frames to display it. Because the data must be available before the rendering of the 6th frame starts, you actually have on average no more than 5,5 * 17ms = 93ms to calculate the response. The real trick is figuring out where you can get away with non-immediate latency requirements. And incidentally, this has knock-over effects: if hard low-latency is not necessary, some GC spikes should be tolerable. Spend the engineering effort where it is crucial, not where it might be nice. At least until you have more workforce than engineering problems. 0: http://www.nngroup.com/articles/response-times-3-important-limits/ http://www.nngroup.com/articles/response-times-3-important-l... (Nielsen, 1993)
  - crawshaw 11y ago
    In the talk Rick described the problem as the data structure responsible for tracking finalizers. The fix is apparently reasonably straightforward, but the cause was not discovered until we were in the Go 1.5 tree freeze, so it has to wait for Go 1.6 in six months. Hopefully the video will be available soon, it contains a lot of information not in the slides.
themartorana 11y ago
But no one is suggesting Go for your web browser or IDE. Go is brilliant for faceless fast-response highly-concurrent situations - like APIs and the like. It's also absurd to accuse Google of not caring about performance when they can search the wealth of information on the Internet in milliseconds.
- chetanahuja 11y ago
  Yeah... the Google search engine is not written in Go. There's a big difference between folks who really, deeply care about sub-ms level latencies ( like this guy https://www.youtube.com/watch?v=S9twUcX1Zp0 https://www.youtube.com/watch?v=S9twUcX1Zp0 ) are not the same folks pushing Go.
  - themartorana 11y ago
    Except they are running their downloads site and much of YouTube on Go, among many others. Indexing the world's content may not be smart to write in Go, but Google's other properties are also heavily hit and seem to run fine.
_ak 11y ago
The Go 1.5 GC guarantees that the GC stops the program for a maximum of 10ms within a 50ms timeframe.
justthistime_ 11y ago
Yeah, I'm really getting tired of these imbeclies. It's really convenient how they switch to _SECONDS_ on the x-axis. Sorry, if they need an y-axis in seconds, GC is far from solved.
- dang 11y ago
  > Yeah, I'm really getting tired of these imbeclies. Please don't include unsubstantive swipes in HN comments. It degrades the discourse for all of us. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- pkroll 11y ago
  The scale of the old GC requires seconds, so the chart with old and new needs to show seconds. The new one doesn't, and shows milliseconds. The title doesn't say that all of GC is solved, just the latency problem, which for most Go use cases is at least arguable.

desdiv 11y ago

>my IDE takes up 500 MB and my web browser over a GB. >So if by his possibly rosy calculations, a basic 3GB heap is still pausing 7 ms. How did you arrive at 3GB? Heap spaces of different processes don't add up, you know?

deleted 11y ago
[deleted]
jnordwick 11y ago
I just said typically for about an low-end estimate for what we use at work. We used to be constrained by Java 32-bit since 64-bit was slow so coded for that range. With compressed OOPS we were able to expand, but still have a lot of code on that low side. Now hundred GB heaps are much more the norm.

mseepgood 11y ago

The first chart goes up to 20 GB heap size. > This is assuming the linear relationship holds up Their goal for 1.6 is to make it constant, not linear: "Zooming in, there is still a slight positive correlation between heap size and GC pauses. But they know what the issue is and it will be fixed in Go 1.6." https://sourcegraph.com/blog/live/gophercon2015/123574706480 https://sourcegraph.com/blog/live/gophercon2015/123574706480

jnordwick 11y ago
His version of "slight" to me isn't so slight. He's brushing under the rug that Go isn't suitable for many of the low latency, memory hungry domains that comprise modern systems.
- bostik 11y ago
  > many of the low latency, memory hungry domains that comprise modern systems. I would say it really depends on the situation, and especially what you consider low-latency. It also depends very much on what your definition of low-latency is. For background: we run a betting exhange. Customers will notice and complain if any action with their money takes more than ~100ms. This threshold aligns quite well with old research about human response times [0]. On the other hand, if we were running an interactive chat/forum system, it would be acceptable to have >500ms latencies from click to comment display. When it comes to communications, reliable persistence tends to be more important to raw latency. (Or to put it another way: it is okay to delay displaying of a fresh comment until it has been stored. That way the user knows they do not need to rewrite their contribution.) I personally have a background in embedded systems, where hard latency limits are the norm for user experience. Developers, end users and companies are all willing to sacrifice throughput for near-immediate feedback .. and doubly so when the system in question happens to control a vehicle dashboard. At 60 frames per second, one frame refresh is about 17ms. When you need to provide visibly immediate feedback to the user, you have at most 6 frames to display it. Because the data must be available before the rendering of the 6th frame starts, you actually have on average no more than 5,5 * 17ms = 93ms to calculate the response. The real trick is figuring out where you can get away with non-immediate latency requirements. And incidentally, this has knock-over effects: if hard low-latency is not necessary, some GC spikes should be tolerable. Spend the engineering effort where it is crucial, not where it might be nice. At least until you have more workforce than engineering problems. 0: http://www.nngroup.com/articles/response-times-3-important-limits/ http://www.nngroup.com/articles/response-times-3-important-l... (Nielsen, 1993)
- crawshaw 11y ago
  In the talk Rick described the problem as the data structure responsible for tracking finalizers. The fix is apparently reasonably straightforward, but the cause was not discovered until we were in the Go 1.5 tree freeze, so it has to wait for Go 1.6 in six months. Hopefully the video will be available soon, it contains a lot of information not in the slides.

themartorana 11y ago

But no one is suggesting Go for your web browser or IDE. Go is brilliant for faceless fast-response highly-concurrent situations - like APIs and the like. It's also absurd to accuse Google of not caring about performance when they can search the wealth of information on the Internet in milliseconds.

chetanahuja 11y ago
Yeah... the Google search engine is not written in Go. There's a big difference between folks who really, deeply care about sub-ms level latencies ( like this guy https://www.youtube.com/watch?v=S9twUcX1Zp0 https://www.youtube.com/watch?v=S9twUcX1Zp0 ) are not the same folks pushing Go.
- themartorana 11y ago
  Except they are running their downloads site and much of YouTube on Go, among many others. Indexing the world's content may not be smart to write in Go, but Google's other properties are also heavily hit and seem to run fine.

_ak 11y ago

The Go 1.5 GC guarantees that the GC stops the program for a maximum of 10ms within a 50ms timeframe.

justthistime_ 11y ago

Yeah, I'm really getting tired of these imbeclies. It's really convenient how they switch to _SECONDS_ on the x-axis. Sorry, if they need an y-axis in seconds, GC is far from solved.

dang 11y ago
> Yeah, I'm really getting tired of these imbeclies. Please don't include unsubstantive swipes in HN comments. It degrades the discourse for all of us. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
pkroll 11y ago
The scale of the old GC requires seconds, so the chart with old and new needs to show seconds. The new one doesn't, and shows milliseconds. The title doesn't say that all of GC is solved, just the latency problem, which for most Go use cases is at least arguable.