tokio-uring VS glommio

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.

I used glommio as the async executor (instead of something like tokio), and it is wonderful. For people wondering whether it's "good enough" or to use C++ and seastar (as I have thought about a lot before starting this project), take the leap of faith, it's fast - both in terms of run time and to code.

My understanding is you always need a runtime, somethings needs to drive the async flow. But there are others on the market, just not without the.. market domination... of tokio.

https://github.com/smol-rs/smol looks promising simply for being minimal

https://github.com/bytedance/monoio looks potentially easier to work with than tokio

https://github.com/DataDog/glommio is built around linux io_uring and seems somewhat promising for performance reasons.

I haven't played with any of these yet, because Tokio is unfortunately the path of least resistance. And a bit viral in how it's infected tings.

I think you missed one which is based on io_uring [1].

In my benchmarks with a slightly tweaked version it was 2x faster than Nginx and and 30x faster than Python's SimpleHttpServer.

[1] https://github.com/DataDog/glommio/blob/master/examples/hype...

b) It's proven now e.g Seastar, Glommio that the fastest way to run a multi-threaded application is to have one instance with one thread pinned per CPU core. Then to have fibers/lightweight threads on top handling all of the asynchronous code. Your approach of lots of instances is the slowest so there will be a ton of unnecessary thread context-switching.

I assume Tokio itself, see e.g monoio or glommio, but also Seastar for C++.

https://github.com/DataDog/glommio Rust thread per core library.

> Few of us have really figured out io_uring. But that doesn't mean it is slower.

seastar.io is a high level framework that I believe has "figured out" io_uring, with additional caveats the framework imposes (which is honestly freeing).

Additionally the rust equivalent: https://github.com/DataDog/glommio

This use case is perfect for https://github.com/DataDog/glommio which is a thread-per-core runtime that is appropriate for latency sensitive code.

It's worth mentioning: Under "Async Executors", for "io_uring" there is only "Glommio"

I recently found out that ByteDance has a competitor library which supposedly has better performance:

https://github.com/bytedance/monoio

https://github.com/DataDog/glommio/issues/554

FYI, Datadog has a Rust library for scheduling things to run thread-per-core with io_uring

It'd be really useful for DB use cases:

https://github.com/DataDog/glommio