5 ms·

I still don't understand why async is faster. Sharding data can be as simple as a buffer per thread in a thread pool to catch incoming data. With async, don't y

I still don't understand why async is faster. Sharding data can be as simple as a buffer per thread in a thread pool to catch incoming data. With async, don't you havev to allocate that input buffer each time? That seems hideously expensive.

samsquire 3y ago
I enjoyed this article from Cal Paterson my excolleague. It's about Python async not being faster: https://calpaterson.com/async-python-is-not-faster.html https://calpaterson.com/async-python-is-not-faster.html I think the idea is that while your blocking waiting for IO in one task you can serve a different task, potentially from a different user. Coroutines, green threads, communicating sequential processes as in Go or Occam.
- jerf 3y ago
  Pure Python is a very slow language compared to Rust, with significant differences in orders of magnitudes of expenses. I would not expect information about Python performance to be particularly relevant to Rust without further evidence directly from Rust.
  - galangalalgol 3y ago
    I think in retrospect, it makes sense to me that if you are io bound vs cpu bound (like my stuff usually is) that async could let you wait on more things at a time.
    - jerf 3y ago
      I think the whole "IO bound" thing has taken on a life of its own and attained a legendary status that is not always an accurate reflection of reality. People often seem to model things as if "waiting on the DB" is all their system does and the code they wrote executes in exactly 0 nanoseconds, but that's not how it works. It isn't actually that hard to talk to a relatively local database with some well-optimized query and be doing CPU work either comparable to the wait you spent on the DB, or even greatly exceeding it, at which point your language's performance in fact does matter, potentially even dominates.
secondcoming 3y ago
async isn't typically 'faster' at all. It just lets do do more with fewer threads, and that has its own benefits. async can actually _increase_ the number of syscalls your application performs.
stonemetal12 3y ago
Which performance metric are you looking at for "faster"? Async is cooperative multitasking applied at a different level of abstraction. Much like OS level multitasking it adds overhead, and reduces performance in terms of latency. On the other hand it improves throughput by allowing better resource use. >don't you havev to allocate that input buffer each time? Have to? No, you could pre-allocate and reuse buffers. It is less straight forward than the buffer per thread strategy, but possible.

samsquire 3y ago

I enjoyed this article from Cal Paterson my excolleague. It's about Python async not being faster: https://calpaterson.com/async-python-is-not-faster.html https://calpaterson.com/async-python-is-not-faster.html I think the idea is that while your blocking waiting for IO in one task you can serve a different task, potentially from a different user. Coroutines, green threads, communicating sequential processes as in Go or Occam.

jerf 3y ago
Pure Python is a very slow language compared to Rust, with significant differences in orders of magnitudes of expenses. I would not expect information about Python performance to be particularly relevant to Rust without further evidence directly from Rust.
- galangalalgol 3y ago
  I think in retrospect, it makes sense to me that if you are io bound vs cpu bound (like my stuff usually is) that async could let you wait on more things at a time.
  - jerf 3y ago
    I think the whole "IO bound" thing has taken on a life of its own and attained a legendary status that is not always an accurate reflection of reality. People often seem to model things as if "waiting on the DB" is all their system does and the code they wrote executes in exactly 0 nanoseconds, but that's not how it works. It isn't actually that hard to talk to a relatively local database with some well-optimized query and be doing CPU work either comparable to the wait you spent on the DB, or even greatly exceeding it, at which point your language's performance in fact does matter, potentially even dominates.

secondcoming 3y ago

async isn't typically 'faster' at all. It just lets do do more with fewer threads, and that has its own benefits. async can actually _increase_ the number of syscalls your application performs.

stonemetal12 3y ago

Which performance metric are you looking at for "faster"? Async is cooperative multitasking applied at a different level of abstraction. Much like OS level multitasking it adds overhead, and reduces performance in terms of latency. On the other hand it improves throughput by allowing better resource use. >don't you havev to allocate that input buffer each time? Have to? No, you could pre-allocate and reuse buffers. It is less straight forward than the buffer per thread strategy, but possible.