Jack Grigg

Now that 3.0.0 has been released, we can pick this back up. @oxarbitrage please rebase this on current master, and then I'll review.

This [previous version of the PR] causes a large regression in `orchard` circuit proving benchmarks. Below measurements are on zcash/orchard@15007026b1181b14f45c5c8cbf32e4fe86bc8d6b with a Ryzen 9 5950X. ## As-is (using `halo2_proofs` from...

See also https://github.com/zcash/zcash/issues/1614 which links to security issues and UX around this problem (which motivated fixing the confirmation level at 10 in the first place).

Interesting! I was expecting to see a performance improvement due to the `bls12_381` speedups. I tested locally (Ryzen 9 5950X), and can reproduce both the expected (though small) speedup from...

My current suspicion is that this is caused by the migration from `bitvec 0.22` to `bitvec 1`. ## Before  ## After  The small box above the highlighted `Iterator::nth`...

Confirmed: - If I revert to `bitvec 0.22` in `bellman`, I recover around a quarter of the lost performance. - If I revert to `bitvec 0.22` in `ff` as well,...

[Here in `bellman::multiexp`](https://github.com/zkcrypto/bellman/blob/2759d930622a7f18b83a905c9f054d52a0bbe748/src/multiexp.rs#L190-L223) is where we are being impacted by the performance of `bitvec`: ```rust // Sort the bases into buckets for (exp, density) in exponents.iter().zip(density_map.as_ref().iter()) { if density {...

Okay, with additional rewriting to cache the exponent chunks (so we iterate over each exponent's bits once instead of in every parallel worker) I've managed to halve the performance regression....

Opened https://github.com/zkcrypto/bellman/pull/83 with the `multiexp` refactor.

And #551 now includes the change. @joebebel could you test that PR and see what kind of improvement you get?