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

Question

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?

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?

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.

Answer 1

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

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.

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.

Answer 2

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]:

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 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.