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

Zero-cost futures in Rust

aturon.github.io

Post reply on HN
Print view View original

281–290 of 348 posts

Re: Zero-cost futures in Rust

#281

Post by benlwalker »

lightcatcher wrote: post #172
pcwalton wrote: post #134

Earlier quoted context omitted.

> Being able to express your code in a sequential manor and still gain the performance offered by implicit fiber,goroutine,w/e scheduling is pretty awesome. You don't gain as much performance. On Linux, you don't actually gain that much if anything over 1:1 threading. Most of the benefits of goroutines actually comes from the small stacks, which don't have anything to do with M:N and 1:1 to begin with—they're a featu…

> Why would you write networking code in C in 2016, when there are better alternatives available (like this one)? Support for kernel bypass networking libraries like ibverbs, DPDK (has an old unmaintained Rust wrapper) and other IO kernel bypass libraries such as SPDK and IOAT. If Rust supported these libraries, I'd much prefer the future based Rust code to a massive event loop in C.

I'm one of the authors of SPDK (which includes an NVMe driver and an IOAT driver). If the community wants to add rust bindings to those two components I'd be very supportive.

Re: Zero-cost futures in Rust

#283

Post by samnardoni »

nv-vn wrote: post #279

Anyone else find the f.select(g)/f.join(g) syntax unintuitive/awkward? I'm confused as to why they wouldn't go with the (IMO) more logical select(f, g) and join(f, g) in this case (since neither Future is really the "subject" in these cases). Not that this is a major concern (it would take only a few lines of code to change within your own program using an alias for the functions), just interested in knowing the rati…

You can write it both ways. t.method() is the same as T::method(t).

Re: Zero-cost futures in Rust

#284

Post by chme »

ridiculous_fish wrote: post #91
Gankro wrote: post #82

Earlier quoted context omitted.

Each chain produces a different static type. If you want to do a dynamic amount of chains (which seems strange to me? Got an example?) you would need to allocate and use dynamic dispatch, yes. Basically `MyFuture.map(x)` => `Map ` `MyFuture.map(x).map(y)` => `Map , Y>` This is obviously disgusting to expose to users, which is one of the reasons this post uses the `impl Trait` syntax to cover it up and say "well it's…

Thanks for your answer. Here's a more realistic example. Say we have a file.close() function that returns a Future , indicating when the close is complete. Now we want to make a Future for closing a list of files: let fut = Future ::new(); let v = vec![file, file2, file3]; for file in v.into_iter() { fut = fut.and_then(file.close()); } Is this possible with this API, or would the assignment to `fut` break because we…

Hmm... Shouldn't iterators be turned to streams?

Like this:

    fut = v.into_iter().map(|file| file.close()).into_future();

Re: Zero-cost futures in Rust

#287

Post by cyber1 »

Little benchmark rs-futures vs lwan (https://lwan.ws) on my machine Core i5

futures-minihttp(singlethread):

  $ wrk -c 100 -t 2 -d 20 http://127.0.0.1:8080/plaintext
  Running 20s test @ http://127.0.0.1:8080/plaintext
    2 threads and 100 connections
    Thread Stats   Avg      Stdev     Max   +/- Stdev
      Latency   823.09us  449.37us  20.98ms   98.69%
      Req/Sec    62.15k    10.51k  105.24k    48.63%
    2479035 requests in 20.10s, 340.44MB read
  Requests/sec: 123335.77
  Transfer/sec:     16.94MB
lwan(singlethread):

  $ wrk -c 100 -t 2 -d 20 http://127.0.0.1:8080/
  Running 20s test @ http://127.0.0.1:8080/
    2 threads and 100 connections
    Thread Stats   Avg      Stdev     Max   +/- Stdev
      Latency   596.45us  573.31us  24.46ms   99.33%
      Req/Sec    86.17k    13.15k  119.71k    76.00%
    3429720 requests in 20.01s, 624.73MB read
  Requests/sec: 171404.15
  Transfer/sec:     31.22MB
For lwan i use http server example from lwan.ws main page.

As you can see in this example C http server much faster than simple http Rust server.

* futures-minihttp release build

* lwan -O3

Re: Zero-cost futures in Rust

#288

Post by cm3 »

This is cool and validates Rust, but I just want to add that even 2kb stacks as mentioned in sibling comments is bigger than Erlang's process stacks. In Erlang 19.0.3, even with dirty-schedulers enabled, a process's default size is 338 words.

Re: Zero-cost futures in Rust

#289

Post by dan00 »

Manishearth wrote: post #266
eximius wrote: post #245

Earlier quoted context omitted.

I don't think I get that without an example. Do you know of any simple examples?

Gankro gave an example, but here's a better way to think about associated types: Think about them the same way you think of a method. Methods are "associated functions". If you implement a trait on a type, it can only have one version of a trait method, not two. Similarly, it can have one associated type, not multiple. With a generic trait the trait itself is generic; there are multiple "versions" of this trait so yo…

> Of course, Rust doesn't forbid having it the other way around -- we could make Output a generic parameter too, and have overloaded functions which can have different output types for the same input (and need type annotations to choose). But we don't want FnOnce to work that way, so we don't have it like that.

Can you please explain why FnOnce shouldn't work this way?

Re: Zero-cost futures in Rust

#290

Post by fnord123 »

Ygg2 wrote: post #51
losvedir wrote: post #27

I dabbled with rust in the past and was really fascinated with it, but haven't played around lately. One thing caught my eye in the post: fn get_row(id: i32) -> impl Future ; That return type looks odd to me. What does it mean to return an "impl", and is that a new feature in rust, or just something advanced that I missed in my exploration before?

Rust couldn't return Traits since they vary in return Size.So using couple of chain and maps would result in following syntax. fn did_too_many_chains() -> Chain >>>, SkipWhile >>> Now, you can write: fn did_too_many_chains() -> impl Iterator and be done with it.

That's awesome. I've been banging my head against the wall trying to implement a Drain iterator for a tree structure and it tries to recurse. I ended up with things like your Chain> and was banging my head against the wall over it.
Post reply on HN