5 ms·

Have 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 h

Have 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 https://github.com/tokio-rs/tokio-uring

otabdeveloper4 5y ago
"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.
- jeltz 5y ago
  Care to explain why they only make sense for interpreted languages and what limitations you are talking about? Async in Rust is mostly just a convenient syntax around ideas which has been around in the C and C++ worlds for decades with libraries like libevent.
- jandrewrogers 5y ago
  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.
  - MuffinFlavored 5y ago
    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?
    - vlovich123 5y ago
      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.
    - weq 5y ago
      http://think-async.com/Asio/asio-1.5.3/doc/asio/overview/core/async.html http://think-async.com/Asio/asio-1.5.3/doc/asio/overview/cor...
  - errantmind 5y ago
    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'
    - alexchamberlain 5y ago
      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.
      - errantmind 5y ago
        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
  - otabdeveloper4 5y ago
    > ...is because they have much higher throughput than the alternatives You're equating "high-performance" with "throughput". This is a classic newbie mistake and exactly what I mean when I mention cargo-cult.
- staticassertion 5y ago
  Yes, io_uring, a linux subsystem, is clearly just a cargo cult feature for people who don't know what they're doing.
  - errantmind 5y ago
    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)
    - staticassertion 5y ago
      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.
      - errantmind 5y 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 https://github.com/axboe/liburing/issues/189
    - threeseed 5y ago
      Up to 2.44x faster for network zerocopy send: https://lore.kernel.org/io-uring/cover.1638282789.git.asml.silence@gmail.com/ https://lore.kernel.org/io-uring/cover.1638282789.git.asml.s... Up to 1.6x faster than epoll: https://twitter.com/axboe/status/1362271500489793539 https://twitter.com/axboe/status/1362271500489793539 io_uring 11% faster for non-polled IO: https://twitter.com/axboe/status/1465358880502861829/photo/1 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.
- CyberRabbi 5y ago
  “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.
  - jlokier 5y ago
    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.
    - CyberRabbi 5y ago
      > It is the same state that threaded systems store. Nope. Synchronous task switching systems additionally have to store CPU register state. In the cooperative case you need to store the caller-saved registers, in the pre-emptive case you need to store all the registers. Async systems simply don’t have to do that extra work. > But some async, stackless systems do a bunch of extra work unwinding and restoring entire call stacks whenever an async task pauses in await Just the really bad ones. In any competent system a callback is stored ready to handle the event. No “unwinding” necessary.
      - gpderetta 5y ago
        A cooperative synchronous task switching (i.e. fiber based) need only save the exact same information as an async based one (i.e. stackless coroutines): at a minimum a context pointer and an instruction pointer. Plus any live registers (which might be none). You only need to save caller saved registers fs your context switching routine uses the conventional ABI, but that's not a requirement.
- threeseed 5y ago
  As I posted above I integrated Hyper (web server) with Glommio (io_uring based async runtime). Based on my limited benchmarks against Vertx/Scala and Nginx it was significantly faster, had zero failed transactions and used a fraction of the memory/CPU. That means I need less servers and have a better end user experience.
threeseed 5y ago
Glommio uses io_uring: https://github.com/DataDog/glommio https://github.com/DataDog/glommio And I integrated Hyper as an example: https://github.com/DataDog/glommio/blob/master/examples/hyper.rs https://github.com/DataDog/glommio/blob/master/examples/hype... And the performance was blisteringly quick (6x better latency streaming from a file compared to Nginx).
mitchtbaum 5y ago
> Have any other Rust async runtimes use io_uring/gotten at all good yet? yes, check out `actix-rt` https://github.com/actix/actix-net https://github.com/actix/actix-net
- ibraheemdev 5y ago
  actix-rt is a wrapper around tokio's single threaded runtime, and (optionally) tokio-uring.

otabdeveloper4 5y ago

"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.

jeltz 5y ago
Care to explain why they only make sense for interpreted languages and what limitations you are talking about? Async in Rust is mostly just a convenient syntax around ideas which has been around in the C and C++ worlds for decades with libraries like libevent.
jandrewrogers 5y ago
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.
- MuffinFlavored 5y ago
  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?
  - vlovich123 5y ago
    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.
  - weq 5y ago
    http://think-async.com/Asio/asio-1.5.3/doc/asio/overview/core/async.html http://think-async.com/Asio/asio-1.5.3/doc/asio/overview/cor...
- errantmind 5y ago
  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'
  - alexchamberlain 5y ago
    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.
    - errantmind 5y ago
      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
- otabdeveloper4 5y ago
  > ...is because they have much higher throughput than the alternatives You're equating "high-performance" with "throughput". This is a classic newbie mistake and exactly what I mean when I mention cargo-cult.
staticassertion 5y ago
Yes, io_uring, a linux subsystem, is clearly just a cargo cult feature for people who don't know what they're doing.
- errantmind 5y ago
  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)
  - staticassertion 5y ago
    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.
    - errantmind 5y 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 https://github.com/axboe/liburing/issues/189
  - threeseed 5y ago
    Up to 2.44x faster for network zerocopy send: https://lore.kernel.org/io-uring/cover.1638282789.git.asml.silence@gmail.com/ https://lore.kernel.org/io-uring/cover.1638282789.git.asml.s... Up to 1.6x faster than epoll: https://twitter.com/axboe/status/1362271500489793539 https://twitter.com/axboe/status/1362271500489793539 io_uring 11% faster for non-polled IO: https://twitter.com/axboe/status/1465358880502861829/photo/1 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.
CyberRabbi 5y ago
“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.
- jlokier 5y ago
  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.
  - CyberRabbi 5y ago
    > It is the same state that threaded systems store. Nope. Synchronous task switching systems additionally have to store CPU register state. In the cooperative case you need to store the caller-saved registers, in the pre-emptive case you need to store all the registers. Async systems simply don’t have to do that extra work. > But some async, stackless systems do a bunch of extra work unwinding and restoring entire call stacks whenever an async task pauses in await Just the really bad ones. In any competent system a callback is stored ready to handle the event. No “unwinding” necessary.
    - gpderetta 5y ago
      A cooperative synchronous task switching (i.e. fiber based) need only save the exact same information as an async based one (i.e. stackless coroutines): at a minimum a context pointer and an instruction pointer. Plus any live registers (which might be none). You only need to save caller saved registers fs your context switching routine uses the conventional ABI, but that's not a requirement.
threeseed 5y ago
As I posted above I integrated Hyper (web server) with Glommio (io_uring based async runtime). Based on my limited benchmarks against Vertx/Scala and Nginx it was significantly faster, had zero failed transactions and used a fraction of the memory/CPU. That means I need less servers and have a better end user experience.

threeseed 5y ago

Glommio uses io_uring: https://github.com/DataDog/glommio https://github.com/DataDog/glommio And I integrated Hyper as an example: https://github.com/DataDog/glommio/blob/master/examples/hyper.rs https://github.com/DataDog/glommio/blob/master/examples/hype... And the performance was blisteringly quick (6x better latency streaming from a file compared to Nginx).

mitchtbaum 5y ago

> Have any other Rust async runtimes use io_uring/gotten at all good yet? yes, check out `actix-rt` https://github.com/actix/actix-net https://github.com/actix/actix-net

ibraheemdev 5y ago
actix-rt is a wrapper around tokio's single threaded runtime, and (optionally) tokio-uring.