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

301–310 of 348 posts

Re: Zero-cost futures in Rust

#301

Post by killercup »

cyber1 wrote: post #287

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: 12…

On Reddit [1], Alex mentioned that the single-thread case was not optimized (yet). What do the numbers for multi-threading look like?

[1]: http://reddit.com/r/rust/comments/4x8jqt/zerocost_futures_in...

Re: Zero-cost futures in Rust

#302

Post by cyber1 »

killercup wrote: post #301
cyber1 wrote: post #287

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: 12…

On Reddit [1], Alex mentioned that the single-thread case was not optimized (yet). What do the numbers for multi-threading look like? [1]: http://reddit.com/r/rust/comments/4x8jqt/zerocost_futures_in...

futures-minihttp(2 threads):

  $ 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   633.87us  808.22us  24.66ms   98.41%
      Req/Sec    86.72k     4.84k   94.90k    85.75%
    3452383 requests in 20.01s, 424.73MB read
  Requests/sec: 172546.21
  Transfer/sec:     21.23MB
lwan(2 threads):

  $ 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   375.26us  618.54us  20.60ms   98.21%
      Req/Sec   116.82k     5.56k  124.07k    92.25%
    4647906 requests in 20.00s, 846.62MB read
  Requests/sec: 232339.90
  Transfer/sec:     42.32MB

Re: Zero-cost futures in Rust

#303

Post by soulbadguy »

yazaddaruvala wrote: post #291
soulbadguy wrote: post #187

Earlier quoted context omitted.

No. they are not two different points. You are artificially restricting the argument, and saying that some parts are a different question by introducing this new idea of "inherent nature" of a closure in rust : Some humans have legs, some do not. Does it mean that having legs is not an "inherent" part of the human experience? So to go back to the argument, we are trying to compare using a coroutine base approach vs u…

May I ask, where do you assume a coroutine's stack lives? i.e. In relation to program memory

Not sure what you mean, but from my understating the coroutine e stacks are just allocated pieces of memory in the current address space ( might be stack allocated or heap allocated depending the the situation)

Re: Zero-cost futures in Rust

#304

Post by soulbadguy »

pcwalton wrote: post #263
soulbadguy wrote: post #255

Earlier quoted context omitted.

> There are no asynchronous operations in that go model, everything is synchronous. You are the second person saying this, and i have to admit i am really confused by this statement. From my understanding, golang does not expose an asyncio interface, but this doesn't meant that golang runtime doesnt perform io operations asynchronously. So golang expose async operation through a synchronious interface, which is what…

> From my understanding, golang does not expose an asyncio interface, but this doesn't meant that golang runtime doesnt perform io operations asynchronously. This is also true for an OS kernel.

I don't understand the point your are making

Re: Zero-cost futures in Rust

#305

Post by gravypod »

pcwalton wrote: post #134
sebcat wrote: post #122

Earlier quoted context omitted.

> I don't want M:N threading as Go implements it. As someone who writes code for enterpricey businesses doing a lot of I/O bound stuff, golang style M:N threading is a godsend over Java's standard library, and other common platforms in that space. 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. With futures, the…

> 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)?

As someone who's done a bit of game development in the past I can easily say that you'll fall flat on your face in some fields if you don't write your own protocols. There are simply no protocols that operate well in every use case and there are also use-cases without standardized protocols.

For extremely high performance operations you NEED to use a custom protocol in some case to squeeze every bit of power out of your applications.

From a game development perspective you need to handle two types of content: content that isn't really ordered by time occurrence and content that needs to happen sequentially.

Because of this you can correctly optimize your networking stack for those needs and get your networking system really fast.

Some people have taken to using TCP with a JSON message passing system and that just doesn't work large scale. You'll have huge latency issues and with a big enough game you have to do some serious bit-packing to make it cost effective to host servers for.

Now I'm speaking generally and this is just from my experience but there is definitely still a reason to write your own network code.

Re: Zero-cost futures in Rust

#306

Post by indeyets »

steveklabnik wrote: post #6
soulbadguy wrote: post #4

Finally a nice async/io interface for rust, always felt that it was a big missing piece, couple of questions for peps familiar with async in other languages : 1 - Isn't the state machine approach the same as C#/.net async/await is using ? But the with the added convenience of the syntactic sugar ? 2 - no allocation : , does'nt the lambda closure need to be allocated somewhere ? 3 - I would have love some comparison (…

1. I am not sure exactly how async/await is implemented, but I believe it is very similar. Some people are also working on implementing similar sugar in Rust, but it's not done yet. 2. Closures are on the stack, not the heap, by default, in Rust. If you don't see a Box, they're not heap allocated. 3. I agree!

(1) here's how it's done in JS: https://tc39.github.io/ecmascript-asyncawait/#desugaring

Re: Zero-cost futures in Rust

#307

Post by gpderetta »

haimez wrote: post #243
gpderetta wrote: post #193

Earlier quoted context omitted.

For the example if you are using kernel bypass of the network stack, which is increasingly common in high throughput/low latency applications.

If you're going to bypass the kernel network stack for performance, you're definitely not going to write the rest of your code in go. The garbage collector, goroutine scheduler, and conservative compile time optimizations will totally undermine the end goal. If you're in that world, you're using C, C++, or That if you're feeling dangerous.

FWIW, I wasn't thinking bout go.

Re: Zero-cost futures in Rust

#308

Post by gpderetta »

haimez wrote: post #247
gpderetta wrote: post #176

Earlier quoted context omitted.

As an example, many real-time systems are often a giant ball of messy asynchronous code and state machines. Futures can help with that, although lately I have found that somtimes the best, cleanest, way to implement a state machine is to make it explicit.

How much do you attribute that to the benefit of creating a high barrier to entry for modifying that code? Could this be summarized as: code that inexperienced devs can't understand, stays performant because they can't figure out how to change it?

None of the teams I've worked with had such a policy and certainly I wouldn't work in a team like that.

Re: Zero-cost futures in Rust

#310

Post by fmap »

pcwalton wrote: post #230
mindslight wrote: post #226

Earlier quoted context omitted.

> This requires that you either know the size of the stack up front ... generally not possible without being conservative Well, you are writing the compiler. Sure you'd be up against the halting problem, but relatively few functions are (non-tail) recursive. Perhaps the unwieldiness of a large stack is better attributed to the feature of unbounded recursion (and FFI into "uncharted territory") than the feature of gre…

It would require higher order control flow analysis like k-CFA, which would certainly fail to produce a bounded stack size on any nontrivial program. The futures library is the control flow analysis. Because it uses the type system instead of higher order control flow analysis, it actually achieves precision.

Are you sure about that? First, many higher-order constructs boil down to simple first-order control flow after partial evaluation (see e.g. AnyDSL https://anydsl.github.io/#publications). Inferring stack size bounds in the presence of higher-order programming features is also possible, and was implemented (as the "static region optimization") in MLkit.

But the main point is that code in a high-level programming language looks very different from C or even Rust code. Sparks in Haskell, or processes in Erlang, or even individual goroutines in Go, are typically executing comparatively tiny programs. If the call graph of the program in question is acyclic, then it should be easy to get a bound on the maximum stack size.

To be clear, I agree with you that a 1:1 threading model is the better design for Rust, simply because it's the only design where you can guarantee zero overhead and don't need a complicated runtime. What I don't agree with is that the M:N threading model is inherently inferior. Especially for a high-level programming language, I would assume that you can reduce the overhead significantly through static analysis and a good implementation.

Post reply on HN