使用 std::chrono::steady_clock 在线程/异步中对代码进行基准测试

Question

假设我有很多计算要在多个线程中运行（以及基准 CPU 时间）。作为一个玩具示例：

#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;
    }
}

我担心因为steady_clock is montonic across threads 基础时钟按进程而不是每个线程滴答（如果安排了任何线程，则时钟滴答为所有 线程）。这意味着如果一个线程正在休眠，steady_clock 仍会为它打勾，而这一次将错误地包含在该线程的duration 中。我的怀疑正确吗？还是steady_clock 仅针对线程内的线程 CPU 时间打勾？

换一种说法，这种方法是否是一种独立计时大量计算的安全方法（这样在一个线程上花费的 CPU 时间不会影响另一个线程的duration）？或者我是否需要为每个计算分离单独的进程以使 steady_clock 仅在计算运行/计划时打勾？

编辑：我也认识到，与内核相比，旋转更多的线程可能是解决此问题的低效方法（尽管我并不特别关心计算吞吐量；此外，我只想要它们作为一个小组以最快的时间完成）。我怀疑在实践中，我需要维护一个小常数的有界线程列表（比如限制在核心数量），并且只有在核心可用时才开始新的计算。但是，这不应该对我上面关心的时间产生影响；它应该只影响挂钟时间。

Answer 1

标准规定steady_clock 模拟物理时间（相对于CPU时间）。

来自 [time.clock.steady]：

steady_clock 类的对象表示时钟，其 time_point 的值不会随着物理时间的增加而减少，time_point 的值相对于实时以稳定的速率增加。也就是说，时钟可能无法调整。

话虽如此，实现对物理时间建模的程度是一个 QOI 问题。不过，您的代码对我来说看起来不错。

如果您的实验结果不令人满意，<chrono> 的客户还可以创建自己的自定义时钟，这些时钟将在 <chrono> 库中具有一流的地位。

Answer 2

这意味着如果一个线程正在休眠，steady_clock 将 仍在为它打勾，这次将错误地包含在 该线程的持续时间。

这不会是错误，正如标准所规定的那样 std::chrono::steady_clock 类，它测量物理时间，而不是 CPU 时间或任何其他时间。请参阅[time.clock.steady] 下的此处：

steady_­clock 类的对象表示时钟，其值为 time_­point 永远不会随着物理时间的推移而减少，并且time_­point 的值相对于 实时...

也就是说，您的代码看起来不错，因为它将为您提供每个线程运行所测量的时间。你有理由想在这里测量 CPU 时间吗？如果是这样，请在 cmets 中告诉我。