That would be interesting to study. We'll do it for Java pretty soon, I guess.
> After all, even if you make stack growth fast, it's hard to compete with a system that has no stack growth at all!
If the same Rust workload were to run on such a system there wouldn't be stack growth, either. The stack would stay at whatever size Rust now uses to store the async fn's state.
> a tremendous amount of work in the Linux kernel
I don't think any work in the kernel would have been required.
> Ultimately, the choice was clear.
I agree the choice is pretty clear for the "zero-cost abstractions" approach, and that Rust should follow it given its target domains. But for domains where the "zero-cost use" approach makes more sense, the increase in accidental complexity is probably not worth some gain in worst-case latency. But that's always the tradeoff the two approaches make.
Assuming you know how to relocate stacks, you could implement efficient delimited continuations in Rust without the kernel's involvement, and use whatever it is you use for async/await scheduling today (so I'm not talking about some built-in runtime scheduler like Go's or Erlang's). But this would require changes in LLVM, and also a somewhat increased footprint (although the footprint could be addressed separately, also by changes in LLVM). The kernel work is only required if you want to suspend computations with non-Rust frames, which you can't do today, either.
I don't know what the old M:N model did, but a compiler can generate essentially the same code as it does for async/await without ever specifying "async" or "await." The reason for that is that the compiler already compiles any subroutine into a state machine (because that's what a subroutine is) in a form you need for suspension. But you do need to know what that form is, hence the required change in LLVM.
There is no inherent reason why it would be any slower or faster. It also does not imply any particular scheduling mechanism.
That would be interesting to study. We'll do it for Java pretty soon, I guess.
> After all, even if you make stack growth fast, it's hard to compete with a system that has no stack growth at all!
If the same Rust workload were to run on such a system there wouldn't be stack growth, either. The stack would stay at whatever size Rust now uses to store the async fn's state.
> a tremendous amount of work in the Linux kernel
I don't think any work in the kernel would have been required.
> Ultimately, the choice was clear.
I agree the choice is pretty clear for the "zero-cost abstractions" approach, and that Rust should follow it given its target domains. But for domains where the "zero-cost use" approach makes more sense, the increase in accidental complexity is probably not worth some gain in worst-case latency. But that's always the tradeoff the two approaches make.