5 ms·

Not sure about Python's async story, but in Node.js it is essential if your program's performance is I/O bound. There's no reason to let a thread stay idle whil

Not sure about Python's async story, but in Node.js it is essential if your program's performance is I/O bound. There's no reason to let a thread stay idle while waiting for a database operation to finish.

rjbwork 5y ago
That doesn't make your code faster though. For a particular bit of single threaded computation the async approach is going to be slower due to context switching overhead. Same in C#, Rust, etc. If your performance is I/O bound, then, as I said, it enables greater scalability by allowing computation to continue on other contexts while waiting for that I/O operation.
- davidkunz 5y ago
  Yes, this is absolutely correct. I don't think anyone would argue that async code makes CPU-bound computations faster, the opposite is the case because you have naturally more overhead.
frenchyatwork 5y ago
I don't think you disagreed at all with rjbwork at all, it's just you're using words differently. The article, and rjbwork, use slower to mean "slower when the CPU isn't regularly idling". In this context, Node.js async is slower as well, that's why the library better-sqlite3 for NodeJS is synchronous (because you're rarely going to be using sqlite in a context where the CPU/memory isn't very busy).
- davidkunz 5y ago
  Yes, I don't disagree with rjbwork. I may have read the article a bit differently, it sounded like "don't bother too much with async, it's slower, even for realistic web servers". In your I/O-bound Node.js server, if you would exchange all async calls with synchronous ones, your performance would get a big hit.
guywhocodes 5y ago
Yeah like being nagged on that you should async your fstat calls, which makes them four times slower.
__turbobrew__ 5y ago
Doesn’t your thread just get put to sleep by the kernel when it is blocked on I/O? Unless Node busy waits on I/O I don’t see the problem?
- davidkunz 5y ago
  Synchronous: The thread will block until the I/O operation is done. No work is performed in this time. Asynchronous: While waiting for the end of the I/O operation, the thread can continue to work, e.g. by handling other requests. So, it's not a problem when the thread sleeps while waiting for the end of the I/O operation, but it's not optimal.
  - __turbobrew__ 5y ago
    Sure, that one thread is blocked but it doesn’t take any CPU time and the rest of the threads on the system continue to run and handle requests? You can pretty easily run thousands of worker threads on a modern system so I don’t see the issue when one of your threads gets blocked on I/O? The linux kernel has a pretty good handle on multitasking, blocking, and scheduling so I don’t see the desire to rebuild the wheel in userspace with coroutines to achieve what the kernel already does.
    - davidkunz 5y ago
      Careful, this is not Erlang. These are real threads, you won't be able to have thousands of them, more like 20 [1]. If most of them are idle, then you can maybe increase it to ~100. They come with a considerable overhead, so it's better to have one thread handle several I/O operations concurrently and in parallel, than to have one thread dedicated to only one I/O operation. [1]: https://serverfault.com/questions/1012360/how-can-i-tell-the-maximum-threads-my-server-can-run#:~:text=Each%20core%20can%20only%20run,one%20thread%20per%20CPU%2Fcore https://serverfault.com/questions/1012360/how-can-i-tell-the....

rjbwork 5y ago

That doesn't make your code faster though. For a particular bit of single threaded computation the async approach is going to be slower due to context switching overhead. Same in C#, Rust, etc. If your performance is I/O bound, then, as I said, it enables greater scalability by allowing computation to continue on other contexts while waiting for that I/O operation.

davidkunz 5y ago
Yes, this is absolutely correct. I don't think anyone would argue that async code makes CPU-bound computations faster, the opposite is the case because you have naturally more overhead.

frenchyatwork 5y ago

I don't think you disagreed at all with rjbwork at all, it's just you're using words differently. The article, and rjbwork, use slower to mean "slower when the CPU isn't regularly idling". In this context, Node.js async is slower as well, that's why the library better-sqlite3 for NodeJS is synchronous (because you're rarely going to be using sqlite in a context where the CPU/memory isn't very busy).

davidkunz 5y ago
Yes, I don't disagree with rjbwork. I may have read the article a bit differently, it sounded like "don't bother too much with async, it's slower, even for realistic web servers". In your I/O-bound Node.js server, if you would exchange all async calls with synchronous ones, your performance would get a big hit.

guywhocodes 5y ago

Yeah like being nagged on that you should async your fstat calls, which makes them four times slower.

__turbobrew__ 5y ago

Doesn’t your thread just get put to sleep by the kernel when it is blocked on I/O? Unless Node busy waits on I/O I don’t see the problem?

davidkunz 5y ago
Synchronous: The thread will block until the I/O operation is done. No work is performed in this time. Asynchronous: While waiting for the end of the I/O operation, the thread can continue to work, e.g. by handling other requests. So, it's not a problem when the thread sleeps while waiting for the end of the I/O operation, but it's not optimal.
- __turbobrew__ 5y ago
  Sure, that one thread is blocked but it doesn’t take any CPU time and the rest of the threads on the system continue to run and handle requests? You can pretty easily run thousands of worker threads on a modern system so I don’t see the issue when one of your threads gets blocked on I/O? The linux kernel has a pretty good handle on multitasking, blocking, and scheduling so I don’t see the desire to rebuild the wheel in userspace with coroutines to achieve what the kernel already does.
  - davidkunz 5y ago
    Careful, this is not Erlang. These are real threads, you won't be able to have thousands of them, more like 20 [1]. If most of them are idle, then you can maybe increase it to ~100. They come with a considerable overhead, so it's better to have one thread handle several I/O operations concurrently and in parallel, than to have one thread dedicated to only one I/O operation. [1]: https://serverfault.com/questions/1012360/how-can-i-tell-the-maximum-threads-my-server-can-run#:~:text=Each%20core%20can%20only%20run,one%20thread%20per%20CPU%2Fcore https://serverfault.com/questions/1012360/how-can-i-tell-the....