4 ms·

Something that looks like async/await and has a rather bad performance can be implemented through channels. Nestable stackless coroutines cannot. By definition

Something that looks like async/await and has a rather bad performance can be implemented through channels. Nestable stackless coroutines cannot. By definition they require compiler support. Your proposed solution will not have any of the advantages of stackless coroutines (effect typing of async functions and perfectly optimal memory use) while suffering all the performance penalty of running on top of a channel.

YetAnotherNick 6y ago
Channels have close to zero performance penalty. If you are talking about goroutines, you need to come up with data or code. I found goroutines to be really cheap to create.
- unscaled 6y ago
  Not true: https://www.jtolio.com/2016/03/go-channels-are-bad-and-you-should-feel-bad/#channels-are-slower-than-implementing-it-yourself:7de476e370ca6a780a51fd680c5a51dd https://www.jtolio.com/2016/03/go-channels-are-bad-and-you-s... I'm pretty sure the implementation has seen some improvements since then. But using a channel for async await is the same as using a global mutex every time you await. That is bound to be contentious on high load.
  - Taek 6y ago
    I think today channels cost a few hundred nanoseconds. For most applications, this is 'close to no overhead'. If you are doing a really tight loop of course or have threads that bump into eachother a million times per second, you're going to want a different primitive. But most programmers aren't going to see any overhead using channels instead of something else.
    - unscaled 6y ago
      Please remember the approach is "every context switch should go through a centralized channel". This including waiting on all other channels. I need to see some benchmark to this level to be proven the overhead is negligible. And of course, there is still the question of WHY would you ever want to do that. What can be gained from simulating an async-await model on top of a channel.

YetAnotherNick 6y ago

Channels have close to zero performance penalty. If you are talking about goroutines, you need to come up with data or code. I found goroutines to be really cheap to create.

unscaled 6y ago
Not true: https://www.jtolio.com/2016/03/go-channels-are-bad-and-you-should-feel-bad/#channels-are-slower-than-implementing-it-yourself:7de476e370ca6a780a51fd680c5a51dd https://www.jtolio.com/2016/03/go-channels-are-bad-and-you-s... I'm pretty sure the implementation has seen some improvements since then. But using a channel for async await is the same as using a global mutex every time you await. That is bound to be contentious on high load.
- Taek 6y ago
  I think today channels cost a few hundred nanoseconds. For most applications, this is 'close to no overhead'. If you are doing a really tight loop of course or have threads that bump into eachother a million times per second, you're going to want a different primitive. But most programmers aren't going to see any overhead using channels instead of something else.
  - unscaled 6y ago
    Please remember the approach is "every context switch should go through a centralized channel". This including waiting on all other channels. I need to see some benchmark to this level to be proven the overhead is negligible. And of course, there is still the question of WHY would you ever want to do that. What can be gained from simulating an async-await model on top of a channel.