4 ms·

Replacing a channel with a ring buffer that spins (and uses runtime.Gosched every 1000 failed attempts) is really bad general advice. The other advice is simila

Replacing a channel with a ring buffer that spins (and uses runtime.Gosched every 1000 failed attempts) is really bad general advice. The other advice is similar. It may be a good idea for very specific use cases and might have served the author well, but the channel will scale far better in the general case and suffer from have less degenerative cases. Looking at artificial benchmarks is very misleading. If you take the ring buffer linked in the article and throw 1000 producers and one consumer at it, it will completely and utterly fall over. Channels on the other hand, will behave just fine. My take: use the language primitives unless you really know what you're doing. Then you should also know that it's not a general optimization.

kasey_junk 11y ago
The problem is 2 fold. The marketing on Go is that it has great concurrency built in, but it doesn't support 2 extremely common concurrency use cases out of the box: 1) lock free queues 2) concurrent maps Worse than that, the language makes it very difficult to write libraries to support those use cases. So sure, in your use case, and maybe the Golang language maintainers use cases, dispensing with channels is bad advice. But it turns out that nearly every single team that has tried to scale golang servers has come to the same position. Give up channels as your concurrency primitives and revert to the sync package if you need to really scale golang programs
- amscanne 11y ago
  Assuming you've got a buffered channel with non-blocking send and receive calls, I seriously doubt that the three lines protected by a mutex are the bottleneck for scaling your service. It's basically exchanging one set of atomic ops for another one. I'm not saying that you couldn't optimize if you have a very specific need, but it's disingenuous to pretend that the lack of a "lock-free" queue is somehow a fatal flaw or preventing you from scaling go programs.
- reality_czech 11y ago
  Normally if you have too much overhead with a channel, you just send more at a time. For example if you are using a channel to distribute out work, send 100 items at a time rather than 1. Then you do fewer channel read and write operations. Concurrent maps have poor performance because of cache-line bouncing and locking overhead. Everyone I've ever talke to who has benchmarked them has said there isn't much point.
- eternalban 11y ago
  > lock free queues That may change. Lock free algorithms generate quite a lot of garbage [1] & the Go GC story is much better now than before. > the language makes it very difficult to write libraries to support those use cases. Not sure why you hold this view. Atomic op primitives are provided. Is the issue the syntactic white noise of using the unsafe mechanisms? [1]: can't find the cite of Cliff Click addressing this point. Intuitively, consider that lock free algorithms trade space for time.
  - kasey_junk 11y ago
    Your point about lock free algos generating garbage is true of some algos but not others. The disruptor (last I looked) was lock free and garbage free. Without starting a huge debate, lack of generics, makes writing collections (especially concurrent safe ones) a trade off between correctness of algorithm & type safety.
    - eternalban 11y ago
      I was addressing the GP's map/queue. > .. generics .. It should be obvious by now that Go's IDE is the command line. So Go generate young wo/man :) But seriously, having recently switched to C11 from Go, I would take C's crappy pre-processor over poor man's metadata in comments approach of Go. [p.s. edit: in the sense that C11 actually has a far less painful way to achieve type-safe generic code.]
- jerf 11y ago
  "The marketing on Go is that it has great concurrency built in" I say this every so often, but it's worth repeating: This is why I tend to consider Go a scripting language rather than a "systems" language. If you're used to Python or Ruby or PHP or something, holy cow does Go ever offer great concurrency support with blistering performance. If, on the other hand, you've got a task where you're literally counting cycles in the CPU and intensely worried about L1 cache and you're using lock-free structures not because you read a blog post about lock-free last night but because you've tried everything else and it's the only way to hit your performance targets, Go is not great choice. It's probably still miles better than Python/PHP/Ruby/etc. even so, but that's damning with faint praise. I think Go occupies a rather nice spot on the cost/benefit chart, but it certainly does not occupy the highest performance slot. But to get to that point, expect to pay some more on the cost side, and for a lot of people, it is more than fast enough, with at most just a bit of performance analysis. Also, I'd suggest that the defining characteristic of channels is "select". If you've got a channel that will never ever be used in a select statement, you're definitely paying a lot for that capability. On the other hand, if you really need it, I suspect it can't get much cheaper. Again, it occupies a rather nice place on the cost/benefit chart, but it is definitely not in the highest performance slot, and, again, for a lot of people it is more than fast enough and a major upgrade over what they are currently using.

kasey_junk 11y ago

The problem is 2 fold. The marketing on Go is that it has great concurrency built in, but it doesn't support 2 extremely common concurrency use cases out of the box: 1) lock free queues 2) concurrent maps Worse than that, the language makes it very difficult to write libraries to support those use cases. So sure, in your use case, and maybe the Golang language maintainers use cases, dispensing with channels is bad advice. But it turns out that nearly every single team that has tried to scale golang servers has come to the same position. Give up channels as your concurrency primitives and revert to the sync package if you need to really scale golang programs

amscanne 11y ago
Assuming you've got a buffered channel with non-blocking send and receive calls, I seriously doubt that the three lines protected by a mutex are the bottleneck for scaling your service. It's basically exchanging one set of atomic ops for another one. I'm not saying that you couldn't optimize if you have a very specific need, but it's disingenuous to pretend that the lack of a "lock-free" queue is somehow a fatal flaw or preventing you from scaling go programs.
reality_czech 11y ago
Normally if you have too much overhead with a channel, you just send more at a time. For example if you are using a channel to distribute out work, send 100 items at a time rather than 1. Then you do fewer channel read and write operations. Concurrent maps have poor performance because of cache-line bouncing and locking overhead. Everyone I've ever talke to who has benchmarked them has said there isn't much point.
eternalban 11y ago
> lock free queues That may change. Lock free algorithms generate quite a lot of garbage [1] & the Go GC story is much better now than before. > the language makes it very difficult to write libraries to support those use cases. Not sure why you hold this view. Atomic op primitives are provided. Is the issue the syntactic white noise of using the unsafe mechanisms? [1]: can't find the cite of Cliff Click addressing this point. Intuitively, consider that lock free algorithms trade space for time.
- kasey_junk 11y ago
  Your point about lock free algos generating garbage is true of some algos but not others. The disruptor (last I looked) was lock free and garbage free. Without starting a huge debate, lack of generics, makes writing collections (especially concurrent safe ones) a trade off between correctness of algorithm & type safety.
  - eternalban 11y ago
    I was addressing the GP's map/queue. > .. generics .. It should be obvious by now that Go's IDE is the command line. So Go generate young wo/man :) But seriously, having recently switched to C11 from Go, I would take C's crappy pre-processor over poor man's metadata in comments approach of Go. [p.s. edit: in the sense that C11 actually has a far less painful way to achieve type-safe generic code.]
jerf 11y ago
"The marketing on Go is that it has great concurrency built in" I say this every so often, but it's worth repeating: This is why I tend to consider Go a scripting language rather than a "systems" language. If you're used to Python or Ruby or PHP or something, holy cow does Go ever offer great concurrency support with blistering performance. If, on the other hand, you've got a task where you're literally counting cycles in the CPU and intensely worried about L1 cache and you're using lock-free structures not because you read a blog post about lock-free last night but because you've tried everything else and it's the only way to hit your performance targets, Go is not great choice. It's probably still miles better than Python/PHP/Ruby/etc. even so, but that's damning with faint praise. I think Go occupies a rather nice spot on the cost/benefit chart, but it certainly does not occupy the highest performance slot. But to get to that point, expect to pay some more on the cost side, and for a lot of people, it is more than fast enough, with at most just a bit of performance analysis. Also, I'd suggest that the defining characteristic of channels is "select". If you've got a channel that will never ever be used in a select statement, you're definitely paying a lot for that capability. On the other hand, if you really need it, I suspect it can't get much cheaper. Again, it occupies a rather nice place on the cost/benefit chart, but it is definitely not in the highest performance slot, and, again, for a lot of people it is more than fast enough and a major upgrade over what they are currently using.