Does deterministic profile have threads instructions?

[eqrion]

From appendix/profiles.rst

The deterministic profile excludes all rules marked \exprofiles{\PROFDET}. It defines a sub-language that does not exhibit any incidental non-deterministic behaviour:

    All [:ref:`NaN <syntax-nan>`](https://github.com/WebAssembly/relaxed-simd/blob/main/document/core/appendix/profiles.rst#id22) values [:ref:`generated <aux-nans>`](https://github.com/WebAssembly/relaxed-simd/blob/main/document/core/appendix/profiles.rst#id24) by [:ref:`floating-point instructions <syntax-instr-numeric>`](https://github.com/WebAssembly/relaxed-simd/blob/main/document/core/appendix/profiles.rst#id26) are canonical and positive.

Even under this profile, the [|MEMORYGROW|](https://github.com/WebAssembly/relaxed-simd/blob/main/document/core/appendix/profiles.rst#id32) and [|TABLEGROW|](https://github.com/WebAssembly/relaxed-simd/blob/main/document/core/appendix/profiles.rst#id34) instructions technically remain [:ref:`non-deterministic <exec-memory.grow>`](https://github.com/WebAssembly/relaxed-simd/blob/main/document/core/appendix/profiles.rst#id28), in order to be able to indicate resource exhaustion.

When threads is merged in the future, is this expected to include shared memory and instructions that operate on it?

If so, then deterministic may not be the best name as that's a huge source of non-determinism. Not sure on a better name though.

If not, then what is the expected ecosystem that will be adopting the 'deterministic' profile? At least for browsers, we'd maybe have an opt-in preference for this for variants like Tor. Other than that, I had heard that having a deterministic variants of these relaxed-simd instructions could be valuable for cloud platforms but I would guess they would also like to have shared memory.

cc'ing @rossberg as I think this came from the profiles proposal originally.

[rossberg]

That would be part of the work for finalising the threads proposal, I'd say.

One option is that the deterministic profile simply forbids shared memories (atomic instructions are fine when applied to non-shared memory, which I believe we decided to allow, so no reason to forbid them).

The least intrusive option would be to merely rule out configurations with more than one thread. Then declaring a shared memory would still be fine, i.e., nothing is taken away from the language, but a host adopting this profile isn't allowed to actually create threads. That would defer the real question to a Post-MVP "Wasm threads" proposal, which seems adequate.

In the future we may also think about specifying a deterministic scheduling model, but it's unclear at this point whether that has any practical value.

[conrad-watt]

I hope, if we add the deterministic profile, that some runtime is actually going to make use of the mechanism (otherwise why are we adding it!?). So we should find a representative of a runtime fitting this description and ask them what their expectations are. If we can't find such a person, that would somewhat call into question the utility of "deterministic" as a profile altogether. @lukewagner - do you have any thoughts about who to ask?

[rossberg]

Wasmtime has a mode to normalise NaNs, which is sort of the Wasm 1.0/2.0 version of deterministic mode. That is needed e.g. by Consensus-based systems running Wasm, such as blockchains. Dfinity is using it, for example. So the need is definitely real.

[conrad-watt]

I guess a consensus system really would want to just forbid the creation of threads, which fits the sketch above. I'm not sure how this fits in a post-MVP threads world with thread.spawn though. Maybe if we make the spawn instruction fallible as has been discussed, it could be required to always fail in deterministic mode, similar to the way we'll need to make memory.grow always succeed/fail.

[eqrion]

similar to the way we'll need to make memory.grow always succeed/fail.

Does the current deterministic profile also restrict these?

[eqrion]

I agree that this is sort of a threads proposal issue, but it does affect the name we choose here so I think it's worth discussing so we don't paint ourselves into a corner.

I guess trying to come at it from an ecosystem perspective there are really three different ones I've heard from:

1. consensus/blockchain systems
2. large cloud platforms
3. browsers with fingerprint resisting

(1): would want no threads, deterministic instruction execution rules, and something around resource exhaustion(?).
(2): would just want deterministic instruction execution rules
(3): is somewhere between (1) and (2). I believe Tor disables shared memory and would want deterministic instructions execution rules, but stock Firefox with resist fingerprinting settings may just want deterministic instruction rules. We also may just not care about this ecosystem enough to have a profile for it.

Ignoring (3) you arrive at the following profiles:

1. full - {}
2. numeric-determinism - {no-relaxed-simd-nondeterminism no-nan-nondeterminism}
3. fully-deterministic - numeric-determinism U {no-threads, no-resource-exhaustion?}

I would say that numeric-determinism is the more important ecosystem at this point and I'd start with that being the one relaxed-simd uses.

[lukewagner]

A 4th use case is for the deterministic profile is build environments that want to ensure reproducible builds by construction using wasm.

Since the deterministic profile is more-widely deployed in production and since, until we add threads, the deterministic profile is the same as the numeric-determinism profile, I'd suggest we start with just the deterministic profile and postpone discussing the addition of more-refined profiles.

[conrad-watt]

until we add threads, the deterministic profile is the same as the numeric-determinism profile

I think there's some difference as deterministic would likely include deterministic memory.grow while the numeric version wouldn't. The numeric version is interesting as it would be (almost) the bare minimum needed to navigate around the specific additional issues caused by relaxed SIMD, so it might make sense as an initial approach while we hash out the details of other "determinisms".

[rossberg]

Yeah, let's not over-engineer it. If there is a need for a no-threads profile in the future, then that should be added as a separate profile — profiles ought to compose, so deterministic no-threads could naturally be formed from the two.

I don't think we can meaningfully make the likes of memory.grow deterministic on the language level, because that would require locking down how much memory is available. Only a given host or platform can possibly define that. Resource exhaustion is a totally different class of non-determinism that not much can be done about in general.

[eqrion]

@rossberg How do you feel about renaming the profile to numeric-determinism (or numeric-deterministic) then, as it won't encompass shared-memory determinism?

[rossberg]

@eqrion, with the threads proposal, deterministic mode will have to disallow the creation of additional threads. That at least is what the consensus, reproducible builds, and similar scenarios need. Do we have as strong a use case for numerics-only determinism?

[eqrion]

@rossberg My impression was that numeric-determinism would be useful for large cloud platforms that want to minimize architectural differences while still allowing multithreading.

In the end, we'll probably want both of these if we're trying to faithfully model real ecosystems out there. I personally think it'd be better to start with the conservative and smaller scoped numeric-determinism, but we could start in the other direction and end in the same place too.

[rossberg]

Yeah, we know immediate users for full determinism. The other seems more hypothetical, so perhaps let's wait until somebody actually requests it.

[eqrion]

As you said above, wasmtime has a canonicalize-nans option, which is the 1.0/2.0 version of numeric-determinism. So it's very much not hypothetical.

Again, I'm fine if you want to start with full determinism. But if we want to model what exists out there faithfully, we'll want numeric-determinism eventually.