Optimize MultiplyMod: reuse div remainder in Knuth reduction (-27% to -37%)

[benaadams]

Summary

Optimises MultiplyMod end to end: tighter JIT output for the Knuth reductions, a cheaper 256x256->512 multiply, and an algebraic shortcut that removes one 64x64 product per quotient digit along with the per-digit call.

Key change: reuse the div remainder

X86Base.X64.DivRem returns the remainder anyway, and the Knuth correction loop maintains the exact identity rhat == (u_top:u_next) - qhat*d_top (each qhat-- adds d_top back into rhat). The top-limb product in the mul-subtract is therefore redundant: the new top limb is just rhat - borrow, and overshoot detection is borrow > rhat. With one fewer mulx chain, the div + correction now inline into the reduction loops without register-pressure spills, removing the per-digit call and its stack-arg stores; the window's top-limb store also turns out to be dead (never read by later iterations or denormalisation). Rare cases (saturated digit, rhat overflow during correction) fall back to the previous EstimateQhat + full mul-subtract path. Applied to Remainder512By256Bits, Remainder512By192Bits, and KnuthStep.

Entry dispatch is also restructured: the modulus size is classified first with scalar tests (a modulus >= 2^128 cannot be 0 or 1, so the wide path skips the throw/one gates), 64-bit moduli route straight to MulModBy64Bits, and the product's high half is tested with a scalar or-chain - a vector IsZero load there spans the four scalar stores just written by the multiply and defeats store-forwarding.

Benchmarks vs main

Random full-width operands; medians of 3 alternating A/B rounds, each best-of-12 in-process rounds of 2M ops; x64 (Zen4-class), .NET 10:

benchmark	main	branch	delta
MulMod, 256-bit modulus (msb set)	72.6 ns	53.3 ns	-27%
MulMod, 256-bit modulus (random top limb)	85.5 ns	56.9 ns	-33%
MulMod, 192-bit modulus	84.4 ns	58.3 ns	-31%
MulMod, 128-bit modulus	95.4 ns	60.3 ns	-37%
MulMod, 64-bit modulus	~25 ns	~25 ns	neutral
MulMod latency (chained results), 256-bit modulus	94.3 ns	76.3 ns	-19%
ExpMod, 256-bit modulus, random 256-bit exponent	36.7 us	23.6 us	-36%

The shorter-modulus paths gain the most because their cost is quotient-digit-bound (a 512-bit product over a 128-bit modulus needs 7 serial quotient digits vs 5 for a 256-bit modulus), and the per-digit saving applies to every digit.

Verification

• 20 million randomized MulMod cases (edge-limb biased: 0, 1, 2^63, 2^64-1, etc.; modulus widths rotating 64/128/192/256-bit) cross-checked against BigInteger: 0 failures.
• Latency-chain outputs are bit-identical between main and branch (matching xor sinks over 2M chained operations).
• FullyQualifiedName~MultiplyMod unit suite run against the branch head.

[Copilot]

Pull request overview

This PR optimizes UInt256.MultiplyMod and its underlying Knuth-style remainder reductions to reduce instruction count and register pressure in the hot modular-multiplication path, improving throughput for 128/192/256-bit moduli.

Changes:

• Restructures MultiplyMod dispatch to classify modulus size with scalar limb tests, route 64-bit moduli directly, and avoid a post-multiply vector IsZero check on the high half.
• Reworks Knuth reduction steps for 192-bit and 256-bit moduli to reuse DivRem’s remainder (rhat) to eliminate redundant top-limb products and dead stores in the sliding window.
• Updates Multiply64’s BMI2 path to compute low via a * b and high via Bmi2.X64.MultiplyNoFlags(a, b) to help the JIT keep results in registers.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/Nethermind.Int256/UInt256.DivideMod.cs	Reworks MultiplyMod dispatch and remainder-by-192/256 routines, plus Knuth step logic to reuse DivRem remainder and reduce mul-sub work.
src/Nethermind.Int256/UInt256.cs	Adjusts Multiply64 BMI2 implementation to favor register allocation and reduce spills.