feat: simple sparse commitment

[ledwards2225]

Add method for more efficiently committing to sparse polynomials.

For polynomials with very few non-zero coefficients, it turns out to be more efficient to first reduce the set of {scalars, points} defining the MSM to only those for which scalar != 0, then perform the MSM. This is implemented in a new method commit_sparse in the CommitmentKey.

This PR also introduces (1) A more comprehensive set of pippenger benchmarks, (2) Tracking of commit times in the ClientIvc benchmark scripts, and (3) a test suite for the commit_sparse functionality.

Here are some benchmarks for committing to a polynomials of varying sizes, each with only 5 random nonzero entries. The first uses commit() and the second uses the new commit_sparse() method:

---------------------------------------------------------------------------------------------------
Benchmark                                                         Time             CPU   Iterations
---------------------------------------------------------------------------------------------------
bench_commit_sparse_random<curve::BN254>/14                    5.79 ms        0.371 ms         1000
bench_commit_sparse_random<curve::BN254>/15                    10.6 ms        0.508 ms         1000
bench_commit_sparse_random<curve::BN254>/16                    12.1 ms         1.86 ms          253
bench_commit_sparse_random<curve::BN254>/17                    14.0 ms         1.71 ms          412
bench_commit_sparse_random<curve::BN254>/18                    73.1 ms         2.75 ms          100

bench_commit_sparse_random_preprocessed<curve::BN254>/14      0.132 ms        0.076 ms         9216
bench_commit_sparse_random_preprocessed<curve::BN254>/15      0.134 ms        0.077 ms         9114
bench_commit_sparse_random_preprocessed<curve::BN254>/16      0.138 ms        0.079 ms         8856
bench_commit_sparse_random_preprocessed<curve::BN254>/17      0.150 ms        0.082 ms         8579
bench_commit_sparse_random_preprocessed<curve::BN254>/18      0.177 ms        0.108 ms         6396

Below are the relevant highlights from ClientIvc bench (master vs branch). Note the reductions in commitment time from databus (bus columns plus counts/tags), ecc_op_wires, and databus_inverses. Also, note that the time spent on these commitments between the unstructured and structured cases is now almost identical, suggesting that the required zero checking is essentially free.

Master - Unstructured:

ClientIVCBench/Full/6      14277 ms        10173 ms

commit(t)                               3613   25.60%

COMMIT::wires(t)                  850    35.80%
COMMIT::z_perm(t)                 449    18.92%
COMMIT::databus(t)                262    11.04%
COMMIT::ecc_op_wires(t)           278    11.71%
COMMIT::lookup_inverses(t)        189     7.98%
COMMIT::databus_inverses(t)       250    10.54%
COMMIT::lookup_counts_tags(t)      95     4.01%

Branch - Unstructured:

ClientIVCBench/Full/6      13530 ms        10167 ms

commit(t)                               2833   21.20%

COMMIT::wires(t)                  849    51.63%
COMMIT::z_perm(t)                 447    27.15%
COMMIT::databus(t)                 10     0.63%
COMMIT::ecc_op_wires(t)            49     2.97%
COMMIT::lookup_inverses(t)        190    11.56%
COMMIT::databus_inverses(t)         4     0.24%
COMMIT::lookup_counts_tags(t)      96     5.82%

Master - STRUCTURED

ClientIVCBench/FullStructured/6      20935 ms        14669 ms            

commit(t)                               7091   34.14%

COMMIT::wires(t)                 1471    25.74%
COMMIT::z_perm(t)                1028    17.98%
COMMIT::databus(t)                509     8.90%
COMMIT::ecc_op_wires(t)           929    16.26%
COMMIT::lookup_inverses(t)        356     6.23%
COMMIT::databus_inverses(t)      1243    21.75%
COMMIT::lookup_counts_tags(t)     179     3.13%

Branch - STRUCTURED

ClientIVCBench/FullStructured/6      18316 ms        13782 ms 

commit(t)                               4398   24.23%

COMMIT::wires(t)                 1468    47.53%
COMMIT::z_perm(t)                1020    33.04%
COMMIT::databus(t)                 13     0.44%
COMMIT::ecc_op_wires(t)            52     1.68%
COMMIT::lookup_inverses(t)        350    11.32%
COMMIT::databus_inverses(t)         5     0.17%
COMMIT::lookup_counts_tags(t)     180     5.82%

[AztecBot]

⚠️ Performance Alert ⚠️

Possible performance regression was detected for benchmark 'C++ Benchmark'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.05.

Benchmark suite	Current: 0696f08	Previous: df99d1d	Ratio
Goblin::merge(t)	219939336 ns/iter	198797375 ns/iter	1.11

This comment was automatically generated by workflow using github-action-benchmark.

CC: @ludamad @codygunton

[ledwards2225]

This was logic previously used only to process bench data for the Relations but I wanted to reuse it for commitments so I just made it a method

[ledwards2225]

This suite was previously just benchmarking committing to zero polynomials of various sizes. I'm assuming it was just a WiP and never used but who knows. I've updated it to include a number of different scenarios, including committing various types of sparse polynomials with the traditional commit() and the new commit_sparse()

[ledwards2225]

@codygunton Here's more data exploring some of the wonky numbers seen in the pippenger benchmarks. These are for "sparse" random polys with respectively 5, 200, 2^10 and 2^15 non-zero entries, using commit vs commit_sparse. The pattern is more in line with expectation for the denser cases, but it's a bit baffling why things are worse for very sparse polys. The 2^15 case gives a sense of how sparse the polys need to be for commit_sparse to be beneficial.

---------------------------------------------------------------------------------------------------
Benchmark                                                         Time             CPU   Iterations
---------------------------------------------------------------------------------------------------
bench_commit_sparse_random<curve::BN254>/16                    12.5 ms         1.10 ms          521
bench_commit_sparse_random<curve::BN254>/17                    14.7 ms         2.71 ms          233
bench_commit_sparse_random<curve::BN254>/18                    74.2 ms         2.92 ms          100
bench_commit_sparse_random<curve::BN254>/19                    80.8 ms         6.24 ms          122
bench_commit_sparse_random<curve::BN254>/20                    98.1 ms         12.3 ms           62

bench_commit_sparse_random_preprocessed<curve::BN254>/16      0.137 ms        0.078 ms         8963
bench_commit_sparse_random_preprocessed<curve::BN254>/17      0.151 ms        0.081 ms         8593
bench_commit_sparse_random_preprocessed<curve::BN254>/18      0.177 ms        0.107 ms         6529
bench_commit_sparse_random_preprocessed<curve::BN254>/19      0.216 ms        0.148 ms         4744
bench_commit_sparse_random_preprocessed<curve::BN254>/20      0.314 ms        0.253 ms         2790

---------------------------------------------------------------------------------------------------
Benchmark                                                         Time             CPU   Iterations
---------------------------------------------------------------------------------------------------
bench_commit_sparse_random<curve::BN254>/16                    4.26 ms         2.43 ms          276
bench_commit_sparse_random<curve::BN254>/17                    6.10 ms         3.23 ms          220
bench_commit_sparse_random<curve::BN254>/18                    18.0 ms         10.9 ms           59
bench_commit_sparse_random<curve::BN254>/19                    26.4 ms         14.1 ms           49
bench_commit_sparse_random<curve::BN254>/20                    42.0 ms         19.5 ms           36

bench_commit_sparse_random_preprocessed<curve::BN254>/16       1.85 ms         1.67 ms          420
bench_commit_sparse_random_preprocessed<curve::BN254>/17       1.83 ms         1.69 ms          420
bench_commit_sparse_random_preprocessed<curve::BN254>/18       1.83 ms         1.72 ms          414
bench_commit_sparse_random_preprocessed<curve::BN254>/19       1.94 ms         1.78 ms          405
bench_commit_sparse_random_preprocessed<curve::BN254>/20       2.02 ms         1.87 ms          389

---------------------------------------------------------------------------------------------------
Benchmark                                                         Time             CPU   Iterations
---------------------------------------------------------------------------------------------------
bench_commit_sparse_random<curve::BN254>/16                    4.54 ms         3.22 ms          221
bench_commit_sparse_random<curve::BN254>/17                    6.49 ms         3.96 ms          177
bench_commit_sparse_random<curve::BN254>/18                    18.6 ms         12.5 ms           57
bench_commit_sparse_random<curve::BN254>/19                    26.7 ms         15.3 ms           46
bench_commit_sparse_random<curve::BN254>/20                    41.6 ms         21.1 ms           33

bench_commit_sparse_random_preprocessed<curve::BN254>/16       4.79 ms         4.57 ms          152
bench_commit_sparse_random_preprocessed<curve::BN254>/17       4.87 ms         4.66 ms          151
bench_commit_sparse_random_preprocessed<curve::BN254>/18       4.91 ms         4.66 ms          151
bench_commit_sparse_random_preprocessed<curve::BN254>/19       4.93 ms         4.70 ms          150
bench_commit_sparse_random_preprocessed<curve::BN254>/20       5.10 ms         4.83 ms          146

---------------------------------------------------------------------------------------------------
Benchmark                                                         Time             CPU   Iterations
---------------------------------------------------------------------------------------------------
bench_commit_sparse_random<curve::BN254>/16                    13.7 ms         12.2 ms           58
bench_commit_sparse_random<curve::BN254>/17                    16.8 ms         14.1 ms           49
bench_commit_sparse_random<curve::BN254>/18                    30.8 ms         25.2 ms           28
bench_commit_sparse_random<curve::BN254>/19                    38.9 ms         28.4 ms           25
bench_commit_sparse_random<curve::BN254>/20                    54.7 ms         34.3 ms           21

bench_commit_sparse_random_preprocessed<curve::BN254>/16       18.7 ms         17.9 ms           38
bench_commit_sparse_random_preprocessed<curve::BN254>/17       20.5 ms         19.7 ms           35
bench_commit_sparse_random_preprocessed<curve::BN254>/18       23.2 ms         22.3 ms           33
bench_commit_sparse_random_preprocessed<curve::BN254>/19       24.2 ms         23.2 ms           30
bench_commit_sparse_random_preprocessed<curve::BN254>/20       25.6 ms         24.6 ms           27

[fcarreiro]

IIUC these shouldn't (aren't) the number of threads, just the number of things you need to iterate. If you look closely at the current implementation of parallel_for, the number of threads are not sth the caller can choose, you can only choose the number of elements to iterate (which is right):

aztec-packages/barretenberg/cpp/src/barretenberg/common/parallel_for_mutex_pool.cpp

Line 124 in 6035595

void parallel_for_mutex_pool(size_t num_iterations, const std::function<void(size_t)>& func)

[ledwards2225]

I guess I'm a little unclear what your suggestion is here. Is your objection about the name num_threads? I guess I'm thinking of it as shorthand for "num threads over which to distribute the work", which is how this value is used if I'm not mistaken. Admittedly though I am being a bit sloppy here in that I don't really need a power-of-2 thread count and my condition for when not to multithread is a bit arbitrary. In practice though the only context that matters is degree ~2^18 and higher so not so important to get the small values right

[fcarreiro]

What I mean is that the value passed to parallel_for is in principle not the number of threads. If you have 16 cores and do parallel_for(200, some_f) then it will be chunked in 200/16 chunks over 16 threads, and f will be called from 0 to 199.

Maybe the way you set it up does make it coincide with the number of threads though. @ludamad would be the best to ask. I'm commenting because I had to use parallel_for recently and noticed this subtlety.

[ledwards2225]

ah I see what you mean. In my case the "num_iterations" input will always be <= actual num threads but your point stands. I don't really love that - seems like the parallel_for interface should allow you to specify how it should multithread.

[fcarreiro]

My above comment also means that you might get fewer real threads than the number of elements. IIUC, this means that your division of vectors here is still thread-safe, but less efficient than you might think (i.e., not one "bucket" per thread).

[fcarreiro]

This will surely help the AVM! (we currently have around 5% non-zero elements)

Maybe a dumb question: I was expecting Pippenger to already "get rid of" the zero scalars after bucketing all the scalars. Why does this preprocessing work better?

[ledwards2225]

This will surely help the AVM! (we currently have around 5% non-zero elements)

Maybe a dumb question: I was expecting Pippenger to already "get rid of" the zero scalars after bucketing all the scalars. Why does this preprocessing work better?

Not a dumb question - the truth is I have not had time to properly dig into our Pippenger implementation and understand whether there is something more natural (and possible more effective) that can be done to the same effect in the core algorithm. This PR represents a very quick and dirty optimization added while I was doing analysis for a somewhat more complex optimization (note the name of this branch is analyze_commitments :)). I was somewhat surprised by its effectiveness as well. I can say two things about the original Pippenger implementation though: (1) committing to zeros or small values is much cheaper than committing to large values, i.e. we are doing less work when you'd expect we would, and (2) the algorithm was likely not at all optimized for this sparse case since it was originally used in Plonk where essentially all of the polynomials are completely dense.

At some point I'd like to understand exactly what's causing performance to be sub-par for these sparse cases and whether there's something more sophisticated and/or effective to be done, but unfortunately I haven't been able to squeeze that into the list of priorities as of yet.

[codygunton]

Looks good for something quick and dirty. FYI I ran the bench breakdown before and after and saw it looks to be producing the same analysis.

[codygunton]

NB the weird asymptotics including a sudden huge jump.

[codygunton]

This is weird for small degree but we don't care in practice?

[codygunton]

FWIW we prob do care about 2^24 since that's the ClientIVC recursive verifier size right now.

[ledwards2225]

yeah easy enough to change for an interested party but I was running these a lot and anything larger was taking too long

[codygunton]

Maybe a follow-on question: if these are at random locations, do we have the same performance?

[ledwards2225]

For the random sparse polys (i.e. the ones for which I was showing bench results) the locations are randomized, but I did not see a difference before and after randomizing the locations.

[codygunton]

Probably worth reserving some space in these just in case / since it's easy.

[ledwards2225]

added