tokio-uring VS monoio

Link should be: https://github.com/tokio-rs/tokio-uring/blob/master/DESIGN.m...

I feel a bit paralyzed by Fear Of Missing Io_Uring. There's so much awesome streaming stuff about (RisingWave, Materialize, NATS, DataFusion, Velox, many more), but it all feels built on slower legacy system libraries.

It's not heavily used yet, but Rust has a bunch of fairly high visibility efforts. Situation sort of feels similar with http3, where the problem is figuring out what to pick. https://github.com/tokio-rs/tokio-uring https://github.com/bytedance/monoio https://github.com/DataDog/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

We have another service coming soon, one for which I'm not specifically looking at Go because of the requirements (mixed workload of 10+ GB heaps with deep hierarchies and a lot of small reads/writes on fast NVMes, low p99 network AND disk latency). I was thinking about jumping straight into Rust and using https://github.com/bytedance/monoio as it neatly fits our use case. I've done some things in Rust before, but not a lot. Long compile times I can handle, but I fear refactorings as I don't like when a language gets in my way. But we'll see - who knows!

I feel a bit paralyzed by Fear Of Missing Io_Uring. There's so much awesome streaming stuff about (RisingWave, Materialize, NATS, DataFusion, Velox, many more), but it all feels built on slower legacy system libraries.

It's not heavily used yet, but Rust has a bunch of fairly high visibility efforts. Situation sort of feels similar with http3, where the problem is figuring out what to pick. https://github.com/tokio-rs/tokio-uring https://github.com/bytedance/monoio https://github.com/DataDog/glommio

There is also another thread-per-core implementation by ByteDance (TikTok) for Rust called Monoio with benchmarks[0] comparing it to Tokio and Glommio.

[0] https://github.com/bytedance/monoio/blob/master/docs/en/benc...

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 assume Tokio itself, see e.g monoio or glommio, but also Seastar for C++.

I think monoio is also thread-per-core but also iouring https://github.com/bytedance/monoio. I don't know how you would shard certain keys into different threads, but if you can do that deterministically then there could be a significant speed up.

I believe this is also "thread-per-core".

Bytedance has their in-house monoio <https://github.com/bytedance/monoio> (supports io-uring) but it requires rust nightly.