Consider expanding `Vector<T>` to support `nint` and `nuint`

[tannergooding]

Rationale

Today Vector<T> supports the following 10 primitive types: byte, sbyte, short, ushort, int, uint, long, ulong, float, and double.

C# 9 is introducing support for nint and nuint which are variable sized integers matching the bitness of the underlying platform. That is, they are 32-bits on 32-bit systems and 64-bits on 64-bit systems.

As such, it may be beneficial to expand Vector<T> to additionally support these types so we can get rid of the using aliases and support performing the cross-platform vector operations using these new primitive types.

Proposal

Extend Vector<T> to support nint and nuint as valid primitive types. This will extend a number of existing generic functions which take a Vector<T> to also support taking the new types rather than throwing a PlatformNotSupportedException.

Additionally, the following non-generic APIs should be added for parity with the existing surface area:

namespace System.Numerics
{
 public partial struct Vector<T>
 {
 public static explicit operator Vector<nint>(Vector<T> value);
 public static explicit operator Vector<nuint>(Vector<T> value);
 }

 public static partial class Vector
 {
 public static Vector<nint> AsVectorIntPtr<T>(Vector<T> value);
 public static Vector<nuint> AsVectorUIntPtr<T>(Vector<T> value);

 public static Vector<nint> Equals(Vector<nint> left, Vector<nint> right);
 public static Vector<nuint> Equals(Vector<nuint> left, Vector<nuint> right);

 public static Vector<nint> GreaterThan(Vector<nint> left, Vector<nint> right);
 public static Vector<nuint> GreaterThan(Vector<nuint> left, Vector<nuint> right);

 public static Vector<nint> GreaterThanOrEqual(Vector<nint> left, Vector<nint> right);
 public static Vector<nuint> GreaterThanOrEqual(Vector<nuint> left, Vector<nuint> right);

 public static Vector<nint> LessThan(Vector<nint> left, Vector<nint> right);
 public static Vector<nuint> LessThan(Vector<nuint> left, Vector<nuint> right);

 public static Vector<nint> LessThanOrEqual(Vector<nint> left, Vector<nint> right);
 public static Vector<nuint> LessThanOrEqual(Vector<nuint> left, Vector<nuint> right);
 }
}

Other Considerations

For API names, we have a guideline that states to use the framework name rather than the language keyword name (e.g. Int32 and Int64 rather than int and long). However, the framework name for nint is IntPtr but the operators exposed and general use case for the two types is somewhat different, as such a name such as NInt and NUInt may be a better alternative. Whatever we choose, it should likely become the standard for nint moving forward.

The same request could be made for System.Runtime.Intrinsics, but the API bloat for this would be much larger and would need further consideration. It might be worthwhile to allow nint/nuint as valid T without exposing the additional overloads initially as that would at least unblock users from providing such APIs themselves.

Tagging subscribers to this area: @tannergooding
Notify danmosemsft if you want to be subscribed.

[tannergooding]

CC. @pgovind, @CarolEidt, @echesakovMSFT

[tannergooding]

We have an existing use case in the runtime in Utf16Utility.Validation.cs where we are using the following to workaround not having this:

#if TARGET_64BIT
using nuint_t = System.UInt64;
#else
using nuint_t = System.UInt32;
#endif

[RamType0]

Could you also support any reference types?
This could be so much powerful.(e.g. Collection look up)
Ofcource, we could not cast other type vectors to reference type vector.

[tannergooding]

Could you also support any reference types?

As I understand it, that would be a non-trivial ask and likely not for a lot of benefit. Many of the operations exposed aren't valid or don't make sense for reference types and the JIT doesn't support tracking GC types in the SIMD registers.
There are likely other considerations I'm not aware of as well and which would best be answered by someone like @jkotas or @Maoni0.

[GrabYourPitchforks]

I wonder if we could optimistically handle fast collection lookup anyway, even without support for reference types in SIMD. Consider that you have a T[] (where T is a reference type), and you want to quickly look up the index of any given T within the array. Assume referential equality checks, not deep equality checks.

The algorithm would then be as follows:

1. Pin the T instance that represents your search target, then project this T to a void* then to nuint.
2. Project the underlying T[] as a Span<nuint>.
3. Perform a vectorized search within the Span<nuint> looking for the "target" nuint.

Since the target is pinned, it cannot be moved by the GC, so you don't have to worry about having the GC track individual elements within the SIMD registers. It's possible that the GC might move other elements of the array while you're inspecting it, but that's ok since neither their original addresses nor their modified addresses will match the pinned address of the target you're seeking. This means you're guaranteed zero false positives and zero false negatives.

Again, this would only work for referential equality checks. Since I'm not sure how common referential vs. deep equality checks are I'm not sure how much benefit this would offer in practice.

[RamType0]

BTW,maybe we also want support for enum.

[RamType0]

1. Pin the T instance that represents your search target, then project this T to a void* then to nuint.

Maybe we need some compiler specific support or JIT intrinsic for done this effectively.
Such as

IntPtr e0,e1,e2,e3;//fixed-pointers
Unsafe.WriteUnaligned(ref Unsafe.As<IntPtr,byte>(ref e0),Unsafe.ReadUnaligned<Vector<nint>>(ref Unsafe.As<T,byte>(ref array[0])));
var vector = Unsafe.ReadUnaligned<Vector<nint>>(ref e0);

[RamType0]

C# going to have record type feature.
So compiler can provide detailed,and structured information about it's equality.
If Vector<object> is supported (or work around with nint works), we could compare deep-equality by SIMD.

This is a pseudo code.

[EquatabilityContract]
[CompilerGenerated]
class Record
{
 [EquatabilityMember]
 long id;
}
Record[] records;
Record Find(long id)
{
 for(var i = 0;i + Vector256<object>.Count <records.Length;i+=Vector256<object>.Count)
 {
 var vector = Unsafe.ReadUnaligned<Vector256<object>>(ref records[i]);
 var ids = Avx2.GatherVector256<long>(JitHelper.OffsetOf<Record>(tokenof(id)),vector);//"tokenof" means member definition reference in IL.Compiler could generate it
 var compare = Avx2.CompareEqual(vector,Vector256.Create(id));
 var mm = Avx2.MoveMask(compare.AsBytes());
 if(mm!=0)
 {
 return Unsafe.As<Record>(vector.GetElement(mm/IntPtr.Size));
 }
 }
}