plonky2/system_zero/benches/lookup_permuted_cols.rs
Daniel Lubarov 7d6c0a448d
Halo2 style lookup arguments in System Zero (#513)
* Halo2 style lookup arguments in System Zero

It's a really nice and simple protocol, particularly for the verifier since the constraints are trivial (aside from the underlying batched permutation checks, which we already support). See the [Halo2 book](https://zcash.github.io/halo2/design/proving-system/lookup.html) and this [talk](https://www.youtube.com/watch?v=YlTt12s7vGE&t=5237s) by @daira.

Previously we generated the whole trace in row-wise form, but it's much more efficient to generate these "permuted" columns column-wise. So I changed our STARK framework to accept the trace in column-wise form. STARK impls now have the flexibility to do some generation row-wise and some column-wise (without extra costs; there's a single transpose as before).

* sorting

* fixes

* PR feedback

* into_iter

* timing
2022-03-16 17:37:34 -07:00

31 lines
1.2 KiB
Rust

use criterion::{criterion_group, criterion_main, BenchmarkId, Criterion};
use itertools::Itertools;
use plonky2::field::field_types::Field;
use plonky2::field::goldilocks_field::GoldilocksField;
use rand::{thread_rng, Rng};
use system_zero::lookup::permuted_cols;
type F = GoldilocksField;
fn criterion_benchmark(c: &mut Criterion) {
let mut group = c.benchmark_group("lookup-permuted-cols");
for size_log in [16, 17, 18] {
let size = 1 << size_log;
group.bench_with_input(BenchmarkId::from_parameter(size), &size, |b, _| {
// We could benchmark a table of random values with
// let table = F::rand_vec(size);
// But in practice we currently use tables that are pre-sorted, which makes
// permuted_cols cheaper since it will sort the table.
let table = (0..size).map(F::from_canonical_usize).collect_vec();
let input = (0..size)
.map(|_| table[thread_rng().gen_range(0..size)])
.collect_vec();
b.iter(|| permuted_cols(&input, &table));
});
}
}
criterion_group!(benches, criterion_benchmark);
criterion_main!(benches);