On Thu, Jul 4, 2013 at 7:49 PM, Daniel Micay <[email protected]> wrote: > 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.
Something else to note here is that a system call on Linux with the syscall instruction is only 2-3x as slow as our current FFI calls. Even a really terrible allocator would likely be better than what we're doing right now. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
