On Thu, Jul 4, 2013 at 6:33 PM, Patrick Walton <[email protected]> wrote: > On 7/4/13 12:58 PM, Daniel Micay wrote: >> >> You can create many threads with fixed stacks, they just start off >> using 4K instead of however much smaller our segmented stacks will be. >> A scheduler will just be more expensive than a regular lightweight >> task. >> >> The 15-100% performance hit from segmented stacks pushes Rust well out >> of the systems language niche. I think it does have to change if Rust >> plans on ever fitting in the niche that C, C++ and D do. > > > I agree. The sole benefit of segmented stacks on modern OS's that lazily > allocate pages is that, on 32-bit, you can avoid running out of address > space with many tasks. This is counterbalanced by these disadvantages:
If we do manage to get them significantly smaller than the page size, they're still potentially useful for I/O handling or as coroutines on x86_64. Like Go, we need to handle system calls and allocation within code aware of segmented stacks for them to really be useful. I think large stacks should be the default (task::spawn) with an API available to reserve a different minimum stack size (task::spawn_reserve(0), to get the smallest initial size). It could just be a clear memory vs. performance trade-off. The caching of stack segments won't be needed because stack growth would just be a fallback. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
