-
Notifications
You must be signed in to change notification settings - Fork 156
CPU Barycentric Evaluation and Test #1068
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
4283016
to
61d1f6b
Compare
8a83a9f
to
92a5086
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 1 of 2 files at r1, all commit messages.
Reviewable status: 1 of 2 files reviewed, 3 unresolved discussions (waiting on @Alon-Ti)
crates/prover/src/core/constraints.rs
line 37 at r1 (raw file):
} pub fn coset_vanishing_derivative<F: ExtensionOf<BaseField>>(coset: Coset, p: CirclePoint<F>) -> F {
Which points are zeros for this function?
Why do we have exp = 4**(log_size - 1)?
document
Code quote:
pub fn coset_vanishing_derivative<F: ExtensionOf<BaseField>>(coset: Coset, p: CirclePoint<F>) -> F {
crates/prover/src/core/poly/circle/evaluation.rs
line 165 at r1 (raw file):
// TODO(Gali): Remove. #[allow(dead_code)] fn weights(log_size: u32, sample_point: CirclePoint<SecureField>) -> Col<CpuBackend, SecureField> {
Is this going to be removed?
Or do we want to keep trivial weight calculation?
Code quote:
#[allow(dead_code)]
fn weights(log_size: u32, sample_point: CirclePoint<SecureField>) -> Col<CpuBackend, SecureField> {
crates/prover/src/core/poly/circle/evaluation.rs
line 303 at r1 (raw file):
.to_vec(), ); let s = CanonicCoset::new(3);
Can we evaluate on a larger CanonicCoset here?
Code quote:
let s = CanonicCoset::new(3);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: 1 of 2 files reviewed, 3 unresolved discussions (waiting on @Alon-Ti and @Gali-StarkWare)
crates/prover/src/core/poly/circle/evaluation.rs
line 165 at r1 (raw file):
Previously, shaharsamocha7 wrote…
Is this going to be removed?
Or do we want to keep trivial weight calculation?
also we would probably need the talk to understand this code
92a5086
to
8abe2fe
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## gali/barycentric #1068 +/- ##
====================================================
+ Coverage 92.64% 92.68% +0.04%
====================================================
Files 106 106
Lines 14273 14374 +101
Branches 14273 14374 +101
====================================================
+ Hits 13223 13323 +100
- Misses 969 970 +1
Partials 81 81 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
⚠️ Performance Alert ⚠️
Possible performance regression was detected for benchmark.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 2
.
Benchmark suite | Current: 34fce22 | Previous: dbfd84c | Ratio |
---|---|---|---|
iffts/simd ifft/26 |
267972097 ns/iter (± 2556591 ) |
127397717 ns/iter (± 2072975 ) |
2.10 |
iffts/simd ifft/27 |
621739418 ns/iter (± 8616375 ) |
259960823 ns/iter (± 9389998 ) |
2.39 |
iffts/simd ifft/28 |
1251160891 ns/iter (± 12913172 ) |
562251429 ns/iter (± 4959325 ) |
2.23 |
merkle throughput/simd merkle |
29257607 ns/iter (± 548243 ) |
13349252 ns/iter (± 275840 ) |
2.19 |
This comment was automatically generated by workflow using github-action-benchmark.
CC: @shaharsamocha7
8abe2fe
to
bb9e718
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: 0 of 2 files reviewed, 3 unresolved discussions (waiting on @Alon-Ti, @Gali-StarkWare, and @shaharsamocha7)
crates/prover/src/core/constraints.rs
line 37 at r1 (raw file):
Previously, shaharsamocha7 wrote…
Which points are zeros for this function?
Why do we have exp = 4**(log_size - 1)?
document
Done.
crates/prover/src/core/poly/circle/evaluation.rs
line 165 at r1 (raw file):
Previously, shaharsamocha7 wrote…
also we would probably need the talk to understand this code
I am in favor of keeping the cpu weight calculation, like you have the cpu version of eval_at_point
crates/prover/src/core/poly/circle/evaluation.rs
line 303 at r1 (raw file):
Previously, shaharsamocha7 wrote…
Can we evaluate on a larger CanonicCoset here?
Will do
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed all commit messages.
Reviewable status: 0 of 2 files reviewed, 1 unresolved discussion (waiting on @Alon-Ti and @Gali-StarkWare)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: 0 of 2 files reviewed, 5 unresolved discussions (waiting on @Alon-Ti and @Gali-StarkWare)
crates/prover/src/core/poly/circle/evaluation.rs
line 165 at r1 (raw file):
Previously, Gali-StarkWare wrote…
I am in favor of keeping the cpu weight calculation, like you have the cpu version of eval_at_point
so you we have a TODO to remove it?
crates/prover/src/core/constraints.rs
line 37 at r3 (raw file):
} /// Evaluates the formal derivative of a vanishing polynomial of the coset at a point.
Consider to change
Suggestion:
/// Evaluates the formal derivative of a vanishing polynomial of the coset at a point `p`.
crates/prover/src/core/constraints.rs
line 42 at r3 (raw file):
// of all cosets of smallet size than the given coset at the given point by 4^(log_size-1), // where log_size is the log size of the coset. This is because of the chain rule (also see // remark 15 in circle stark article).
you can also add a link to the circle stark paper
Suggestion:
// The formal derivative is computed by multiplying the product of the vanishing polynomials of
// of all cosets of smallet size than the given coset at the given point by 4^(log_size-1).
// See Remark 15 in circle stark paper).
crates/prover/src/core/constraints.rs
line 44 at r3 (raw file):
// remark 15 in circle stark article). let field_four = F::one() + F::one() + F::one() + F::one();
NIT use from_u32_unchecked
Code quote:
F::one() + F::one() + F::one() + F::one()
crates/prover/src/core/poly/circle/evaluation.rs
line 168 at r3 (raw file):
/// point p and domain size. The domain is the circle domain corresponding to the canonic coset of /// the size provided. fn weights(log_size: u32, sample_point: CirclePoint<SecureField>) -> Col<CpuBackend, SecureField> {
Why not get the coset directly?
Also rename function and change doc accordingly
Suggestion:
/// Computes the weights for Barycentric Lagrange interpolation for point `p` on `coset`.
fn barycentric_weights(coset: CanonicCoset, sample_point: CirclePoint<SecureField>) -> Col<CpuBackend, SecureField> {
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: 0 of 2 files reviewed, 6 unresolved discussions (waiting on @Alon-Ti and @Gali-StarkWare)
crates/prover/src/core/poly/circle/evaluation.rs
line 168 at r3 (raw file):
/// point p and domain size. The domain is the circle domain corresponding to the canonic coset of /// the size provided. fn weights(log_size: u32, sample_point: CirclePoint<SecureField>) -> Col<CpuBackend, SecureField> {
Can we write here the simplest way to evaluate the barycentric_weights?
Code quote:
fn weights(log_size: u32, sample_point: CirclePoint<SecureField>) -> Col<CpuBackend, SecureField> {
bb9e718
to
3f47b68
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: 0 of 2 files reviewed, 4 unresolved discussions (waiting on @Alon-Ti and @shaharsamocha7)
crates/prover/src/core/constraints.rs
line 42 at r3 (raw file):
Previously, shaharsamocha7 wrote…
you can also add a link to the circle stark paper
Done.
crates/prover/src/core/poly/circle/evaluation.rs
line 165 at r1 (raw file):
Previously, shaharsamocha7 wrote…
so you we have a TODO to remove it?
It's for the allow dead code
crates/prover/src/core/poly/circle/evaluation.rs
line 303 at r1 (raw file):
Previously, Gali-StarkWare wrote…
Will do
Done.
crates/prover/src/core/poly/circle/evaluation.rs
line 168 at r3 (raw file):
Previously, shaharsamocha7 wrote…
Why not get the coset directly?
Also rename function and change doc accordingly
I need to order them according to the bit reverse order of the circle domain order, which is different than the canonic coset order. We could either
- Get the log size and compute the circle domain of the relevant canonic coset
- Get the canonic coset and then convert it to a circle domain
- Get a circle domain
wdyt?
crates/prover/src/core/poly/circle/evaluation.rs
line 168 at r3 (raw file):
Previously, shaharsamocha7 wrote…
Can we write here the simplest way to evaluate the barycentric_weights?
Done.
3f47b68
to
8dd5b33
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 1 of 2 files at r4, all commit messages.
Reviewable status: 1 of 2 files reviewed, 1 unresolved discussion (waiting on @Alon-Ti and @Gali-StarkWare)
crates/prover/src/core/poly/circle/evaluation.rs
line 168 at r3 (raw file):
Previously, Gali-StarkWare wrote…
I need to order them according to the bit reverse order of the circle domain order, which is different than the canonic coset order. We could either
- Get the log size and compute the circle domain of the relevant canonic coset
- Get the canonic coset and then convert it to a circle domain
- Get a circle domain
wdyt?
I think getting CanonicCoset and use to_circle_domain explains it best, wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: 1 of 2 files reviewed, 4 unresolved discussions (waiting on @Alon-Ti and @Gali-StarkWare)
crates/prover/src/core/poly/circle/evaluation.rs
line 198 at r5 (raw file):
return weights; } }
Why do we need this? Let's make this function assert/assume that p is not in the domain
If it was, we could just return the evaluation and no need for weights, is that right?
Code quote:
// If p is in the domain at position i, then w_j = δ_ij
for i in 0..domain.size() {
if domain.at(i).into_ef() == sample_point {
let mut weights = vec![SecureField::zero(); domain.size()];
weights[i] = SecureField::one();
return weights;
}
}
crates/prover/src/core/poly/circle/evaluation.rs
line 249 at r5 (raw file):
) -> SecureField { // Evaluation = Σ W_i * Poly(i) for all i in the evaluation domain. // For more information on barycentric weights calculation see [`weights`]
rename
Suggestion:
[`barycentric_weights`]
crates/prover/src/core/poly/circle/evaluation.rs
line 254 at r5 (raw file):
return evals.values[bit_reverse_index(i, evals.domain.log_size())].into(); } }
I think this should be removed, but please comment or assert that p is not in domain
Code quote:
for i in 0..evals.domain.size() {
if point == evals.domain.at(i).into_ef() {
return evals.values[bit_reverse_index(i, evals.domain.log_size())].into();
}
}
8dd5b33
to
dbfd84c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: 1 of 2 files reviewed, 3 unresolved discussions (waiting on @Alon-Ti and @shaharsamocha7)
crates/prover/src/core/poly/circle/evaluation.rs
line 198 at r5 (raw file):
Previously, shaharsamocha7 wrote…
Why do we need this? Let's make this function assert/assume that p is not in the domain
If it was, we could just return the evaluation and no need for weights, is that right?
Done.
crates/prover/src/core/poly/circle/evaluation.rs
line 249 at r5 (raw file):
Previously, shaharsamocha7 wrote…
rename
Done.
crates/prover/src/core/poly/circle/evaluation.rs
line 254 at r5 (raw file):
Previously, shaharsamocha7 wrote…
I think this should be removed, but please comment or assert that p is not in domain
Done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 1 of 1 files at r6, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @Alon-Ti)
crates/prover/src/core/poly/circle/evaluation.rs
line 192 at r6 (raw file):
let domain = coset.circle_domain(); let (s_i_i, v_i_p): (Vec<_>, Vec<_>) = (0..domain.size())
I think it is clearer
Suggestion:
let (si_i, vi_p): (Vec<_>, Vec<_>) = (0..domain.size())
crates/prover/src/core/poly/circle/evaluation.rs
line 195 at r6 (raw file):
.map(|i| { let point_i = domain.at(i).into_ef::<SecureField>(); let minus_two_times_point_i_y = point_i.y * SecureField::from(-2);
not sure about domain_point/coset_point, wdyt?
I'm also ok with just point
Suggestion:
let domain_point = domain.at(i).into_ef::<SecureField>();
let minus_two_point_y = point_i.y * SecureField::from(-2);
dbfd84c
to
09362b6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @Alon-Ti and @shaharsamocha7)
crates/prover/src/core/poly/circle/evaluation.rs
line 192 at r6 (raw file):
Previously, shaharsamocha7 wrote…
I think it is clearer
Done also for vn_p
crates/prover/src/core/poly/circle/evaluation.rs
line 195 at r6 (raw file):
Previously, shaharsamocha7 wrote…
not sure about domain_point/coset_point, wdyt?
I'm also ok with just point
Went with coset point
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 1 of 1 files at r7, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @Alon-Ti)
crates/prover/src/core/poly/circle/evaluation.rs
line 188 at r7 (raw file):
// [`coset_vanishing_derivative`]. // TODO(Gali): Change weights order to bit-reverse order.
this todo is not in place (can fix in another pr)
Code quote:
// TODO(Gali): Change weights order to bit-reverse order.
crates/prover/src/core/poly/circle/evaluation.rs
line 303 at r7 (raw file):
.iter() .map(|point| poly.eval_at_point(*point)) .collect::<Vec<_>>();
unblocking
Suggestion:
.collect_vec();
09362b6
to
34fce22
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 1 of 1 files at r8, all commit messages.
Reviewable status:complete! all files reviewed, all discussions resolved (waiting on @Alon-Ti)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed all commit messages.
Reviewable status:complete! all files reviewed, all discussions resolved (waiting on @Alon-Ti)
No description provided.