Skip to content
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

[feat] Implement Stateful for VmChipComplex #1211

Merged
merged 4 commits into from
Jan 15, 2025
Merged

Conversation

nyunyunyunyu
Copy link
Contributor

@nyunyunyunyu nyunyunyunyu commented Jan 13, 2025

1st commit:

  • Implement Stateful for system chips.
  • Implement SharedVariableRangeCheckerChip.

2st commit:

  • Implement Stateful for VmChipComplex.
  • Add ExecutionSegment::new_for_proving which constructs a ExecutionSegment just for proving.
  • Add ExecutionSegment::store_chip_complex_state to store states.

Note: some memory states need to clone. We should to try to avoid it in the future.

closes INT-2951

@nyunyunyunyu nyunyunyunyu changed the title [HOLD][feat] Implement Stateful for SystemComplex [feat] Implement Stateful for VmChipComplex Jan 13, 2025
@nyunyunyunyu nyunyunyunyu marked this pull request as ready for review January 13, 2025 15:25
@nyunyunyunyu nyunyunyunyu force-pushed the feat/impl-state-persist branch from 51eace6 to a7fef1a Compare January 13, 2025 16:40

This comment has been minimized.

@nyunyunyunyu nyunyunyunyu requested a review from luffykai January 14, 2025 17:05
Self(Arc::new(VariableRangeCheckerChip::new(bus)))
}

pub fn bus(&self) -> VariableRangeCheckerBus {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we implement deref https://doc.rust-lang.org/std/ops/trait.Deref.html from SharedVariableRangeCheckerChip to Arc, can we avoid all these self.0.xx functions?

@@ -489,6 +534,30 @@ impl<F: PrimeField32> SystemBase<F> {
}
}

impl<F: PrimeField32> Stateful<SystemBaseState<F>> for SystemBase<F> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

semi-related but not directly for this PR: shouldn't trait Stateful specify the state S should be Serialize + Deserialize

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the trait-level, It seems not a must because Stateful can be used in memory(maybe?).

crates/vm/tests/integration_test.rs Show resolved Hide resolved
}

fn store_state(&self) -> VmInventoryState {
// TODO: parallelize this.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what's stopping you?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some implementations of Executor/Periphery are not Send + Sync due to RefCell/Box. I think we can address this if this is a bottleneck.

@@ -431,6 +463,12 @@ pub struct VmChipComplex<F: PrimeField32, E, P> {
bus_idx_max: usize,
}

#[derive(Clone, Serialize, Deserialize)]
pub struct VmChipComplexState<F> {
base: SystemBaseState<F>,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is just a matter of where you invoke bitcode, but wouldn't it match the other chip's pattern more if you bitcode deserialized to SystemBaseState without load state? otherwise you will need to specify this state in protobuf

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I intend to avoid unnecessary serialization because bitcode is not zero-copy. The existing implementation only serialize one more time when sending the struct. I wanted to mention this but didn't find a good place for comments.

@@ -694,6 +694,13 @@ impl<F: PrimeField32> MemoryController<F> {
pub fn offline_memory(&self) -> Arc<Mutex<OfflineMemory<F>>> {
self.offline_memory.clone()
}
pub fn get_memory_logs(&self) -> Vec<MemoryLogEntry<F>> {
// TODO: can we avoid clone?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you could make a separate take_memory_logs fn

Copy link
Contributor Author

@nyunyunyunyu nyunyunyunyu Jan 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, but store_state(&self) so I cannot take..

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if it's safe to change the function signature to store_state(self)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

huh why is it not store_state(&mut self): some sync thing?

Copy link
Contributor

@jonathanpwang jonathanpwang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM after addressing @luffykai 's comments

This comment has been minimized.

@nyunyunyunyu nyunyunyunyu force-pushed the feat/impl-state-persist branch from 3d63ce9 to 1b0f937 Compare January 15, 2025 15:30

This comment has been minimized.

Copy link

group app.proof_time_ms app.cycles app.cells_used leaf.proof_time_ms leaf.cycles leaf.cells_used
verify_fibair (+23 [+0.7%]) 3,500 711,252 25,510,625 - - -
fibonacci_program (+9 [+0.1%]) 6,112 1,500,137 51,505,102 - - -
regex_program (-230 [-1.2%]) 18,743 4,190,904 165,028,173 - - -
ecrecover_program (+92 [+3.6%]) 2,641 285,401 15,092,297 - - -

Commit: 3242120

Benchmark Workflow

@nyunyunyunyu nyunyunyunyu merged commit ebf7aa6 into main Jan 15, 2025
23 checks passed
@nyunyunyunyu nyunyunyunyu deleted the feat/impl-state-persist branch January 15, 2025 16:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants