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

Futures Is Stable on Rust 1.36

github.com

Post reply on HN
Print view View original

11–20 of 21 posts

Re: Futures Is Stable on Rust 1.36

#11

Post by rabito »

perfmode wrote: post #6
rabito wrote: post #4

How is the cost in terms of binary size nowadays? Last time I checked using Futures meant adding roughly 5MB to the binary. To me at least that is unacceptable, so I just rolled my own stuff on top of rayon's thread pools.

Where does the bloat come from? Which features are offered by the standard futures that you left out in your implementation?

It was the runtime required to actually run the Futures.

Rust's Futures allow for easy chaining, whereas I only implemented a simple callback that runs on completion, but it doesn't allow one to get at the computed value directly. I simply send a "check for updates" event there. Instead the value gets stored in a Mutex and has to be pulled out of that explicitly, although it can stay in the "Async" type, just that it gets stored directly in the struct after it's pulled out of the Mutex. The advantage is you don't have to pay for the locking all the time and the value can stay where it is, so you don't need to juggle it around. You can see it here: https://github.com/rabite0/hunter/blob/master/src/preview.rs...

I started working on an improved version that actually allows for a callback with a reference to the value upon completion and also a callback that moves the value out, but I haven't finished that yet and after seeing this I might not ever, but I probably will, since it's definitely educative.

Re: Futures Is Stable on Rust 1.36

#12

Post by marshray »

rabito wrote: post #4

How is the cost in terms of binary size nowadays? Last time I checked using Futures meant adding roughly 5MB to the binary. To me at least that is unacceptable, so I just rolled my own stuff on top of rayon's thread pools.

I just made a socket server for a small protocol, no (explicit) Tokio.

  [dependencies]
  futures-preview = { version = "0.3.0-alpha.14", features = ["io-compat"] }
  futures-util-preview = "0.3.0-alpha.14"
  byteorder = "1.2.7"
  clap = "2.32.0"
  log = "0.4.3"
  simple_logger = "0.5.0"
  lazy_static = "1.2.0"
  num-traits = "0.2"
  num-derive = "0.2"
  bytes = "0.4.12"
My source is on the order of ~1000 lines of (non-trivial) code and has 17 instances of 'async fn' and 23 instances of 'await!(...)'.

Nightly 2018, --release, the resulting .exe is 990 KiB.

Re: Futures Is Stable on Rust 1.36

#14

Post by cesarb »

jeffdavis wrote: post #13

If the current version of rust is 1.34.1, and futures is stabilized, why not 1.35? Not asking for this to happen, I am just curious about the stabilization/release process.

If the current stable version of Rust is 1.34, the current beta version of Rust is 1.35, and the currently nightly version of Rust (which is where major changes, including stabilization of features, are made) is 1.36.

Re: Futures Is Stable on Rust 1.36

#15

Post by bluejekyll »

rabito wrote: post #10
bluejekyll wrote: post #8

Earlier quoted context omitted.

You're probably thinking of the Tokio library in regards to the size, though I can't right now validate the size. Futures themselves are very lightweight.

Ah, yes, that was probably it. I stopped looking into Rust's Futures pretty much as soon as I noticed how heavyweight the required runtime is, which seemed ridiculous to me, since Futures are so simple conceptually. I have to look into this again. In general, Rust's big binaries are one of the things that puts me off the most. Even dynamic linking often doesn't help much. Then again, if a few MB, which is a rounding…

When Rust switched to the system allocator by default, that slimmed down the minimum size quite a bit. In addition to that, where size matters, there are some articles about how to slim it down even more, here's an example: https://github.com/johnthagen/min-sized-rust

Re: Futures Is Stable on Rust 1.36

#16

Post by rabito »

bluejekyll wrote: post #15
rabito wrote: post #10

Earlier quoted context omitted.

Ah, yes, that was probably it. I stopped looking into Rust's Futures pretty much as soon as I noticed how heavyweight the required runtime is, which seemed ridiculous to me, since Futures are so simple conceptually. I have to look into this again. In general, Rust's big binaries are one of the things that puts me off the most. Even dynamic linking often doesn't help much. Then again, if a few MB, which is a rounding…

When Rust switched to the system allocator by default, that slimmed down the minimum size quite a bit. In addition to that, where size matters, there are some articles about how to slim it down even more, here's an example: https://github.com/johnthagen/min-sized-rust

Thanks for the link! I knew about strip, which helps a lot, but the other options look promising as well.

I really care about binary size, since for short running programs, or when startup latency is important it can actually be much faster in real time to have less, but slower code. Especially so on a slow HDD like in my laptop. Loading a few MB when it's under heavy load can take a few seconds.

Edit: Wow, LTO makes a huge difference. Almost a 40% smaller in my case AND it's faster. Really excited to try xargo now.

Re: Futures Is Stable on Rust 1.36

#17

Post by steveklabnik »

rabito wrote: post #11
perfmode wrote: post #6

Earlier quoted context omitted.

Where does the bloat come from? Which features are offered by the standard futures that you left out in your implementation?

It was the runtime required to actually run the Futures. Rust's Futures allow for easy chaining, whereas I only implemented a simple callback that runs on completion, but it doesn't allow one to get at the computed value directly. I simply send a "check for updates" event there. Instead the value gets stored in a Mutex and has to be pulled out of that explicitly, although it can stay in the "Async" type, just that it…

To be clear, it's "a" runtime, not the runtime. It's the most popular one, but there's others as well, and some focus on embedded and binary size.

Re: Futures Is Stable on Rust 1.36

#18

Post by The_rationalist »

marshray wrote: post #12
rabito wrote: post #4

How is the cost in terms of binary size nowadays? Last time I checked using Futures meant adding roughly 5MB to the binary. To me at least that is unacceptable, so I just rolled my own stuff on top of rayon's thread pools.

I just made a socket server for a small protocol, no (explicit) Tokio. [dependencies] futures-preview = { version = "0.3.0-alpha.14", features = ["io-compat"] } futures-util-preview = "0.3.0-alpha.14" byteorder = "1.2.7" clap = "2.32.0" log = "0.4.3" simple_logger = "0.5.0" lazy_static = "1.2.0" num-traits = "0.2" num-derive = "0.2" bytes = "0.4.12" My source is on the order of ~1000 lines of (non-trivial) code and h…

And that is without stripping

Re: Futures Is Stable on Rust 1.36

#19

Post by rabito »

steveklabnik wrote: post #17
rabito wrote: post #11

Earlier quoted context omitted.

It was the runtime required to actually run the Futures. Rust's Futures allow for easy chaining, whereas I only implemented a simple callback that runs on completion, but it doesn't allow one to get at the computed value directly. I simply send a "check for updates" event there. Instead the value gets stored in a Mutex and has to be pulled out of that explicitly, although it can stay in the "Async" type, just that it…

To be clear, it's "a" runtime, not the runtime. It's the most popular one, but there's others as well, and some focus on embedded and binary size.

Sorry if that wasn't clear, it's been a rather long time since I checked on the Future story. There seem to be more options now than when I looked into it. When I did my research over half a year ago tokio seemed to be the only option. Glad to see that's not the case any more.

Re: Futures Is Stable on Rust 1.36

#20

Post by steveklabnik »

rabito wrote: post #19
steveklabnik wrote: post #17

Earlier quoted context omitted.

To be clear, it's "a" runtime, not the runtime. It's the most popular one, but there's others as well, and some focus on embedded and binary size.

Sorry if that wasn't clear, it's been a rather long time since I checked on the Future story. There seem to be more options now than when I looked into it. When I did my research over half a year ago tokio seemed to be the only option. Glad to see that's not the case any more.

It’s all good! To elaborate a bit, there’s a trait, Executor, that people can implement to build these kinds of things. This stuff, along with the final version of Futures, stabilized a few days ago. But it’s been baking a while.
Post reply on HN