- Where: zoom.us
- When: February 16th, 5pm-6pm UTC (February 16th, 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.
- Branch Hinting (Yuri Iozzelli) [10 min]
- Poll for phase 2
- Fixed-width SIMD (Zhi An Ng) [10 min]
- Poll for phase 4
- Web Security Content Policy (Francis McCabe) [10 min]
- Potential Poll for phase 1?
- Memory64 (Wouter van Oortmerssen) [10 min]
- Poll for phase 3
- Closure
None
None
Wouter van Oortmerssen
Ezzat Chamudi
Deepti Gandluri
Luke Imhoff
Jay Phelps
Lars Hansen
Rick Battagline
Zalim Basharov
Nick Fitzgerald
Yuri Iozzelli
Francis McCabe
Luke Wagner
Paolo Severini
Derek Schuff
Sergey Rubanov
SJG
Jbirch
Dan Weber
Jakob Kummerow
Petr Penzn
Flaki
Yuri Delendik
Mano Koukoutos
Andrew Brown
Steve Sanderson
Shravan Narayan
Arun Purushan
Mingqiu Sun
Ross Tate
Ryan Hunt
Charles Vaughn
Adam Klein
Andreas Rossberg
Asumu Takikawa
Slava Kuzmich
Emanuel Ziegler
Zhi An Ng
Daniel Wirtz
Ioanna Dimitriou
Ghislain Hude
Nabeel Al-Shamma
Ghislain HUDE
Pat
Keith Miller
Conrad Watt
David Piepgrass
Sam Lindley
YI Presenting slides
AR: the main spec says that no engine is allowed to reject a module due to anything in the custom section. So if it’s malformed, just ignore it. That’s a requirement for custom sections in general.
YI: In particular, while the first few requirements listed here are easy to check because they are in the section itself, we validate everything except the branch section is correct.. I’m not sure how this interaction should be.
LH: you have to validate the bytecode anyway, so the compiler can always reject something while it’s compiling. I don’t think it’s hard to validate the hints during compilation. Mostly it’s about preventing implementations from diverging. Don’t want to hold up the proposal but it would be nice to try to keep the implementations aligned.
YI: That’s why these are included in the slides, want to make everyone aware before poll to phase 2. Have a POC in V8 under an experimental flag - no tools support yet, will be needed to play with this on a real codebase - I have an initial benchmark, but would be nice to have more compiled examples that are useful
PP: Not an attempt to say it shouldn’t be done - couple of meetings ago we had a discussion about floating point modes where we had a discussion about wasm emulating the CPU, similarly we don’t find this in the CPU, a similar point here
YI: you could add more FP instructions to cover the cases; the original proposal had instructions for branch hints, more in line with modeling it as instructions. But I think there’s a need for this kind of behavior since right now the wasm code isn’t directly executable. We found real issues with very unlikely branches that made the generated assembly very suboptimal. Also since the wasm control flow is structured, there’s no good way to place blocks arbitrarily.
PP: I don’t have all the background on the issue, you could think about it as different semantics for codegen - I’m sure there’s a good reason this is being proposed - you would have to put this through tools - there is no hardware that supports this - often the compiler decides this ahead of time and it doesn’t get to the assembly code, just a point to note nothing to block
YI: When code becomes machine code it disappears, this becomes a meta section - another difference to FP is that this doesn’t change the semantics of the program in any way it shouldn’t be observable by a wasm program
WV: I have similar concerns to Petr. Last time we voted on phase 1 there was quite a bit of discussion about whether this can be something purely in the tools. We talked about looking for real-world benchmarks with significant gains. I’m not sure we have enough information there to go forward.
YI: I agree that there aren’t real world benchmarks, did this with a simple loop in V8, there’s a difference but it’s a synthetic benchmark so it’s not representative of anything - working on a codebase which will give 5-10% difference, the way we
DG: we’re about 7 minutes over for this item. Are there other folks who feel that benchmarks should be required for phase 2, or something that can be done after that. Are there opinions on that?
AR: when we discussed SIMD, there were some folks who wanted to see number first.
DG: we were stuck at phase 2 for a long time while we gathered that data. In that case we knew we wanted to do it but didn't know exactly which instructions. I’m not sure if phase 1 vs phase 2 makes the big difference here if the issue is just tools, it will still be on the champions to try to motivate some tool support.
YI: not sure the concerns that were raised are shared with the group. If there are issues about the exact shape of the proposal, i will still go on because we can fix a few things later. Issues with the proposal itself, then we can talk more about it.
DG: we should probably talk more about it in a followup meeting. Next is fixed-width SIMD
Fixed-width SIMD (Zhi An Ng) - slides[10 min]
DP: I”m curious by what you meant by “poor lowering”?
ZN: i64x2 min/max lowers to 9 instructions on x64 - so the Intel lowering does not match the semantics of ARM or the scalar versions, we have to pick or one or the other - heavily feature one or the other - that’s an example of poor lowering - unsigned comparisons are not well supported until AVX512, so that’s not sufficient
PP: one small point: some instructions with somewhat questionable lowering were still added when there was still consensus that they were needed
DG: yes, when they were heavily motivated by application use cases and still had good speedups, they were added
LI: what was wrong with prefetch?
ZN: Prefetch is tricky for specification, if you prefetch out of bounds it’s an error - a no-op is also valid - that makes it hard to specify in terms of normal you don’t really want to spec a no-op - a little bit of tension
TL: beyond the spec issues, we did prototype prefetch and benchmark it, but the results weren't good
PP: They’re heavily biased on architecture
DP: why is prefetch part of this? Isn't prefetch something you could do separately from SIMD?
ZN: Native architectures have added this with SIMD instructions, so based on this feedback - in SIMD there’s usually a stride where you don’t want to prefetch linearly - I believe someone actually brought it up - will add a link to the notes, and take a look at the issue
POLL: Push the SIMD proposal to phase 4
| SF | F | N | A | SA |
|---|---|---|---|---|
| 17 | 18 | 0 | 0 | 0 |
CSP is a policy that the browser enforces, allows publishers to specify what they want to do with content, usually specified as a URL. You specify whether you want to allow a particular site to be loaded from (another?) web page. There isn’t currently a policy for wasm so it’s typically tied to ‘unsafe-eval’ from JS. This is problematic because many people would like to use wasm but not allow ‘eval’ in JS.
FM: Concerns for polling can be that there will be no spec changes here, except that we will make a recommendation to a different group
CV: I’ve got a little more background/ I’m actually the one who filed issue #7 about this. Firefox just allows wasm, doesn’t gate it behind unsafe-eval. Chrome allows you to use CSP with unsafe-eval as long as you’ve loaded in a worker that has unsafe-eval supported. So you can send the module across, but safari doesn’t allow that. So basically we have the worst-case where every browser does something differently and the workarounds are incomplete. This goes back to shipping in 2017 so that’s probably why the phase 0 proposal has a repo. I think wasm-eval is a good approach to get something easy to agree on and implement. This is a risk for recommending wasm as a solution, since it makes it difficult or incompatible with CSP.
FM: To follow up on that -= there’s a regular stream of people that complain that they don’t want to use unsafe-eval, they do want to control this in JS, there’s a substantial set of people that want this
CV: you start to see.. E..g. libsodium, how people discover this is that they grab a Wasm lib, and install into their stack that is more locked down, and realize this is not going to work.
FM: Is Phase 1 the right thing t\
DG: I think phase one seems right, generally it’s pretty low bar, it’s fairly exploratory
DS: generally we thought of phase 1 as, do we agree that this is a problem worth solving.
LI: Isn’t this the same thing as the mime type registration?
DS: similar in the sense that we are not producing an addition to the Wasm spec per se, but something we want to get agreement in the CG about. Francis already laid out what the product will have to be produced, not a spec but something else. Which means not all of the phases will apply. Couple of options, do it ad-hoc, make it a champion responsibility to see what is proposed matching the process.
FM: the product is a letter of recommendation to the AppSec WG
BT: There will be WPT tests that come out of this, they don’t necessarily need to be hosted in this repository - some of the phases map on to what we need to move forward. Even though stuff will land in different repos it matches our phase structure
DG: 1 more minute left, if there are no other concerns, we should poll for phase 1.
POLL: CSP to phase 1
| SF | F | N | A | SA |
|---|---|---|---|---|
| 13 | 10 | 7 | 0 | 0 |
WO presenting slides
KM: did you test if there was a performance difference between 32 and 64 here?
WO: We’ve been talking about this, do not have tests yet - as the V8 work progresses we will get those numbers - this will be slower because we can’t do checks with guard pages, nopt sure how much slower it’s going to be - even if it is significant then doesn’t mean we stop working on it, but more to figure out how to move it forward
KM: if it’s super significant, do we think a lot of people will still want to use this?
WO: If it’s outrageously slower, then most people would want to target wasm64, which is unlikely
KM: we have both [bounds check and not] on 32-bit and we think probably 5-10%
WO: Most people, or most use cases where they want to work in a 64-bit world, it may be an okay price to pay
KM: figuring how to do better memory management, in our current world we have no way of releasing memory. Don’t know if we should gate on that, wonder if we should consider that.
WO: You mean shrink memory? I have an issue open about possibilities about memory reservation as opposed to .. does that sounds like it would be beyond the MVP or the separate proposal
CW: in recent discussion, the person was saying, this is a feature they would like even if 64 bit didn’t exist, could be a separate proposal.
KM: Totally agree that it’s likely to be a separate proposal, overhead is so much higher
WO: Huge fan of bringing memory mapped version of Wasm, happy to chat more about that independent of this proposal for now
RT: i’ll mention that there are some researchers interested in working with wasm on type system ideas for eliminating bounds checks
WO: At this point issue#3 is most important - we concluded on one type of bounds checking, do those options preclude the optimizations
RT: Will point folks to that issue
??: Is there a link I can read the whole scheme that we use for this
WO: <link to issue 3> and overview text in the repo
DG: I think we’re ready for a poll
POLL: memory64 to phase 3
| SF | F | N | A | SA |
|---|---|---|---|---|
| 6 | 22 | 5 | 0 | 0 |
DG: one followup from this meeting that will be added to next meeting is more time for branch hinting.