7 ms·
TLDR; I’ve claimed a few times that our futures library provides a zero-cost abstraction, in that it compiles to something very close to the state machine code
by jaytaylor 10y ago
TLDR;
I’ve claimed a few times that our futures library provides a zero-cost abstraction, in that it compiles to something very close to the state machine code you’d write by hand. To make that a bit more concrete:
- None of the future combinators impose any allocation. When we do things like chain uses of and_then, not only are we not allocating, we are in fact building up a big enum that represents the state machine. (There is one allocation needed per “task”, which usually works out to one per connection.)
- When an event arrives, only one dynamic dispatch is required.
- There are essentially no imposed synchronization costs; if you want to associate data that lives on your event loop and access it in a single-threaded way from futures, we give you the tools to do so.
This sounds quite badass and awesome. I'm not sure what other language implementations take this approach, but this is clearly an extremely beautiful, powerful, and novel (to me at least!) concept. Before reading this, I thought rust was great. This takes it to the next level, though.
- crudbug 10y agoGenerating state machine out of async fluent APIs was enlightening. How are are handling errors ? - One Error state with the context ?
- hawkice 10y agoThis is probably better answered by how Rust handles errors generally: https://doc.rust-lang.org/book/error-handling.html https://doc.rust-lang.org/book/error-handling.html Suffice it to say, similar magic tricks have already been at work to make handling errors not soak up a lot of space, and it'd work well with something like this, I think.
- crudbug 10y agoGenerating state machine out of async fluent APIs was enlightening. How are are handling errors ? - One Error state with the context ?
- merb 10y agothat sounds great but I guess that will make the compilation time bigger.
- pcwalton 10y agoCompared to what?
- merb 10y agocompared to a non free rust future
- deleted 10y ago[deleted]
- Manishearth 10y agoYeah, using closures in zero-cost abstractions (like iterator or now future adaptors) does make compilation slow. LLVM isn't used to this kind of code, and takes time optimizing it. However, now that we have MIR we can optimize this on the Rust side first, before the type info has been lost. This was one of the reasons MIR was added :)
- deleted 10y ago[deleted]
- dbaupp 10y agoI'm... curious about why you think LLVM isn't used to the sort of code that results from these sort of zero-cost abstractions: C++ code is also very aggressive about templates that inline away to nothing, and modern C++ especially has many similar abstractions to Rust (cf. closures, and the range proposal). Rust isn't special in that particular regard. Maybe you mean LLVM is very low-level and thus it sees everything in the abstractions, which obviously takes time to sort through (and is especially wasteful to do multiple times for different monomorphisations). Thus, using MIR to optimise at a higher level can simplify code more efficiently before it hits LLVM.
- rcthompson 10y agoAnd in practice: > ...we’ve added a comparison of minihttp against a directly-coded state machine version in Rust. The two are within 0.3% of each other.