Create vector constants inline and not via ROS<byte>

[gfoidl]

Prerequisites

• I have written a descriptive pull-request title
• I have verified that there are no overlapping pull-requests open
• I have verified that I am following the existing coding patterns and practice as demonstrated in the repository. These follow strict Stylecop rules 👮.
• I have provided test coverage for my change (where applicable)

Description

On .NET 6 onwards (which is relevant here) it's better for codegen to define vector constant inline (including to have helper-methods for this).

• private static readonly VectorXYZ-fields produce less ideal code with more indirections
• reading the vector constant from a ROS (which may refer directly to assembly's data segment) results in some overhead

Now the vector constants can be read from memory directly.

_{PS: I don't have any other planned PRs -- right now weather is too bad / good enough to dig through this code 😉}

[gfoidl]

I've forgotten these in the other PR (I think because they're kept as nint due the operation in L231).

[antonfirsov]

I wonder if we should create a helper method for these? Feels very noisy seeing this before all our SIMD loops.

internal static partial class Numerics
{
    // Not sure about the name
    public static nint VectorCount<T>(Span<T> dest, int vectorSize) => (nint)((uint)dest.Length / (uint)vectorSize);
}

So then we can do:

nint n = Numerics.VectorCount(dest, Vector256<float>.Count);

[antonfirsov]

@JimBobSquarePants meh or yeah?

[gfoidl]

I like the idea.
But it should be generic to account for different vector types w/o specifying the whole vector).

Maybe as extension to span?

[antonfirsov]

But it should be generic to account for different vector types

I wish there was an IIntrinsicVector<T> interface with a static Count property but there isn't, and we are not on net7.0+ anyways :) So I'm just passing Vector256<float>.Count as a parameter in my recommendation, meaning that there is no way to check if the Vector256<T> and Span<T> element types are the same. Not ideal, but still better than writing out the verbose uint magic everywhere IMHO.

[gfoidl]

no way to check if the Vector256<T> and Span<T> element types are the same

They don't need to match. Reading e.g. Vector128<float> out of a ROS<byte> is pretty common.

So for the generic variant there could be two generic arguments. Here I don't like that the type of the span must be repeated. That should be infered (by the compiler).

In your I don't like that VectorXYZ<Type>.Count needs to be typed.

What do you think of this approach (IIRC it's only ROS/Span)?

[antonfirsov]

What do you think of this approach (IIRC it's only ROS/Span)?

I like this option the most. We can have one overload for each span type.

[gfoidl]

Super.

I prefer doing this in a separete PR, as it doesn't match with this PR (this location is a left-over from the other PR) and there a quite a few places that need to be touched.
Fine?

Anyway I'll do this change later this afternoon (here or in a new PR).

[antonfirsov]

New PR is fine for me!

[gfoidl]

--> #2422

[stefannikolei]

@gfoidl On fire

[JimBobSquarePants]

I'm really curious to benchmark the library now vs v3.0.0. There's been lots of improvements!

[gfoidl]

curious to benchmark the library now vs v3.0.0

So am I too. Memory, and especially "static footprint" should be better. The latter is important for server usage, especially for serverless computing (less startup-cost, less memory consumption).