4 ms·
Performance is not only wall clock time. With high latency, I/O bound tasks, the cost will be often determined by how much memory you need. And in the cloud, yo
by pkolaczk 2y ago
Performance is not only wall clock time. With high latency, I/O bound tasks, the cost will be often determined by how much memory you need. And in the cloud, you can’t pay for memory alone. The more memory you need, the more vcores you have to reserve. You might end up in a situation your cpus are mostly idling, but you can’t use fewer cores because of RAM needed to keep the state of thousands of concurrent sessions. In this case Rust async can bring a tremendous advantage over other languages, particularly Java and Go.
- palata 2y ago> you can’t use fewer cores because of RAM needed to keep the state of thousands of concurrent sessions. In this case Rust async can bring a tremendous advantage over other languages, particularly Java and Go. Can you elaborate on that? What about green threads?
- vlovich123 2y agoGreen threads can use more memory than async if you have a lot of I/O operations in flight since the stack is not precisely sized at pause points. Similarly, switching in new stacks is a bit more expensive than continuing a paused async task. Implementation details matter of course.
- palata 2y agoRight, that's interesting. Still curious to know if that is "slightly better" or if that qualifies for the "tremendous advantage" mentioned above!
- vlovich123 2y agoIt’s hard to say. If you want to use green threads, you may want to look at the may crate [1]. The reason Rust prioritized stackless async just like C++ did is that it fits better the systems programming needs (i.e. it’s syntactic sugar for a state machine you could hand implement) while not preventing things like stackful coroutines. If Rust manages to solve the coloring problem of async (e.g. by adopting effect systems [2] or alternatives), then stackful and stackless coroutines syntactic sugar could conceivably exist within the std language (perhaps leaving out stackless on nostd). The reason you don’t see both stackless and stackful coroutines in a single language like Rust is the coloring problem is made 50% worse. [1] https://crates.io/crates/may https://crates.io/crates/may [2] https://blog.yoshuawuyts.com/extending-rusts-effect-system/ https://blog.yoshuawuyts.com/extending-rusts-effect-system/
- steveklabnik 2y agoNote that May has soundness issues that the authors handwave away. You can get UB in safe code while using it.
- vlovich123 2y agoYou mean the TLS issue called out or something else? I wasn't trying to recommend may specifically of course. Or are you saying that stackful coroutines must have soundness issues due to missing language features to make it safe?
- steveklabnik 2y agoThe TLS thing, yeah. I am unsure if it's inherent to stackful coroutines or not, it's been a minute since I've dug into that.
- vlovich123 2y agoYeah, for TLS to work safely I suspect the only way would be language support which knows to media TLS through a "context pointer" so that the green threads could restore the context when resuming. In C++ the story is even worse because someone could take the address of a TLS variable & use it elsewhere. I think in general it's very very tricky to mix TLS and stackful coroutines that can be scheduled on arbitrary threads and languages like Go pick the stackful coroutines and drop the ability to do TLS. To be fair though, I think people generally just avoid TLS when running with green thread systems.