This could profit from the new c# extension constructs.

Yeah, I'm interested in them. I'm hoping many of these methods will eventually make it into the runtime so I don't actually need them though.

These fallbacks seem to be unnecessary on NET8+. The count >= 16 causes value << count to emit just a vpsllw without and masking.

Right, I'd expect we can drop the Sse2, AdvSimd, and PackedSimd path and instead just do:

if (count >= 16)
{
    return Vector128<short>.Zero;
}
return value << count;

Since count is expected to be constant, the if (count >= 16) path should typically be dropped and we just get vpsllw or the relevant platform specific shift emitted by the xplat operator.

MultiplyLow should be equivalent to Vector128.Multiply i.e. left * right.

Yep, this can just be left * right in all cases

Nothing is actually using that... I must have added it in error.

Maybe overkill but I'd make these widen-saturate-narrow fallbacks into generic helpers (which may not be optimal on Mono) to reduce amount of duplicated code e.g.

interface IBinaryOp<T> { 
    static abstract T Apply(T left, T right); 
}
struct SubtractOp : IBinaryOp<Vector128<T>> { 
    static abstract Vector128<T> Apply(Vector128<T> left, Vector128<T> right) => left - right;
}
// With further overloads for ushort@uint, byte@ushort, sbyte@short.
// Could be made generic over integers too if there was a generic Widen helper...
public static Vector128<short> SaturateOp<T>(
    Vector128<short> left, Vector128<short> right, Vector128<int> min, Vector128<int> max) 
    where T : IOp<Vector128<int>> 
{
    (Vector128<int> leftLo, Vector128<int> leftHi) = Vector128.Widen(left);
    (Vector128<int> rightLo, Vector128<int> rightHi) = Vector128.Widen(right);

    Vector128<int> lo = T.Apply(leftLo, rightLo);
    Vector128<int> hi = T.Apply(leftHi, rightHi);

    lo = Clamp(lo, min, max);
    hi = Clamp(hi, min, max);

    return Vector128.Narrow(lo, hi);
}

Given I'll be getting the runtime versions in the future I'll probably not bother.

Add #if NET10_0_OR_GREATER guard in all narrowing and saturating methods to utilize dotnet/runtime#115525.

I'm only targeting .NET 8 just now. By the time I finally get around to targeting .NET 10, I'll drop 8 support and use the runtime directly.

Pains me to say this, seeing this nice port, but Vector128.ExtractMostSignificantBits is equivalent to MoveMask (and that JIT intrinsic can benefit from AVX512 masking).

Yep, this can just be value.ExtractMostSignificantBits() which does all the same handling here, but which can sometimes be optimized by the JIT for special scenarios and on platforms without a native instruction.

Ha! Fantastic!

These Unsafe.As could be replaced with Unsafe.WriteUnaligned.

These Unsafe.As could be replaced with Unsafe.ReadUnaligned.

This isn't quite the same.

Sse2.Average (pavg) and AdvSimd.FusedAddRoundedHalving (urhadd) are instead effectively doing:

return Vector128.Narrow(
    (Vector128.WidenLower(left) + Vector128.WidenLower(right) + Vector128<ushort>.One) >> 1,
    (Vector128.WidenUpper(left) + Vector128.WidenUpper(right) + Vector128<ushort>.One) >> 1
);

Which is to say that, it accounts for a potential 9th bit to ensure a correct rounded result. This can be observed for Average(255, 1) which should produce 128 but where this fallback will produce 0

This is probably not needed. The xplat call should do the "right thing" and will allow the JIT to use something like Avx.Permute(vector, control) instead if its a more efficient encoding

How can it use Avx when we're targeting Vector128 support only?

AVX isn't just 256-bit support. It includes a number of newer 128-bit instructions and a general new encoding as well. The same goes for AVX512, where it provides a new encoding and newer 128/256-bit instructions in addition to the 512-bit instruction support.

The JIT knows what the actual underlying hardware supports and will opportunistically light up for newer instruction sets where it will benefit perf or size. So it's already using some of these in various places where safe.

For NAOT or other scenarios where you aren't jitting it won't use these newer instructions or encodings, but will still allow optimizations where feasible. For example, certain control inputs may allow you to emit Sse.UnpackLow instead and save 1 byte of encoding space, just because they are equivalent in functionality for that particular control.

Ah but I only use this method where Vector256.IsHardwareAccelrated is false.

That can still be AVX capable hardware. V256.IsHardwsreAccelerated requires AVX2

But even without that, the xplat api still gives more flexibility for the JIT to optimize so it’s often preferred where feasible

We tend to be very 1-to-1 for the platform specific APIs

OK, will update

Similar thing here. I'd expect just the xplat call is sufficient and the JIT will continue emitting the optimal shuffle instruction for that control byte.

I can't see Sse2.Shuffle(vector, control) for float?

Right. I was rather trying to say that I expect you can just have this be Vector128.Shuffle using the same general mechanism for creating the Vector128 indices out of the control. It can have the same general benefits to codegen and makes it more portable.

A better fallback would be to do this:

The reason is that V64 isn't accelerated on all platforms and you already have a V128, so this allows you to avoid decomposing the vector and doing more operations.

Similar comment

In .NET 9+ the Vector128.Create((byte)0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15) can be Vector128<byte>.Indices

The total Vector128.Create((byte)0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15) + Vector128.Create(numBytes) can itself become Vector128.CreateSequence<byte>(start: numBytes, step: 1)

.NET 8 only unfortunately. Good to see a new API though, writing these is cumbersome and not great to read.

Similar thing, in .NET 9 this can become Vector128.CreateSequence<byte>(start: numBytes, step: unchecked((byte)(-1)))

Why not just AdvSimd.Arm64.AddPairwise(prodLo, prodHi)?

I'll add that also. I want to be able to support as many Arm chipsets as possible.

For Arm64, you can use AdvSimd.MultiplyWideningLower/Upper, then shift, then narrow

indices works differently between Avx2 and Vector256

In particular, Avx2 shuffles within 2x 128-bit lanes and so it expects [0, 15] for the lower and then [0, 15] for the upper. (it's effectively doing V256.Create(V128.Shuffle(vector.GetLower(), indices.GetLower()), V128.Shuffle(vector.GetUpper(), indices.GetUpper())

While V256 shuffles within a single 256-bit lane and so it expects [0, 31] across the whole thing. The perf is then dependent on what the hardware supports and if the indices cross lanes at all. That is, it is fastest on all hardware if indices.GetLower() is only [0, 15] and indices.GetUpper() is only [16, 31], just because AVX2 doesn't actually provide full-width byte shuffle; only AVX512VBMI capable hardware provides proper full width support.

Ah... That's interesting. We're relying on the Avx2 behavior currently. I'll have a look at the current calls to see if I can adjust the indices, though maybe I should rename this ShufflePerLane or Shuffle128

Went with ShufflePerLane for clarity.

Based on sse2neon it is probably cheaper to not widen. This applies to other helpers too.