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
I'm trying to benchmark a concurrent data structure, and I want to benchmark its read/write behaviour under thread contention. However, unlike all of the threaded examples in documentation, this structure's performance characteristics change as it is modified: internal parts of it are consumed or rearranged by different threads, so it needs to be constructed again for each run of the benchmark.
This means:
If the tested structure is made static, or initialised in the benchmark function body before calling divan::Bencher methods, then only the first iteration sees the structure as it was constructed. The other iterations see one which contents have been consumed by the first iteration, with almost no work left to benchmark.
Either the structure is constructed once, then shared among all iterations (the first option), or constructed separately for each thread, and never shared (the second option). I need a way to make it constructed once per benchmark run, and shared only among threads that are part of the same benchmark run. Do I correctly understand that this is currently not possible using the threads option?
My current workaround is to start a const number of threads myself inside the with_inputs closure and have them wait at a std::sync::Barrier, then as part of the bench_local_values closure, release the Barrier and join the threads to time them:
This works, but there's a lot of code duplicating what I imagine Divan would do internally to implement the threads option.
I also see worse performance when benchmarking with 1 thread using this method than I do from an otherwise-identical benchmark with #[divan::bench(threads = [1])]. Probably because Divan doesn't use a Barrier when single-threaded. Which is smart, and another reason why I feel like this could be handled.
Am I missing a better existing way to do this?
If yes, could an example be added illustrating it?
If no, do you think this use-case could be handled by Divan?
The text was updated successfully, but these errors were encountered:
I'm trying to benchmark a concurrent data structure, and I want to benchmark its read/write behaviour under thread contention. However, unlike all of the threaded examples in documentation, this structure's performance characteristics change as it is modified: internal parts of it are consumed or rearranged by different threads, so it needs to be constructed again for each run of the benchmark.
This means:
If the tested structure is made
static
, or initialised in the benchmark function body before callingdivan::Bencher
methods, then only the first iteration sees the structure as it was constructed. The other iterations see one which contents have been consumed by the first iteration, with almost no work left to benchmark.If it is initialised in
with_inputs
, each thread gets its own copy of the whole structure, so they never contend.Either the structure is constructed once, then shared among all iterations (the first option), or constructed separately for each thread, and never shared (the second option). I need a way to make it constructed once per benchmark run, and shared only among threads that are part of the same benchmark run. Do I correctly understand that this is currently not possible using the
threads
option?My current workaround is to start a
const
number of threads myself inside thewith_inputs
closure and have them wait at astd::sync::Barrier
, then as part of thebench_local_values
closure, release theBarrier
and join the threads to time them:This works, but there's a lot of code duplicating what I imagine Divan would do internally to implement the
threads
option.I also see worse performance when benchmarking with 1 thread using this method than I do from an otherwise-identical benchmark with
#[divan::bench(threads = [1])]
. Probably because Divan doesn't use a Barrier when single-threaded. Which is smart, and another reason why I feel like this could be handled.Am I missing a better existing way to do this?
If yes, could an example be added illustrating it?
If no, do you think this use-case could be handled by Divan?
The text was updated successfully, but these errors were encountered: