- Where: zoom.us
- When: December 20th, 5pm-6pm UTC (December 20th, 9am-10am Pacific 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)
- Proposals and discussions
- Phase 1 poll: alternate floating-point rounding mode instructions (Kloud Koder)[20 mins]
- Closure
None
None
- Thomas Lively
- Derek Schuff
- Kloud Koder
- Dan Gohman
- Ilya Rezvov
- Slava Kuzmich
- Chris Woods
- Ryan Hunt
- Heejin Ahn
- kevmoo
- Matthias Liedtke
- Brendan Dahl
- Zalim Bashorov
- Benjamin Titzer
- David Piepgrass
- Petr Penzn
- Andrew Brown
Phase 1 poll: alternate floating-point rounding mode instructions
KK: I’ve been advocating for interval arithmetic primitives because 15 years ago I learned the importance of interval arithmetic for mechanical engineering and software engineering. I assumed it would go mainstream because of how important it is for safety in engineering, but it hasn’t. As I realized all the problems of implementation of rounding modes, I figured it wasn’t going to just happen itself, so I decided to help do something about it. There’s an interval arithmetic library in Rust, and its authors have agreed to implement it in wasm, so thanks to them for their help too.
KK presenting proposal
KK: All of these are the same as instructions that we have, with different rounding modes. The order is the same as in the existing spec. From the discussion, I’m proposing a separate rounding mode byte. There do exist other rounding modes (e.g. away from zero) that may appear in hardware in the future, so this leaves room for them. SIMD is not included, because unfortunately ARMv8 does not implement them.
There are also sign extraction instructions. F32.sgn just extracts the sign bit, even if it’s just a NaN. the asgn version gets the arithmetic sign, (e.g. + or -0)
We need these instructions because you would need to emulate it on every multiply or divide.
TL: Can you explain the sign extraction again, why it’s needed?
KK: This is outlined in the issue somewhere; if you do a multiply in interval arithmetic, literally the method you use, that yields the final interval has a bunch of ifs that ask about the sign of the inputs. If you have really wide SIMD you could do all the possible sign permutations and mask them off, but practically hardware doesn’t really support that. So you are asking the same thing all the time, which requires converting from float to int, and it’s expensive.
TL: Is there a more efficient hardware implementation of this than the equivalent sequenc of wasm instructions today?
KK: Intel I believe has an fsign/ftest/fextract sometthing like that, that can get the bits in ah
TL: you mentioned this Rust interval library. Do you know who their users are? Any interesting applications?
KK: don’t actually know.
DS: Any other use cases besides interval arithmetic for these alternative rounding modes?
KK: Maybe hardware vendors thought that intervals would matter, I don’t know. The other application is integer rounding. Apart from that, I don’t know.
CW: there are applications in cyber-physical control systems, and that would be of interest to us as a potential user, as a global manufacturer of lots of things, power equipment, industrial, and shop-floor stuff, etc.
TL: you’re the first large company that’s expressed interest in this proposal, do you have resources that could be put toward the development of this proposal?
CW: we do have some resources, but they’re currently committed to other parts of wasm. Obviously our use cases are outside of the browser world. WE could probably help some with e.g. validation, but most of our resources are currently allocated.
TL: just thinking about the process, I don’t see a problem going to phase 1 today. But going forward, unless the process changes we need 2 browser implementations, so browsers need to be convinced that it’s worth implementing. As a step toward that it would be useful to get real-world experience with it, even if it’s not in the browser. So e.g. if someone implemented in something like WAMR and got some real world testing (e.g. you) that could help motivate the browsers to implement even without
CW: yeah that’s something I think we could talk about directly.
DP (chat): Btw, does anyone know if, of anyone who is taking a serious interest in unums/posits (http://loyc.net/2019/unum-posits.html)?
DP: there’s a book called “the end of error that talks about unums, that discusses rounding error and getting tighter bounds than you can get with interval arithmetic. It has unum as the building block, which is better than FP number. You get ranges of results like interval arithmetic, and it gets a tighter bound around the answer by using more than 2 numbers. It’s really interesting but does need hardware support to be fast.
DS: This sounds vaguely familiar. We might have had folks suggest this for Wasm in the past. Historically the response has been that it’s one of the design goals of wasm to expose existing functionality rather than coming up with completely new primitives.
DP: Unums have a long history at this point of interesting ideas, but also of over-hyped "this fixes everything!" advertising and not entirely fair characterizations of IEEE 754.
PP: Missed beginning of presentation, but intel was discussed, right? I.e. the performance considerations? E.g. in Intel the rounding mode is global; if you have individual instructions and you might end up flipping the rounding mode back and forth a lot.
TL: yeah this is one of the things I think an implementation can help with, to see what the actual performance is.
PP: yeah this is also something that a compiler optimization could help with, just wondering if you’d discussed it. If someone implements this in a system without separate instructions you’d need to find a way to group them.
Vote for phase 1:
SF: 4 F: 3 N: 8 A: 0 SA: 0
Phase 1 vote passes
BT: I think these rounding modes are great for converting integers as I mentioned on the issue. Also because this is in hardware we should find a way to expose this and there are niche uses. So the issue is just finding a good encoding
DG: I’ll also add that this has been an open question in wasm for a long time so I’m happy to see it making progress.