#487: WebAssembly SIMD review

Visit on Github.

Opened Mar 19, 2020

Hello TAG!

I'm requesting a TAG review of WebAssembly SIMD.

Further details:

  • I have reviewed the TAG's API Design Principles
  • The group where the incubation/design work on this is being done: WebAssembly Community Group
  • The group where standardization of this work is intended to be done: WebAssembly Working Group

You should also know that...

This is purely a WebAssembly performance feature that does not affect web API behavior, but is still useful for developers to be aware of as it can change performance characteristics of applications using WebAssembly. It adds a new 128-bit value type that is not exposed to JavaScript and several new opcodes for vector operations that are documented here.

We'd prefer the TAG provide feedback as:

🐛 open issues in our GitHub repo for each point of feedback

Discussions

2020-04-06

Minutes

Ken: I think it's pretty good.

[discussion of JS SIMD]

Tess: it's surprising to me that there would be a desire to expose SIMD just to WA and not JS.

Tess: worried that the shape of the API of the web is being driven by expediency... that worries me. I don't like the idea of JS and WA have different capabilities.

Ken: [WA] does have threading as well.. They are working on it [JS SIMD].

Tess: i will take a look soon.

Ken: our Intel SIMD experts have looked at this and ensured that it meets requirements... I could have a talk with internal team .... This covers the use cases they have.

Dave: have some people reviewed that it makes sense across other architectures?

Ken: it works on ARM.

Ken: will get additional feedback this week.

Peter: let's try to close it off at the plenary session

2020-06-22

Minutes

Peter: updated explainer... Missing Tess. Should we defer this to another breakout?

Ken: I'm fine with it. It's web assembly only. Designed in a way that works across architectures... So I think it's pretty well designed. Heavily used in codecs, gamed, machine learning. It would be sad not having access to this on the web I think. Tess said should we have this on javascript - some performance issues with that. It is specialized but for people that use WA it makes a lot of sense. I don't see anything wrong with the proposal.

Peter: marks as proposed closed - and let's close it at the plenary