CG-11-22.md

Agenda for the November 22nd video call of WebAssembly's Community Group

• Where: zoom.us
• When: November 22nd, 5pm-6pm UTC (November 22nd, 9am-10am Pacific Time)
• Location: link on calendar invite

Registration

None required if you've attended before. Send an email to the acting WebAssembly CG chair to sign up if it's your first time. The meeting is open to CG members only.

Logistics

The meeting will be on a zoom.us video conference. Installation is required, see the calendar invite.

Agenda items

1. Opening, welcome and roll call
   1. Opening of the meeting
   2. Introduction of attendees
2. Find volunteers for note taking (acting chair to volunteer)
3. Proposals and discussions
   1. Relaxed-math mode next steps (Dan Gohman) [30 minutes]
      • relaxed-simd poll: 6 for, 3 neutral, 0 against
      • relaxed-simd feedback and next steps
      • some profiles discussion
      • more profiles discussion
4. Closure

Agenda items for future meetings

None

Schedule constraints

None

Meeting Notes

Attendees

Thomas Tränkler Andrew Brown Sean Jensen-Grey Alon Zakai Luke Wagner Saul Cabrera Chris Fallin Paolo Severini Yuri Iozzelli Conrad Watt Asumu Takikawa Dan Gohman Nabeel Al-Shamma Shoaib Kamil Ilya Rezvov Thomas Lively Brendan Dahl Manos Koukoutos David Piepgrass Zhi An Ng Alex Chrichton

Relaxed-math mode next steps (Dan Gohman) [30 minutes]

DanG Presenting slides

AR: common misconception, purpose of profile is not to increase fragmentation, but the opposite. it deals with inevitable fragmentation, things that are not implementable everywhere. proposal tries to minimize the inevitable fragmentation.

DanG: I think there are multiple perspectives on that, let’s finish talking about it and talk about it in the end.

CWatt: ready for people to jump in with hot takes? My opinion: this is a spec organization question. We can get relaxed simd all the way throught standardization (relaxed mode), later if we want to standardize deterministic mode. Don't know if we should block relaxed simd progress until we resolve this. Second take, when we introduce some kind of mode, we should have the non-deterministic profile a clear default, because the safe thing to do when producing code is with fewer assumptions. Don't want to create a situation where users make a mistake of code only working on deterministic mode, but web browsers are relaxed.

FM: I’ve said this before, but over the longer term, the pressure on any given engine is to implement the entire spec. There’s a related problem which is that if you have a moving spec, then at any one point in time, not all engines will implement everything. I view the “inevitable” fragmentation Andreas raised as a non-issue.

AR: I want to reply and disagree on both accounts, FM’s versioning problem is almost impossible to solve, and not the goal of profiles. The purpose of profiles is to legalize a way to not support some features. This is not about the web, and about supporting environments that are more constricted, embedded for example can’t support SIMD or GC, or other proposals, it’s not going to go away, we can either ignore the problem and fail as a standarization group, or propose an alternative

DP (chat): Francis may be forgetting about (1) IoT targets where engines must be small and (2) open source engines that don't have the resources to support everything

SJG (chat): almost identical to risc-v extensions

FM (chat): My counter example dates back to the 1980's-1990's. Micro computers used to run limited versions of almost C. That is no longer a thing.

DP (chat): Generally there is no "counterexample" you can give to an existence proof. But generally speaking, even if Moore's law continues, low-power low-transistor-count devices are always useful. If your doorbell starts running a full version of Wasm, your T-shirt may still be more limited

FM (chat): OTOH, this kind of subsetting/profiles was also quoted as a major reason for the failure of jdk me

SJG (chat): capabilities and resource limits, negotiating with the engine in the least number of round trips. https://gist.github.com/dominiksalvet/2a982235957012c51453139668e21fce. WASM64+GC+SIMD maxheap:8G.

DP (chat): I'm not familiar with JDK ME … but honestly I think Wasm has had better management than Oracle thus far

SJG (chat): they are run pretty well now, definitely something to learn from https://openjdk.org/bylaws

FM (chat): JDK ME is a failure because essentially, no-one uses it, including its intended target audience of embedded devices.

DP (chat): I know a lot more about .NET Compact Framework which I don't think was well-managed (e.g. they chose to develop a completely separate codebase, one with very poor performance; and if the .NET people as a whole had designed .NET more judiciously it would've been more practical to have a subset of .NET that wasn't as limited as .NET CF was.)

DP (chat): "X is a failure because no-one uses it" is a confused statement. "no-one uses it" is simply the definition of failure itself, not an explanation for the failure. And my point is, you can't point to a project that wasn't executed well to prove that there is no demand or that it can't succeed

SJG (chat): What does the right thing mean? I don't believe sentences of that structure have stood the test of time. :) HTTP and RISC-V seem like models that have

DP (chat): On a personal note, I strongly preferred to use C# for my embedded project but used 100% C++ because .NET CF was just too slow

FM (chat): One of the reasons that JDK ME 'was a failure' was that it was, in practice, virtually impossible for programmers to actually use. The number of interactions between different APIs turned out to be a major source of intractability for programmers.

DanG: anyone else wants to jump in?

CWoods: from our POV, want to run Wasm in embedded products for 2 decades, profiles will be useful. Low cost process isolation, when size of runtime reaches a limit, we can use containers, no need to Wasm. Spoke to others, similar views in the embedded non web space. Have interest in solving versioning problem too, for longevity.

CWatt: The versioning problem will have to be solved by feature detection, profiles on its own is the wrong thing to solve this problem

DP (chat): Tend to agree, if you're saying feature detection should be finer-grained than profiles; I think both ideas are good

DeeptiG: what should the goal of this discussion be? The profiles discussion can be very open ended. Hoping we can scope it to some part of relaxed simd / relaxed math mode.

CWatt: how much of this is blocking relaxed simd?

DeeptiG: one way to phrase it, figure out how much of profiles we want to punt for the future

SK: profiles is explicit to reduce number of profiles, tryin to revise that part of profiles proposal is a vastly open ended discussion.

AR: What do you mean by revive or revise?

SK: it's unclear whether creating a relaxed math mode profile is something the profiles proposers are happy about. When i reviewed the profiles proposal, it explicitly wants to reduce number of profiles (handful rather than a dozen). It already has half dozen proposed profile. We might be at odds with the original profiles proposal.D

AR: Handling determinism was one of the motivations for the profiles proposal, and I don’t think we need any more than that here. For the same reason the profiles profile tries to minimize the number of profiles, we should also try to reduce the number of SIMD modes. They should align quite neatly. As Conrad pointed out, this modes-versus-profiles issues is mostly a spec issue, so I don’t think there would be a problem specifying the deterministic or relaxed mode in an ad hoc manner for now. I would hope that we could move profiles along faster so that such an intermediate step wouldn’t be necessary.

DanG: deterministic and non-deterministic in ad hoc way, with a path towards profiles in the future

DeeptiG: that approach addresses my concern, have ad hoc way that feeds into future later, we can have meta discussion about profiles then

CWoods: risk that we paint ourselves in a corner if profiles come along and we have to reconsider something? It sounds like profiles by the back door.

DeeptiG: in this case we know we want a deterministic mode, spec infrastructure for this, don't know if we are handicapping ourselves for the future.

AR: basically profiles are a general way of doing the same thing, from one special case to a more general mechanism. Spec wise it might not be that different.

CWoods: addresses my concern, thanks

DanG: The current modes proposal doesn’t propose any way of detect which mode we’re in, how do we resolve this? If we had the profiles mechanism, that would be one way of defining flags or some way to say which mode we’re in

AR: don't think it is desirable to do that, as producers, you cannot assume you're running in deterministic mode, this is something an engine or environment decides, it provides that reduced language subset. You want your generated code to work in all environments. Shouldn't depend on accidental invariants that only hold in a subset of the language. You will invite misuse with such a feature.

CW: I guess I’m a little more worried that producers are going to misuse it, realistically producers may already do that depending on what engines would support. Would it be better to have custom sections to have some mechanism where we issue a warning or an error when the incorrect mode is being used. Concerned about the user error portion of this. Taking FMA for example, it’s possible for someone wanting FMA in the deterministic mode to assume that it maps to a single instruction, and that would be an incorrect assumption

SJG (chat): shouldn't the producer ask for deterministic mode?

TL: These problems are still hypothetical, so we can proceed cautiously for now as we don’t have problems that actual users are running into at this time.

PP: Not hypothetical, we’re changing the precision of FP instructions so it is detectable, maybe not important but definitely detectible. If we make a decision, we should make it consciously, its possible to detect it but it is important way to make it observable.

AR: not actually detectable in a reliable way, you can assume with some certainty after performing some tests. from profiles perspective, it is a strict subset you are in, you can't change the behavior, you can only rule it out

PP: Re. the FMA example, if you add a number to the same value but opposite signs and multiple, in deterministic mode, you’d get a 0.. In strict mode you would get a deterministic answer and you don’t when you have FMA. I’m in favor of this, I’d like to just make folks aware

DanG: for CPP, we have people working on those toolchains in this meeting. We are on board with not depending on deterministic mode, will not lower CPP FMA to this relaxed instruction.

TL: Yeah, we don’t have all languages in the meeting, but certainly LLVM will never do the wrong thing here. We should aim to reduce complexity.

DeeptiG: This will be the more conservative way of doing this.

DanG: Anyone else who has an opinion here?

NS: We’re agreed that relaxed mode + relaxed SIMD is a positive feature for a set of libraries and applications, the discussion is more about the mechanism by which we allow it.

DanG: That’s accurate, we’re looking at a way of introducing the proposal in a way that doesn’t harm other proposals.

NS: Agree with TL, we can use profiles in the future to move this discussion forward

DanG: Summarizing, we’re aligned on introducing a deterministic/relaxed mode for now, and with profiles in the future as one way to include this, but not blocking any future discussion. We will also not be providing any way of detecting profiles

RW (chat): is mode defined on a per process basis?

TL (chat): Rich, mode is determined on an engine-by-engine basis. A single engine might be configurable to be in one mode or the other, but never both at the same time.

RW: Content could come from any provider. What if one provider assumes one mode and another assumes another mode? Then we could have a problem.

DanG: Deterministic behavior is a subset of the relaxed mode, so it should always be possible to run in deterministic mode

TL: Well behaved producers should always assume relaxed mode, so that’s the supersetting behavior that Dan was talking about. There will never be incompatibilities.

DanG: Toolchains like C++, even with ffast-math, we wouldn’t opti-in to this proposal by default. For most users, you won’t be able to generate any of this code unless you explicitly opt into the generating relaxed SIMD instructions

PP (chat): About detecting FMA the example is "a * b + a * (-b)": in dual rounding mode it would be zero, in single rounding it would be some multiple of the rounding error. From https://randomascii.wordpress.com/2013/07/16/floating-point-determinism/

SJG (chat): How about the wasm itself has a section that lists the modes that the code requires to run.

TL (chat): We just decided not to have a section like that because we'll assume that producers do the right thing anyway.

TT: Are we going to have a big-picture discussion, or just case-by-case? This is the first instance of fragmenting the ecosystem, so we should make sure we don’t paint ourselves into a corner.

DanG: Profiles does not have a consensus at this point, it’s a pretty big picture, we’re hoping to move this without blocking this proposal, hopefully profiles gains traction and we can use that in the future

TT: Agree about not blocking relaxed SIMD. Will we also have a big picture discussion in general?

DanG: We’ve had similar discussions before. Do you have specific concerns?

TT: Say you have a module that supports a particular feature, but another hardware doesn’t, how do we minimize the fragmentation of the ecosystem.

NS: This goes back to versioning and fragmentation, this is already the case that some browsers don’t support some versions of features, this is what FM characterized this as long term fragmentation

AR: To clarify, this is not about CPU architectures, this is about environments, it’s not possible for all environments to support all proposals based on environments. Disjointed environments will exist, and we can’t assume that code will be ported across them. In general the idea is that some environments just won’t have anything to do with each other

TT: Not what I wanted to address, wanted a forum

AR: Start with the profiles repo as that’s the right place to start with this discussion

PP: Pasted code snippets etc.We can follow up offline If we don’t automatically produce FMAs, then that seems to make the proposal less usable.

DeeptiG: want to address usability, having a flag doesn't make it less usable, we are enabling certain set of users who know what they are doing

PP: there won't be a flag right, intrinsics only, no fast math mode. If you see it in the source code, they really mean it.

DeeptiG: we don't want to shoehorn what we are doing with a proposal to fit a compiler flag.

CW: the cloud ecosystem will want deterministic mode because of something, would anyone want to speak to that?

LW: People demoing large amount of Wasm workloads, and just being able to move them on different hardware, the excitement around it was that Wasm is a portable, deterministic ISA, in that context deterministic mode would be the default mode that folks on the cloud would operate on, it’s possible people would decide to opt out of the deterministic mode. The nice thing about this is that we can eventually have some set of canonical lowerings and hardware can converge on behavior, and we can get rid of relaxed mode.

RW: Agree with that. Down the road there might be some merging, but maybe not depending on what CPUs do. Would constant time Wasm be another mode?

CW: Constant time is about the timing behavior, rather than the semantic behavior of the instructions, the spec doesn’t say anything about timing of instructions, and it’s probably not possible for the spec to say anything about timing, but give engines enough information to

BT: I’d like to mention backwards compatibility. Wasm will last 20 or more years, so we will have modules that compile under today’s assumptions. I’m concerned that we will need to emulate older hardware to successfully run modules that assume specific hardware behavior.

DeeptiG: every relaxed instruction has an equivalent deterministic lowering. We can add it to the appendix. No the union of all behaviors. You can lower to existing SIMD instructions, not as performant but expected to work.

DanG: for QFMA that's not true.

DeeptiG: That's true, we still have the open issue of whether we should add a deterministic FMA, and we can make a decision on that in the subgroup

DanG: overall path forward, don't depend on profiles, race with it to see if it can achieve consensus in time for relaxed simd, go forward with ad-hoc. Toolchains will use relaxed mode responsibly. Fair?

TL: SGTM

CWatt: Even if we’re not going all the way to profiles immediately, I still think we should specify relaxed mode as the default with the deterministic subset as a secondary note.

DeeptiG: SGTM as well. I think there’s a broader discussion about profiles that would be useful to have at a future CG meeting. Andreas, maybe we can schedule time for that offline.

AR: Sounds good.

DeeptiG: Want to make sure we’re not blocking this proposal, but want to figure out general profiles direction sooner rather than later.

DanG: Conrad, let’s continue that discussion in the context of actually writing the spec.

Closure