chore: bench phase breakdown + thread sweep for MSM reduction

[peter941221]

Context

This PR addresses AztecProtocol/barretenberg#1656 by making the MSM::batch_multi_scalar_mul(...) phase breakdown measurable and by adding a benchmark case that targets the exact regime called out in the issue (2^16 points with 256 threads).

The goal is to answer: is the single-threaded final reduction (accumulate_results) actually a bottleneck relative to the full MSM?

What Changed

1) Phase Breakdown (BB_BENCH) inside batch_multi_scalar_mul

Added BB_BENCH scopes for:

• MSM::batch_multi_scalar_mul/evaluate_work_units
• MSM::batch_multi_scalar_mul/accumulate_results
• MSM::batch_multi_scalar_mul/batch_normalize
• MSM::batch_multi_scalar_mul/scalars_to_montgomery

These are surfaced in google-benchmark output via GOOGLE_BB_BENCH_REPORTER(state).

2) New Benchmark Case: BatchMSM_1656

Added a dedicated benchmark:

• PippengerBench/BatchMSM_1656/256/{msm_size}
• Single MSM (num_polys = 1)
• Sizes:
  • msm_size ∈ {2^16, 2^20}

This uses bb::set_parallel_for_concurrency(256) to force the intended partitioning and restores the original value after the benchmark finishes.

Results (Local)

Machine: 4 vCPU laptop (so 256 threads is intentionally oversubscribed; the key point is the absolute reduction overhead).

Key takeaways (from BB_BENCH counters; time counters are nanoseconds):

• 2^16, 256 threads:
  • accumulate_results ≈ 139k ns (~0.139 ms)
  • total ≈ 521 ms
  • reduction fraction ~0.027%
• 2^20, 256 threads:
  • accumulate_results ≈ 141k ns (~0.141 ms)
  • total ≈ 3457 ms
  • reduction fraction ~0.004%

So the final reduction appears negligible in these regimes on my setup, and the benchmark now makes it easy to validate on a 64+ core machine where the original concern is most relevant.

Notes / Background

• MSM here is a Pippenger-style MSM. For background reading on multiexponentiation / multi-product methods:
  • Nicholas Pippenger, On the evaluation of powers and related problems (1976).
  • Jurjen Bos and Matthijs Coster, Addition Chain Heuristics (CRYPTO 1989).
  • Ryan Henry, Pippenger's Multiproduct and Multiexponentiation Algorithms (2010).

How To Run

cmake --build <build-dir> --target pippenger_bench
CRS_PATH=<path-to-bn254_g1.dat> <build-dir>/bin/pippenger_bench \
  --benchmark_filter='BatchMSM_1656' \
  --benchmark_min_time=0.1s \
  --benchmark_counters_tabular=true

Fixes AztecProtocol/barretenberg#1656

[peter941221]

CI3 (External) is currently blocked because this is an external PR from a fork: the workflow says external PRs need the ci-external or ci-external-once label to run.

Would someone with label permission mind adding one of those labels so CI can execute? (This PR only touches the MSM benchmark + BB_BENCH instrumentation; no CI/workflow files.)

[peter941221]

Follow-up: I narrowed the BatchMSM_1656 registration to target only the original issue scenario (threads=256, msm_size ∈ {2^16, 2^20}), so the benchmark name is now:

• PippengerBench/BatchMSM_1656/256/{msm_size}

Latest local run (4 vCPU laptop; BB_BENCH time counters are ns):

• 2^16: accumulate_results ≈ 139k ns (~0.139 ms) vs total ≈ 521 ms
• 2^20: accumulate_results ≈ 141k ns (~0.141 ms) vs total ≈ 3457 ms

[AztecBot]

This issue was automatically closed because it was referenced in PR #21965 which has been merged to the default branch.

View workflow run