tc39
SSE2 Float64x2 support?
What's the roadmap look like to support Float64x2?
We ported our game engine as well as NVidia's PhysX 3.3.3 to JavaScript using Emscripten, and the SIMD.js support in Firefox currently doesn't support Float64x2. It's currently being patched as such:
Warning: Patching up SIMD.Float64x2.equal to return a Bool64x2 instead of Int32x4!
Warning: Patching up SIMD.Float64x2.notEqual to return a Bool64x2 instead of Int32x4!
Warning: Patching up SIMD.Float64x2.greaterThan to return a Bool64x2 instead of Int32x4!
Warning: Patching up SIMD.Float64x2.greaterThanOrEqual to return a Bool64x2 instead of Int32x4!
Warning: Patching up SIMD.Float64x2.lessThan to return a Bool64x2 instead of Int32x4!
Warning: Patching up SIMD.Float64x2.lessThanOrEqual to return a Bool64x2 instead of Int32x4!
So for now, to keep ASM.js validation, we have to disable SSE2 support, otherwise we get a pretty huge performance hit. I'm being told that it was dropped from the first version spec, but to properly support SSE2 in SIMD.js we need this.
Thank you!
Float64x2 was left out of the ES2015 spec due to the lack of compelling use cases. Would it be possible for this code to use scalar operations for Float64x2 but vector operations for other types? How much of a performance regression do you get due to the lack of Float64x2 support? I don't mean for the asm.js validation failure, but when comparing avoiding using Float64x2 vs what you might expect when using it. This information will be useful in building the case for adding Float64x2.
We are not the owner of NVidia's PhysX SDK. We'd prefer to not modify their code and just use it "as is". And most likely there will be more cases in the near future that uses these types, in code that does not belong to us. Is there any technical difficulties to add support for these types, or is it really just because you didn't have a use case? I find it kind of strange that we would be forced to change all the libraries out there just because of that. I mean, it's part of the SIMD language, you can't just ignore it.
There are many things in SSE that we decided to leave out for various reasons, especially when there was no ARM equivalent. In this case, there was an ARM equivalent, but we received strong pressure from TC39 to reduce the surface area of the API, and this seemed like a thing we could remove. But maybe that decision was in error. I'm not sure whether it would be too late to add that back in, as far as the standardization process goes. The current plan was to leave Float64x2 for Phase 2 of SIMD.js (maybe going for standardization in 2017 or 2018). There are other critical features which are being left for Phase 2, such as support for accelerating the sum of absolute differences.
@sunfishcode @billbudge @PeterJensen @nmostafa Do you think we should try to add back Float64x2 into SIMD.js Phase 1? Or, should we start maintaining a Phase 2 draft spec so that some early implementors can implement Float64x2 (it seems fairly clear what the API shape should be; I don't expect any surprises)? TC39 has made it clear that it doesn't want to hold implementors back from implementing and shipping things until Stage 3, and I'd expect a SIMD.js Phase 2 proposal to sail through pretty smoothly given our reception the first time.
I think it should still be left for Phase 2, not in favor of rushing it. And certainly we can start working on a draft spec for phase 2.
Just to be clear, we are not in a rush to get this in. However your schedule is a bit worrying. We're targeting to release a beta version of our engine running on the web sometime in 2016, release early 2017 if possible. We are not forced to enable SIMD instructions yet, but that would make a bigger splash if we could demo it.
The way that TC39 standardization drives the implementation schedule is by requiring that at least two shipping browsers must have implemented the feature before it can go the final stage (4). However, what also drives implementations is demand. Having a major physics engine as a 'customer' would probably encourage implementors to add the Float64x2 support sooner, I think. So, implementation schedule wise, I don't think pushing Float64x2 to phase1 instead of waiting for phase2 will affect the implementation schedule much. Having a real world use case does. At least I think so.
Here's a post about people trying to use SIMD.js: https://groups.google.com/forum/#!topic/emscripten-discuss/Z0ky-oF4jnc
Seems like the "patching" actually cause performance issues.
Talked with @bnjbvr really briefly at a conference recently, and given that a) we have a good guess what Float64x2 ops will look like, b) Firefox Nightly already implements it (the flavor of it that existed in the spec before it was pulled out) and c) it is useful for porting SSE2 projects, we feel positive about implementing it in Firefox by extrapolating from the spec even if the spec doesn't yet carry it. I don't feel strongly either way whether it should be part of phase 1, but would be very happy to see a draft come up that documents the closest-to-official thinking of what it would look like in phase 2.
I would welcome Float64x2 / Float64x4 very much. It is very useful in simulating differential equations for example, and in some odd cases where you really need extra precision. Or when using interval arithmetic.
