Add support for other multi-threading APIs#1027
Add support for other multi-threading APIs#1027krzikalla wants to merge 1 commit intogoogle:masterfrom
Conversation
| { | ||
| ThreadManager::Result& results = manager->results; | ||
| results.cpu_time_used += timer->cpu_time_used(); | ||
| results.real_time_used = std::max(results.real_time_used, timer->real_time_used()); |
There was a problem hiding this comment.
Note to myself: leftover of another fix.
Here it still must be results.real_time_used += timer->real_time_used();
dmah42
left a comment
dmah42
left a comment
There was a problem hiding this comment.
some style notes while i work through the ramifications.
can you provide some example output in the PR so i can see if there's any impact?
also we'll need some tests.
| int num_thread_states_; | ||
|
|
||
| friend struct internal::BenchmarkInstance; | ||
| friend class ThreadState; |
There was a problem hiding this comment.
avoid friends please. add a protected section with accessors if you need that.
| }; | ||
|
|
||
| class ThreadState : public State | ||
| { |
There was a problem hiding this comment.
note we use google style so this (and other braces) should be on the previous line. you can use clang-format to make this easier.
| if (st.GetNumThreadStates() > 0) | ||
| { | ||
| CHECK((!b->explicit_threading) || b->manual_threading) | ||
| << "Benchmark " << b->name.str() << " run with managed threading. It must not create ThreadStates!"; |
There was a problem hiding this comment.
i believe this line is too long. please check with clang-format.
LebedevRI
left a comment
LebedevRI
left a comment
There was a problem hiding this comment.
Thanks. This looks more acceptable.
I think this needs some tests.
| BENCHMARK(BM_MultiThreaded)->ManualThreading()->Threads(1)->Threads(2)->Threads(4); | ||
| ``` | ||
| If you use the `ThreadState` object and explicitly specify the number of threads, then you must | ||
| use `ManualThreading` and the number of created `ThreadState` objects must match the number of specified threads. |
There was a problem hiding this comment.
Is this postcondition actually required? Can it be lifted?
There was a problem hiding this comment.
Do you mean the postcondition, that number of ThreadStates == number of threads? I don't see a way to do this.
Note, that this postcondition is only requried, if you explicitly specify the number of threads via Threads() and if you create at least one ThreadState object during the benchmark run. It would be odd, if in this case the numbers doesn't match.
There was a problem hiding this comment.
Do you mean the postcondition, that number of ThreadStates == number of threads?
Yes.
I don't see a way to do this.
Note, that this postcondition is only requried, if you explicitly specify the number of threads viaThreads()and if you create at least oneThreadStateobject during the benchmark run. It would be odd, if in this case the numbers doesn't match.
In particular, as discussed (?) in previous PR, i would like to call ->Threads(),
but disable benchmark-based threading. I.e. i'd like a way to use threads
as yet another parameter, without it actually creating all those threads,
and without dividing the measurements by the "thread count".
What exactly do you want to see?
Can I expect OpenMP availability, so that we can test with OpenMP as the alternative threading API? (question goes also @LebedevRI ) |
what the output (tabular is fine) looks like when using openmp.
i'm pretty sure you could check for openmp availability before enabling those tests... and add them to the buildbots. |
While that should work, i would personally maybe suggest just sticking with using |
that's true. as long as the api is being exercised and the expectations met, it shouldn't matter. |
3 participants
This PR replaces the OpenMP PR. It adds more flexibility to multi-threaded benchmarks.
You can perform scalability tests independent of std::thread.
And by the means of ThreadState you can also open a parallel region before the iteration loop, which enables you to measure the asynchronous progress of multiple threads across iterations.
For more information see the section "Multithreaded Benchmarks" in the README.