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

11–20 of 132 posts

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

#11

Post by nulltype »

Retra wrote: post #10
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…

It's just far easier to write bloated software than it is to write efficient software. Particularly in the "just get it done" atmosphere most programmers operate under.

I would say it's a trade-off between writetime efficiency and runtime efficiency. The trend has been that runtime efficiency matters less and less. Compare the modern idea of "efficient" software to the binary that early machines were programmed in.

With Moore's law possibly ending and current memory access speeds though, it may be starting to matter a lot moore.

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

#12

Post by eggnet »

nulltype wrote: post #8
eggnet wrote: post #2

Interesting. I think the GC pauses are go's biggest problem. Looks like they are tackling this head on with positive results.

Have you encountered any problems with go GC pauses?

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 we also ran into raw request per second numbers that were lower than we liked.

The direction we have taken was to switch to C++ for this application. Having said that, the gc pauses were the primary reason for the change.

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

#13

Post by omarforgotpwd »

nulltype wrote: post #8
eggnet wrote: post #2

Interesting. I think the GC pauses are go's biggest problem. Looks like they are tackling this head on with positive results.

Have you encountered any problems with go GC pauses?

For many applications, like web backends that may have previously been written in Ruby, Python, or JavaScript, the garbage collector was not noticeable at all. Improvements to the garbage collector target apps that previously would have been written in C with manual memory management, as mentioned in the talk. Not all apps need to be written in C obviously, but this will help bring Go's concurrency primitives to places where the GC was previously a deal breaker, such as eggnet's program.

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

#14

Post by nulltype »

eggnet wrote: post #12
nulltype wrote: post #8

Earlier quoted context omitted.

Have you encountered any problems with go GC pauses?

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?

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

#15

Post by andrewchambers »

davidw wrote: post #3

Erlang's per-process (Erlang process, not Unix process) GC is pretty good from this point of view. I'm surprised they didn't mention it as something to think about.

Why would you mention it? Go is shares all memory, erlang doesn't. It is a different problem.

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

#16

Post by smegel »

nulltype wrote: post #9
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…

I'm not sure users really care how many gigabytes their word processor is. How fast it is is probably more interesting to them. And while wasting CPU cycles on abstraction layers isn't a great way to make a super fast program, if the program still runs at 60fps and took half as much time to develop, then maybe they're worth it. Of course, when you end up with some standards-driven monstrosity like a modern web browse…

> and took half as much time to develop

Abstractions make coding faster now?

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

#17

Post by oldmanjay »

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…

I know it's a common complaint amongst a certain set to remember some bizarre version of the good old days when software was lean and mean and usable and did all the work our modern software does, but that time literally never existed. What you call bloat, most people either call "usability and features" or simply don't notice at all. The fact that you (apparently) don't like usability and features and prefer to call them bloat doesn't actually give any veracity to your opinions - certainly not enough to make such assertive unsupported statements.

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

#19

Post by benaiah »

smegel wrote: post #16
nulltype wrote: post #9

Earlier quoted context omitted.

I'm not sure users really care how many gigabytes their word processor is. How fast it is is probably more interesting to them. And while wasting CPU cycles on abstraction layers isn't a great way to make a super fast program, if the program still runs at 60fps and took half as much time to develop, then maybe they're worth it. Of course, when you end up with some standards-driven monstrosity like a modern web browse…

> and took half as much time to develop Abstractions make coding faster now?

No, it'd be way faster to just do it all in assembly. These fancy "high level languages" and "memory management" and "libraries" are just cons foisted on poor unsuspecting programmers by middle management and enthusiastic marketers. Real Programmers (TM) don't need any of that shit.

(/s)

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

#20

Post by RussianCow »

smegel wrote: post #16
nulltype wrote: post #9

Earlier quoted context omitted.

I'm not sure users really care how many gigabytes their word processor is. How fast it is is probably more interesting to them. And while wasting CPU cycles on abstraction layers isn't a great way to make a super fast program, if the program still runs at 60fps and took half as much time to develop, then maybe they're worth it. Of course, when you end up with some standards-driven monstrosity like a modern web browse…

> and took half as much time to develop Abstractions make coding faster now?

Isn't that the point? Why else use abstractions if not to make yourself more productive?
Post reply on HN