c++oding="utf-8" ?>
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 实现中都可靠。
实操写法：
#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<:chrono::microseconds>(duration).count();
std::cout </:chrono::microseconds></p>
<ul>
<li>不要用 <code>time_since_epoch()</code> 转成绝对时间再减——多此一举，还可能溢出</li>
<li>避免用 <code>double</code> 转换（如 <code>duration.count() * 1e-6</code>），整数 cast 更快、无浮点误差</li>
<li>若需毫秒/秒级输出，用 <code>milliseconds</code> 或 <code>seconds</code> 替换 <code>microseconds</code> 即可</li>
</ul>
<h3>如何验证你拿到的是真纳秒级 Wall Time？</h3>
<p>光看类型没用，得看实际分辨率。可用以下代码探测：</p>
<pre class="brush:php;toolbar:false;">auto res = std::chrono::steady_clock::period::num
/ static_cast<double>(std::chrono::steady_clock::period::den);
std::cout <ul>
<li>输出 <code>1e-09</code> 表示理论纳秒级（常见于 Linux x86_64）</li>
<li>输出 <code>1e-07</code> 或更大（如 Windows 上常见 <code>1e-07</code>），说明底层用的是 QueryPerformanceCounter 低频采样，实际抖动可能达 10–15μs</li>
<li>此时别硬凑纳秒输出——用 <code>microseconds</code> cast 更诚实</li>
</ul>
<h3>高频测量时容易踩的坑</h3>
<p>单次测量误差 > 100ns 很常见，尤其在短代码块（</p>
<ul>
<li>编译器可能优化掉空循环或纯计算块（加 <code>volatile</code> 或用 <code>asm volatile("" ::: "memory")</code> 防止）</li>
<li>CPU 频率动态缩放（turbo boost / P-state）会导致同一段代码多次运行时间差异达 2–3×</li>
<li>没做 warmup：第一次调用可能触发 TLB miss、cache miss、分支预测器冷启动</li>
<li>没重复多次取最小值或中位数：单次结果受中断、调度干扰太大</li>
</ul>
<p>简单防干扰建议：循环测 100 次，丢弃首 10 次，取剩余中位数。</p>
<p>真正难的不是调哪个 clock 函数，而是理解 “Wall Time” 在不同负载、不同内核调度策略、不同 CPU 微架构下的物理意义是否一致——哪怕用了 <code>steady_clock</code>，在容器里跑、开了 cgroup 限频、或遇到 SMT 抢占，测出来的“时间”也未必反映纯粹的硬件流逝。</p></double>C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
