Wasmtime GitHub notifications bot (Aug 01 2023 at 13:25): Wasmtime GitHub notifications bot (Aug 01 2023 at 13:25):SoniEx2 opened issue #6792:
Thanks for filing a feature request! Please fill out the TODOs below.
Feature
wasi is opaque to JIT. by implementing wasi in wasm it would make wasi no longer opaque to JIT.
Benefit
transparent to JIT means more optimizable. for example running posix code on top of wasi on top of posix means translating posix -> wasi, and then internally wasi -> posix. some of this translation could be optimized away.
Implementation
TBD
note: wasm is a strong sandbox, much stronger than most sandboxes out there. it is possible to expose functions (raw platform functions) to a module (wasi.wasm) that are not exposed to any other modules. (this is also advantageous in other JITed systems even without a sandbox, if you can trust the code - e.g. LWJGL3 does it.)
Alternatives
this is honestly the only viable approach to making wasi faster. but "not doing anything" is always an option.
Wasmtime GitHub notifications bot (Aug 01 2023 at 13:26):SoniEx2 edited issue #6792:
Thanks for filing a feature request! Please fill out the TODOs below.
Feature
wasi is opaque to JIT. by implementing wasi in wasm it would make wasi no longer opaque to JIT.
Benefit
transparent to JIT means more optimizable. for example running posix code on top of wasi on top of posix means translating posix -> wasi, and then internally wasi -> posix. some of this translation could be optimized away if the JIT could see it.
Implementation
TBD
note: wasm is a strong sandbox, much stronger than most sandboxes out there. it is possible to expose functions (raw platform functions) to a module (wasi.wasm) that are not exposed to any other modules. (this is also advantageous in other JITed systems even without a sandbox, if you can trust the code - e.g. LWJGL3 does it.)
Alternatives
this is honestly the only viable approach to making wasi faster. but "not doing anything" is always an option.
Wasmtime GitHub notifications bot (Aug 01 2023 at 13:45):bjorn3 commented on issue #6792:
Cranelift currently doesn't support inlining of any kind (https://github.com/bytecodealliance/wasmtime/issues/4127) So there is no benefit at all until that is implemented. Also WASI is not implemented directly on top of posix, but it is implemented on top of cap-std (+ tokio in case of async functions) which provides a capability abstraction like wasi on both unix and windows systems (as well as on wasm32-wasi itself). I'm not sure how much we can move into a wasm module without duplicating the entirety of cap-std and while still working on both unix and windows.
To be clear it is not a crazy idea at all. For example many javascript engines implement some "native" functions in javascript or the internal bytecode language that they compile javascript to to allow inlining. It is just that I'm not entirely sure that it will provide as much benefit for wasi compared to the effort it will likely take.
Wasmtime GitHub notifications bot (Aug 01 2023 at 13:54):SoniEx2 commented on issue #6792:
if you could force codegen for windows/linux library code to generate wasm... and then embed that... hmm...
Wasmtime GitHub notifications bot (Aug 01 2023 at 13:55):SoniEx2 edited a comment on issue #6792:
if you could force codegen for windows/linux library code to generate wasm... and then embed that... hmm...
(calling conventions might require additional wasmtime support tho)
Wasmtime GitHub notifications bot (Aug 01 2023 at 14:02):SoniEx2 edited a comment on issue #6792:
if you could force codegen for windows/linux library code to generate wasm... and then embed that... hmm...
(calling conventions might require additional wasmtime support tho)
it might also provide a considerable benefit on big-endian platforms. tho we're not entirely sure how to handle that tbh.
Wasmtime GitHub notifications bot (Aug 01 2023 at 14:04):SoniEx2 edited a comment on issue #6792:
if you could force codegen for windows/linux library code to generate wasm... and then embed that... hmm...
(calling conventions might require additional wasmtime support tho)
it might also provide a considerable benefit on big-endian platforms. would definitely complicate things tho.
Wasmtime GitHub notifications bot (Aug 03 2023 at 18:37):jameysharp commented on issue #6792:
I like the idea of exposing more syscall-like code to optimization! As bjorn3 commented, this is not easy to do, but it would be nice.
I expect that the actual system call from userspace to the kernel, and time spent in the kernel processing the request, is really the slow part. Compared to that, the handful of function calls between wasm and host-side Rust are probably not significant. I'd want to see the results of profiling (e.g. with Linux
perf) showing that there's significant time spent in the WASI implementation before trying to do something like this.I think the key issue here is that we allow Wasmtime's users to customize the behavior of things like filesystem access or clocks by writing arbitrary Rust. In theory, we could use bjorn3's work on cg-clif to compile host-side Rust code to CLIF, so it still has access to unchecked host memory and library code, which wasm doesn't. As bjorn3 noted, that wouldn't help unless we also had inlining support in Cranelift, and even then I'm not convinced we'd gain much, for the above reasons.
So my guess is this would be more complicated than it's worth. That said, it might be a fun experiment. @SoniEx2, it's welcome to try. I am skeptical that we'd be able to provide much help, or that we'd merge the result in Wasmtime, but I would enjoy being proven wrong!
I'm marking this as "not planned" because I don't think the Wasmtime project as a whole is going to put time into this, but I don't want to discourage experimenting.
Wasmtime GitHub notifications bot (Aug 03 2023 at 18:37):jameysharp closed issue #6792:
Thanks for filing a feature request! Please fill out the TODOs below.
Feature
wasi is opaque to JIT. by implementing wasi in wasm it would make wasi no longer opaque to JIT.
Benefit
transparent to JIT means more optimizable. for example running posix code on top of wasi on top of posix means translating posix -> wasi, and then internally wasi -> posix. some of this translation could be optimized away if the JIT could see it.
Implementation
TBD
note: wasm is a strong sandbox, much stronger than most sandboxes out there. it is possible to expose functions (raw platform functions) to a module (wasi.wasm) that are not exposed to any other modules. (this is also advantageous in other JITed systems even without a sandbox, if you can trust the code - e.g. LWJGL3 does it.)
Alternatives
this is honestly the only viable approach to making wasi faster. but "not doing anything" is always an option.
Last updated: Nov 22 2024 at 16:03 UTC