CG-02-14.md

March 8, 2023 · View on GitHub

WebAssembly logo

Agenda for the February 14th video call of WebAssembly's Community Group

Where: zoom.us
When: February 14th, 5pm-6pm UTC (January 3rd, 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

Opening, welcome and roll call
1. Opening of the meeting
2. Introduction of attendees
Find volunteers for note taking (acting chair to volunteer)
Proposals and discussions
1. Relaxed SIMD phase 4 poll: https://github.com/WebAssembly/relaxed-simd [5 min]
2. Implementation-defined limits discussion [10 min]
3. Initial information regarding the next hybrid CG meeting [15 min]
Closure

Agenda items for future meetings

None

Meeting Notes

Attendees

Conrad Watt
Derek Schuff
Zalim Bashorov
Chris Woods
Kevin Moore
WIllem
Daniel Hillerström
Krisztian Gacsal
Robin Freyler
Jeff Charles
Paolo Severini
Saul Cabrera
Sergey Rubanov
Thomas Lively
Ilya Rezvov
Alex Crichton
Nick Fitzgerald
Alon Zakai
Yury Delendik
Andreas Rossberg
Zhi An Ng
Heejin Ahn
Sam Clegg
Manos Koukoutos
Nabeel Al-Shamma
Petr Penzin
Mingqiu Sun
Brendan Dahl
Asumu Takikawa
Sean Jensen-Grey
Deepti Gandluri
Chris Fallin
Jakob Kummerow
Keith Winstein
Slava Kuzmich
Marat Dukhan
Francis McCabe
Shoaib Kamil
Adam Klein
Johnnie Birch
Andrew Brown
Rick Battagline
Ashley Nelson
Luke Wagner
Emanuel Ziegler
Peter Huene
Yuri Iozzelli

Proposals and discussions

Relaxed SIMD phase 4 poll: https://github.com/WebAssembly/relaxed-simd [5 min]

ZA Presenting slides. [TODO: Add slides]

Relaxed SIMD to Phase 4

PP: Does SpiderMonkey implement the relaxed semantics?

YD: we did the relaxed semantics

DG: More context: there was an option that if we ever run into issues with the relaxed semantics/implementation-defined behavior, we have the option to implement them in terms of “strict” SIMD, but it’s not recommended

AR: you say the spec interpreter implements the deterministic semantics. Does that include the change using FMA that we decided on 2 weeks ago?

ZA: Does not include it yet, but will do soon after.

AR: yeah, so this is largely my fault, I didn’t get to review until a couple of days ago. But really technically our entry requirement for phase 4 is that the spec is done. I don’ tknow how far we want to stretch it if it’s still under review and there’s work to be done. I don’t think it will take long. I don’t know theres a reason to rush the vote until the work is done. I worry we’re setting a precedent to play fast-and-loose with the rules.

CW: What is the rule that we’re violating right now?

AR: that the spec is done. It’s still under review and there are things to fix. And that the interpreter has work still. None of this is a big deal, but I did want to raise the question. It’s really more about setting precedent than about the actual proposal. This proposal overall has moved forward quite quickly, so I don’t know that there’s a reason to rush it.

ZA: Happy to punt this until after we get the right things in place and we’re happy with both the stacks and ???

DS: Can we get a commitment for timely review of the proposal?

AR: I’ll try my best, sometimes there is too much on my plate

CW: just to be completely specific, are we saying that the interpreter implementing the deterministic semantics is going to be a blocker for phase 4? It doesn’t seem like a strict requirement?

AR: That’s a fair point, it seems more ideal if it does so it’s clear that we know what it does. Not a strict requirement. Before we move to Phase 5 we should do it

TL: I’m unclear on that. You’re saying you’d prefer that the spec interpreter implements the relaxed semantics?

AR: No so that it implements the deterministic mode. There are two ways of doing this here. One is it implements the deterministic mode because it has a deterministic implementation and it would be good if it matched the deterministic mode we specify. We could randomize it to some degree and allow it to exercise the larger semantics. I don’t know if we want to do that, if it’s worth doing that but that would be the other option. But if we have a deterministic implementation, it would be good if it matched the deterministic mode.

TL: I agree, it’s what I would expect for FMA. Are there any other behavior differences that we need to update?

ZA: As far as I can remember no, but I will check and see if they are consistent with the deterministic semantics.

AR: Final remark, Spec is based on the profiles spec draft, but which we haven’t progressed to any phase yet.

DG: maybe we should schedule for the next meeting and figure out what makes sense for profiles. The repo has some discussion about what do profiles look like, which ones do we care about and which ones we don’t etc. Also wanted to add to your previous remark, why is this necessary to move forward. Implementations have been ready for a long time and we need to get this into the hands of users who have been waiting for a year.

AR: Which I understand but there are multiple other proposals which it has been years.

DG: Which is fine, but I just want to respond to that

AR: I think this one has gone exceptionally fast by our standards

CW: Different expectations going forward maybe.

PP: Kind of interesting aspect but the fact that we are going to base it on profiles and profiles is the proposal itself and it’s not in any sort of phase, that sounds somewhat interesting.

CW: I guess I never considered it strictly necessary that we base this on profiles. You can think of relaxed SIMD as the full profile, and then you could base profiles on that.

PP: That was sort of if you are going to standardize the profiles in a different way, I guess you could change the profiles. We haven’t gone through all the normal phases of profiles and figuring out if they actually work the way we want. Could be tricky to undo something that was put in this spec. But that’s the risk if you want to take it.

AR: just to clarify, I think we could of course specify it without profiles, but currently it includes the entire profiles spec. It really is based on it as far as the spec goes. We could undo that but we’d have to update the spec. And since this is really the minimum for profiles, which I don't’ think there’s big disagreement over.

PP: I don’t know how broadly this is defined at the moment, the only concern is that something in the profile part of the spec would have to be removed later and that’s a backwards compatibility problem.

AR: Only thing about profiles that is in there is a framework for determining profiles, it contains the deterministic profile which is what the relaxed SIMD uses right now. There is nothing we don’t need right now but it is defined in a general way that encourages other profiles to be added. I guess the question, I think it makes sense but Im biased obviously.

TL: I agree it seems clear to me that we have consensus that folks want a deterministic profile, and as you said we have spec machinery that doesn’t do anything but define that. So I would be fine merging that spec machinery and the deterministic profile as part of this phase 4 vote. Other future profiles should have separate discussions.

AR: In terms of what’s an open question on the profiles repo, whether it should include a SIMD profile or not.

TL: right, I think we should discuss that separately.

MD: Don’t all engines include SIMD?

TL: only web engines. But I think we can separate that from the phase 4 vote.

CW: Anything else to say on this agenda item?

TL: I think we should vote and I’m sympathetic to not setting a precedent of moving too quickly and not ignoring our rules.. Having it on the full CG agenda in the future is not that useful, the only change is that we updated the interpreter. I say we do the vote now and make it provisional on the interpreter work.

AR: Hold on, the main thing is the spec work not the interpreter work. main the PR has to merge. I did the review and there are some minor things. Main thing I think is the spec for FMA. nothing big, it’s just technically not done yet.

TL: so I’d be in favor of a provisional vote saying that once the spec is done, it should move to phase 4 once the spec is ready.

CW: In that case, I’ll run a contingent poll, so contingently, typing, running a poll in Zoom

DS: We have 1 against vote, let’s give that person an opportunity to have a statement. If someone wants to do that, now is your chance. Usually we know who it is, but we don’t this time (because of Zoom vote)

Poll Relaxed-SIMD to Phase 4:

SF	F	N	A	SA
8	23	6	1	0

CW: If the against vote would like to speak up, please post on GH or send us an email. Even with the vote, we have a successful vote for Relaxed SIMD moving to phase 4, contingent on the spec getting done.