generalize main sumcheck as one gkr layer #964
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
hero78119
force-pushed
the
feat/unify_main_sumcheck
branch
2 times, most recently
from
b33203f to
ca8d4e1
Compare
hero78119
force-pushed
the
feat/unify_main_sumcheck
branch
2 times, most recently
from
1721f07 to
40379b3
Compare
dreamATD
force-pushed
the
feat/unify_main_sumcheck
branch
from
40379b3 to
627a3c6
Compare
dreamATD
force-pushed
the
feat/unify_main_sumcheck
branch
from
627a3c6 to
b3472db
Compare
Collaborator
|
The newest benchmark compared with the master branch:
|
Collaborator
Author
|
👍 I tried to run with latest master
Before/after result looks ok, and overall within noise threshold |
yczhangsjtu
pushed a commit
that referenced
this pull request
Jun 19, 2025
This PR build on top of #799 with one extra 48ded1a to introduce backend expression and cached in constrain system. This align the design with pre-compile so its easier for next step refactor to introduce precompile chip in main flow. Main sumcheck read/write lookup expression was simplified, as post `evaluate()` was also removed. ### Expression Expression will be simplified into 2 kind: frontend and backend expression - frontend expression: expression with Witin/StructuralWitin/Fixed, in recursive/nested style - backend expression: expression with Witin only, in monomial style. After circuit setup, both expression content are all known and freezed. During runtime, we can take backend expression and evaluate its scalar with "challenge/instance" then the final expression can be put into sumcheck. ### benchmark The nice thing is before/after change, there is no performance difference. | Benchmark | Median Time (s) | Median Change (%) | |----------------------------------|------------------|----------------------------------------| | fibonacci_max_steps_1048576 | 2.0641 | -0.9869% (No change in performance detected) | | fibonacci_max_steps_2097152 | 3.5514 | -1.0748% (Change within noise threshold) | | fibonacci_max_steps_1048576 | 2.0641 | -0.9869% (No change in performance detected) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR build on top of #799 with one extra 48ded1a to introduce backend expression and cached in constrain system. This align the design with pre-compile so its easier for next step refactor to introduce precompile chip in main flow.
Main sumcheck read/write lookup expression was simplified, as post
evaluate()was also removed.Expression
Expression will be simplified into 2 kind: frontend and backend expression
After circuit setup, both expression content are all known and freezed. During runtime, we can take backend expression and evaluate its scalar with "challenge/instance" then the final expression can be put into sumcheck.
benchmark
The nice thing is before/after change, there is no performance difference.