CG-07-09.md

Agenda for the July 9 video call of WebAssembly's Community Group

• Where: zoom.us
• When: July 9, 4pm-5pm UTC (July 9, 9am-10am Pacific Daylight Time)
• Location: link on calendar invite
• Contact:
  • Name: Ben Smith
  • Email: binji@google.com

Registration

None required if you've attended before. Email 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. Extended name section
      1. Poll: Phase 1?
   3. Discuss WebAssembly Benchmarks repo
   4. Single Module Feature testing
      1. Poll: Phase 1?
   5. TPAC 2019 Wasm presence
   6. WebAssembly Discord server
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

• Alon Zakai
• Luke Imhoff
• Sam Warfield
• Ben Smith
• Deepti Gandluri
• Derek Schuff
• Francis McCabe
• Jacob Gravelle
• Sam Clegg
• Andrew Scheidecker
• Deepti Gandluri
• Thomas Tränkler
• Lars Hansen
• Thomas Lively
• Alex Crichton
• Ryan Hunt
• Andreas Rossberg
• Petr Penzin
• Jay Phelps
• Arun Purushan
• Sergey Rubanov
• Adam Klein
• Keith Miller
• Pat Hickey
• Lilit Darbinyan
• Sven Sauleau
• Fisher Darling
• Peter Jensen
• Rich Winterton
• Ben Titzer
• Michael Starzinger

Find volunteers for note taking (acting chair to volunteer)

Adoption of the agenda

Proposals and discussions

Review of action items from prior meeting.

None.

Extended name section

AS: Old PR that I had, gist is to add the missing components to the name section that are currently stopping round tripping from wast file to binary format - type names, table names, memories, global names… everything that can be named in the text format in the MVP. WAVM has implemented this for a long time, along with an lld fork that implements some of these.

Open to using byte offsets, but for consistency indices are more robust and easier to implement, for WAVM at least. Encourage folks to look at the overview. https://github.com/AndrewScheidecker/wasm-extended-name-section/blob/master/proposals/extended-name-section/Overview.md

SC: Seems non-controversial except for label names. It would have to come from the debug information, haven’t looked at the fork yet. What are we looking at for this proposal today?

AS: Moving from phase 0 to phase 1. Not sure how much it affects the process here, but this doesn’t add any changes that affect the Wasm spec, so it’s not clear. The name sections are not tested by the spec test suite.

LI: Purpose is to round trip, so we should have tests that test that

AS: If you have a producer that puts something useful in the names then that’ll come out in the discussion

KM: For functions in the JSAPI, useful to expose as .name for exposing the function name for exported functions. We could add it to the proposal - Doubtful if it’s a breaking change. Have tests for it

AR: It’s reasonable to extend the JS API, but difficult to specify. Name section is a custom section, so it could be garbled, but we can spec that it’s not well formed then it doesn’t return anything. You have to be restrictive about what you specify. Makes sense?

KM: Sounds reasonable

AS: Not in my interest to specify anything related to JS. Proposal is for folks only on the Wasm side of things. One other note, I also have names for data and element segments - is the right place to put this in the bulk memory proposal?

TL: Bulk memory proposal is far enough along, but let’s not add anything new there - having them in a new proposal sgtm. DS: Fairly uncontroversial in terms of the proposal. Any objections to moving this to phase 1?

KM: When is the scope of the feature decided?

BS: Phase 1 is meant to be that this is a problem we want to address, reasonably happy in the design direction, some of the details can be hashed out later.

PP: Is this going to be used for debug info?

AS: Not exactly, wouldn’t be replacing existing debug information. This is names that are in the text format DS: Nobody is proposing that browsers parse debug info, but the names section would specify the need for names to be parsed correctly.

TL: Is it easily extensible to add new types of sections? I.e. events section - will it be trivial to extend?

AS: This proposal doesn’t change any of that from the MVP, WAVM has names for what you’re calling events, so pretty straightforward to add

DS: Any objections to move to phase 1? No objections. [AI: File an issue/Fork a repo]

Discuss WebAssembly Benchmarks repo

BT: Created a repo, seems to have good support about having this be a public repo. I have some ideas, but would like to run them by the group. Talked about requiring certain type of line items - licensing, understanding the benchmarking algorithm, and how it works. We should avoid the knowledge of how the benchmarks are implemented being lost, so they are easily modifiable and understandable.

BT: Also methodology, lots of academic literature here. Sigplan has recommendations, 6 page explainer. We can follow suit here. I’d like to put up some info here on the repo. Want to gather more info here from folks.

BT: Right process is to propose line items as github issues LI: one way we might allow kernels is if we have a minimal reproduction case that documents the history of why the code snippet matters. But it’s better to have the relevant code in a tight loop rather than in a whole web page. But it’s good to have e.g. a link to a bug with the context

BT: Definitely agree that we should allow kernels, microbenchmarks, applications, domain specific applications. Kernels are vital, motivation for having algorithmic descriptions is so that we understand the implementation

BS: Some people were commenting in the issues in the design repos with bechmarks they were interested in, have you looked at any of those?

BT: Haven’t looked at them yet, will look through them. Have someone on my team that will be looking into this. People interested please subscribe to the issue if interested. DS: Any questions/comments?

LW: Was previously interested in load time benchmarks, I had some workloads but there were problems, can I delete that repo as it’s subsumed by this one?

BT: Propose them as an issue on the current repo so they’re not lost?

LW: one of those was godot, which was good but it was problematic because it depends on WebGL2

BS: Let’s archive instead of deleting.

LW: Trying to reduce visual noise, strart with archiving

BT: Looked at a lot of benchmarks, just a bunch of C code, no licensing, possibly from the 80s. HAving it licensed, and documented is useful.

PP: this is good, it’s been missing from a lot of recent conversations about web performance.

BT: File issues first, and then Pull requests. Casting a wide net first, and then narrowing them down.

BS: Maybe have them in a separate branch, so people only see official benchmarks on master

FD: Thoughts on augmenting the wast format or other format to load up the description of e.g. the benchmark type? It’s convenient to be able to automatically fetch tests when developing an implementation.

BT: What kind of an extension were you thinking of?

FD [??]

PP: Chakra has a wrapper for wabt, JS interface for wabt. Not sure if that’s helpful

??: When we get the collection of benchmarks together, when there is some code, have the documentation with it so we know why it’s there.

BT: Yes

??: Should we figure out the format through issues?

BT: Yes

DS: Any other comments or questions for Ben?

BT: Thanks

####Single Module Feature testing

BS: also related to “fat binaries” e.g. multiple formats in a single binary One observation is that I think a lot of the code would be common between modules that do or don’t use the feature (for many of the features at least). Hopefully adding a second feature to a module wouldn’t increase the size by 2x.

RW: SIMD easy to test for single versions, should we think of this as a growable section? Because new instructions can be added as additional proposals

BS: I have a couple of different ways this could work. If some new iteration of simd adds horizontal adds, you can have them as separate bits that you check for in the module. Will get into the alternatives later.

BS: High level idea is that for the binary format we add two new section types, feature test section, and conditional section

BT: If you have a feature that adds new types you need multiple sections, and that are combined together?

BS: Sections are easy to extend..

BT: How do you reference them stabilly?

BS: That’s a tooling concern, index means different things, if you want it to be stable, you have to pad it out or make sure they occur earlier.

BT: e.g. if the feature is true, use these 12 functions but otherwise use these other functions

BS: This is a relatively simple way of specifying that

LI: since we use byte offsets, how does that work as if they were compacted in memory?

BS: We don’t use byte offsets for anything currently. We only use them in some of the custom sections. All of the official known sections use indices

LI: does it matter that the index space has holes in it afterwards?

BS: the idea is that there wouldn’t be holes, you’d have to put in dummy elements or know how to remap those values.

AR: This feature test section contains modules essentially? IS this completely recursive?

BS: Wasn’t my intention, we want to constrain that in some ways. This part of the feature is most controversial, maybe we should have strings instead. It does have some troubling aspects

AR: requires the decoder/validator to be reentrant, so that’s a bit concerning, may not be worth the complexity

BT1: Does this add complexity to the names section, or other debug info we’ve discussed?

BS: Yes, if you have new sections you have to add a custom section that’s conditional

LI: if we need multiple sections with the same condition, could you include multiple with the same condition so the impl doesn’t have to re-evaluate?

BS: Let me talk about the conditions - at a high level conditions should be simple to evaluate. Shouldn’t be more complicated than the types of sections we currently evaluate. For each feature test bit we get 0/1 and then we can combine them. Local.get would be a way to get the 0th feature and combine with and/or eqz with the condition you want. So it’s possible you need multiple evaluations, tl has a proposal that i will later discuss

FM: is there a possibility of not loading the module if the feature test fails?

BS: you could have a section which was invalid, so yes but it would be clunky

FM: You might want to add that capability, gating feature

TL: Question about conditional section, would be nice if they were custom sections. We need some way to say don’t include.. If you have an MVP section, and you want to replace it with some feature, you don’t want the mvp to be strange in any way, you want all MVP engines to recognize it the same way. If you can only mark customs as being the ones that can be turned on, and not have the capability to turn off MVP sections, it’s not gracefully backwards compatible.

BS: yeah i agree it would be nice. I'm a little uncomfortable using custom sections, but it's probably the only way to make it work with MVP

TL: Alternatively we could figure out what the cost is, and then explicitly say that it’s not compatible, but worth looking closer

BS: ultimate goal is that we have some way to specify in a single module, multiple modules with different features and validate different ways. With a native binary you can just add instructions, and if they dont run it doesn't matter. With validation we need a way to not validate part of the binary. So we have section boundaries as the most natural division so we need to figure out how to combine sections, etc. maybe having a way to exclude sections.

LI: How will this interact with WASI’s optional import feature? Will it subsume?

BS: Orthogonal.. Engine decides the implementation. Think of it as something separate - what kind of sections will validate, and not what imports are available.

RW: Could see a use case where I’d like to know what features are available through JS. Have you thought about what we can expose to JS?

BS: you can already do that using feature test modules. This is meant to avoid having to do a second fetch. If you want to expose features like that, you could e.g. have a conditional global section which returns true if the feature is present. A bit clunky but you could do it that way.

AS: would it be simpler to have a way to embed multiple modules, and your conditions enable/disable that, and yo specify how the inner modules map to imports/exports of the outer module?

TL: One of the ideas is that you can have a module that’s 95% the same, one uses SIMD and the other doesn’t. For that one little hot loop you want a SIMD/non-SIMD version and nothing else.

AS: Proposing that you have module level conditionals instead of section level conditionals. The feature test specs at the top of the module defines how the main module that is not conditionally compiled will import the SIMD/non-SIMD a nd the feature test section will figure out which function to import.

BS: one of the things i tried to solve is that putting the sections in the same place allows streaming compilation like normal; separating into modules would make that harder.

BT: By having a conditionals sections the modules have access to the internals, so if you have two modules that need to share state that will need to be imported/exported

<alternative feature test section, alternative conditional section from slides>

SW: sponsorship for college students is still open, can we discuss this soon so people can take advantage of that?

DG: I’ll start a github issue to discuss

BS: should we poll for phase 1 for feature testing?

Objections for phase 1?

SC: have concerns about the complexity it puts on the tools, but that doesn’t need to block phase 1.

AR: I have more fundamental concerns, but shouldn’t block phase 1. [no other objections, so unanimous consent for phase 1]

DG: can move discussion to a future meeting. But briefly: TPAC early registration is closed. Folks interested in attending, but won’t be an official CG meeting. We should talk about what we want the wasm presence to be. We can add that to a future CG meeting. Also: previously we discussed an official chat other than the IRC which hasn’t got much traction. Pasted a discord invite link, folks can try it out, and we can discuss online in future meetings.

Closure