Using std::chrono::steady_clock to benchmark code in a thread/async

Suppose I have lots of computations that I want to run (and benchmark CPU time) in multiple threads. As a toy example:

#include <chrono>
#include <future>
#include <iostream>
#include <vector>


using unit_t = std::chrono::nanoseconds;

unit_t::rep expensive_computation()
auto start = std::chrono::steady_clock::now();
// Something time-consuming here...
auto end = std::chrono::steady_clock::now();

auto duration = std::chrono::duration_cast<unit_t>(end - start).count();

return duration;


int main()
std::vector<std::future<unit_t::rep>> computations;

for (int i = 0; i < 100; i++)
computations.push_back(std::async(expensive_computation));


for (size_t i = 0; i < computations.size(); i++)
auto duration = computations[i].get();
std::cout << "#" << i << " took " << duration << "ns" << std::endl;




I'm concerned that since steady_clock is montonic across threads the underlying clock ticks per process and not per thread (if any thread is scheduled the clock ticks for all threads). This would mean that if a thread were sleeping, steady_clock would still be ticking for it and this time would incorrectly be included in the duration for that thread. Is my suspicion correct? Or does steady_clock tick only for thread CPU time within a thread?

steady_clock

steady_clock

duration

steady_clock

Put another way, is this approach a safe way to independently time lots of computations (such that no CPU time spent on one thread will affect the duration of another thread)? Or do I need to spin off separate processes for each computation to make the steady_clock only tick when the computation is running/scheduled?

duration

steady_clock

edit: I also recognize that spinning up more threads than cores may be an inefficient approach to this problem (although, I don't particularly care about computation throughput; moreover, I just want them all as a group to complete in the fastest time). I suspect in practice, I'd need to maintain a small-constant bounded list of threads in flight (say capped at the number of cores) and only start new computations as a core becomes available. But, this shouldn't have an impact on timing that I care about above; it should only affect the wall clock time.

future.get()

future.wait()

2 Answers
2

The standard specifies that steady_clock model physical time (as opposed to CPU time).

steady_clock

From [time.clock.steady]:

Objects of class steady_clock represent clocks for which values of time_point never decrease as physical time advances and for which values of time_point advance at a steady rate relative to real time. That is, the clock may not be adjusted.

steady_clock

time_point

That being said, how well an implementation models physical time is a QOI issue. Nevertheless, your code looks fine to me.

Should your experimentations prove unsatisfactory, clients of <chrono> can also author their own custom clocks that will have first class status within the <chrono> library.

<chrono>

<chrono>

pthread_getcpuclockid

This would mean that if a thread were sleeping, steady_clock would
still be ticking for it and this time would incorrectly be included in
the duration for that thread.

That won't be incorrectly though, as the standard specifies for
class std::chrono::steady_clock that it measures physical time, not CPU time or any other time. See here under [time.clock.steady]:

std::chrono::steady_clock

Objects of class steady_­clock represent clocks for which values of
time_­point never decrease as physical time advances and for which values of time_­point advance at a steady rate relative to
real time ...

steady_­clock

time_­point

time_­point

That said, your code looks fine in that it will give you the time measured for each thread run. Is there a reason for you to want to measure CPU time here? If so then let me know in the comments.

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.