search

tc39 / ecmascript_simd

SIMD numeric type for EcmaScript
Other
544 stars 64 forks source link

Separate out Phase 2 items from polyfill/tests #214

Closed littledan closed 9 years ago

littledan commented 9 years ago

This includes selectBits, {load,store}[123], Float64x2. Once we have this separated out, Phase 2 can serve as a playground for additional new features that we can't get into Phase 1. In particular, we need the tests separated out in order to get to Stage 3 at TC39.

littledan commented 9 years ago

load/store123 are staying. We can just delete selectBits and Float64x2 and they will live on in the git logs.

dead-claudia commented 9 years ago

Use case for Float64x2/Bool64x2: complex number libraries, and other scientific libraries. Where's the reasoning for that lacking a use case?

johnmccutchan commented 9 years ago

@impinball We are looking for benchmarks which help motivate the inclusion of features. Do you have some benchmarks that use Float64x2 and demonstrate a significant speedup when ported to SIMD?

littledan commented 9 years ago

Done

juj commented 9 years ago

What was the rationale to delay Float64x2 to phase 2? Is there (an approximate even?) schedule for phase 2 to roll out? I am having trouble to understand that "we decided to remove it because nobody gave us a benchmark to prove it is useful" would have been a good reason. Was there any other reasons?

The removal of Float64x2 is making it difficult for me to port Unreal Engine, PhysX, OpenCV, MathGeoLib and Opus to use SIMD, since @sunfishcode replaced the SIMD polyfill in Emscripten which removed Float64x2 there, which impacts attempts of supporting SSE2. Is there a phase 2 polyfill maintained somewhere that would not have it removed?

sunfishcode commented 9 years ago

@juj At present, there is no up-to-date polyfill for Float64x2. However, it should be easy to re-introduce on top of @billbudge's recent refactoring work.

The rationale for removing it from the current standard proposal is that SIMD.js is a significant addition to ES, introducing value types, a new API idiom, and an extraordinarily large (given the context) number of new functions, and the committee wished us to reduce the overall size.

Fortunately, additions to SIMD.js will be much simpler to standardize than the initial version of SIMD.js since they won't introduce new kinds of types or new kinds of APIs; they'll just be introducing new types and APIs similar to existing ones. And, updates will fit well with TC-39's new processes which are aimed at letting features be standardized when they're ready rather than waiting for the next monolithic document publication.

And, my understanding is that many of the Float64x2 use cases are also SharedArrayBuffer use cases, and while it's definitely important for us to be prototyping both of these, the importance of actually standardizing Float64x2 is not as great as it could be when paired with standardizing SharedArrayBuffer too.

billbudge commented 9 years ago

We should probably refactor the polyfill and tests so we can optionally add Phase 2 types, relaxed APIs and architecture specific APIs. As it stands it would require a separate polyfill that couldn't reuse the existing polyfill's internal machinery. It seems straightforward to make everything more data-driven, so the polyfill and tests are totally declarative, and get turned into code by a common mechanism.