3 ms·
> Sure, but that overhead is also not essential, but a feature of Go's particular implementation. The only way to get around the FFI performance problem would
by pcwalton 7y ago
> Sure, but that overhead is also not essential, but a feature of Go's particular implementation.
The only way to get around the FFI performance problem would be for all fibers to have big stacks. At that point you've thrown away their biggest selling points: high scalability and fast spawning.
- pron 7y ago> The only way to get around the FFI performance problem would be for all fibers to have big stacks. I don't know all of Rust's specific constraints, but it is not the case in general. There are two levels for FFI support in this context, based on whether you want to allow FFI to block the lightweight thread (perhaps through an upcall), or not. Only if you want to allow that do you need "big stacks", but even then they can be "virtually big" but "physically small". If you don't, then all you need to do is to temporarily run FFI code on a "big stack", but you know that all the FFI frames are gone by the time you want to block. Depending on your FFI, if you don't allow the FFI code to hold pointers into you language's stack, you're all good.
- Rusky 7y ago> Depending on your FFI, if you don't allow the FFI code to hold pointers into you language's stack, you're all good. Rust does this with virtually all FFI.