WebAssembly / simd

Branch of the spec repo scoped to discussion of SIMD in WebAssembly
Other
531 stars 43 forks source link

Vector Instructions Instead of SIMD #443

Closed sirinath closed 3 years ago

sirinath commented 3 years ago

Instead of fixed size SIMD why not opt for variable size vector instructions.

ngzhian commented 3 years ago

Variable size vector instructions are a separate proposal in https://github.com/WebAssembly/flexible-vectors/.

sirinath commented 3 years ago

Since variable size vector Instructions will cover all the fixed size SIMD use cases also why have SIMD. You will need more and more instructions as you support different sizes. This is adding more complexity and maintenance issues when some of the instructions become not so relevant down the line.

ngzhian commented 3 years ago

variable size vector Instructions

A proposal with variable size vector instructions is much harder to design. We want to focus on and try to get something useful out soon, and 128-bit is widely available. A flexible vector proposal won't benefit devices like ARM (SVE is not that widely available yet).

We don't plan to add 256 or 512 bit versions of all these instructions (at least no one has come up with the proposal), such wider instructions can be added to the flexible-vectors proposal.

penzn commented 3 years ago

Also flexible vectors proposal builds on top of this one - in the first iteration it extends instruction from this proposal to variable width.

Maratyszcza commented 3 years ago

Since variable size vector Instructions will cover all the fixed size SIMD use cases also why have SIMD.

Variable size vector instructions cover only a small subset of SIMD use-cases, specifically 1D vector operations. 2D operations, e.g. matrix-matrix multiplication either don't perform well with variable-size SIMD, or require specialization for each possible SIMD width. Irregular algorithms (e.g. compression) too typically specialize for a particular SIMD width.

bhack commented 3 years ago

Variable size vector instructions cover only a small subset of SIMD use-cases, specifically 1D vector operations. 2D operations, e.g. matrix-matrix multiplication either don't perform well with variable-size SIMD

So what is the roadmap for this to scale over 128bit?

workingjubilee commented 3 years ago

WebAssembly also is not the only ISA to propose variable width vectors that specifically build on and extend fixed width vectors: Arm's SVE instructions also build on, and require, Arm Neon instructions to be available.

And while it's correct that adding SIMD instructions for both 128-bit and variable-width vectors is, well, adding more instructions, and that makes things more complicated, the fact that there is any application for fixed-width vectors at all means that it is still desirable to have a fixed width API, and it still enables avoiding a far more dangerous threat: having fixed-width instructions for 128 bits, 256 bits, 512 bits, 1024 bits... and so on.

sirinath commented 3 years ago

My logic is a variable length vector instruction when set for 128-bit would be the same as a fixed 128-bit SIMD instruction which will generate the same machine code. Having this will add more instruction which are redundant when variable length proposal is implemented. The useful life of the fixed width proposal is the window between the fixed being implemented and the variable lengths proposal being implemented, which I believe would not be very long. Depending on the platform the generated machine code could be a platform specific 128-bit SIMD instruction.

Adding a new set of instructions (which will become obsolete very soon) does not make sense unless they can be repurposed for variable length proposal as is without making the instructions obsolete. I.e., implement the variable length instructions but the length initially limited to 128-bits.

tlively commented 3 years ago

Since there is already a separate proposal for variable-width vector instructions and they are out of scope for this particular proposal, I'm going to close this issue. Further discussion would be welcome on the other proposal, though!