You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains 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
Cairo 0 programs don't allow input arguments (aka arguments to the main function). This is circumvented in cairo 1 by creating the arguments before calling the main function, by creating instructions that declare the input arguments as constants and allocate them as tempvars. This creates a "fake stack", with the builtin bases and the return_fp & return_pc and then a "real_stack" (used by main) with the builtin bases and the arguments.
An example of the execution segment after cairo 1 initialization (both VM & added instructions) would be:
[
// fake stack starts here
2:0 (range_check)
3:0 (bitwise)
4:0 (return_fp)
5:0 (return_pc)
// real stack starts here
2:0 (range_check)
3:0 (bitwise)
17 (arg 0)
67 (arg 1)
]
While this solves the issue of cairo 0 not being compatible with arguments (as the initial_stack doesn't contain the arguments), it inserts the values of the arguments into the instructions, making the program hash vary depending on the arguments passed to the program.
This PR aims to solve this last program by creating both the initial (inputless) stack and the real stack in an initialization method (similar to the VM's initialize) and removing the instructions responsible for creating the real stack in create_entrypoint. The result of this changes should not modify cairo 1 executions, as the starting execution segment before calling the main function will remain the same
Other solutions previously explored: Removing create_entry_point altogether and using the normal cairo-vm initialization & segment_arena builtin runner: This lead to problems concerning CairoPie as segment_arena & argument creation disrupted the segment order required by cairo pie validations, and arguments were not expected in the initial_stack
**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 ± σ): 27.125 s ± 0.011 s [User: 26.331 s, System: 0.790 s]
Range (min … max): 27.117 s … 27.132 s 2 runs
Benchmark 2: hyper_threading_pr threads: 1
Time (mean ± σ): 27.119 s ± 0.034 s [User: 26.279 s, System: 0.837 s]
Range (min … max): 27.095 s … 27.143 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.610 s ± 0.011 s [User: 26.946 s, System: 0.797 s]
Range (min … max): 14.602 s … 14.618 s 2 runs
Benchmark 2: hyper_threading_pr threads: 2
Time (mean ± σ): 14.355 s ± 0.029 s [User: 26.352 s, System: 0.806 s]
Range (min … max): 14.334 s … 14.375 s 2 runs
Summary
'hyper_threading_pr threads: 2' ran
1.02 ± 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.967 s ± 0.260 s [User: 38.781 s, System: 0.996 s]
Range (min … max): 10.783 s … 11.151 s 2 runs
Benchmark 2: hyper_threading_pr threads: 4
Time (mean ± σ): 10.970 s ± 0.330 s [User: 38.516 s, System: 0.947 s]
Range (min … max): 10.736 s … 11.203 s 2 runs
Summary
'hyper_threading_main threads: 4' ran
1.00 ± 0.04 times faster than 'hyper_threading_pr 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.732 s ± 0.239 s [User: 39.096 s, System: 0.946 s]
Range (min … max): 10.563 s … 10.901 s 2 runs
Benchmark 2: hyper_threading_pr threads: 6
Time (mean ± σ): 10.948 s ± 0.010 s [User: 38.642 s, System: 0.965 s]
Range (min … max): 10.941 s … 10.955 s 2 runs
Summary
'hyper_threading_main threads: 6' ran
1.02 ± 0.02 times faster than 'hyper_threading_pr 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.610 s ± 0.134 s [User: 39.196 s, System: 1.060 s]
Range (min … max): 10.515 s … 10.704 s 2 runs
Benchmark 2: hyper_threading_pr threads: 8
Time (mean ± σ): 10.555 s ± 0.118 s [User: 38.930 s, System: 0.910 s]
Range (min … max): 10.472 s … 10.639 s 2 runs
Summary
'hyper_threading_pr threads: 8' ran
1.01 ± 0.02 times faster than 'hyper_threading_main 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.656 s ± 0.326 s [User: 39.576 s, System: 0.990 s]
Range (min … max): 10.425 s … 10.886 s 2 runs
Benchmark 2: hyper_threading_pr threads: 16
Time (mean ± σ): 10.601 s ± 0.070 s [User: 39.252 s, System: 1.002 s]
Range (min … max): 10.551 s … 10.650 s 2 runs
Summary
'hyper_threading_pr threads: 16' ran
1.01 ± 0.03 times faster than 'hyper_threading_main threads: 16'
fmoletta
changed the title
[Cairo 1] Replace hardcoding arguments with vm initialization
[Cairo 1] Replace hardcoded arguments with vm initialization
May 7, 2024
Attention: Patch coverage is 99.54751% with 1 lines in your changes are missing coverage. Please review.
Project coverage is 94.76%. Comparing base (258dd84) to head (0896a0d).
Report is 6 commits behind head on main.
❗ Current head 0896a0d differs from pull request most recent head 6eb6768. Consider uploading reports for the commit 6eb6768 to get more accurate results
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.
Cairo 0 programs don't allow input arguments (aka arguments to the main function). This is circumvented in cairo 1 by creating the arguments before calling the main function, by creating instructions that declare the input arguments as constants and allocate them as tempvars. This creates a "fake stack", with the builtin bases and the return_fp & return_pc and then a "real_stack" (used by main) with the builtin bases and the arguments.
An example of the execution segment after cairo 1 initialization (both VM & added instructions) would be:
While this solves the issue of cairo 0 not being compatible with arguments (as the initial_stack doesn't contain the arguments), it inserts the values of the arguments into the instructions, making the program hash vary depending on the arguments passed to the program.
This PR aims to solve this last program by creating both the initial (inputless) stack and the real stack in an initialization method (similar to the VM's initialize) and removing the instructions responsible for creating the real stack in
create_entrypoint
. The result of this changes should not modify cairo 1 executions, as the starting execution segment before calling the main function will remain the sameOther solutions previously explored: Removing create_entry_point altogether and using the normal cairo-vm initialization & segment_arena builtin runner: This lead to problems concerning CairoPie as segment_arena & argument creation disrupted the segment order required by cairo pie validations, and arguments were not expected in the initial_stack