3 ms·

> Synchronous sequences are generally faster than asynchronous ones because yielding and getting scheduled back has a non-zero overhead Indeed. I remember bein

> Synchronous sequences are generally faster than asynchronous ones because yielding and getting scheduled back has a non-zero overhead Indeed. I remember being shocked when I first read "Thousands of Threads and Blocking I/O" [0] by Paul Tyma. After reading the C10k problem [1], I just believed that a big pile of threads would never work and never updated my beliefs. While such an approach is still quite memory limited compared to asynchronous approaches, it scales quite far and can have a very high work rate. [0] https://www.slideshare.net/e456/tyma-paulmultithreaded1 https://www.slideshare.net/e456/tyma-paulmultithreaded1 [1] http://www.kegel.com/c10k.html http://www.kegel.com/c10k.html

deleted 9y ago
[deleted]
lomnakkus 9y ago
Allow me to third that. It's one of dangers assuming that what you learned at university 15-20 years ago still applies. Another interesting talk: [0] (and even that is 5 years old) [0] https://www.youtube.com/watch?v=KXuZi9aeGTw https://www.youtube.com/watch?v=KXuZi9aeGTw
fafhrd91 9y ago
i'd say in most projects i worked, threads would be enough. but it is so boring :) new shiny async code is much more entertaining! on other hand we should talk about C100k or C1m problems.
- nordsieck 9y ago
  Someone actually coined the C10M problem a while back [0]. It looks like it hasn't been updated in quite a while, though. http://c10m.robertgraham.com/p/blog-page.html http://c10m.robertgraham.com/p/blog-page.html
kitd 9y ago
The problem is that, in practice, many of those thread contexts are holding open resources like DB connections or file handles, and the costs related to those mount pretty quickly. This is why actor models are good IMO. They are based on the actual resource model, rather than the developer's mental model. That is, until the developer learns to change his/her mental model.

deleted 9y ago

[deleted]

lomnakkus 9y ago

Allow me to third that. It's one of dangers assuming that what you learned at university 15-20 years ago still applies. Another interesting talk: [0] (and even that is 5 years old) [0] https://www.youtube.com/watch?v=KXuZi9aeGTw https://www.youtube.com/watch?v=KXuZi9aeGTw

fafhrd91 9y ago

i'd say in most projects i worked, threads would be enough. but it is so boring :) new shiny async code is much more entertaining! on other hand we should talk about C100k or C1m problems.

nordsieck 9y ago
Someone actually coined the C10M problem a while back [0]. It looks like it hasn't been updated in quite a while, though. http://c10m.robertgraham.com/p/blog-page.html http://c10m.robertgraham.com/p/blog-page.html

kitd 9y ago

The problem is that, in practice, many of those thread contexts are holding open resources like DB connections or file handles, and the costs related to those mount pretty quickly. This is why actor models are good IMO. They are based on the actual resource model, rather than the developer's mental model. That is, until the developer learns to change his/her mental model.