4 ms·

> We all have multicore machines and it would be great if we could use more than 1/8 or 1/12 (or whatever high thread count of your beefy servers) of our hardwa

> We all have multicore machines and it would be great if we could use more than 1/8 or 1/12 (or whatever high thread count of your beefy servers) of our hardware. It is probably important here to realize that async solves concurrency, not parallelism. You can use async with a single threaded runtime for I/O concurrency and mix that with threads for computational parallelism for long running jobs. That said, there may be some benefit a multi-threaded runtime would have for the typical I/O bound app (after working around lifetime limitations by adding Send/Sync to data structures). This is because I/O bound programs and those requiring computation are not mutually exclusive and there is always some amount of computation going on, so there may still be some benefit. I doubt a synthetic benchmark would answer this as those typically don't measure any actual work performed, but just "requests/sec".

bkolobara 3y ago
> It is probably important here to realize that async solves concurrency, not parallelism. You can use async with a single threaded runtime for I/O concurrency and mix that with threads for computational parallelism for long running jobs. In my experience, it's impossible to mix threads and async tasks. They can't communicate or share state. Threads need locks, while async tasks require an awake mechanism. If you just stick to unbounded channels that don't block on send, you can get far, but in 99% cases you will need to decide upfront on a specific approach.
- thinkharderdev 3y ago
  This has not been my experience at all. Delegating compute-intensive tasks to rayon inside a tokio runtime is not particularly hard (assuming you can pipeline things to separate IO and compute effectively). A pattern that has worked quite well for me is to use ``` struct ComputeTask { some_state: SomeState, completion: Sender<Output>, } impl ComputeTask { fn run(self) { .. do you compute-intensive stuff self.sender.send(output); } } async fn do_stuff() -> Result<Output> { let (tx,rx) = tokio::sync::oneshot::channel(); let task = ComputeTask { .., tx } rayon::spawn(move || task.run()); rx.await } ```

bkolobara 3y ago

> It is probably important here to realize that async solves concurrency, not parallelism. You can use async with a single threaded runtime for I/O concurrency and mix that with threads for computational parallelism for long running jobs. In my experience, it's impossible to mix threads and async tasks. They can't communicate or share state. Threads need locks, while async tasks require an awake mechanism. If you just stick to unbounded channels that don't block on send, you can get far, but in 99% cases you will need to decide upfront on a specific approach.

thinkharderdev 3y ago
This has not been my experience at all. Delegating compute-intensive tasks to rayon inside a tokio runtime is not particularly hard (assuming you can pipeline things to separate IO and compute effectively). A pattern that has worked quite well for me is to use ``` struct ComputeTask { some_state: SomeState, completion: Sender<Output>, } impl ComputeTask { fn run(self) { .. do you compute-intensive stuff self.sender.send(output); } } async fn do_stuff() -> Result<Output> { let (tx,rx) = tokio::sync::oneshot::channel(); let task = ComputeTask { .., tx } rayon::spawn(move || task.run()); rx.await } ```