Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Monoio – A thread-per-core Rust async runtime with io_uring

github.com

Post reply on HN
Print view View original

21–30 of 84 posts

Re: Monoio – A thread-per-core Rust async runtime with io_uring

#21

Post by alexchamberlain »

errantmind wrote: post #17
jandrewrogers wrote: post #5

Earlier quoted context omitted.

Async models are idiomatic for high-performance server code regardless of the programming language, particularly for anything I/O or concurrency intensive. The reason people use thread-per-core software architectures, which naturally require an async model, is because they have much higher throughput than the alternatives. If software performance, efficiency, and scalability are primary objectives, you are going to b…

The GP mentioned "async runtimes". There are other approaches to async that don't involve using an async runtime, like epoll / kqueue. I personally prefer writing synchronous code, running in multiple threads pulling from a shared work queue. It isn't a one-size-fits-all solution but it is widely applicable, and you get to avoid the complexity of writing 'async code'

Async runtimes are just wrappers around the underlying async technology, like epoll, kqueue and io_uring.

They give structure in a similar way if/for/while put structure around the underlying PC jumps.

Re: Monoio – A thread-per-core Rust async runtime with io_uring

#22

Post by errantmind »

staticassertion wrote: post #14
errantmind wrote: post #12

Earlier quoted context omitted.

Last I saw there was no substantial evidence of io_uring delivering a significant improvement over epoll, but I haven't looked in the last year. I wouldn't assume it is good just because it is in Linux (this is coming from someone who uses Linux exclusively)

I don't assume it's good because of Linux, I have a generally negative view of Linux. It's just stupid to attribute io_uring to rust or call it cargo culting for Rust to use io_uring. The two projects are unrelated. As for performance, I wouldn't judge based on a year ago, obviously a lot has changed since then - you can find numbers if you'd like, I saw the maintainer posting benchmarks only a few weeks ago.

Yea, I'll have to check it out again. I see very mixed results, it is likely io_uring may not fully replace epoll for all situations as some people thought it would. That's fine though

https://github.com/axboe/liburing/issues/189

Re: Monoio – A thread-per-core Rust async runtime with io_uring

#23

Post by errantmind »

threeseed wrote: post #18
errantmind wrote: post #12

Earlier quoted context omitted.

Last I saw there was no substantial evidence of io_uring delivering a significant improvement over epoll, but I haven't looked in the last year. I wouldn't assume it is good just because it is in Linux (this is coming from someone who uses Linux exclusively)

Up to 2.44x faster for network zerocopy send: https://lore.kernel.org/io-uring/cover.1638282789.git.asml.s... Up to 1.6x faster than epoll: https://twitter.com/axboe/status/1362271500489793539 io_uring 11% faster for non-polled IO: https://twitter.com/axboe/status/1465358880502861829/photo/1 And it's not like io_uring is complete. With every kernel release the gap over epoll gets bigger.

I was unable to replicate these results, and neither can other people. I'll look into it again though and see.

https://github.com/axboe/liburing/issues/189

edit: I'm not sure why I'm unable to reply to the comment below but I don't think anyone is being unnecessarily combative. I linked it twice because it is relevant to both replies to my comment. There is useful information in that thread if you read it end to end. What it does demonstrate is io_uring isn't a clear cut improvement over a much simpler approach. That may change in the future as it is improved though.

Re: Monoio – A thread-per-core Rust async runtime with io_uring

#24

Post by Arnavion »

threeseed wrote: post #20
ezekiel68 wrote: post #3

I truly appreciate that this team uses nightly rust and only runs only Linux currently (due to relying on io_uring). Truly in the spirit of systems programming - focusing on a single, tight, efficient implementation first and leaving other considerations such as cross-platform compatibility for later. Lets those of us who love to live on the bleeding edge have our nice things too! :)

io_uring is coming to Windows: https://twitter.com/axboe/status/1396837335141134336

Following that through to the blog post ([1]), it's interesting how much new API they had to add. The Windows IO API is already completion-style (as opposed to epoll, etc's readiness-style) - userspace submits an async operation to the kernel, blocks on a channel to receive its result, and the kernel enqueues the result to said channel when it's done. So I naively assumed that they'd "just" have to refit io_uring's API on top of the existing Win32 API.

[1]: https://windows-internals.com/i-o-rings-when-one-i-o-operati...

Re: Monoio – A thread-per-core Rust async runtime with io_uring

#25

Post by jgilias »

I wonder how much and for what Rust is being used at Bytedance, given that this seems to be under their GitHub org. It's pretty interesting that they are apparently using it.

Edit: For those wondering who Bytedance are, I can save you a Google search. These are the people making TikTok.

Re: Monoio – A thread-per-core Rust async runtime with io_uring

#26

Post by wtallis »

errantmind wrote: post #23
threeseed wrote: post #18

Earlier quoted context omitted.

Up to 2.44x faster for network zerocopy send: https://lore.kernel.org/io-uring/cover.1638282789.git.asml.s... Up to 1.6x faster than epoll: https://twitter.com/axboe/status/1362271500489793539 io_uring 11% faster for non-polled IO: https://twitter.com/axboe/status/1465358880502861829/photo/1 And it's not like io_uring is complete. With every kernel release the gap over epoll gets bigger.

I was unable to replicate these results, and neither can other people. I'll look into it again though and see. https://github.com/axboe/liburing/issues/189 edit: I'm not sure why I'm unable to reply to the comment below but I don't think anyone is being unnecessarily combative. I linked it twice because it is relevant to both replies to my comment. There is useful information in that thread if you read it end to end.…

I really don't see why you've chosen to link to that github issue multiple times in this thread. The discussion in that issue doesn't convincingly demonstrate anything except that some people are trying to be unnecessarily combative about io_uring. We don't need to be dragging that attitude into HN threads. If you want to talk about some real performance problems with io_uring, find a way to do so without that baggage.

Re: Monoio – A thread-per-core Rust async runtime with io_uring

#27

Post by jlokier »

CyberRabbi wrote: post #9
otabdeveloper4 wrote: post #4

Earlier quoted context omitted.

"Async runtimes" is a thing that only makes sense for interpreted languages and their limitations. This thing is pure cargo cult and shows that Rust mostly appeals to newbies who don't know what they are doing.

“Async” / event loop systems will usually be more efficient because 1) they don’t have to store unnecessary processor state to memory between handling events and 2) they are associated with cooperative event handlers and the assumption of a cooperative system provides more opportunities for optimization.

Ironically, it is not true that "async" (stackless) event loop systems don't store unnecessary processor state to memory.

Those systems store the entire processing state in future object memory. It is the same state that threaded systems store.

Stackful context switching systems (which includes some kinds of efficient threads - I would count Linux kernel internal threads among these) store that same state in the stack and context objects when context switching, so in principle store about the same amount of state. But some async, stackless systems do a bunch of extra work unwinding and restoring entire call stacks whenever an async task pauses in await, and therefore take more CPU time to context switch than stackful systems do.

Re: Monoio – A thread-per-core Rust async runtime with io_uring

#28

Post by errantmind »

alexchamberlain wrote: post #21
errantmind wrote: post #17

Earlier quoted context omitted.

The GP mentioned "async runtimes". There are other approaches to async that don't involve using an async runtime, like epoll / kqueue. I personally prefer writing synchronous code, running in multiple threads pulling from a shared work queue. It isn't a one-size-fits-all solution but it is widely applicable, and you get to avoid the complexity of writing 'async code'

Async runtimes are just wrappers around the underlying async technology, like epoll, kqueue and io_uring. They give structure in a similar way if/for/while put structure around the underlying PC jumps.

Yes, but they also introduce a lot of complexity to the developer experience. It is turtles all the way down with async code, as they say

Re: Monoio – A thread-per-core Rust async runtime with io_uring

#29

Post by jlokier »

errantmind wrote: post #12
staticassertion wrote: post #6

Earlier quoted context omitted.

Yes, io_uring, a linux subsystem, is clearly just a cargo cult feature for people who don't know what they're doing.

Last I saw there was no substantial evidence of io_uring delivering a significant improvement over epoll, but I haven't looked in the last year. I wouldn't assume it is good just because it is in Linux (this is coming from someone who uses Linux exclusively)

I'm testing io_uring for file I/O for a database engine, which is a very different code path than networking with epoll, and so far I've been disappointed to find it roughly 20% slower than my userspace thread pool doing the same thing for that task.

Most likely there is some tweak to batching and maybe SQE submission watermarks, but I haven't found the formula yet.

I was surprised to find the sqpoll thread spins instead of a fast timer. Seems like a contention problem on a single core system, which still exist in VMs, etc.

Re: Monoio – A thread-per-core Rust async runtime with io_uring

#30

Post by aneutron »

staticassertion wrote: post #15
MuffinFlavored wrote: post #7

Earlier quoted context omitted.

> for later or for never :P why not prove like... "this is the best. all other platforms/circumstances/situations are subpar" if the performance differences are enough, i can picture people making excuses to avoid all of those other platforms (or just never using this... more likely)

Agreed. I wouldn't care if Rust dropped Windows/ OSX support entirely. Totally niche platforms.

I think you're being sarcastic, but I'm not totally sure.
Post reply on HN