UInt128 improve division by 64 bit on x64

[Daniel-Svensson]

Adds a similar fast path as for decimal
#99212 for when divisor fits in 64 bit.

It should inprove performance quite a bit if the UInt128 is larger than 64bit.
I did not do any benchmarks but based on similar test for 96 by 32 division the new code should be at least 10ns faster.

Question:

• Have you considered adding overloads for division (and maybe multiplication) against ulong/uint?
  That should allow specialized faster code for common scenarios without adding complicated code to the JIT to detect and handle it without lots of runtime checks for 64/32bit values.

Note: It might be possible to further improve performance for non x64 by calling into decimal`s Div96By32 or Div128By64 if divisor is lower than than the top 64 byte for all other platforms, but it would require measuring the performance.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-numerics
See info in area-owners.md if you want to be subscribed.

[tannergooding]

This has build failures that need to be addressed. Looks to be warning due to the usage of an API marked preview.

[Daniel-Svensson]

@tannergooding I added suppression for "CA2252 // This API requires opting into preview features" in source.

I assume there is a good reason why preview features are no longer allowed System.Private.CoreLib when it was previously allowed for "dogfooding preview features", so looking at enabling it for the project seemed to be out of question.

Is there a better way to solve it available to corelib / the dotnet runtime repro?

[jkotas]

This API is marked with Preview attribute because it produces suboptimal code. Have you verified that this change actually improves performance?

In general, any change that is a performance optimization needs to come with perf numbers.

[Daniel-Svensson]

This API is marked with Preview attribute because it produces suboptimal code. Have you verified that this change actually improves performance?

It is not optimal, but it is quite good

As I understand it the major issue which prevents general usage in Math.DivRem is that constant detection (and maybe propagation) is not yet done. The generated code is can often be optimal, unless you use to many value tuple calls and it starts to spill to the stack.

As for preview

In general, any change that is a performance optimization needs to come with perf numbers.

Yes, see Uint128 division benchmarks below, the it should give a much better confidence than my original statement about it being at least 10ns faster. (it is almost 20ns or 9 times faster)

This PR

commit 60cc066

(I built the benchmarks as self contained and then copied over all dll's from (runtime\artifacts\bin\coreclr\windows.x64.Release)

BenchmarkDotNet v0.13.12, Windows 11 (10.0.22631.3593/23H2/2023Update/SunValley3)
AMD Ryzen 7 5800X, 1 CPU, 16 logical and 8 physical cores
.NET SDK 9.0.100-preview.4.24267.66
  [Host] : .NET 9.0.0 (42.42.42.42424), X64 RyuJIT AVX2

Job=InProcess  Toolchain=InProcessEmitToolchain  

Method	A_high	A_low	B	Mean	Error	StdDev	Allocated
DivisionByUInt64	0	7115061911280	1311768467463790321	2.278 ns	0.0052 ns	0.0044 ns	-
DivisionByUInt128	0	7115061911280	1311768467463790321	2.760 ns	0.0035 ns	0.0029 ns	-
DivisionByConstant	0	7115061911280	1311768467463790321	2.377 ns	0.0043 ns	0.0038 ns	-
DivisionByUInt64	1	7115061911280	1311768467463790321	2.322 ns	0.0669 ns	0.0687 ns	-
DivisionByUInt128	1	7115061911280	1311768467463790321	2.632 ns	0.0082 ns	0.0069 ns	-
DivisionByConstant	1	7115061911280	1311768467463790321	2.439 ns	0.0136 ns	0.0120 ns	-

NET 9 preview 4

BenchmarkDotNet v0.13.12, Windows 11 (10.0.22631.3593/23H2/2023Update/SunValley3)
AMD Ryzen 7 5800X, 1 CPU, 16 logical and 8 physical cores
.NET SDK 9.0.100-preview.4.24267.66
  [Host] : .NET 9.0.0 (9.0.24.26619), X64 RyuJIT AVX2

Job=InProcess  Toolchain=InProcessEmitToolchain  

Method	A_high	A_low	B	Mean	Error	StdDev	Allocated
DivisionByUInt64	0	7115061911280	1311768467463790321	2.417 ns	0.0048 ns	0.0045 ns	-
DivisionByUInt128	0	7115061911280	1311768467463790321	2.725 ns	0.0094 ns	0.0078 ns	-
DivisionByConstant	0	7115061911280	1311768467463790321	2.438 ns	0.0032 ns	0.0025 ns	-
DivisionByUInt64	1	7115061911280	1311768467463790321	20.622 ns	0.1809 ns	0.1692 ns	-
DivisionByUInt128	1	7115061911280	1311768467463790321	22.516 ns	0.4261 ns	0.3777 ns	-
DivisionByConstant	1	7115061911280	1311768467463790321	22.324 ns	0.0258 ns	0.0215 ns	-

Source code

```// See https://aka.ms/new-console-template for more information using BenchmarkDotNet.Attributes; using BenchmarkDotNet.Running;

Console.WriteLine("Hello, World!");

// Run benchmakrs using benchmarks switcher
BenchmarkSwitcher.FromAssembly(typeof(BenchmarkUInt128Division).Assembly).Run(args);

///

/// Benchmark UInt128 division using BenchmarkDotNet.
/// The property A uses Param and is a UInt128 with iether 0 or a random value in upper 64 bits.
/// The property B uses Param and is a UInt128 created from a 64bit value
///

[MemoryDiagnoser]
[InProcess]
public class BenchmarkUInt128Division
{
UInt128 _a;
UInt128 _b;
ulong aHi;
ulong aLo;

[Params(0, 1)]
public ulong A_high
{
    get => aHi;
    set
    {
        aHi = value;
        _a = new UInt128(aHi, aLo);
    }
}

[Params(0x00006789abcdef0)]
public ulong A_low

{
    get { return aLo; }
    set
    {
        aLo = value;
        _a = new UInt128(aHi, aLo);
    }
}

[Params(0x123456789abcdef1)]
public ulong B
{
    get => (ulong)_b;
    set => _b = new UInt128(0ul, value); 
}

[Benchmark]
public UInt128 DivisionByUInt64()
{
    return _a / B;
}

[Benchmark]
public UInt128 DivisionByUInt128()
{
    return _a / _b;
}

[Benchmark]
public UInt128 DivisionByConstant()
{
    return _a / 7;
}

}

</details>

[jkotas]

I have done quick perf tests:

using System;
using System.Diagnostics;

var sw = new Stopwatch();

for (;;)
{
   sw.Restart();
   UInt128 sum = 0;
   for (UInt128 i = 1; i < 100_000_000; i++) sum += (UInt128)i / (UInt128)3;
   Console.WriteLine(sw.ElapsedMilliseconds);
}

It runs 1.3x slower with this change. Would it be better to apply this optimization only for non-zero higher bits?

[Daniel-Svensson]

Would it be better to apply this optimization only for non-zero higher bits?

I've changed the order so that the new code is only used as a fallback in case of non-zero higher bits.
It seems to improve your example from an average of 147 to 127 for me (plain preview.4 gives around 140)

My best guess is that the performance change comes from PGO based aggressive inlining in which case the standard division can get replaced with mul and shift, but the instrinct will not.

[tannergooding]

Rerunning CI. Going to finish reviewing this today after CI finishes

[Daniel-Svensson]

@tannergooding I have updated the suppressions for this PR and the decimal PR to handle the introduction of ExperimentalAttribute, so it compiles again.

[tannergooding]

This looks good. But could you give some updated perf numbers prior to this getting merged?