2

I work on computationally-heavy code like PDE solvers that can generally be well parallelized using something like pthreads. The routines in std::thread appear to work well for this purpose. That said, there's a lot of press about the upcoming async/await stabilization and I'm not sure whether this has implications for code that should execute in parallel on separate cores.

I'm aware that concurrency is not the same as parallelization, but that doesn't seem to preclude an executor like Tokio from running processes in parallel. I'm curious whether async/await, Tokio, or the like has benefits for computation heavy processes or whether it's really best used for things like I/O.

Shepmaster
  • 388,571
  • 95
  • 1,107
  • 1,366
wyer33
  • 6,060
  • 4
  • 23
  • 53
  • It looks like your question might be answered by the answers of [What is the best approach to encapsulate blocking I/O in future-rs?](https://stackoverflow.com/q/41932137/155423). If not, please **[edit]** your question to explain the differences. Otherwise, we can mark this question as already answered. – Shepmaster Aug 26 '19 at 19:10
  • *preclude an executor like Tokio from running processes in parallel* — it already does. – Shepmaster Aug 26 '19 at 19:12
  • Note that async/await isn't unique to Rust, and exists in many other programming languages. Even beyond that specific syntax, the concepts of futures and promises exist in even more languages. See things like [Async/Await vs Threads](https://stackoverflow.com/q/15148852/155423); [If async-await doesn't create any additional threads, then how does it make applications responsive?](https://stackoverflow.com/q/37419572/155423). Learning about promises / futures will be way more beneficial. – Shepmaster Aug 26 '19 at 19:21
  • @Shepmaster Alright, so if I understand you correctly, `ThreadPool` (or `futures-cpupool`) is an executor that can execute processes in parallel using threads. These executors benefit from the new async/await syntax. Whether this is better or worse than `std::thread` depends on the application. Does that sound about right? – wyer33 Aug 26 '19 at 19:37
  • 3
    As I understand it, async/await is most beneficial to IO-bound tasks since now it can handle more block operations with less OS threads. As for CPU-bound tasks, I'd say it'll have far less impact. – edwardw Aug 26 '19 at 19:42
  • 1
    To be clear, `async` / `await` is (mostly) **syntax sugar** (see more details in [What is the purpose of async/await in Rust?](https://stackoverflow.com/q/52835725/155423)). The underlying concepts of futures (and the closely related promises in other languages) are more important. – Shepmaster Aug 26 '19 at 19:46
  • Yes, futures will see the **most** benefit in IO-bound tasks like network interaction, but it's not limited to that. See [nushell](http://www.jonathanturner.org/2019/08/introducing-nushell.html) as an example of using futures. My personal belief is that futures can also help with creating composible *interruptible* computations, but I don't have anything to back that up with. – Shepmaster Aug 26 '19 at 19:49

0 Answers0