4 ms·

Maybe you should contribute to the go development to improve the performance for everyone.

kasey_junk 10y ago
There have been many discussions over the years about augmenting channels so that they can be more performant in specific instances like spsc or spmc. The language maintainers have not been very receptive and the broader community has at times been outright hostile.
eloff 10y ago
They have Dmitry Vyukov, who's better at that kind of thing than me. If they want to fix the problem, they don't need my help. I would rather publish my work, and if they want to adapt it for Go's channels, they can do that with my blessing. To me the tricky part seems to be how they need an implementation good for all cases. Performance engineering is all about tradeoffs. Memory usage, throughput, latency are often competing requirements and you have to choose one. Furthermore, unless they can somehow statically determine how many threads access a channel, they have to use a MPMC queue, which is a performance anti-pattern. I would modify the language (maybe just make() builtin) to allow specifying what type of Channel is needed where, SPSC, MPSC, SPMC, etc. But we all know how that would be received.
- zzzcpan 10y ago
  If you control both the compiler and the scheduler these optimizations become somewhat easier and without any syntax changes, no? Like removing naive synchronization on channel operations and having scheduler to deal with them, tracking states, amortizing synchronization, etc.
  - eloff 10y ago
    Some become easier, yes. But I don't think it's that easy to tell how many threads access a channel. We have runtime race-checkers precisely because we don't know how to check that at compile time. Whether the specific case of channels in Go is easier, I don't know. You can in Rust because the language makes you specify which threads owns what and two threads can't own the same thing at the same time (as I understand it anyway.)

There have been many discussions over the years about augmenting channels so that they can be more performant in specific instances like spsc or spmc. The language maintainers have not been very receptive and the broader community has at times been outright hostile.

eloff 10y ago

They have Dmitry Vyukov, who's better at that kind of thing than me. If they want to fix the problem, they don't need my help. I would rather publish my work, and if they want to adapt it for Go's channels, they can do that with my blessing. To me the tricky part seems to be how they need an implementation good for all cases. Performance engineering is all about tradeoffs. Memory usage, throughput, latency are often competing requirements and you have to choose one. Furthermore, unless they can somehow statically determine how many threads access a channel, they have to use a MPMC queue, which is a performance anti-pattern. I would modify the language (maybe just make() builtin) to allow specifying what type of Channel is needed where, SPSC, MPSC, SPMC, etc. But we all know how that would be received.

zzzcpan 10y ago
If you control both the compiler and the scheduler these optimizations become somewhat easier and without any syntax changes, no? Like removing naive synchronization on channel operations and having scheduler to deal with them, tracking states, amortizing synchronization, etc.
- eloff 10y ago
  Some become easier, yes. But I don't think it's that easy to tell how many threads access a channel. We have runtime race-checkers precisely because we don't know how to check that at compile time. Whether the specific case of channels in Go is easier, I don't know. You can in Rust because the language makes you specify which threads owns what and two threads can't own the same thing at the same time (as I understand it anyway.)