Skip to content

Enable_using_secure_run_in_proof_mode #2113

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

Open
wants to merge 1 commit into
base: starkware-development
Choose a base branch
from

Conversation

YairVaknin-starkware
Copy link
Collaborator

@YairVaknin-starkware YairVaknin-starkware commented Jun 3, 2025

TITLE

Description

Description of the pull request changes and motivation.

Checklist

  • Linked to Github Issue
  • Unit tests added
  • Integration tests added.
  • This change requires new documentation.
    • Documentation has been added/updated.
    • CHANGELOG has been updated.

This change is Reviewable

Copy link

github-actions bot commented Jun 3, 2025

**Hyper Thereading Benchmark results**




hyperfine -r 2 -n "hyper_threading_main threads: 1" 'RAYON_NUM_THREADS=1 ./hyper_threading_main' -n "hyper_threading_pr threads: 1" 'RAYON_NUM_THREADS=1 ./hyper_threading_pr'
Benchmark 1: hyper_threading_main threads: 1
  Time (mean ± σ):     25.616 s ±  0.040 s    [User: 24.857 s, System: 0.755 s]
  Range (min … max):   25.588 s … 25.644 s    2 runs
 
Benchmark 2: hyper_threading_pr threads: 1
  Time (mean ± σ):     25.494 s ±  0.017 s    [User: 24.701 s, System: 0.790 s]
  Range (min … max):   25.482 s … 25.506 s    2 runs
 
Summary
  hyper_threading_pr threads: 1 ran
    1.00 ± 0.00 times faster than hyper_threading_main threads: 1




hyperfine -r 2 -n "hyper_threading_main threads: 2" 'RAYON_NUM_THREADS=2 ./hyper_threading_main' -n "hyper_threading_pr threads: 2" 'RAYON_NUM_THREADS=2 ./hyper_threading_pr'
Benchmark 1: hyper_threading_main threads: 2
  Time (mean ± σ):     14.292 s ±  0.030 s    [User: 24.995 s, System: 0.805 s]
  Range (min … max):   14.271 s … 14.314 s    2 runs
 
Benchmark 2: hyper_threading_pr threads: 2
  Time (mean ± σ):     13.933 s ±  0.030 s    [User: 24.837 s, System: 0.851 s]
  Range (min … max):   13.912 s … 13.955 s    2 runs
 
Summary
  hyper_threading_pr threads: 2 ran
    1.03 ± 0.00 times faster than hyper_threading_main threads: 2




hyperfine -r 2 -n "hyper_threading_main threads: 4" 'RAYON_NUM_THREADS=4 ./hyper_threading_main' -n "hyper_threading_pr threads: 4" 'RAYON_NUM_THREADS=4 ./hyper_threading_pr'
Benchmark 1: hyper_threading_main threads: 4
  Time (mean ± σ):     10.588 s ±  0.476 s    [User: 37.781 s, System: 0.942 s]
  Range (min … max):   10.252 s … 10.925 s    2 runs
 
Benchmark 2: hyper_threading_pr threads: 4
  Time (mean ± σ):     10.210 s ±  0.145 s    [User: 37.379 s, System: 1.067 s]
  Range (min … max):   10.107 s … 10.313 s    2 runs
 
Summary
  hyper_threading_pr threads: 4 ran
    1.04 ± 0.05 times faster than hyper_threading_main threads: 4




hyperfine -r 2 -n "hyper_threading_main threads: 6" 'RAYON_NUM_THREADS=6 ./hyper_threading_main' -n "hyper_threading_pr threads: 6" 'RAYON_NUM_THREADS=6 ./hyper_threading_pr'
Benchmark 1: hyper_threading_main threads: 6
  Time (mean ± σ):     10.479 s ±  0.064 s    [User: 37.846 s, System: 0.982 s]
  Range (min … max):   10.434 s … 10.525 s    2 runs
 
Benchmark 2: hyper_threading_pr threads: 6
  Time (mean ± σ):     10.184 s ±  0.181 s    [User: 37.824 s, System: 1.080 s]
  Range (min … max):   10.056 s … 10.313 s    2 runs
 
Summary
  hyper_threading_pr threads: 6 ran
    1.03 ± 0.02 times faster than hyper_threading_main threads: 6




hyperfine -r 2 -n "hyper_threading_main threads: 8" 'RAYON_NUM_THREADS=8 ./hyper_threading_main' -n "hyper_threading_pr threads: 8" 'RAYON_NUM_THREADS=8 ./hyper_threading_pr'
Benchmark 1: hyper_threading_main threads: 8
  Time (mean ± σ):     10.353 s ±  0.010 s    [User: 38.353 s, System: 1.008 s]
  Range (min … max):   10.345 s … 10.360 s    2 runs
 
Benchmark 2: hyper_threading_pr threads: 8
  Time (mean ± σ):     10.378 s ±  0.041 s    [User: 37.812 s, System: 1.085 s]
  Range (min … max):   10.349 s … 10.407 s    2 runs
 
Summary
  hyper_threading_main threads: 8 ran
    1.00 ± 0.00 times faster than hyper_threading_pr threads: 8




hyperfine -r 2 -n "hyper_threading_main threads: 16" 'RAYON_NUM_THREADS=16 ./hyper_threading_main' -n "hyper_threading_pr threads: 16" 'RAYON_NUM_THREADS=16 ./hyper_threading_pr'
Benchmark 1: hyper_threading_main threads: 16
  Time (mean ± σ):     10.504 s ±  0.262 s    [User: 38.423 s, System: 1.090 s]
  Range (min … max):   10.318 s … 10.689 s    2 runs
 
Benchmark 2: hyper_threading_pr threads: 16
  Time (mean ± σ):     10.139 s ±  0.026 s    [User: 37.995 s, System: 1.129 s]
  Range (min … max):   10.120 s … 10.158 s    2 runs
 
Summary
  hyper_threading_pr threads: 16 ran
    1.04 ± 0.03 times faster than hyper_threading_main threads: 16


Copy link

github-actions bot commented Jun 3, 2025

Benchmark Results for unmodified programs 🚀

Command Mean [s] Min [s] Max [s] Relative
base big_factorial 2.146 ± 0.020 2.127 2.189 1.01 ± 0.01
head big_factorial 2.133 ± 0.009 2.120 2.149 1.00
Command Mean [s] Min [s] Max [s] Relative
base big_fibonacci 2.078 ± 0.028 2.058 2.137 1.02 ± 0.01
head big_fibonacci 2.047 ± 0.005 2.040 2.056 1.00
Command Mean [s] Min [s] Max [s] Relative
base blake2s_integration_benchmark 7.551 ± 0.175 7.448 8.041 1.00
head blake2s_integration_benchmark 7.612 ± 0.199 7.525 8.171 1.01 ± 0.04
Command Mean [s] Min [s] Max [s] Relative
base compare_arrays_200000 2.208 ± 0.006 2.198 2.216 1.00
head compare_arrays_200000 2.208 ± 0.014 2.186 2.236 1.00 ± 0.01
Command Mean [s] Min [s] Max [s] Relative
base dict_integration_benchmark 1.437 ± 0.005 1.431 1.448 1.00 ± 0.01
head dict_integration_benchmark 1.432 ± 0.010 1.419 1.448 1.00
Command Mean [s] Min [s] Max [s] Relative
base field_arithmetic_get_square_benchmark 1.224 ± 0.009 1.216 1.247 1.00 ± 0.01
head field_arithmetic_get_square_benchmark 1.223 ± 0.005 1.216 1.230 1.00
Command Mean [s] Min [s] Max [s] Relative
base integration_builtins 7.589 ± 0.123 7.508 7.926 1.00
head integration_builtins 7.597 ± 0.030 7.555 7.640 1.00 ± 0.02
Command Mean [s] Min [s] Max [s] Relative
base keccak_integration_benchmark 7.716 ± 0.121 7.645 8.055 1.00
head keccak_integration_benchmark 7.744 ± 0.121 7.636 7.964 1.00 ± 0.02
Command Mean [s] Min [s] Max [s] Relative
base linear_search 2.179 ± 0.011 2.167 2.204 1.00 ± 0.01
head linear_search 2.177 ± 0.008 2.164 2.192 1.00
Command Mean [s] Min [s] Max [s] Relative
base math_cmp_and_pow_integration_benchmark 1.510 ± 0.008 1.501 1.527 1.00 ± 0.01
head math_cmp_and_pow_integration_benchmark 1.505 ± 0.007 1.498 1.522 1.00
Command Mean [s] Min [s] Max [s] Relative
base math_integration_benchmark 1.458 ± 0.007 1.451 1.476 1.00 ± 0.01
head math_integration_benchmark 1.457 ± 0.011 1.447 1.486 1.00
Command Mean [s] Min [s] Max [s] Relative
base memory_integration_benchmark 1.209 ± 0.003 1.205 1.214 1.00
head memory_integration_benchmark 1.210 ± 0.004 1.205 1.219 1.00 ± 0.00
Command Mean [s] Min [s] Max [s] Relative
base operations_with_data_structures_benchmarks 1.549 ± 0.008 1.540 1.565 1.00
head operations_with_data_structures_benchmarks 1.552 ± 0.006 1.544 1.562 1.00 ± 0.01
Command Mean [ms] Min [ms] Max [ms] Relative
base pedersen 533.0 ± 2.2 530.7 538.7 1.00
head pedersen 537.2 ± 10.2 530.7 563.9 1.01 ± 0.02
Command Mean [ms] Min [ms] Max [ms] Relative
base poseidon_integration_benchmark 620.3 ± 3.5 614.5 625.8 1.00 ± 0.01
head poseidon_integration_benchmark 618.4 ± 4.0 613.4 624.9 1.00
Command Mean [s] Min [s] Max [s] Relative
base secp_integration_benchmark 1.859 ± 0.010 1.848 1.874 1.01 ± 0.01
head secp_integration_benchmark 1.838 ± 0.010 1.825 1.853 1.00
Command Mean [ms] Min [ms] Max [ms] Relative
base set_integration_benchmark 630.0 ± 3.7 627.1 640.1 1.00
head set_integration_benchmark 630.9 ± 5.2 624.5 643.1 1.00 ± 0.01
Command Mean [s] Min [s] Max [s] Relative
base uint256_integration_benchmark 4.248 ± 0.016 4.225 4.281 1.00
head uint256_integration_benchmark 4.255 ± 0.040 4.220 4.363 1.00 ± 0.01

@YairVaknin-starkware YairVaknin-starkware force-pushed the yairv/enable_using_secure_run_in_proof_mode branch from 4c7661b to 9ad4783 Compare June 3, 2025 10:39
@gabrielbosio gabrielbosio mentioned this pull request Jun 3, 2025
Copy link
Collaborator

@yuvalsw yuvalsw left a 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 r1, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @YairVaknin-starkware)


vm/src/vm/runners/cairo_runner.rs line 1032 at r1 (raw file):

                    stop_ptr.ok_or_else(|| RunnerError::NoStopPointer(Box::new(builtin.name())))?;
                builtin_segment_info.push((index, stop_ptr));
            }

Suggestion:

            if proof_mode {
                // In proof‐mode there are builtin runners for all builtins, but only the ones that are in the program are finalized (`stop_ptr` is set). Only collect those.
                if let Some(stop_ptr) = stop_ptr {
                    builtin_segment_info.push((index, stop_ptr));
                }
            } else {
                // In non‐proof-mode all builtin runners are from the program and thus should be finalized (`stop_ptr` is set).
                let stop_ptr =
                    stop_ptr.ok_or_else(|| RunnerError::NoStopPointer(Box::new(builtin.name())))?;
                builtin_segment_info.push((index, stop_ptr));
            }

vm/src/vm/runners/cairo_runner.rs line 1032 at r1 (raw file):

                    stop_ptr.ok_or_else(|| RunnerError::NoStopPointer(Box::new(builtin.name())))?;
                builtin_segment_info.push((index, stop_ptr));
            }

suggestion

Suggestion:

            match stop_ptr {
                Some(stop_ptr) => {
                    // comment ...
                    builtin_segment_info.push((index, stop_ptr));
                }
                None => {
                    if !proof_mode {
                        // comment...
                        RunnerError::NoStopPointer(Box::new(builtin.name()))
                    }
                }
            }

@YairVaknin-starkware YairVaknin-starkware force-pushed the yairv/enable_using_secure_run_in_proof_mode branch 2 times, most recently from 20953cc to e5ad90b Compare June 8, 2025 08:06
Copy link
Collaborator Author

@YairVaknin-starkware YairVaknin-starkware left a 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 1 files reviewed, 2 unresolved discussions (waiting on @yuvalsw)


vm/src/vm/runners/cairo_runner.rs line 1032 at r1 (raw file):

Previously, yuvalsw wrote…

suggestion

Refactored so we only check if proof_mode once.


vm/src/vm/runners/cairo_runner.rs line 1032 at r1 (raw file):

                    stop_ptr.ok_or_else(|| RunnerError::NoStopPointer(Box::new(builtin.name())))?;
                builtin_segment_info.push((index, stop_ptr));
            }

Done.

Copy link

codecov bot commented Jun 8, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.63%. Comparing base (bdf604f) to head (763901a).

Additional details and impacted files
@@                  Coverage Diff                   @@
##           starkware-development    #2113   +/-   ##
======================================================
  Coverage                  96.63%   96.63%           
======================================================
  Files                        104      104           
  Lines                      43864    43900   +36     
======================================================
+ Hits                       42388    42424   +36     
  Misses                      1476     1476           

☔ 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.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@YairVaknin-starkware YairVaknin-starkware force-pushed the yairv/enable_using_secure_run_in_proof_mode branch from e5ad90b to 622a92b Compare June 8, 2025 10:01
Copy link
Collaborator

@yuvalsw yuvalsw left a 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 r2, all commit messages.
Reviewable status: 0 of 1 files reviewed, 1 unresolved discussion (waiting on @YairVaknin-starkware)


vm/src/vm/runners/cairo_runner.rs line 1023 at r2 (raw file):

        // Closure to process each builtin's segment info based on whether we are in proof mode or not.
        let mut process: ProcessBuiltinSegmentClosure<'_> = if proof_mode {

While saving the if inside the loop, it complicates the code, also adding other indirections - so I am not sure it's more efficient (saving the if is pretty negligible). Unless I missed some other reason to use a closure here, I prefer the previous way.
Though I will not block on it, if you choose to leave it this way, please explain why.

Copy link
Collaborator

@yuvalsw yuvalsw left a 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 r3.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @YairVaknin-starkware)

@YairVaknin-starkware YairVaknin-starkware force-pushed the yairv/enable_using_secure_run_in_proof_mode branch from 622a92b to 1043f0a Compare June 8, 2025 13:17
Copy link
Collaborator Author

@YairVaknin-starkware YairVaknin-starkware left a 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, 1 unresolved discussion (waiting on @yuvalsw)


vm/src/vm/runners/cairo_runner.rs line 1023 at r2 (raw file):

Previously, yuvalsw wrote…

While saving the if inside the loop, it complicates the code, also adding other indirections - so I am not sure it's more efficient (saving the if is pretty negligible). Unless I missed some other reason to use a closure here, I prefer the previous way.
Though I will not block on it, if you choose to leave it this way, please explain why.

It's not there in terms of efficiency. They should be pretty similar in that regard (most efficient would just be duplication of the loop, but still really negligible for our use case). I Just like this style better and I think this avoids polluting the loop with a logic that could be decided earlier on in the run (it's pretty standard practice to have different methods do different things based on some branch logic, just here there's no need to define them outside the func scope and the logic is pretty "thin").

Copy link
Collaborator

@yuvalsw yuvalsw left a 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 r4, all commit messages.
Reviewable status: all files reviewed, 6 unresolved discussions (waiting on @YairVaknin-starkware)


vm/src/vm/runners/cairo_runner.rs line 1023 at r2 (raw file):

Previously, YairVaknin-starkware wrote…

It's not there in terms of efficiency. They should be pretty similar in that regard (most efficient would just be duplication of the loop, but still really negligible for our use case). I Just like this style better and I think this avoids polluting the loop with a logic that could be decided earlier on in the run (it's pretty standard practice to have different methods do different things based on some branch logic, just here there's no need to define them outside the func scope and the logic is pretty "thin").

I disagree - the if way is much more readable and straight forward IMO. Anyway as said, not blocking on this if you insist.


vm/src/vm/runners/cairo_runner.rs line 1016 at r4 (raw file):

    // Returns a map from builtin base's segment index to stop_ptr offset
    // Aka the builtin's segment number and its maximum offset

Suggestion:

    /// Returns a map from builtin base's segment index to stop_ptr offset
    /// Aka the builtin's segment number and its maximum offset

vm/src/vm/runners/cairo_runner.rs line 1017 at r4 (raw file):

    // Returns a map from builtin base's segment index to stop_ptr offset
    // Aka the builtin's segment number and its maximum offset
    pub fn get_builtin_segments_info(&self) -> Result<Vec<(usize, usize)>, RunnerError> {

Any reason not to use HashMap?
If there is, please just adjust the doc saying it's a vector mapping these values, not "a map".

Code quote:

<Vec<(usize, usize)>

vm/src/vm/runners/cairo_runner.rs line 3938 at r4 (raw file):

    #[test]
    #[cfg_attr(target_arch = "wasm32", wasm_bindgen_test)]
    fn get_builtin_segments_info_non_proof_mode() {

consider uniting the test using parametrrization


vm/src/vm/runners/cairo_runner.rs line 3952 at r4 (raw file):

        let mut hint_executor = BuiltinHintProcessor::new_empty();
        let runner = cairo_run(program_data, &cairo_run_config, &mut hint_executor).unwrap();
        assert_eq!(runner.get_builtin_segments_info(), Ok(vec![(2, 6)]));

how only a single segment?
Which builtin is it?
Why is it index 2?

  • Same questions for the other test
  • Please reply to those questions in comments.

@YairVaknin-starkware YairVaknin-starkware force-pushed the yairv/enable_using_secure_run_in_proof_mode branch from 1043f0a to 763901a Compare June 10, 2025 06:28
Copy link
Collaborator Author

@YairVaknin-starkware YairVaknin-starkware left a 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, 4 unresolved discussions (waiting on @JulianGCalderon and @yuvalsw)


vm/src/vm/runners/cairo_runner.rs line 1017 at r4 (raw file):

Previously, yuvalsw wrote…

Any reason not to use HashMap?
If there is, please just adjust the doc saying it's a vector mapping these values, not "a map".

No need for random access here, and later used as a tuple in a few places. I don't see a reason to change it.


vm/src/vm/runners/cairo_runner.rs line 3938 at r4 (raw file):

Previously, yuvalsw wrote…

consider uniting the test using parametrrization

they don't have the needed dep. prefer not to add it or create a custom macro for this case.


vm/src/vm/runners/cairo_runner.rs line 3952 at r4 (raw file):

Previously, yuvalsw wrote…

how only a single segment?
Which builtin is it?
Why is it index 2?

  • Same questions for the other test
  • Please reply to those questions in comments.

It's just range check. idx 2 for non proof mode, idx 4 for proof mode since the layout contains some before it, but not used.

Copy link
Collaborator

@yuvalsw yuvalsw left a comment

Choose a reason for hiding this comment

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

:lgtm:

Reviewed 1 of 1 files at r5, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @JulianGCalderon and @YairVaknin-starkware)


vm/src/vm/runners/cairo_runner.rs line 3952 at r4 (raw file):

Previously, YairVaknin-starkware wrote…

It's just range check. idx 2 for non proof mode, idx 4 for proof mode since the layout contains some before it, but not used.

ok, but as said - "Please reply to those questions in comments "

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