zap VS tokio-uring

This actually can be at the level of a missed optimization. A run queue with a lock-shared queue amongs all the threads scales even worse than the tokio version. Sharding the run queues and changing the notification algorithm, even while keeping locks on the sharded queues improves throughput drastically.

Tokio is an async runtime, but I don't see why being an async runtime should make it worse from a throughput perspective for a thread pool. I actually started on a Rust version [0] to test out this theory of whether async-rust was the culprit, but realized that I was being nerd-sniped [1] at this point and I should continue my Zig work instead. If you're still interested, I'm open to receiving PRs and questions on that if you want to see that in action.

It's still correct to benchmark and compare tokio here given the scheduler I was designing was mean to be used with async tasks: a bunch of concurrent and small-executing work units. I mention this in the second paragraph of "Why Build Your Own?".

The thread pool in the post is meant to be used to distribute I/O bound work. A friend of mine hooked up cross-platform I/O abstractions to the thread pool [2], benchmarked it against tokio to be have greater throughput and slightly worse tail latency under a local load [3]. The thread pool serves it's purpose and the quicksort benchmark is to show how schedulers behave under relatively concurrent work-loads. I could've used a benchmark with smaller tasks than the cpu-bound partition()/insertion_sort() but this worked as a common example.

I've already mentioned why rayon isn't a good comparison: 1. It doesn't support async root concurrency. 2. scoped() waits for tasks to complete by either blocking the OS thread or using similar inline-scheduler-loop optimizations. This risks stack overflow and isn't available as a use case in other async runtimes due to primarily being a fork-join optimization.

[0]: https://github.com/kprotty/zap/blob/blog-rust/src/thread_poo...

[1]: https://xkcd.com/356/

[2]: https://github.com/lithdew/hyperia

[3]: https://gist.github.com/kprotty/5a41e9612657de00788478a7dde4...

You can implement one: https://github.com/kprotty/zap/blob/lifo/src/runtime/Pool.zig

BTW If you're interested in work stealing, i'm writing my own which has a bundle of optimizations for minimal task dispatch overhead and memory efficiency. To appease some of your criteria: yes, it's currently being used in "real world production" for an http server (although not that specific version).

This is a logical fallacy. Specifically either a "Slippery Slope" or "Either/Or". You assume that fast channel implementations must have originated or have been ported to Rust and are both popular. Things like Stakker and zap are anecdotal examples of where this already isn't the case. Even so, there exists fast synchronized channels both inside and outside of async Rust. Because they aren't popular or aren't tuned to efficient runtimes doesn't mean they don't exist, which was my argument.

While Mio will probably not implement uring in its current design, there's https://github.com/tokio-rs/tokio-uring if you want to use io_uring in Rust.

It's still in development, but the Tokio team seems intent on getting good io_uring support at least!

As the README states, the Rust implementation requires a kernel newer than the one that shipped with Ubuntu 20.04 so I think it'll be a while before we'll see significant development among major libraries.

That's what the pool is for: https://github.com/tokio-rs/tokio-uring/blob/master/src/buf/fixed/pool.rs

Tokio supports io_uring (https://github.com/tokio-rs/tokio-uring), so perhaps when it's mature and battle-tested, it'd be easier to transition to it if Cloudflare aren't using it already.

- Tokio suffers from a similar problem

Eg via tokio-uring.

I strongly recommend you to look into io-uring and use async executors that take advantages of it: - tokio-uring (not recommended as it is still undergoing development) - monoio - glommio

This is my thinking as well. Specifically, I realized that if you don’t use tasks, but rather futures and join, than structured concurrency just works out (at the cost of less efficient poll). In a single-threaded/thread-per-core runtime, tasks could have the same semantics as futures. Somewhat elaborated here: https://github.com/tokio-rs/tokio-uring/issues/81

There's a new API on Linux called io_uring that has performance benefits, but most executors don't use it yet, except executors meant specifically to harness the power of io_uring like tokio-uring and Glommio

Breaking it down a bit further- Rust's async is zero-cost, and there's no way to write faster equivalent code to the language construct in Rust (and presumably other LLVM languages). Tokio introduces abstractions over OS APIs (indirectly) and provides a runtime. The runtime isn't zero cost, but it is likely to be better optimized for "standard" situations than a homebrewed solution, and its primary competition is in the form of other large async runtimes. On the other hand, Tokio's IO routines are (AFAIK) about as well written as one can get with blocking OS APIs, and the only competitors in that space are projects like tokio-uring that use APIs more well suited for asynchronous usage.