Stream: git-wasmtime

Topic: wasmtime / issue #10048 Pulley `weval` support

Wasmtime GitHub notifications bot (Jan 18 2025 at 23:48):

gkgoat1 opened issue #10048:

Feature

Pulley should support weval such that, on wasm platforms, it can be aot compiled if modules are known statically.

Benefit

This would unlock aot compilation of components down to core wasm using Wasmtime, along with enhancing weval to be able to process programs like itself.

Implementation

• If WASM is not supported currently in Pulley, that would have to be implemented first
• A Rust api for weval's WASM interface would also be needed
• After that, it should really just come down to calling the functions when needed

Alternatives

For components, another route is converting them fully to js with jco, then using something like Porffor to aot compile it. The rest could be done by allowing wizer to use the js engine WASM runtime, which would be provided by StarlingMonkey, which can further aot compile to a component, coverable with the previous alternative. These pipelines, while somewhat easier to plan for, are convoluted for the user and might massively reduce performance.

Wasmtime GitHub notifications bot (Jan 20 2025 at 23:17):

cfallin commented on issue #10048:

This idea is roughly plausible, but the prerequisite (which you note) of Wasmtime-with-Pulley-on-Wasm is the major dependency here that pushes it to a "long-term idea" bucket, IMHO. I'll note that "enhancing weval to be able to process programs like itself." is a research question bordering on intractability (the interpreter that weval processes really does need to be in the right shape; this is getting at the second and third Futamura projections which I don't yet know how to do in an imperative-IR world). And "just" in "it should really just come down to" is doing a lot of heavy lifting as well: getting the Pulley interpreter into a form that could partial-evaluate back out to Wasm-sandboxed-inside-Wasm is a significant and uncertain project.

I suspect there might be an X-Y problem at play here: what is the end goal you're driving toward? If "AOT compilation of components down to core Wasm", I suspect there are simpler and more direct designs that would do that (abstracting out Wasmtime's adapter generation into a tool that does module linking). If "application embedding Wasmtime to run a Wasm module, all compiled together into a Wasm", some sort of linking approach that hoists the Wasm module to a native Wasm module alongside the rest of the application is likely to be a much shorter path to a performant and tractable design. Happy to offer further thoughts if it's something different than that, of course.

Wasmtime GitHub notifications bot (Jan 22 2025 at 00:17):

gkgoat1 commented on issue #10048:

This idea is roughly plausible, but the prerequisite (which you note) of Wasmtime-with-Pulley-on-Wasm is the major dependency here that pushes it to a "long-term idea" bucket, IMHO. I'll note that "enhancing weval to be able to process programs like itself." is a research question bordering on intractability (the interpreter that weval processes really does need to be in the right shape; this is getting at the second and third Futamura projections which I don't yet know how to do in an imperative-IR world). And "just" in "it should really just come down to" is doing a lot of heavy lifting as well: getting the Pulley interpreter into a form that could partial-evaluate back out to Wasm-sandboxed-inside-Wasm is a significant and uncertain project.

I was, in fact, getting at those other futamura projections. However, as you pointed out, weval might not be ready for that sort of process yet. That could probably be split out into a more long-term project (requiring inlining in both our waffles, among other optimizations).

I suspect there might be an X-Y problem at play here: what is the end goal you're driving toward? If "AOT compilation of components down to core Wasm", I suspect there are simpler and more direct designs that would do that (abstracting out Wasmtime's adapter generation into a tool that does module linking). If "application embedding Wasmtime to run a Wasm module, all compiled together into a Wasm", some sort of linking approach that hoists the Wasm module to a native Wasm module alongside the rest of the application is likely to be a much shorter path to a performant and tractable design. Happy to offer further thoughts if it's something different than that, of course.

The goal is primarily AOT compilation of components to core WASM; Wasmtime is the only WASM runtime with native component model support, and tools like jco and wasm-component-layer use its API. This distances the component model from a standard, and incurs seperate projects like pit and alternate, witx-using, WASI forks like WASIX to support more runtimes. Compiling components to core WASM would allow interaction with those core-wasm-using systems, in addition to allow running on underpowered systems where a further compiler is required.

Embedding Wasmtime, and further on, weval support, may solve this, but seems to be too much work, and I understand that. However, our ABIs can be bridged; a wip version of one can be found as the pit WIT bridge (note that it uses my fork of waffle). We could split that goal of compiling components to core WASM into another issue (possibly somewhere else?). Feel free to close and reopen when ready.

Wasmtime GitHub notifications bot (Jan 23 2025 at 02:20):

cfallin commented on issue #10048:

For sure, I actually fully agree that there should be a better tooling path toward lowering components into core Wasm that is portable -- I'm not the best person to speak to plans or thoughts on that, but maybe @alexcrichton or @pchickey are. My main point is only that I think partially evaluating a Wasm interpreter over a Wasm module is quite an indirect and brittle path to get a module inside a component to pop out the other side; and moreover from a planning point of view I don't want to put "make weval good enough to make that pipeline invisible" on the critical path of such a useful tool idea.

Wasmtime GitHub notifications bot (Jan 23 2025 at 04:05):

alexcrichton commented on issue #10048:

Personally yeah I would agree with @cfallin that there are likely better routes than weval to bringing component runtimes elsewhere. I believe wasmedge was working on a component model implementation in addition to one or two other engines, but I'm not sure of the progress at this time.

Wasmtime GitHub notifications bot (Jan 23 2025 at 05:26):

cfallin closed issue #10048:

Feature

Pulley should support weval such that, on wasm platforms, it can be aot compiled if modules are known statically.

Benefit

This would unlock aot compilation of components down to core wasm using Wasmtime, along with enhancing weval to be able to process programs like itself.

Implementation

• If WASM is not supported currently in Pulley, that would have to be implemented first
• A Rust api for weval's WASM interface would also be needed
• After that, it should really just come down to calling the functions when needed

Alternatives

For components, another route is converting them fully to js with jco, then using something like Porffor to aot compile it. The rest could be done by allowing wizer to use the js engine WASM runtime, which would be provided by StarlingMonkey, which can further aot compile to a component, coverable with the previous alternative. These pipelines, while somewhat easier to plan for, are convoluted for the user and might massively reduce performance.

Wasmtime GitHub notifications bot (Jan 23 2025 at 05:26):

cfallin commented on issue #10048:

I'll go ahead and close this issue, but @gkgoat1 please do feel free to open issues for the more direct goals (e.g. lowering components to core Wasm) if desired.

Last updated: Jan 24 2025 at 00:11 UTC