CG-08-07.md

June 5, 2020 · View on GitHub

WebAssembly logo

Agenda for the August 7 video call of WebAssembly's Community Group

  • Where: zoom.us
  • When: August 7, 4pm-5pm UTC (August 7, 9am-10am Pacific Time)
  • Location: link on calendar invite
  • Contact:

Registration

None required if you've attended before. Email JF Bastien or Ben Smith 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. Adoption of the agenda
  4. Proposals and discussions
    1. Review of action items from prior meeting.
    2. New champions needed for proposals:
      1. Fixed-width SIMD
      2. Type Reflection for WebAssembly JavaScript API
      3. Exception handling
      4. Web Content Security Policy
    3. Moving SIMD proposal to stage 2 (arunp)
      1. What remains to be done here?
    4. Follow up on last meeting's volatile discussion
  5. Closure

Agenda items for future meetings

None

Schedule constraints

None

Meeting Notes

Opening, welcome and roll call

Opening of the meeting

Introduction of attendees

  • Adam Klein
  • Alon Zakai
  • Andreas Rossberg
  • Ben Smith
  • Ben Titzer
  • Conrad Watt
  • Dan Ehrenberg
  • Deepti Gandluri
  • Derek Schuff
  • Heejin Ahn
  • Jay Phelps
  • JF Bastien
  • Lars Hansen
  • Luke Wagner
  • Pat Hickey
  • Peter Jensen
  • Richard Winterton
  • Sam Clegg
  • Sergey Rubanov
  • Sven Sauleau
  • Thomas Lively
  • Thomas Yeun

Find volunteers for note taking (acting chair to volunteer)

Pat Hickey

Adoption of the agenda

Luke Seconds

Proposals and discussions

Review of action items from prior meeting.

New champions needed for proposals:

  1. Fixed-width SIMD

Arun: I was talking to Peter Jensen from Intel about this proposal, pending approval from management we may be able to co-champion this together

  1. Type Reflection for WebAssembly JavaScript API

Andreas: I have too much on my plate to champion this, I’m happy to help with this but need someone to do the work of writing the spec and tests

BS: As champion its not necessarily your responsibility to write the spec or do the technical work, but just to take the role of pushing it forward and finding people to delegate the technical work to. Is that everyone else’s perspective? (Many nods)

Luke: Till volunteered to champion the reflection API.

  1. Exception handling

Heejin volunteers

  1. Web Content Security Policy

JF: Brad setup a meeting with another group in the W3C to talk about how to structure this. There’s low interest from people on the web for getting this right?

BS: I got the same impression. Maybe we can let this drop until people are interested.

BT: I don't know if we will be able to let it drop. Google had some people interested. Maybe Domenic will take it. We’ll have discussions and come back.

Moving SIMD proposal to stage 2 (arunp)

  1. What remains to be done here?

(Copied from Phase document)

  • Full proposed English spec text available in a forked repo around which a reasonably high level of consensus exists.
  • Updates to the formal notation, test suite, and reference interpreter are NOT yet required.

Arun: Is there anything besides these to take it to stage 2?

BS: I copied the requirements in (above). How far off are we on the items in point #2 above?

Deepti: I think there are a lot of rough edges and we are working to resolve issues in the spec. We didn’t have everyone on board with the spec as-is. We didn’t want to call something spec text if it didn't have numbers for the instructions,

JF: When we started the SIMD work we voted to not add instructions that didn’t have a measurable advantage

JF: We can go back to what we had voted on, maybe a year ago. We should figure that part out. Move forward only the stuff that met the bar we proposed.

Deepti: We have some early use cases for the floating point instructions, do we just need a use case or do we need fleshed out performance analysis?

JF: I think it would be useful to go back to what the notes said, add to the issue list -- what we were looking for. It was pretty well thought out, so...

Deepti: Ok

Dan: We went through that process with simd.js and ended up settling on including FP instructions based on some JS benchmarks. Would it make sense to pick up that evidence?

JF: If I remember it ended up being pretty underwhelming. We voted on standardizing an API that works well on every architecture - it has to map well to both arm and x86. If you start adding shuffles and 16-bit instructions I really want to make sure we get it right or else we’ll paint ourselves into a corner. We had a long discussion about this and I want to make sure we stick to it. It was a google meeting at the quad

Keith: I think it was at the microsoft meeting

JF: Yes we discussed it there too. James came back with numbers there

BT: It’s great that we have notes on that, can we get something that’s less hidden away.

JF: Yes this criteria we came up with should be made part of the SIMD proposal.

BS: Action item: put this into the proposal?

Deepti volunteers

Andreas: What is the current status of SIMD with respect to introducing more nondeterminism? Some of the instructions might be underspecified?

BT: Vector floating point on (...) might do something on arm

JF: Some floating point instructions flush to zero - It only does that on arm v7, not on newer v8, so that's up to the implementor. We can also say that ARMv7 can’t use those vector instructions.

BS: There’s another question about reciprocal square root

Deepti: Not in spec, but there’s a pull request

Andreas: So the goal is to avoid more nondeterminism?

JF: We said we would explore it but we need a principled way to deal with it. Will ARMv7 have to devectorize (scalarize) to follow the spec? It’s more difficult for reciprocal square root, useful for games, and we get different results for different hardware. We have some hand-wavy criteria about what we want

RW: The result (for reciprocal square root) is not more or less accurate, it's just different

JF: Similar to threads proposal, there’s a well-defined way to get seq cst, you can step outside those bounds, but you can always constrain the behavior to being deterministic. Maybe FTZ will be fine, we don’t know. That’s the pushback from people like Andreas, trying to reduce non-determinism. We wanted a principled approach so we can provide support for different users of web assembly.

Keith: It would be reasonable to come up with a limiting factor (bound on what nondeterminism may be)

JF: We talked about adding sin and cos, having emulated through libc requires look up tables and so on, but then the question was whether you care about sin and cos way far away from zero. Transcendentals are really hard to get right. The question is: where do you offer the precision, which inputs matter.

Andreas: If we add stuff like that, somehow insulate it (clear criteria) from the rest of webassembly with a high bar for doing that.

Keith: One idea, is to have in your module an imprecision … if you don’t want imprecise floating point ops then you can block it in a module.

JF a few issues / prior discussions:

Andreas: Per-module annotations keep coming up but it doesn’t actually work. Module boundaries don’t mean anything, you can call funcs and in the future take refs across module boundaries.

BT: There should be a deterministic cos and a fast cos, with different byte codes.

Andreas: This reminds me - we already have nondeterminism with NaNs, could we add an instruction to normalize NaNs so that you can work around the nondeterminism you have there, pay the cost to normalize when you need it.

Luke: I’ve been thinking about this case about wasm-on-blockchains… when a host wants absolute determinism, there is a bit set for the host. They get a limit for all the resources, NaNs canonicalized, all that other stuff. I assume that’s what people want...

Andreas: Fully deterministic can work w/r/t/ resources, requirements for how to specify things in that dimension can vary a lot.

Luke: Maybe there are multiple possibilities on resource side -- but otherwise the spec may tell you what it means to be “deterministic”. Maybe a tool injects it for you?

Andreas: We could have an appendix for deterministic wasm. These embedders could use that. But outside that space, we may want to selectively enforce determinism, so for that case it may be useful to inject nan canonicalization.

BT: The NaN canonicalization instruction sounds good to me and is easy to add.

JF: see https://llvm.org/docs/LangRef.html#llvm-canonicalize-intrinsic

LW: Is there a lower-level expressiveness problem? It would add a little bit of code bloat but its not like we haven’t exposed a certain CPU instruction.

BS: If we want to move this forward it needs a stage 0 proposal. We should discuss this more in another meeting.

BT: sounds like the question is: If we are going to have nondeterminism, is there always going to be some escape hatch that comes with it?

Andreas: We also talked about compartmentalization of the spec, so things like threads won’t be allowed on these embeddings. But for other things, tiny things… because there is not a clear boundary that we’re defining for a new feature. There’s a risk that this might spread if we don’t have a clear policy.

BT: One way to phrase that is, try to have fully deterministic from the start but where we can’t achieve it, we add a mechanism that may be a special bytecode or may be a mode to make it deterministic at slightly higher cost that is opt-in.

Andreas: That sounds good

RW: So this means that we may allow FTZ then?

BT: That was part of the original SIMD discussion, FTZ may be something we allow

JF: But just to be clear, this is allowing things that current hardware doesn’t do anymore. Since 2010 this has not been a thing. Modern HW is fast when it comes to denormals, so this would be a backwards-looking feature.

BT: We’re only talking about SIMD with FTZ, not scalar instructions

Andreas: Lets not add it if we don’t have to, but please make sure there’s an escape hatch if it has to be added.

Follow up on handing C++ volatile in WebAssembly

JF: Last meeting we said we’d come back to this - Dan was supposed to look at things, Heejin was going to add some things to the issue.

Heejin: I posted the address of the GH issue for that https://github.com/WebAssembly/tool-conventions/issues/60

The discussion was informative. It’s not really relevant to the spec itself, maybe continue the discussion there.

BS: Since Dan isn’t here there isn’t much more we can discuss.

JF: I’d like to make sure we can let Heejin move forward. Can we bring this up next meeting again? Heejin, are you blocked?

Heejin: For this issue I want to have consensus before we proceed. I want to check in with Dan to make sure he’s comfortable with what we came up with.

JF: Can you and Dan follow up offline and if there is anything still unclear we can discuss it next meeting, otherwise proceed as we discussed last time.

Closure