-
Notifications
You must be signed in to change notification settings - Fork 106
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
micro benchmarks #32
base: main
Are you sure you want to change the base?
micro benchmarks #32
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question: instead of declaring one bencher function for each (msm, fft, poly_eval), have you tried ark_std::start_timer
and ark_std::end_timer
(another usage example)?
they use concrete struct instance to avoid the necessity of locking? (need to double check)
Do your bencher profile more accurately under multi-threaded run?
Ha, good idea! I didn't know about their timer... I will switch to theirs... |
Did some digging in the ark_std's timer. Those are macros that get you the running time within a function. We need to benchmark FFTs and MSMs across multiple functions so we will still need to declare global variables to store the result. Given this I am inclined to keep the current design.
I think they don't need to lock because it is within a single function. |
rm target/*.txt | ||
rm target/*.log | ||
RAYON_NUM_THREADS=64 cargo bench --features=bench > target/64core.log |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mt
in the file name is ambiguous (my first reaction: "merkle tree? where?" 😆 then I realize it means to say "multithreading")? plus it's a bit confusing with the co-existence of./scripts/run_benchmark.sh
- location of
*.txt/log
files probably should betarget/plonkbench/*.txt/log
(Criterion's artifacts are all undertarget/criterion/*
) cargo bench plonk-benches
instead since there'smerkle_path
bench inprimitives/
let mut f = File::create(format!( | ||
"../target/{}-threads.txt", | ||
rayon::current_num_threads() | ||
)) | ||
.expect("Unable to create file"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let mut f = File::create(format!( | |
"../target/{}-threads.txt", | |
rayon::current_num_threads() | |
)) | |
.expect("Unable to create file"); | |
let mut path = PathBuf::new(); | |
path.push(env!("CARGO_MANIFEST_DIR")); | |
path.push(format!("target/plonkbench/{}-threads", rayon::current_num_threads())); | |
path.set_extension("txt"); | |
let mut f = OpenOptions::new() | |
.write(true) | |
.create(true) | |
.truncate(true) | |
.open(path.clone()) | |
.unwrap(); |
You can try using something like this to overwrite the file instead of appending to it in case the file already exists (which File::create
does)
thread_local!(static FFT_START_TIME: RefCell<Instant> = RefCell::new(Instant::now())); | ||
thread_local!(static FFT_TIMER_LOCK: RefCell<bool> = RefCell::new(false)); | ||
thread_local!(static FFT_TOTAL_TIME: RefCell<Duration> = RefCell::new(Duration::ZERO)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if there's better method here, basically we are dealing with a global time counter that accumulates time spent across code snippets in many functions.
- I wonder if we can get rid of the time lock, and start time -- they can be local variable, right? only the total time needs to be globally accessible.
if FFT_TIMER_LOCK.with(|lock| *lock.borrow()) { | ||
panic!("another FFT timer has already started somewhere else"); | ||
} | ||
|
||
FFT_START_TIME.with(|timer| { | ||
*timer.borrow_mut() = Instant::now(); | ||
}); | ||
|
||
FFT_TIMER_LOCK.with(|lock| { | ||
*lock.borrow_mut() = true; | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this logic is slightly baffling to me, so if FFT is locked, then we panic?
- it seem to me that our timer will never be used by 2 threads at the same time? because the multi-threaded code is in-between the
fft_start()
andfft_end()
(e.g. insidefn compute_selector_polynomials
), so maybe we don't need this locking to begin with? - If we have proper concurrency control, then FFT timer should never panic, but rather wait on lock to be released instead?
Description
closes: #XXXX
Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.
This PR adds micro benchmarks for subroutines within proving and verification. It is enabled with
--features=bench
Wrote unit testsPending
section inCHANGELOG.md
Files changed
in the GitHub PR explorer