Go GC: Solving the Latency Problem in Go 1.5
sourcegraph.com
Go GC: Solving the Latency Problem in Go 1.5
1–10 of 132 posts
Re: Go GC: Solving the Latency Problem in Go 1.5
#2Interesting. I think the GC pauses are go's biggest problem.
Looks like they are tackling this head on with positive results.
Re: Go GC: Solving the Latency Problem in Go 1.5
#3Erlang'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.
Re: Go GC: Solving the Latency Problem in Go 1.5
#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 abstraction or poorly written code until it runs at the same speed that old code ran on the old CPU. I'm impressed that hardware designers and compiler authors can do their jobs well enough to make this sort of bloated software (e.g. multiple gigabytes for a word processor or image editor) succeed in spite of itself.
There are of course CPU advancements that make a huge performance difference when used properly (e.g. SSE, multiple cores in consumer machines) and some applications will use them to great effect, but these seem to be few and far between.
Re: Go GC: Solving the Latency Problem in Go 1.5
#5Erlang'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.
I've gone through the exercise of enabling something like per-process GC in Go by using multiple processes and the standard Go RPC library. It's easier to get to that point in Erlang, because you're already there by default.
Very good low-latency GC is good an alternative to per-process GC, especially combined with Go's ability to let you write to avoid GC pressure.
Re: Go GC: Solving the Latency Problem in Go 1.5
#6Better images of the plots:
Re: Go GC: Solving the Latency Problem in Go 1.5
#7> ...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…
Why would I want to solve the same problem I was solving last year, but just a little bit faster (or more times, if you prefer)?
If it was good enough last year, it's probably good enough today. Today I will solve new problems with even more resources.
Re: Go GC: Solving the Latency Problem in Go 1.5
#8Interesting. 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?
Re: Go GC: Solving the Latency Problem in Go 1.5
#9> ...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 browser, you do seem to have a lot of unnecessary abstraction layers and also it's slow.
Re: Go GC: Solving the Latency Problem in Go 1.5
#10> ...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.