Adapt barycentric weights to the lifted protocol.

[leo-starkware]

No description provided.

[reviewable-StarkWare]

This change is 

[leo-starkware]

• Rename max_log_size to lifting_log_size. #1289
• Adapt barycentric weights to the lifted protocol. #1288 👈 (View in Graphite)
• Fix non-parallel bugs. #1287
• lifted

This stack of pull requests is managed by Graphite. Learn more about stacking.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.97%. Comparing base (47186dd) to head (5221f96).

Additional details and impacted files

@@                 Coverage Diff                  @@
##           leo/fix_nonparallel    #1288   +/-   ##
====================================================
  Coverage                91.97%   91.97%           
====================================================
  Files                      119      119           
  Lines                    14958    14966    +8     
  Branches                 14958    14966    +8     
====================================================
+ Hits                     13757    13765    +8     
  Misses                    1111     1111           
  Partials                    90       90           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Gali-StarkWare]

@Gali-StarkWare reviewed 2 files and all commit messages, and made 2 comments.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @leo-starkware).

---

crates/stwo/src/prover/pcs/mod.rs line 128 at r1 (raw file):

                // TODO(Leo): the computation `point.repeated_double(max_log_size - log_size)` is
                // likely repeated a bunch of times in a typical flat air. Consider moving it
                // outside the loop.

I guess it doesn't matter in the parallel case, right?

Code quote:

                // TODO(Leo): the computation `point.repeated_double(max_log_size - log_size)` is
                // likely repeated a bunch of times in a typical flat air. Consider moving it
                // outside the loop.

---

crates/stwo/src/prover/pcs/quotient_ops.rs line 221 at r1 (raw file):

    }

    fn prove_and_verify_pcs<B: BackendForChannel<Blake2sMerkleChannel>, const STORE_COEFF: bool>(

Suggestion:

STORE_COEFFS

[leo-starkware]

@leo-starkware made 2 comments.
Reviewable status: 1 of 2 files reviewed, 1 unresolved discussion (waiting on @Gali-StarkWare).

---

crates/stwo/src/prover/pcs/mod.rs line 128 at r1 (raw file):

Previously, Gali-StarkWare wrote…

I guess it doesn't matter in the parallel case, right?

it also matters in parallel, in the sense that some threads could save this computation. But to do it one would need a map that is shareable among threads, not sure if worth the effort.

---

crates/stwo/src/prover/pcs/quotient_ops.rs line 221 at r1 (raw file):

    }

    fn prove_and_verify_pcs<B: BackendForChannel<Blake2sMerkleChannel>, const STORE_COEFF: bool>(

done

[Gali-StarkWare]

@Gali-StarkWare reviewed 1 file and all commit messages, made 1 comment, and resolved 1 discussion.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @leo-starkware).

---

crates/stwo/src/prover/pcs/mod.rs line 128 at r1 (raw file):

Previously, leo-starkware wrote…

it also matters in parallel, in the sense that some threads could save this computation. But to do it one would need a map that is shareable among threads, not sure if worth the effort.

Yes, but the total time would not change even if we had another dashmap..
The non-parallel case is much less efficient, but I'm not sure we care about it (@gilbens-starkware wdyt?)

[Gali-StarkWare]

@Gali-StarkWare made 1 comment.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @leo-starkware).