3 ms·

What makes you think that? Looking at the summary it looks like async is better in every way.

scottlamb 6y ago
Better or equal in all the ways measured. But some things aren't measured, maybe because they're obvious to the author or because they're harder to quantify. * Rust's async ecosystem [1] adds a lot of complexity over simple threaded code. * Rust's async ecosystem doesn't interoperate as easily with C libraries written in a simple threaded way. (And it's debatable which interoperates more easily with C libraries written with a different event loop.) * async tasks can't be preempted, so concurrency will fall off a cliff if they run on O(cpus) threads and involve long-running computations or accidental blocking. I think it's reasonable to ask if these numbers are enough better to justify all that, particularly given the disappointing "this advantage goes away if the context switch is due to I/O readiness". And to go back and argue pro-async for a moment, io_uring might eliminate that disappointing caveat. Then again, on the pro-thread side, there's Google's interesting fibers model that might solve some of these performance issues. [2] Also, "~17µs for a new kernel thread" is the wrong number, since you can avoid that cost with a simple thread pool. Personally I think some things are better written as async, but it's a mistake to impose it on everything. For example, if you're writing a web app in Rust, I think you're usually better off writing threaded request handlers and having a mechanism for them to interact with the async hyper code. The hyper code is better off as async because an Internet-facing server might have an enormous number of connections in keepalive state. [1] or maybe I should say ecosystems, plural, given the current tokio vs async-std divide. [2] https://lwn.net/Articles/826860/ https://lwn.net/Articles/826860/
andrewchambers 6y ago
async rust is more complex with a larger dependency tree and is harder to write. You get a marginal to good benefit if you have a specific work load that I think most people don't really have.

Better or equal in all the ways measured. But some things aren't measured, maybe because they're obvious to the author or because they're harder to quantify. * Rust's async ecosystem [1] adds a lot of complexity over simple threaded code. * Rust's async ecosystem doesn't interoperate as easily with C libraries written in a simple threaded way. (And it's debatable which interoperates more easily with C libraries written with a different event loop.) * async tasks can't be preempted, so concurrency will fall off a cliff if they run on O(cpus) threads and involve long-running computations or accidental blocking. I think it's reasonable to ask if these numbers are enough better to justify all that, particularly given the disappointing "this advantage goes away if the context switch is due to I/O readiness". And to go back and argue pro-async for a moment, io_uring might eliminate that disappointing caveat. Then again, on the pro-thread side, there's Google's interesting fibers model that might solve some of these performance issues. [2] Also, "~17µs for a new kernel thread" is the wrong number, since you can avoid that cost with a simple thread pool. Personally I think some things are better written as async, but it's a mistake to impose it on everything. For example, if you're writing a web app in Rust, I think you're usually better off writing threaded request handlers and having a mechanism for them to interact with the async hyper code. The hyper code is better off as async because an Internet-facing server might have an enormous number of connections in keepalive state. [1] or maybe I should say ecosystems, plural, given the current tokio vs async-std divide. [2] https://lwn.net/Articles/826860/ https://lwn.net/Articles/826860/

andrewchambers 6y ago

async rust is more complex with a larger dependency tree and is harder to write. You get a marginal to good benefit if you have a specific work load that I think most people don't really have.