Re: Short Vectors Versus Long Vectors

On 4/23/2024 5:39 PM, MitchAlsup1 wrote:

BGB wrote:
 

On 4/23/2024 1:22 AM, Anton Ertl wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Tue, 23 Apr 2024 02:14:32 +0000, MitchAlsup1 wrote:
big snip>

 

As can be noted, SIMD is easy to implement.

 ADD/SUB is, MUL and DIV and SHIFTs and CMPs are not; especially when
MUL does 2n = n × n and DIV does 2n / n -> n (quotient) + n (remainder)
 

MUL:
Have a few instructions, giving the Low, High-Signed, and High-Unsigned results.
DIV:
Didn't bother with this.
Typically faked using multiply-by-reciprocal and taking the high result.
Something like MOD would need to be faked, but SIMD modulo doesn't really tend to be a thing IME.
Division by a non-constant scalar/vector value will need a runtime call.
SHIFT:
Mostly faked using ALU shifts and masking.
CMPxx:
There are dedicated instructions for this.

Main obvious drawback is the potential for combinatorial explosions of instructions. One needs to keep a fairly careful watch over this.

 

Like, if one is faced with an NxN or NxM grid of possibilities, naive strategy is to be like "I will define an instruction for every possibility in the grid.", but this is bad. More reasonable to devise a minimal set of instructions that will allow the operation to be done within in a reasonable number of instructions.

 

But, then again, I can also note that I axed things like packed-byte operations and saturating arithmetic, which are pretty much de-facto in packed-integer SIMD.

 MANY SIMD algorithms need saturating arithmetic because they cannot do
b + b -> h and avoid the overflow. And they cannot do B + b -> h because
that would consume vast amounts of encoding space.
 

There are ways to fake it.
Though, granted, most end up involving extra instructions and 1 bit of dynamic range.
Though, the main case where one can't spare any dynamic range is typically packed byte, which I had skipped (in favor of faking packed-byte scenarios using packed word).
But, could add, say:
   PSHAR.W  Rm, Rn  //Packed Shift right 1 bit, arithmetic
   PSHLR.W  Rm, Rn  //Packed Shift right 1 bit, logical
   PSHAL.W  Rm, Rn  //Packed Shift left 1 bit, arithmetic saturate
   PSHLL.W  Rm, Rn  //Packed Shift left 1 bit, logical saturate
In a naive case, one could fake a virtual PADDSS.W instruction as, say:
   PSHAR.W  R4, R16
   PSHAR.W  R5, R17
   PADD.W   R16, R17, R18
   PSHAL.W  R18, R2
These could more efficiently address both saturation, and 1-bit shift (the most common case).
Shift left 1-bit (without saturation) can generally be handled with:
   PADD.W R4, R4, R2
Or similar.

Likewise, a lot of the gaps are filled in with specialized converter and helper ops. Even here, some conversion chains will require multiple instructions.

 

Well, and if there is no practical difference between a scalar and SIMD version of an instruction, may well just use the SIMD version for scalar.

 

....

 

- anton