Andrew Brown (May 13 2024 at 17:08): Andrew Brown (May 13 2024 at 17:08):The wasi-nn specification has been moving along, slowly adding adding and modifying functionality, all based on WIT-defined features that imply the component model. But now we're trying to decide: how long should we keep the old preview1-ABI implementations alive? (I'll use preview1-ABI to refer to the WITX-defined version and preview2-ABI to refer to the WIT-defined version, since wasi-nn was not included in either preview). The problem is that, as I tried to implement new features based on the preview2-ABI in Wasmtime, it became clear that the old preview1-ABI implementation could not support them. So I proposed simply removing this older code in #8530. In discussions about this in the ML working group, we wanted to match what the rest of the community is doing here. I mentioned that currently Wasmtime has an adapter that can be used to compose a preview1 core Wasm module into a preview2 component; maybe wasi-nn could do something similar to bridge the gap between existing modules and the Wasmtime implementation, which is moving forward. But this brought up questions about matching the _timeline_ of WASI implementations:
I'm interested in hearing from some of the WASI community on what the best path forward is here.
Andrew Brown (May 13 2024 at 17:13):cc: @Pat Hickey, @Bailey Hayes, @Dan Gohman, @Alex Crichton, etc...
Alex Crichton (May 13 2024 at 17:27):The adapter strategy is not one I might recommend pursuing here. The rationale for the existence of the current adapter is primarily because updating languages to support preview2 natively was a no-go when preview2 did not exist. It provided a transitionary bridge from "nothing" to "ok preview2 is done and here's exactly what it is". Without it we more-or-less couldn't have demo'd anything along the way in a way that's possible for someone other than a developer working on it to implement.
The adapter itself is pretty awful to maintain. Ongoing maintenance isn't the worst but writing it "looks like Rust" but it definitely does not feel like Rust. It's not as simple as "oh just throw some stuff in there" but it instead needs to be very specially crafted against very specific rules which aren't exactly all written down. In that sense it may not even be possible to do an adapter for wasi-nn.
I also think that the calculus is different for wasi-nn. There's a precise definition of the witx-based version and the WIT-based version. In that sense there's no need for a transitionary period. There's additionally no built-in standard library support for wasi-nn (unlike for example the fs-related WASI APIs) which means that it's theoretically much easier to upgrade existing support from witx to wit with some source changes and dependency updates.
The one thing the adapter does buy you is the ability to run unmodified historical binaries as components. Whether or not that's critical to wasi-nn is something I'm not sure of though.
That's a bit of background, but I can try to answer some of the specifics here as well:
how long does Wasmtime intend to keep preview1 support available in-tree?
If by preview1 you mean wasi_snapshot_preview1 support the answer is "probably quite some time". There are no plans to remove it and it's likely going to stick around for many years to come as it'll be a long time before those binaries all disappear and/or become irrelevant.
how long does Wasmtime intend to maintain the adapter? Is it feasible to add wasi-nn support to it?
The current adapter will likely be maintained as long as the wasi_snapshot_preview1 support, so probably quite awhile
Andrew Brown (May 13 2024 at 18:30):Thanks @Alex Crichton, that's helpful. In Wasmtime then, what should the plan be moving forward:
add_to_linker come from: (a) manually re-implement or (b) dynamic "adapt-to-component" (@Dan Gohman and I were discussing this) Alex Crichton (May 13 2024 at 18:40):No plans to remove wiggle at this time, no, it'll probably stick around as long as preview1 things. For testing the number of wasi-nn tests is small enough I think it'd be fine to write them twice and/or have a runtime bool selecting which api is used and call them twice
Bailey Hayes (May 15 2024 at 15:50):We've seen prototypes for a p2 -> p1 adapter. It seems like this would be good path for delivering newer wasi-nn specs to wasip1 runtimes.
Last updated: Dec 23 2024 at 13:07 UTC