abrown edited PR #4949 from wasi-parallel-cpu
to main
:
This change implements [
wasi-parallel
] in Wasmtime. It addresses only the CPU parallelism (not GPU), since this would introduce additional complexity to an already difficult review (if you're interested about the GPU progress, talk to @egalli). Each commit implements a separate piece to the puzzle. Though most of the changed lines are not the core implementation (seetests
,LICENSE
, etc.), due to the size of the PR, it may be convenient to look at this commit by commit.[
wasi-parallel
]: https://github.com/WebAssembly/wasi-parallelI see several issues highlighted by this change:
- __lacking toolchain support__: in the absence of any other feasible path, the WebAssembly bytes of the kernel code to be executed in parallel are embedded in the host WebAssembly module itself. This is problematic for many reasons, not least of which is the ability for the host WebAssembly module to tamper with the kernel (on the flip side: an intra-module JIT compiler feature!). But that is not the end of it: toolchain support is also lacking simply to produce modules that use atomics and shared memory. For C programs: https://github.com/WebAssembly/wasi-libc/issues/326. For Rust programs: https://github.com/rust-lang/rust/issues/102157. Due to all this, most tests and examples in this crate are meticulously hand-crafted WAT files — once toolchain support improves these difficult-to-maintain files should be replaced.
- __uncomfortable Wasmtime/Wiggle APIs__: this implementation of
wasi-parallel
works by creating new instances of the kernel in each thread of a thread pool — the host module exports a shared memory and the kernel imports it. Getting access to the shared memory from within awasi-parallel
invocation is difficult with Wasmtime/Wiggle: the best way I could think to resolve this is to teach Wiggle toskip
a WITX function and then manually implementadd_to_linker
for that function. This is tedious and error-prone, so I would be excited to discuss better solutions. Note that an almost identical version of this problem will arise when I try to implement [wasi-threads
].[
wasi-threads
]: https://github.com/WebAssembly/wasi-threadsWhy now? The rationale behind merging this code behind the
wasi-parallel
feature flag is to enable users to try this out locally and to iterate on this in-tree (e.g., toolchain, GPU parts).
abrown updated PR #4949 from wasi-parallel-cpu
to main
.
abrown updated PR #4949 from wasi-parallel-cpu
to main
.
abrown updated PR #4949 from wasi-parallel-cpu
to main
.
abrown updated PR #4949 from wasi-parallel-cpu
to main
.
alexcrichton submitted PR review.
alexcrichton submitted PR review.
alexcrichton created PR review comment:
Personally I'm wary of continuing to take on large unvetted dependencies, even through the optional wasi proposals. The previous wasi proposals we have implemented were largely grandfathered in but I would personally prefer to take this opportunity to not continue to try to grandfather in new features.
Is it possible to slim down the proposal's dependency tree to not rqeuire so many exemptions? Or otherwise are these sorts of crates absolutely required? If so I would personally prefer to have an official vet on-the-record for the inclusion here.
alexcrichton created PR review comment:
Mind bumping this to 2021 with
edition.workspace = true
?
alexcrichton closed without merge PR #4949.
alexcrichton commented on PR #4949:
I'm going to close this as this is a pretty old PR at this point and efforts have shifted significantly in the intervening two years. Nowadays most things are happening around "shared-everything-threads" which is the most likely path forward I think. If others disagree though I'm happy to reopen.
Last updated: Dec 23 2024 at 12:05 UTC