Skip to content

Commit

Permalink
Materialize the section on "Long SIMD".
Browse files Browse the repository at this point in the history
This is meant to address the original concern in
WebAssembly/spec#41
  • Loading branch information
sunfishcode committed May 12, 2015
1 parent fac3a4c commit 04daaa3
Showing 1 changed file with 18 additions and 2 deletions.
20 changes: 18 additions & 2 deletions FutureFeatures.md
Original file line number Diff line number Diff line change
Expand Up @@ -93,8 +93,24 @@ This is covered in the [tooling](Tooling.md) section.
## Asynchronous Signals
* TODO

## Non-fixed-width SIMD
* TODO
## "Long SIMD"
* The initial SIMD API will be a "short SIMD" API, centered around fixed-width
128-bit types and explicit SIMD operations. This is quite portable and useful,
but it won't be able to deliver the full performance capabilities of some of
today's popular hardware. There is an opportunity for someone to propose a
"long SIMD" model which will generalize to wider hardware vector lengths make
more natural use of advanced features like vector lane predication,
gather/scatter, and so on. Interesting questions to ask of such an model will
include:
* How will this model map onto popular modern SIMD hardware architectures?
* What is this model's relationship to other hardware parallelism features,
such as GPUs and threads with shared memory?
* How will this model be used from higher-level programming languages?
For example, the C++ committee is considering a wide variety of possible
approaches; which of them might be supported by the model?
* What is the relationship to the "short SIMD" API? "None" may be an
acceptable answer, but it's something to think about.
* What non-determinism does this model introduce into the overall platform?

## Operations which may not be available or may not perform well on all platforms
* Fused multiply-add.
Expand Down

0 comments on commit 04daaa3

Please sign in to comment.