Stream: git-wasmtime

Topic: wasmtime / PR #4949 wasi-parallel: implement CPU parallelism

Wasmtime GitHub notifications bot (Sep 23 2022 at 18:03):

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 (see tests, 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-parallel

I 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 a wasi-parallel invocation is difficult with Wasmtime/Wiggle: the best way I could think to resolve this is to teach Wiggle to skip a WITX function and then manually implement add_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-threads

Why 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).

Wasmtime GitHub notifications bot (Sep 23 2022 at 18:13):

abrown updated PR #4949 from wasi-parallel-cpu to main.

Wasmtime GitHub notifications bot (Sep 26 2022 at 18:00):

abrown updated PR #4949 from wasi-parallel-cpu to main.

Wasmtime GitHub notifications bot (Sep 26 2022 at 18:16):

abrown updated PR #4949 from wasi-parallel-cpu to main.

Wasmtime GitHub notifications bot (Sep 26 2022 at 18:50):

abrown updated PR #4949 from wasi-parallel-cpu to main.

Wasmtime GitHub notifications bot (Oct 04 2022 at 17:17):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Oct 04 2022 at 17:17):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Oct 04 2022 at 17:17):

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.

Wasmtime GitHub notifications bot (Oct 04 2022 at 17:17):

alexcrichton created PR review comment:

Mind bumping this to 2021 with edition.workspace = true?

Last updated: Nov 22 2024 at 17:03 UTC