high_resolution_clock不适合测Wall Time，因为它不保证单调性，可能受系统时间调整影响而跳变；实际中Windows下常退化为system_clock，Linux下多alias到steady_clock，macOS存在调度抖动。
用 std::chrono::high_resolution_clock 测 Wall Time 是可行的，但必须注意它不保证是单调时钟，且在某些平台（如 Windows + MSVC）可能退化为 steady_clock 或存在微秒级抖动——真要精确测代码块耗时，优先选 steady_clock。
为什么 high_resolution_clock 不适合测 Wall Time？
它名义上“高精度”，但标准只要求它是三个时钟（system_clock、steady_clock、high_resolution_clock）中“分辨率最高”的那个，没规定它必须是单调的。实际中：
- Linux GCC：常 alias 到
steady_clock（OK） - Windows MSVC：常 alias 到
system_clock（受系统时间调整影响，clock_gettime(CLOCK_REALTIME)级别） - macOS Clang：行为依赖 libc++ 实现，有时返回纳秒但有 10–15ms 的调度抖动
也就是说，如果你的代码块执行期间系统时间被 NTP 调整了，high_resolution_clock::now() 可能跳变，导致负值或异常大值。
正确做法：用 steady_clock 测 Wall Time
Wall Time 指的是真实流逝的物理时间，只要求单调、稳定、不受系统时钟修改影响——这正是 steady_clock 的设计目标。它基于硬件计数器（如 TSC、HPET），精度通常达纳秒级，且在所有主流 STL 实现中都可靠。
立即学习“C++免费学习笔记（深入）”；
实操写法：
#include <chrono> #include <iostream> <p>auto start = std::chrono::steady_clock::now(); // ... your code block ... auto end = std::chrono::steady_clock::now();</p><p>auto duration = end - start; auto microseconds = std::chrono::duration_cast<std::chrono::microseconds>(duration).count(); std::cout << "Wall time: " << microseconds << " μs\n";
- 不要用
time_since_epoch()转成绝对时间再减——多此一举，还可能溢出 - 避免用
double转换（如duration.count() * 1e-6），整数 cast 更快、无浮点误差 - 若需毫秒/秒级输出，用
milliseconds或seconds替换microseconds即可
如何验证你拿到的是真纳秒级 Wall Time？
光看类型没用，得看实际分辨率。可用以下代码探测：
auto res = std::chrono::steady_clock::period::num
/ static_cast<double>(std::chrono::steady_clock::period::den);
std::cout << "Resolution: " << res << " seconds\n";
- 输出
1e-09表示理论纳秒级（常见于 Linux x86_64） - 输出
1e-07或更大（如 Windows 上常见1e-07），说明底层用的是 QueryPerformanceCounter 低频采样，实际抖动可能达 10–15μs - 此时别硬凑纳秒输出——用
microsecondscast 更诚实
高频测量时容易踩的坑
单次测量误差 > 100ns 很常见，尤其在短代码块（
- 编译器可能优化掉空循环或纯计算块（加
volatile或用asm volatile("" ::: "memory")防止） - CPU 频率动态缩放（turbo boost / P-state）会导致同一段代码多次运行时间差异达 2–3×
- 没做 warmup：第一次调用可能触发 TLB miss、cache miss、分支预测器冷启动
- 没重复多次取最小值或中位数：单次结果受中断、调度干扰太大
简单防干扰建议：循环测 100 次，丢弃首 10 次，取剩余中位数。
真正难的不是调哪个 clock 函数，而是理解 “Wall Time” 在不同负载、不同内核调度策略、不同 CPU 微架构下的物理意义是否一致——哪怕用了 steady_clock，在容器里跑、开了 cgroup 限频、或遇到 SMT 抢占，测出来的“时间”也未必反映纯粹的硬件流逝。
