Zero-cost futures in Rust

Post by JoshTriplett » Thu, Aug 11, 2016, 9:46 PM UTC

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.

Post by JoshTriplett » Thu, Aug 11, 2016, 9:48 PM UTC

pcwalton wrote: post #179

DblPlusUngood wrote: post #162

Earlier quoted context omitted.

The space overhead is significantly worse for native threading in the presence of many threads since each thread needs both a user and kernel stack. For M:N, there are N kernel stacks.

Fair enough, but kernel stacks are 8K. 10K user + kernel size is a far cry from the 2MB default pthread stack size people usually talk about when they talk about 1:1. I don't know of any benchmark comparing Go vs. a 1:1 implementation with 2K pthread stack sizes, but I would be surprised if the performance difference is large at all.

Post by pcwalton » Thu, Aug 11, 2016, 9:50 PM UTC

Thaxll wrote: post #180

pcwalton wrote: post #158

Earlier quoted context omitted.

Arguing about whether a 30% difference is "significant" isn't really interesting.

You're talking about using a language where you have to manually manage the memory, is significantly harder to use than Go, have less built-in concurrent patterns, inferior standard library, so yes 30% seems a very small benefit. I didn't had look into the benchmark but my guess is that it's waiting on the I/O so any language with good concurrent model will have the same numbers. The benchmark would have been more in…

Post by soulbadguy » Thu, Aug 11, 2016, 9:56 PM UTC

steveklabnik wrote: post #130

saynsedit wrote: post #119

Earlier quoted context omitted.

This is missing his point. "Increment" is called outside of its scope when the epoll triggers. If "counter" is stack allocated that would cause a segfault, so it must be heap allocated which is his point.

Well, they're two different points: closures in rust do not inherently have to heap allocate. But that also doesn't mean that they can _not_ be heap allocated either. And in this example, it's not even really the closures that allocate: it's still one allocation, regardless of the number of closures.

Post by anonymousDan » Thu, Aug 11, 2016, 10:05 PM UTC

pcwalton wrote: post #173

ansible wrote: post #160

Earlier quoted context omitted.

I haven't seen a benchmark of huge numbers of native threads vs. a userland scheduler, but I have a hard time imagining that a userland scheduler will beat the kernel's scheduler. The kernel scheduler has a much more global picture of the system compared to userland. Doesn't using kernel threads imply lots of context switches? Doesn't that tend to be expensive in terms of time on modern architectures?

> Doesn't using kernel threads imply lots of context switches? No, it's actually fewer context switches. That's because each I/O completion event goes straight from the kernel to the code that was waiting on it (1 context switch), not from the kernel to the userland dispatcher to the code that was waiting on it (2 context switches).