SPECID at runtime

[penzn]

From yesterday's video call, there are differences in amount of support a wasm proposal might get in a particular runtime, for example, SIMD support varies in somewhat significant ways. I am wondering out loud if there would be value in adding specid instruction (analogous to cpuid feature in processors), that would allow querying features supported by the runtime?

Currently, if you want to compile for more than one set of features, you have to build multiple modules and do test loads to figure out what is supported.

We can open a discussion on the main spec if that is a good idea.

By the way, those video meetings happen monthly, please fill out form in #63 to sign up. It is understandable that the current time would be inconvenient to participants outside of the US, but it is open to adjustment.

[gnzlbg]

for example, SIMD support varies in somewhat significant ways.

I think this is expected given that SIMD is not a WASM extension, yet.

adding specid instruction (analogous to cpuid feature in processors), that would allow querying features supported by the runtime?

What makes SIMD special here, e.g., can I use this to query other WASM features at run-time (e.g. thread support or atomic support)? Right now these are validation errors.

I have the feeling that it might make sense framing such a feature in the context of WASM as a whole, and not only SIMD.

[penzn]

What makes SIMD special here, e.g., can I use this to query other WASM features at run-time (e.g. thread support or atomic support)? Right now these are validation errors.

I have the feeling that it might make sense framing such a feature in the context of WASM as a whole, and not only SIMD.

Yes, that is the intent. This group had some exposure to this types of issues, so I thought I'd open the issue here first, but the end goal is to move this discussion up to the main spec.

[penzn]

@gnzlbg, I updated the description, avoiding loading two modules with the same code is the motivation for this, like you mentioned in #79

[gnzlbg]

There are two orthogonal issues at play here.

The first one, is whether it is worth it to have a WASM function that returns whether a particular feature is supported or not. Right now, such a function can already be implemented, e.g, have a WASM function that calls external code (e.g. javascript), and tells it to load a wasm module that uses a particular feature, and if that fails to validate, that feature is not supported.

Would it be worth it to add such an API to WASM? Probably not right now. These APIs are useful on real hardware, because one can compile a binary that uses many different features, and use the API to only choose execution paths involving supported features. In WASM, however, this is not possible. A binary that uses a feature that is not supported fails to validate.

That is, users of such an API, would have to use it before actually trying to load the modules that uses the different features. Having to do an external call at that point to figure out which features are available, and which modules to load, isn't really a big deal, and happens only once when loading a module (as opposed to, e.g., real hardware, where cpuid could be called more often).

The second issue is whether it would make sense to split the "simd128" feature into smaller features to allow users to use an hypothetical run-time feature detection system to detect differences across implementations and be able to load different modules. Right now, we only have a single feature, "simd128", so implementations that do not fully support it, should just say so, and fail to validate any module that requires it - otherwise, the module would validate successfully but fail at run time. For users to be able to tell the current implementation differences, we'd need to slice the "simd" feature into smaller features, to allow users to query smaller subsets.

I don't think this is worth it either. Once the SIMD spec moves from "experiment" to "stable feature", implementations should start failing to validate until they catch up with the spec. Future extensions will go into simd128_2 or similar features, so users will be able to tell between those at some point.

It might make more sense here to add some sort of "feature versioning", where we can just version the current simd128 spec as being version 0.2.3 or similar, and users and implementations can use semver to figure out if they are talking about "the same" spec. Once we release the feature, then it will have version 1.0.0, and if we start adding stuff in backwards compatible ways, we could at some point release 1.1.0, etc. Implementations can then use semver to know that if a module requires simd=1.1.0 and they support simd=1.2.0 then that module should be supported.

I requested this type of versioning before, e.g., in #35 , but there wasn't much interest for it. Some point later #72 happened, but then it was reduced again, to what we have now, which isn't particularly useful IMO.

IMO it makes no sense to special case feature versioning, run-time feature detection, etc. for SIMD. We can at best come up with conventions to like what was implemented after #72, but to make those conventions useful a better system is needed.

[tlively]

+1 this is an important issue close to the top of mind for lots of folks across all of WebAssembly. It would be good to open an issue on the design repo: https://github.com/webassembly/design. In particular feature detection would be useful to expose to modules and via the C embedder API because currently the only way to do feature detection is via module creation and loading, which may not be possible in all contexts and is unnecessarily complicated for this use case where it is possible.

[dtig]

There's a couple of different issues here. First the complexities of feature detection when it comes to SIMD especially. For this, see issue that @binji opened about Single-module feature testing.

The second, about spec versioning. My concerns with versioning as in #35 is that with SIMD still being in Phase 1, having a structured versioning system implies that implementations can support different versions, and that the tools should work with that version as well which is quite a bit of overhead. At Phase 1, proposals are still being prototyped, and can change. The SIMD proposal has been stable for a little bit, so I'd argue that the reason we are see the need for versioning is because the Phase it is in does not reflect how far along the proposal is so moving it along in the standards process to reach an MVP is the right way to resolve this.

[dtig]

Closing this issue as there isn't anything SIMD specific we can do here, and the discussion has moved to the design repo.