I’m working on a Maths library, and I’d like to be able to convert it to use the new INumber<T> interfaces in System.Numerics. The methods in here are often on hot paths and so would be good if they can be as fast as possible, while also being pleasant to work with. I’ve been benchmarking them as I go, and noticed something that seems a little odd.

There’s a few cases where we divide an array value by its index, due to using System.Numerics, this cannot be done via an implicit conversion like you would when the type is defined, the recommended method seems to be to use INumber<T>.Create{Checked|Saturating|Truncating}(int n)

The benchmark methods I’m running are fairly simple, like so:

public static double[] DivideByImplicit(double[] values)
{
    double[] result = new double[values.Length];
    for (int i = 1; i < result.Length; i++)
    {
        result[i] = values[i] / i;
    }

    return result;
}

// Overloads for other types (int, long, float, decimal)
// ...


public static T[] DivideByChecked<T>(T[] values) where T : INumber<T>
{
    T[] result = new T[values.Length];
    for (int i = 1; i < values.Length; i++)
    {
        result[i] = values[i] / T.CreateChecked(i);
    }

    return result;
}

// Same again but for Saturating/Truncating
// ...

For int, long and decimal, the results are within a few percentage points at most, but when it comes to float and double there’s a much larger performance hit, ~25% for double but up to a full 100% increase in time for float:

Why is the impact so much higher when converting to a float/double than it is to any other numeric type? Not shown for brevity, but I also ran benchmarks for arrays of size 1, 100 and 1_000_000, and the slowdown wasn’t visible on 1 or 100, but was similar on 1_000_000.