5 ms·

How much performance is gained by going async instead of blocking threads on modern hardware? Skimmed through https://vorner.github.io/async-bench.html https:/

by arve0 8y ago

How much performance is gained by going async instead of blocking threads on modern hardware? Skimmed through https://vorner.github.io/async-bench.html https://vorner.github.io/async-bench.html. If I understand it correctly, one get about twice the performance with async. Is this correct? Seems like a compromise (code complexity vs performance) not worth taking.

asdkhadsj 8y ago
Not to over simplify, but when you say code complexity, are you referring to the code you read? Like, the dev UX? If so, I'd argue that long term once async/await have landed properly, the code largely looks and behaves the same. With that said, I've not even used it yet, because I've got no clue when this is landing enough that I can reasonably use it.. and I'm on Nightly lol.
- arve0 8y ago
  > are you referring to the code you read? Yes, the code the developer needs to read, write and understand. I'm not familiar of how async/await will be in Rust, but I guess some code differences/complexities can be: 1. Make sure, manually(?), that all things are async / non-blocking. 2. Implementing Future.poll / wrapping types in Future? (What is Pin? ref https://rust-lang.github.io/async-book/execution/future.html https://rust-lang.github.io/async-book/execution/future.html) 3. Async polution, a function that uses async must be async too? 4. Setup some scheduler that maintain how many concurrent async operations one thread has? 5. More verbose error-messages / stack-traces?
  - hobofan 8y ago
    > 3. Async polution, a function that uses async must be async too? Coming from JS, that's a non-problem in Rust. You can easily make a function blocking by creating a event loop and resolving the future you get from another function in it. So when I refactor my code to be async, I'm starting by making a single function async, and the moving the event loop from function to function, until as much of the code is async as I want.
    - asdkhadsj 8y ago
      To add to that, not too long ago I was wishing Rust was more like Go on the Async front. Where the scheduler was more built into the language, and I didn't have to use "ugly" async/await stuff everywhere. In hindsight, I prefer async/await. My reason is primarily that like your example points out, it really lets me be in full control over the scheduled behavior. I could even take non-io work and make it "async". Ie, some long processing application takes a break every million iterations to let other tasks steal some work. That's just cool! Arguably a similar thing could be designed in Go if every million iterations you used some type of IO primitive, like sending some data over a channel, but the behavior of Rust's model is more fine grained.
  - asdkhadsj 8y ago
    Disclaimer: My understanding of Futures is limited. > 1. Make sure, manually(?), that all things are async / non-blocking. You'd have to make sure any IO you do is using Futures - ie, use a package to provide async IO primitives for disk and network access. You would also need to use the appropriate await syntax call on any future using methods - that would require a bit of overhead to know, but at least the compiler has your back on that. > 2. Implementing Future.poll / wrapping types in Future? In most cases I don't think you'd have a use case to implement a Future - would you? Ie, main IO calls are the big ones for wasting threads - and libraries like mio/hyper/etc provide your IO primitives. > 3. Async polution, a function that uses async must be async too? Yea, my understanding is that this is definitely an issue. I am already planning on using `async` tags on basically all my functions, because everything I use bound to IO in one form or another. On the bright side, I believe (don't quote me!) that you can drop ugly `fn foo() -> Futures<Item=Result<A,B>>` wrapping, since I believe `async fn foo() -> Result<A,B>` does the same thing. .. again, the syntax is not finalized haha. > 4. Setup some scheduler that maintain how many concurrent async operations one thread has? If you're using Async I'd imagine you'd already have chosen a scheduler. I believe Tokio will be the defacto - though Rayon might be involved here, not sure. > 5. More verbose error-messages / stack-traces? Errors themselves would be unaffected, if you're talking normal error values - remember those are just values in Rust, like Go, so not much special there. Though as you said, I imagine if you dump a trace it would look different, no idea. None of this post was meant to counter you in anyway. I just hoped to provide a bit of clarity on the tiny things I can contribute to. I hope I helped more than hurt. Have a nice day :)
steveklabnik 8y ago
That post is from a year ago, a lot has changed. And, for web servers, it can be more than 2x. For example, look at techempower's plaintext benchmark: https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=plaintext https://www.techempower.com/benchmarks/#section=data-r17&hw=... Hyper gets 7,013,819. It's async. Iron gets 109,815, and is synchronous. That's 63x. Iron uses hyper under the hood, so that should be a good comparison.
bluejekyll 8y ago
async isn't only about performance, but has other advantages, like reduced resource consumption. In addition to that async io also gives you better control over how to cancel io reads and writes on systems where the IO is not interruptible. But you are correct, if you don't have a specific need, async is generally harder than using threads for concurrency. Ideally the async/await work in Rust is going to make that trade-off less extreme than it is today, which may mean more people will feel comfortable using it as it should reduce boiler plate.
- hobofan 8y ago
  > but has other advantages, like reduced resource consumption Could you expand on that? I've never heard that mentioned about async before.
  - steveklabnik 8y ago
    You can think of a task as being a thread, but it has one single allocation that’s the exact possible stack size. No more, no less. This uses less memory than spinning up a thread with the default stack size. Yes, you could use the proper APIs and get the correct size too, but you have to figure that size out by hand for each thread. It just implicitly happens with tasks.
    - hobofan 8y ago
      Huh, I didn't know that! (I also misinterpreted the context as I read the top level comment as async vs a single thread with blocking code, but after rereading it that makes more sense.)
      - steveklabnik 8y ago
        It's all good; it's one of the things that's specific to our implementation. Other forms may or may not do this, but I'm pretty sure that it's novel to at least Rust, and maybe C++; there's some discussion that I think it can do this in some circumstances as well.
deleted 8y ago
[deleted]

by arve0 8y ago

asdkhadsj 8y ago

Not to over simplify, but when you say code complexity, are you referring to the code you read? Like, the dev UX? If so, I'd argue that long term once async/await have landed properly, the code largely looks and behaves the same. With that said, I've not even used it yet, because I've got no clue when this is landing enough that I can reasonably use it.. and I'm on Nightly lol.

arve0 8y ago
> are you referring to the code you read? Yes, the code the developer needs to read, write and understand. I'm not familiar of how async/await will be in Rust, but I guess some code differences/complexities can be: 1. Make sure, manually(?), that all things are async / non-blocking. 2. Implementing Future.poll / wrapping types in Future? (What is Pin? ref https://rust-lang.github.io/async-book/execution/future.html https://rust-lang.github.io/async-book/execution/future.html) 3. Async polution, a function that uses async must be async too? 4. Setup some scheduler that maintain how many concurrent async operations one thread has? 5. More verbose error-messages / stack-traces?
- hobofan 8y ago
  > 3. Async polution, a function that uses async must be async too? Coming from JS, that's a non-problem in Rust. You can easily make a function blocking by creating a event loop and resolving the future you get from another function in it. So when I refactor my code to be async, I'm starting by making a single function async, and the moving the event loop from function to function, until as much of the code is async as I want.
  - asdkhadsj 8y ago
    To add to that, not too long ago I was wishing Rust was more like Go on the Async front. Where the scheduler was more built into the language, and I didn't have to use "ugly" async/await stuff everywhere. In hindsight, I prefer async/await. My reason is primarily that like your example points out, it really lets me be in full control over the scheduled behavior. I could even take non-io work and make it "async". Ie, some long processing application takes a break every million iterations to let other tasks steal some work. That's just cool! Arguably a similar thing could be designed in Go if every million iterations you used some type of IO primitive, like sending some data over a channel, but the behavior of Rust's model is more fine grained.
- asdkhadsj 8y ago
  Disclaimer: My understanding of Futures is limited. > 1. Make sure, manually(?), that all things are async / non-blocking. You'd have to make sure any IO you do is using Futures - ie, use a package to provide async IO primitives for disk and network access. You would also need to use the appropriate await syntax call on any future using methods - that would require a bit of overhead to know, but at least the compiler has your back on that. > 2. Implementing Future.poll / wrapping types in Future? In most cases I don't think you'd have a use case to implement a Future - would you? Ie, main IO calls are the big ones for wasting threads - and libraries like mio/hyper/etc provide your IO primitives. > 3. Async polution, a function that uses async must be async too? Yea, my understanding is that this is definitely an issue. I am already planning on using `async` tags on basically all my functions, because everything I use bound to IO in one form or another. On the bright side, I believe (don't quote me!) that you can drop ugly `fn foo() -> Futures<Item=Result<A,B>>` wrapping, since I believe `async fn foo() -> Result<A,B>` does the same thing. .. again, the syntax is not finalized haha. > 4. Setup some scheduler that maintain how many concurrent async operations one thread has? If you're using Async I'd imagine you'd already have chosen a scheduler. I believe Tokio will be the defacto - though Rayon might be involved here, not sure. > 5. More verbose error-messages / stack-traces? Errors themselves would be unaffected, if you're talking normal error values - remember those are just values in Rust, like Go, so not much special there. Though as you said, I imagine if you dump a trace it would look different, no idea. None of this post was meant to counter you in anyway. I just hoped to provide a bit of clarity on the tiny things I can contribute to. I hope I helped more than hurt. Have a nice day :)

steveklabnik 8y ago

That post is from a year ago, a lot has changed. And, for web servers, it can be more than 2x. For example, look at techempower's plaintext benchmark: https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=plaintext https://www.techempower.com/benchmarks/#section=data-r17&hw=... Hyper gets 7,013,819. It's async. Iron gets 109,815, and is synchronous. That's 63x. Iron uses hyper under the hood, so that should be a good comparison.

bluejekyll 8y ago

async isn't only about performance, but has other advantages, like reduced resource consumption. In addition to that async io also gives you better control over how to cancel io reads and writes on systems where the IO is not interruptible. But you are correct, if you don't have a specific need, async is generally harder than using threads for concurrency. Ideally the async/await work in Rust is going to make that trade-off less extreme than it is today, which may mean more people will feel comfortable using it as it should reduce boiler plate.

hobofan 8y ago
> but has other advantages, like reduced resource consumption Could you expand on that? I've never heard that mentioned about async before.
- steveklabnik 8y ago
  You can think of a task as being a thread, but it has one single allocation that’s the exact possible stack size. No more, no less. This uses less memory than spinning up a thread with the default stack size. Yes, you could use the proper APIs and get the correct size too, but you have to figure that size out by hand for each thread. It just implicitly happens with tasks.
  - hobofan 8y ago
    Huh, I didn't know that! (I also misinterpreted the context as I read the top level comment as async vs a single thread with blocking code, but after rereading it that makes more sense.)
    - steveklabnik 8y ago
      It's all good; it's one of the things that's specific to our implementation. Other forms may or may not do this, but I'm pretty sure that it's novel to at least Rust, and maybe C++; there's some discussion that I think it can do this in some circumstances as well.

deleted 8y ago

[deleted]