Monoio – A thread-per-core Rust async runtime with io_uring
1–10 of 84 posts
Re: Monoio – A thread-per-core Rust async runtime with io_uring
#2Have any other Rust async runtimes use io_uring/gotten at all good yet?
Best of the best modern systems programmers gotta get good sometime. Not sure if it's happening yet. Ok here's one point of call: https://github.com/tokio-rs/tokio-uring
Re: Monoio – A thread-per-core Rust async runtime with io_uring
#3I 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! :)
Re: Monoio – A thread-per-core Rust async runtime with io_uring
#4Have any other Rust async runtimes use io_uring/gotten at all good yet? Best of the best modern systems programmers gotta get good sometime. Not sure if it's happening yet. Ok here's one point of call: https://github.com/tokio-rs/tokio-uring
"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.
Re: Monoio – A thread-per-core Rust async runtime with io_uring
#5Have any other Rust async runtimes use io_uring/gotten at all good yet? Best of the best modern systems programmers gotta get good sometime. Not sure if it's happening yet. Ok here's one point of call: https://github.com/tokio-rs/tokio-uring
"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 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 be writing a lot of async code in a systems language like Rust or C++. People that “know what they are doing” understand this and why. Hence the interest in async libraries for Rust.
Re: Monoio – A thread-per-core Rust async runtime with io_uring
#6Have any other Rust async runtimes use io_uring/gotten at all good yet? Best of the best modern systems programmers gotta get good sometime. Not sure if it's happening yet. Ok here's one point of call: https://github.com/tokio-rs/tokio-uring
"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.
Yes, io_uring, a linux subsystem, is clearly just a cargo cult feature for people who don't know what they're doing.
Re: Monoio – A thread-per-core Rust async runtime with io_uring
#7I 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! :)
> 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)
Re: Monoio – A thread-per-core Rust async runtime with io_uring
#8Earlier 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 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…
can you take code that is blocking in nature and make it async (like an FFI dlsym call), or at a low level does that just boil down to lots of polling/timers?
Re: Monoio – A thread-per-core Rust async runtime with io_uring
#9Have any other Rust async runtimes use io_uring/gotten at all good yet? Best of the best modern systems programmers gotta get good sometime. Not sure if it's happening yet. Ok here's one point of call: https://github.com/tokio-rs/tokio-uring
"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.
Re: Monoio – A thread-per-core Rust async runtime with io_uring
#10Earlier 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…
can you take code that is blocking in nature and make it async (like an FFI dlsym call), or at a low level does that just boil down to lots of polling/timers?
Not sure what code you’re looking at but in reality all code is asynchronous by nature (ie you ask the HW to do something and it tells you it’s done some time later). Then we layer blocking syscalls on top and then you layer async underneath. Io_uring is an attempt at getting everything asynchronous top to bottom.
Some times we use polling if there’s sufficient traffic and interrupts are inefficient but that’s still asynchronous, just batched.