- Where: zoom.us
- When: May 26th, 4pm-5pm UTC (May 26th, 9am-10am Pacific Daylight Time)
- Location: link on calendar invite
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.
The meeting will be on a zoom.us video conference. Installation is required, see the calendar invite.
- Opening, welcome and roll call
- Opening of the meeting
- Introduction of attendees
- Find volunteers for note taking (acting chair to volunteer)
- Adoption of the agenda
- Proposals and discussions
- Review of action items from prior meeting.
- Should we move proposals entirely out of the design repo? (JP Sugarbroad)
- Poll to include .bitmask operations in the current SIMD proposal.
Context with benchmarking data: PR, Issue - Poll to advance reference types to phase 4 (Andreas Rossberg)
- Poll to advance typed (function) references to phase 2 or 3 (Andreas Rossberg)
- Update on Module Types / Module Linking proposal (slides)
- Poll: Rename "Module Types" to "Module Linking", broadening scope as proposed in PR #3 and advance proposal to stage 1
- Closure
- Update on Module Types / Module Linking proposal (slides) - moved to next meeting due to lack of time.
None
Ben Smith
Deepti Gandluri
Lars Hansen
Nick Fitzgerald
Ms2ger
Ross Tate
Dan Gohman
Svyatoslav Kuzmich
Paul Dworzanski
Yury Delendik
Shravan Narayan
Ben Titzer
Francis McCabe
Tobias Tebbi
Richard Winterton
Heejin Ahn
Alex Crichton
Ryan Hunt
Jay Phelps
Paolo Severini
Arun Purushan
Arseny Kapoulkine
Alon Zakai
Jacob Mischka
Luke Wagner
Nabeel Al-Shamma
Jakob Kummerow
Zhi An Ng
Ioanna Dimitriou
Thomas Lively
JP Sugarbroad
Derek Schuff
Andreas Rossberg
Emanuel Ziegler
Pat Hickey
Till Schneidereit
Adam Klein
Arnaud Robin
Sam Clegg
Zalim
Mingqui Sun
David Piepgrass
Peter Jensen
Petr Penzin
Dan Gohman
Ben Smith seconds
JS: Tried to clean up some of the documentation around the phases, people don’t usually use the design repo, just use the proposals repository - there’s already a lot of stuff already in the design repository, having less there makes sense
SC: Is this just for future features?
JS: It started that way, but
AR: Makes perfect sense, we should update the pages on the design repo to make sure folks know it’s outdated info
JS: Was already in the process of doing that - can update documentation
SC: Keep the future feature proposals for historical documentation?
<It already is, several>
AR: Should we move the proposal into the spec repo - might be harder to discover original repositories
JS: Makes more sense to merge the original proposals, a few extra directory entries in github is not a lot of work. We should backfill instead of getting rid of history
AR: To clarify - copy from design repo to the spec repo?
JS: We can discuss this in the github repository
TL: Should we still file an issue for the design repository for new proposals?
BS: We should use the proposals repo - people have used the design repository in the past
PP: Just had a chat with someone trying to follow Wasm discussions, they missed discussions everywhere else
AR: Why do we have a separate proposal repo at all? Why don’t we just merge?
< More discussion about the mechanics of the proposals repo vs. design repo>
JS: Abstract ideas for proposals, vs actual design idea - where should this live?
JS: get rid of tracking issues in design repo, future features point to proposals repo, sounds reasonable?
DeG: Will you, JS, follow up offline on this?
JS: open 2 issues, 1 for agreed changes, i will probably make them, another one to track discussion on where we want proposals to go, where to draw the line between design and proposal?
AK presenting slides
DaG: Can you comment on the any_true case? Shouldn’t AnyTrue be able to cover this?
AK: not quite, anytrue is less general, you get told whether there is any match. If there isa match you still have to find a match. For string search, you are looking at the substring, you have to do a match of the substring from the matched character. With anytrue, you then need scalar comparisons.
DaG: Is that difference worth an instruction here?
AK: we can run the tests to find out. Strongly suspect it will be well worth it for substring matches. E.g. if char you are searching for occurs every 8 chars, with a bitmask, you can do 16-wide comparison. Otw you have to do 16-byte comparisons, even though only 2 of them will match. There is code for this on the PR. Strongly suspect we will see degradation if we do anytrue + 16 comparisons, don’t know for sure, have not benchmarked it yet.
KM: This is the same instruction used in google's swiss hash. Tested w/ scalar version vs. simd instruction, right?
AR: We did not do comparisons to the swiss hash table - mostly because only thought of it yesterday when putting it together.
KM: Is there something other than string search... I suspect swiss hash is larger base of code.
AR: Structure of the swiss hash is the same as string search, exact same comparison where you do eq + bitmask + ctz loop to find matches
KM: Which architectures did you test on? Snapdragon and intel? [AK: yes] OK.
DeG: If you were looking for more arches, we can get that when we get back to the office. [KM: OK, makes sense].
KM: If we add this now, and then we test against some subset of older CPUs and find issues. What is the process for re-evaluating our decision then?
DeG: If we find out it is bad, then we can bring it back and find a different semantic. I suspect it will be wanted because it's hard to emulate. If it does show a performance cliff, then we'll bring it back as an issue on the simd repo.
AK: This is probably the best semantic -- the only difference is what bit to check, but this is probably the best since it is the top bit. It was chosen because it matches intel semantics best, but it probably matches ARM best as well. Maybe it will be added as a native ARM instruction, not sure.
Poll results:
| SF | F | N | A | SA |
|---|---|---|---|---|
| 8 | 11 | 12 | 0 | 0 |
AR: we have had plenty of slides, status is, last 2 open issues were resolved, subtyping removed and relaxed restriction on predeclaring references to functions, you don’t have to do it in a segment, you can do it anywhere outside function. Both implemented, tests are updated, SpiderMonkey implements all that, not sure if V8 has caught up. Anyone from V8 can comment on that?
DeG: not sure if we are up to date on that, JK, do you happen to know if we are up to date?
JK: not personally involved, not sure, don’t think we are up to date
DeG: my impression as well, we don’t object to the changes, it will be OK to move forward? What do other V8 folks think?
BG: phase documents require 2 implementations, but we have most of the implementation, and the purpose is to prove that we can implement it.
DeG: any objections to doing this without 2 full implementation, v8 has most of it, but not the latest changes
AR: or is there another implementation somewhere
BS: Would have to be another web implementation based on current requirements
KM: my internet failed, this is about reference type? I don’t think we have made the changes
AR: fairly large change, but mostly restricting stuff, not implementing new changes
KM: It wouldn’t be hard to implement - just the one function when Ross was proposing the split.
AR: way more than that, instructions changes
KM: All those functions flow through that in our implementation..
RH: encoding change, ref.null has immediate
AR: br table subtly changed back to what it was before, and some other changes like that
BT: don’t want to be that guy but we should enforce the letter of the law, cos these things can slide for a while
TL: was gonna say, there isn’t much downside if we wait a little bit for the implementations to catch up
DeG: How about a provisional poll to see if anyone objects to advancement, then do a more official poll once implementation catches up
BT: take a poll, when this is implemented, advance the proposal
AR: we shouldn’t poll in advance
DeG: intent is to see if there are any other objections, since this has been a proposal with many comments
LH: Bulk memory is blocked waiting on reference types? Is bulk memory included in reference types? Do we vote separately on bulk memory?
AR: I think we should vote separately, in terms of the actual work, everything is resolved in the reference types proposal for the mutual dependency - having said that we should still update the documentation - like the proposal document in the bulk memory proposal repo. One thing that changes is the ref.null const
BS: I’ve already changed that, based on what’s already there
AR: It’s all already there, just not implemented in the right way
JS: Do we wanna do that poll?
DeG: Barring the implementations, are there any other objections to moving forward w/ reference types to phase 4. It sounds like there are no objections, so let's bring this back next time.
POLL Result: No objections, unanimous consent.
AR: make sense, more comfortable following the doc, if yall could prioritize this, it will be helpful
EZ: we will do that
Poll to advance typed (function) references to phase 2 or 3 (Andreas Rossberg)
<TODO: AR to add slides>
JS: Why do you have as_non_null when you have br_on_null? Is it because as_non_null is trapping?
AR: It’s basically because in some cases the compiler knows it’s not null - forcing it to branch there would include code for no good reason
KM: It's useful to know the number of locals at the beginning -- so let creating locals on the fly; that means locals are dynamic by block. Might be a problem for fast code generators. Can we put a limit on the number of locals.
AR: Technically we could, Agree that it’s kind of gross. What would.. Would just knowing the number be enough? Don’t you need to know which types they are?
KM: I assume they're all just De bruijn indices, so the bigger question is what is the maximum index so I can reserve stack space for them.
AR: Yeah, I agree, seems like a simplification that’s maybe not sufficient for other implementations - good to bet implementation feedback here with real implementations
KM: From our implementation we'd have to do it with two passes, to gather the maximum index and then rewrite afterward.
AR: It would be possible
TL: Are we aware of any toolchain experimentation?
AR: Nope, want to advance to phase 2, then tools can start prototyping
BT: Would it be possible to predclare everything, but they must be let-bound before we use them...
AR: Then you get into control flow dependency issues
JS: Discuss on issue? 1 min left, should make a poll now if we want to.
DeG: More needs to be discussed. Phase 2 poll seems reasonable.
Poll: move to phase 2
| SF | F | N | A | SA |
|---|---|---|---|---|
| 3 | 21 | 8 | 2 | 0 |
ms2ger: Against for lack of actual spec text
DeG: There's been a precedent for that happening for other proposals too. Ross, do you want to say why you're against for notes
RT: it came up that subtyping and typed func ref have very important interaction, and we haven’t talked much about it yet before we move ahead
AR: There's no function subtyping here though, right?
RT: since there is no subtyping yet, if we were to add it later, then performance will be very different. Adding contravariance is not something you wanna do lightly. I want a plan.
DeG: 2 mins over, please follow up with issue on repo