SIMD subgroup meeting on 2022-11-04

[ngzhian]

This is a joint meeting with flexible-vectors and any SIMD related presentations are also welcome, e.g. new architectures or toolchains, longer term discussion that don't fit into flexible-vectors or relaxed-simd.

The meeting will be on Friday, Oct 28 at 9:00AM - 10:00AM PDT/ 5:00PM - 6:00PM CET.

If this meeting doesn't already appear on your calendar, or you are a new attendee, please fill out this form to attend.

[ngzhian]

I totally forgot to create this issue amidst all the excitement around the in-person meeting, sorry :P
I will be OOO, so if we have a meeting, @penzn please run it. But I think it is a bit late to suggest agenda items now, and probably we have too many meetings this week already due to the in-person :)

[penzn]

I can log in and check for an open discussion. We can sync on feedback from in-person, though it would be good to have you in the meeting.

[Maratyszcza]

The meeting was moved a week later

[penzn]

@Maratyszcza can you edit issue title and description to say it is next week?

[Maratyszcza]

Listing some ideas that floated at the in-person CG meeting for potential discussion tomorrow.

@justinmichaud suggested that Relaxed SIMD should have explicit instructions for testing exactly which semantics is implemented by each Relaxed SIMD computational instruction. My original motivation for not exposing implementation testing instructions was to make it harder to write code that relies on architecture-specific behaviors. Justin expects that this will happen anyway, and having an explicit mechanism for testing for architecture-specific behaviors will simplify debugging if browsers get a bug report like "my Web app works in Chrome/Safari/Firefox, doesn't work in Safari/Firefox/Chrome".

Many participants voiced the suggestion that deterministic semantics should be a normative part of the spec rather than sprinkled across multiple Pull Requests. Several folks, including @sunfishcode, strongly prefer Relaxed Multiply-Add to use FMA semantics in deterministic mode, even if comes at big performance cost on some devices today. Overall, the community would like to see a path forward where non-determinism would naturally go away in the long-term, as new hardware implements native instructions which match deterministic semantics.

@titzer suggested that Relaxed SIMD should be a superset of native SIMD instruction sets, and provide WebAssembly equivalents for native instructions Relaxed SIMD instructions are lowered too. In this proposal, Relaxed SIMD would have e.g. an equivalent of the x86 PMADDUBSW instruction which computes 8 dot products of 2-element int8_t vectors and 2-element uint8_t vectors with saturation of results to int16_t. In this proposal all non-determinism is reduced to a feature testing instructions which tell if e.g. WAsm'ified PMADDUBSW is natively supported by hardware, and Relaxed SIMD operations would become macros that select between WAsm'ified equivalents of native instructions based on feature testing results. Ben's proposal is motivated by desire to exactly express all semantics the software might depend on in the WAsm bytecode, in order to guarantee portability across platforms through emulation of the WAsm'ified native instructions. In the long term, the hardware would implement the semantics of all WAsm'ified native instructions, and the need for emulation would go away.

[penzn]

Filed #104 to provide some background (not strictly tied to what has been discussed at CG meeting).

[dtig]

We came out of the CG meeting with several ideas/options that @Maratyszcza summarized above, in addition to that I think it would be useful to step back and what problems these ideas are solving. Parsing through the notes once more, some of the concerns raised and potential follow up that might be useful:

• Live code migration on the web - is this a thing we should be concerned about?
• Environments that need a deterministic lowering - are there cases where engines that target these environments aren't able to use the slower, but deterministic lowering that's available for the operations as proposed? What incremental enhancements would be useful?
• Implementation defined behavior, and it's impact. Focusing specifically on the usage patterns, and the type of implementation defined behavior introduced in this proposal.
• How do we narrow down the spec concerns (set/list non-determinism, profiles)?

[ngzhian]

Notes are at https://github.com/WebAssembly/meetings/blob/main/simd/2022/SIMD-11-04.md

[ngzhian]

Next meeting at #109 .