3 ms·
>Threads, obviously, accomplish the same thing, and arguably more easily. But threads have a performance problem when they must interact heavily. Cross-thread c
by simias 6y ago
>Threads, obviously, accomplish the same thing, and arguably more easily. But threads have a performance problem when they must interact heavily. Cross-thread communication is expensive.
I didn't know that cross "async" communication was cheaper, that does seem like a good selling point, but what exactly makes it cheaper? After all threads share the same address space, so you can just pass pointers around the same way you would within the same thread. I expected the overhead to be roughly similar.
Things can get cache-expensive if the code is running on different cores, but then again using all the hardware resources available is generally something you want to do if you care about performance.
- sanxiyn 6y agoI think the point is that you can omit atomics in async case, if you are always using async in single thread mode.
- thegeomaster 6y agoNot just atomics, you'd probably need mutexes or rwlocks in a lot of scenarios, and these can become a bottleneck quickly if you don't think it through. Async has the benefit of context switches (handing off execution) being explicit, so you're fine as long as you don't leave any half-updated state before you do an async function call.
- afavour 6y agoRust also lets you avoid atomics by using structs that implement Send. Having an async function return such a struct is a lot easier to map mentally (for me, at least)
- tijsvd 6y agoIt's faster than multiple threads even on a single core. There are syscalls involved to wait, and to wake up. That doesn't matter for I/O, since syscalls are involved anyway, but it does for mutexes and condition variables. With async, handing off control to one or more other tasks is cheap (tokio around 100 ns), for threads it's more expensive (2-3 us). And of course with threads it's harder to actually run single-core, you need to dedicated a specific core which brings operational complexity.