5 ms·

Yep that part makes sense to me. But I meant: if there's no perf bottleneck why care about async i/o at all? Since that's the impetus for async i/o usually. A s

Yep that part makes sense to me. But I meant: if there's no perf bottleneck why care about async i/o at all? Since that's the impetus for async i/o usually. A sibling comment to yours answered that part for me. My understanding now is that concurrent code in any paradigm is going off the beaten path, i.e. away from standardized CL, so at the very least you aren't going to be able to write concurrent code portable across different CLs.

Jtsummers 5y ago
Async IO is not chosen because a language isn't fast enough, it's because IO isn't fast enough. Async IO would be useful even if you handwrite everything in the best and fastest assembler possible because in the time it takes to go out and read some data (even on an SSD) you can compute many, many more things. The purpose of async IO is to permit the interleaving of fast and slow activities. If I were still doing scientific computing (it's been a while) I'd want async IO (some implementation of it) even if I had the best GPU for my number crunching bits. Loading the model takes a lot of time and there are other activities the program can engage in during that delay. CL's lack of a standard way to do async IO (in this particular instance) means that even if you have a very fast program, you end up with either a bottleneck waiting for IO or you've recreated the async IO model from other languages (or their standard libraries or their de facto standard libraries) and are now responsible for it.
- brazzy 5y ago
  > The purpose of async IO is to permit the interleaving of fast and slow activities. You absolutely do not need async IO for that. You can do that with a synchronous programming model just fine, using threads and letting the OS do its thing. Async is an absolutely horrible programming model. There are really only two advantages is brings: It lets you avoid the memory and context switching overhead of threads if you need to handle a very large number of requests concurrently, and it lets you do concurrency without worrying about synchronizing access to shared resources (but there are much better ways to do that).
  - Jtsummers 5y ago
    If you use threads to cordon off the slow IO code, you're doing async IO, just without core language or library support for it.
    - brazzy 5y ago
      I was referring to using blocking IO, one thread per request. You know, the much simpler way that was the norm before async became fashionable.
  - Karrot_Kream 5y ago
    > You absolutely do not need async IO for that. You can do that with a synchronous programming model just fine, using threads and letting the OS do its thing. "just fine" is highly relative here and is doing most of the work in your statement. Do you have any conditions under which this is "just fine"? Any more detail? Or else it's just a personal preference.
    - brazzy 5y ago
      A preference? The term was mostly meant to convey that it can be done without problems, contradicting the assertion that async IO "permits" the interleaving of fast and slow activities. Synchronous models have been used for that far longer and more often than asynchronous ones. CGI scripts, Perl, Java servlets all did synchronous IO while also interleaving slow and fast activities for decades before Node made async IO fashionable. An in my second paragraph, I specifically mentioned the specific conditions where async has advantages.
      - Karrot_Kream 5y ago
        > Synchronous models have been used for that far longer and more often than asynchronous ones. CGI scripts, Perl, Java servlets all did synchronous IO while also interleaving slow and fast activities for decades before Node made async IO fashionable. Node didn't make async IO fashionable, as much as you seem to want the beat the drum of "new/hype" vs "old/Lindy/mature". Synchronous IO was slow, memory-inefficient (to spawn multiple threads), and didn't scale well. Slow enough that the C10K [1] problem was framed to capture the issues. Event loops in net servers were mostly popularized by nginx [2] to explicitly solve the C10K problem, which is what started driving folks to use event-loop async programming. Moreover event loops had been popular for years in GUI programming before multiple cores simply because CPU-level parallelism just _was not possible_ (well except for ILP which is a bit different). For example, Tcl/Tk had an event loop driving GUI display logic for ages [3], which really is the same problem. Instead of waiting on NIC events, we were waiting on keyboard/mouse events instead. Just because it's old doesn't mean it's good. There are lots of old bad things and lots of old good things, just like there are lots of new bad things and lots of new good things. [1]: https://en.wikipedia.org/wiki/C10k_problem https://en.wikipedia.org/wiki/C10k_problem [2]: https://en.wikipedia.org/wiki/Nginx#HTTP_proxy_and_Web_server_features https://en.wikipedia.org/wiki/Nginx#HTTP_proxy_and_Web_serve... [3]: https://wiki.tcl-lang.org/page/Tcl+event+loop https://wiki.tcl-lang.org/page/Tcl+event+loop
orthecreedence 5y ago
Yeah, admittedly I could have gone with threading/hunchentoot and been much better off. It was probably stupid to forge the entire async path the way I did. To be fair, Turtl these days gets enough traffic where async does probably make sense for us, and nodejs is serving us well.

Jtsummers 5y ago

Async IO is not chosen because a language isn't fast enough, it's because IO isn't fast enough. Async IO would be useful even if you handwrite everything in the best and fastest assembler possible because in the time it takes to go out and read some data (even on an SSD) you can compute many, many more things. The purpose of async IO is to permit the interleaving of fast and slow activities. If I were still doing scientific computing (it's been a while) I'd want async IO (some implementation of it) even if I had the best GPU for my number crunching bits. Loading the model takes a lot of time and there are other activities the program can engage in during that delay. CL's lack of a standard way to do async IO (in this particular instance) means that even if you have a very fast program, you end up with either a bottleneck waiting for IO or you've recreated the async IO model from other languages (or their standard libraries or their de facto standard libraries) and are now responsible for it.

brazzy 5y ago
> The purpose of async IO is to permit the interleaving of fast and slow activities. You absolutely do not need async IO for that. You can do that with a synchronous programming model just fine, using threads and letting the OS do its thing. Async is an absolutely horrible programming model. There are really only two advantages is brings: It lets you avoid the memory and context switching overhead of threads if you need to handle a very large number of requests concurrently, and it lets you do concurrency without worrying about synchronizing access to shared resources (but there are much better ways to do that).
- Jtsummers 5y ago
  If you use threads to cordon off the slow IO code, you're doing async IO, just without core language or library support for it.
  - brazzy 5y ago
    I was referring to using blocking IO, one thread per request. You know, the much simpler way that was the norm before async became fashionable.
- Karrot_Kream 5y ago
  > You absolutely do not need async IO for that. You can do that with a synchronous programming model just fine, using threads and letting the OS do its thing. "just fine" is highly relative here and is doing most of the work in your statement. Do you have any conditions under which this is "just fine"? Any more detail? Or else it's just a personal preference.
  - brazzy 5y ago
    A preference? The term was mostly meant to convey that it can be done without problems, contradicting the assertion that async IO "permits" the interleaving of fast and slow activities. Synchronous models have been used for that far longer and more often than asynchronous ones. CGI scripts, Perl, Java servlets all did synchronous IO while also interleaving slow and fast activities for decades before Node made async IO fashionable. An in my second paragraph, I specifically mentioned the specific conditions where async has advantages.
    - Karrot_Kream 5y ago
      > Synchronous models have been used for that far longer and more often than asynchronous ones. CGI scripts, Perl, Java servlets all did synchronous IO while also interleaving slow and fast activities for decades before Node made async IO fashionable. Node didn't make async IO fashionable, as much as you seem to want the beat the drum of "new/hype" vs "old/Lindy/mature". Synchronous IO was slow, memory-inefficient (to spawn multiple threads), and didn't scale well. Slow enough that the C10K [1] problem was framed to capture the issues. Event loops in net servers were mostly popularized by nginx [2] to explicitly solve the C10K problem, which is what started driving folks to use event-loop async programming. Moreover event loops had been popular for years in GUI programming before multiple cores simply because CPU-level parallelism just _was not possible_ (well except for ILP which is a bit different). For example, Tcl/Tk had an event loop driving GUI display logic for ages [3], which really is the same problem. Instead of waiting on NIC events, we were waiting on keyboard/mouse events instead. Just because it's old doesn't mean it's good. There are lots of old bad things and lots of old good things, just like there are lots of new bad things and lots of new good things. [1]: https://en.wikipedia.org/wiki/C10k_problem https://en.wikipedia.org/wiki/C10k_problem [2]: https://en.wikipedia.org/wiki/Nginx#HTTP_proxy_and_Web_server_features https://en.wikipedia.org/wiki/Nginx#HTTP_proxy_and_Web_serve... [3]: https://wiki.tcl-lang.org/page/Tcl+event+loop https://wiki.tcl-lang.org/page/Tcl+event+loop

orthecreedence 5y ago

Yeah, admittedly I could have gone with threading/hunchentoot and been much better off. It was probably stupid to forge the entire async path the way I did. To be fair, Turtl these days gets enough traffic where async does probably make sense for us, and nodejs is serving us well.