Optimize BN254Pairing call

[benaadams]

Changes

• Remove double copy
• Use intrinsic endian swap
• Using mclBn_millerLoop inside the loop and one mclBn_finalExp at the end removes N‑1 final exponentiations, which are the expensive part. On BN254 that is a meaningful win at even modest N.

Types of changes

What types of changes does your code introduce?

• Optimization

Testing

Requires testing

• No

[LukaszRozmej]

can't mutate input

[benaadams]

can't mutate input

Fixed

[LukaszRozmej]

No idea if it works :)

[rubo]

Apart from using Miller loop/final exp combo, other changes don't bring any performance benefits according to my benchmarks, just made the code less readable:

add

| Method | Mean     | Error    | StdDev   |
|------- |---------:|---------:|---------:|
| RunOld | 848.0 ns |  3.18 ns |  2.82 ns |
| RunNew | 855.4 ns | 17.02 ns | 18.92 ns |

mul

| Method | Mean     | Error    | StdDev   |
|------- |---------:|---------:|---------:|
| RunOld | 21.24 us | 0.238 us | 0.211 us |
| RunNew | 21.93 us | 0.437 us | 0.448 us |

[benaadams]

Apart from using Miller loop/final exp combo, other changes don't bring any performance benefits according to my benchmarks, just made the code less readable:

Better?

Though it was more about BN254Pairing than Add or Mul

[Copilot]

Pull Request Overview

This PR optimizes the BN254 elliptic curve precompiles by improving memory management, implementing SIMD-accelerated byte reversal operations, and enhancing the pairing check algorithm. The changes focus on performance improvements while maintaining correctness.

Key changes:

• Replaced ArrayPool and stackalloc-based memory management with direct byte arrays to reduce allocations and copies
• Implemented hardware-accelerated byte reversal using AVX2, SSE, and Vector128 intrinsics with scalar fallback
• Optimized pairing check to use Miller loop followed by single final exponentiation instead of full pairing per pair

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
BN254PairingPrecompile.cs	Simplified memory management by removing ArrayPool usage and passing inputData.Span directly to BN254.CheckPairing
BN254MulPrecompile.cs	Added named constants for input/output lengths and simplified output allocation
BN254AddPrecompile.cs	Added named constants, implemented input padding logic to avoid unnecessary copies when input matches expected length
BN254.cs	Major refactoring: changed signatures to use ReadOnlySpan, added SIMD-optimized byte reversal methods, optimized pairing check algorithm, and improved deserialization methods to work with pointers

[rubo]

Better?

Doesn't look like they made any difference

Though it was more about BN254Pairing than Add or Mul

Well, there are lots of changes bringing no performance gain but a negligible loss (at least on my machine)?

[benaadams]

Added change to annotate some lightweight methods with SuppressGCTransition NethermindEth/mcl-bindings#8

[benaadams]

Well, there are lots of changes bringing no performance gain but a negligible loss (at least on my machine)?

Better now? Removes one stackalloc entirely as well as .ToArray and moves other stackalloc out of common path

[benaadams]

Though is more about BN254Pairing than Mul and Add

[rubo]

Overall, the situation is the following:

Pairing check:

| Method      | Mean     | Error     | StdDev    |
|------------ |---------:|----------:|----------:|
| 'Before PR' | 3.272 ms | 0.0349 ms | 0.0326 ms |
| 'After PR'  | 2.210 ms | 0.0297 ms | 0.0278 ms |

where almost all the improvement comes from the Miller loop/final exp combo:

| Method      | Mean     | Error     | StdDev    |
|------------ |---------:|----------:|----------:|
| 'Before PR' | 2.356 ms | 0.0362 ms | 0.0339 ms |
| 'After PR'  | 2.232 ms | 0.0400 ms | 0.0521 ms |

Thus, all other bells and whistles add just ~5% improvement.

For add:

| Method      | Mean     | Error   | StdDev  |
|------------ |---------:|--------:|--------:|
| 'Before PR' | 857.3 ns | 4.05 ns | 3.59 ns |
| 'After PR'  | 861.6 ns | 6.65 ns | 5.89 ns |

On each run, the changes are slower, although slightly.

The same for the mul:

| Method      | Mean     | Error    | StdDev   |
|------------ |---------:|---------:|---------:|
| 'Before PR' | 21.43 us | 0.235 us | 0.220 us |
| 'After PR'  | 22.06 us | 0.346 us | 0.324 us |

[rubo]

Though is more about BN254Pairing than Mul and Add

Then maybe better to leave them intact? They're clearly worse now.

Added change to annotate some lightweight methods with SuppressGCTransition

That's interesting, but that doesn't seem to make any difference in this particular case.

[benaadams]

Though is more about BN254Pairing than Mul and Add

Then maybe better to leave them intact? They're clearly worse now.

Are you using 96 byte inputs for Mul and 128 byte inputs for Add in the benchmarks?

[benaadams]

They're clearly worse now.

The difference for both is less than the error; the difference on Add is ~16 cpu cycles? (4.3 ns)

[Marchhill]

please verify no hive test regressions

[Marchhill]

Could these methods be moved to somewhere they can be reused, like byte array extensions or something

[benaadams]

Not sure want to encourage pointers 😅

Will move if crops up again

[benaadams]

please verify no hive test regressions

Looks ok