I have a computation that most of the time is CPU heavy. There are dependencies between tasks, where some tasks sometimes wait for partial results from other tasks. It seems async is perfect for this. If the runtime uses as many threads as there are cpu cores, it should normally max out all the cor…

Another pattern I have seen sometimes is to orchestrate the blocking work in the runtime by spawning tasks off for each piece of work, having a single-threaded runtime similar to your IO one move around data and spawn tasks as necessary.

[image] tczajka: Is there any reason not to just use the core tokio threads for this? I think if a "normal" Tokio thread blocks, then some I/O operations may hang.

Basically, tokio can't predict that you're about to spend the next two minutes spinning in the current thread, so it has no way to know it needs to push your other work to another thread, or that it needs to start another one. This might not be a problem in practice for your current program, on your…

[image] simonbuchan: By default, tokio starts (core count - 1) threads for non blocking work, so you can quite easily block yourself in this situation any time there is a dependency (await). Can you elaborate? Why would I deadlock myself on await? If a task is awaiting on something, wouldn't …

Based on @simonbuchan 's worker_threads = 1, I made the following example: #[tokio::main(flavor = "multi_thread", worker_threads = 1)] async fn main() { tokio::task::spawn(async move { // Compare with: //tokio::task::spawn_blocking(move || { println!("Going to sleep!"); s…

[image] jbe: println!("Some small task ..."); tokio::time::sleep(std::time::Duration::from_millis(100)).await; println!("... may take a long time now."); Yes I understand that, but I'm interested in overall throughput. So it's OK if a simple task takes a long time if something els…

There is a theorem bounding total computation time on N processors regardless of the order in which you schedule tasks: Brent's law . As long as tokio isn't wasting threads unnecessarily, it should satisfy that theorem. In other words, if at some point there are N cores (I would presumably set tokio…

You certainly can run CPU heavy things in a Tokio runtime, but it generally only makes sense if you only use the runtime for CPU heavy things. Putting any network IO on the same runtime would be a pretty bad idea, since your IO would frequently end up pausing for a long time. At this point I usually…

[image] alice: You certainly can run CPU heavy things in a Tokio runtime, but it generally only makes sense if you only use the runtime for CPU heavy things. Putting any network IO on the same runtime would be a pretty bad idea, since your IO would frequently end up pausing for a long time. R…

Using two runtimes with IO on just one is certainly possible. As for the communication between tasks, not if it has to happen via channels. It is true that async lets you do certain things more easily.

[image] alice: Another pattern I have seen sometimes is to orchestrate the blocking work in the runtime by spawning tasks off for each piece of work, having a single-threaded runtime similar to your IO one move around data and spawn tasks as necessary. Do you mean creating your own runtime in…

Tokio: using core threads for cpu-heavy computation

help

alice October 29, 2022, 9:16pm 13

No, I meant to do it within Tokio.

Your use-case sounds reasonable enough.

Topic		Replies	Views
Why shouldn't I use Tokio for my High-CPU workloads?	28	8949	November 12, 2021
Tokio Tasks for CPU-bound ops	4	1333	March 3, 2024
Don't fully understand tokio multithreaded runtime benefits help	18	6800	September 26, 2024
CPU intensive Tokio tasks end up on the same thread help	6	2294	June 24, 2021
Is it possible to launch this worker in a separate thread instead of blocking the main one? help	14	809	June 22, 2024

Tokio: using core threads for cpu-heavy computation

Related topics