C++如何实现支持跨平台的高精度单调时钟类？（性能基准测试基础）

应优先使用 std::chrono::steady_clock 测量性能，因其跨平台、单调、不随系统时间跳变；避免误用 system_clock 或 high_resolution_clock，并防止编译器优化待测代码。

用 std::chrono::steady_clock 就够了，别自己封装

标准库的 std::chrono::steady_clock 就是为此而生的：跨平台、单调、不随系统时间调整跳变、精度足够做性能基准。windows 上它底层调用 QueryPerformancecounter，linux/macos 通常映射到 CLOCK_MONOTONIC，所有主流编译器都支持。自己用 gettimeofday、clock_gettime 或 WinAPI 手写反而容易出兼容性问题。

常见错误现象：std::chrono::system_clock 被误用——它可能因 NTP 校时或手动改系统时间而倒退或跳跃，导致基准测试结果负值或剧烈抖动；std::chrono::high_resolution_clock 在部分旧版 libstdc++（如 GCC 4.8）中只是 system_clock 的别名，不保证单调。

• 始终优先用 std::chrono::steady_clock，不是“高精度”就一定更好
• 避免依赖 high_resolution_clock，它的语义在 c++11/14 中未严格规定
• 构造时不要用 time_since_epoch() 直接转整数——不同平台 epoch 基准不同，只用于相对差值

如何安全地测一段代码的耗时（纳秒级）

核心是避免编译器优化掉待测逻辑，同时防止时钟调用本身引入显著偏差。直接用 steady_clock::now() 两次取差是最轻量、最可靠的方式。

使用场景：微基准（microbenchmark），比如比较两个 memcpy 实现、测量 hash 函数单次开销。

立即学习“C++免费学习笔记（深入）”；

• 必须把待测代码放在 volatile 变量读写之间，或用 asm volatile("" ::: "memory") 内存栅栏（GCC/Clang），否则编译器可能整个优化掉
• 不要用 auto start = steady_clock::now() 然后 duration_cast<nanoseconds>(end - start).count()</nanoseconds> —— count() 返回的是 rep 类型（可能是 long long 或 int64_t），直接打印或参与计算前先确认是否溢出
• 单次测量意义不大，至少跑 3–5 次取最小值（排除缓存预热、TLB miss 等偶然干扰）

auto start = std::chrono::steady_clock::now(); // volatile dummy = do_work(); // 防优化 do_work(); auto end = std::chrono::steady_clock::now(); auto ns = std::chrono::duration_cast<std::chrono::nanoseconds>(end - start).count();

Windows 下 QueryPerformanceCounter 还有必要手撸吗？

没必要。除非你卡在非常老的环境（如 VS2010 + Windows XP），且明确测出 steady_clock 精度不足（比如只到 15ms），否则手调 QueryPerformanceCounter 只会增加维护成本和出错概率。

容易踩的坑：QueryPerformanceFrequency 返回值可能为 0（极罕见但存在），或在某些虚拟机里频率不稳定；LARGE_INTEGER 直接相减若没处理符号位，会导致巨大正数；不同 CPU 核心的 TSC 不同步（启用 QPC 时系统已处理，但旧驱动可能失效）。

• 现代 MSVC（2015+）和 libc++/libstdc++ 都已正确封装 QPC，steady_clock::now() 就是它
• 若真要手撸，务必检查 QueryPerformanceFrequency(&freq) 返回值，且用 __emul64 或 Int128 处理 64×64 除法避免截断
• 不要用 GetTickCount64 替代——它只有 1–15ms 分辨率，且非单调（可能回绕）

跨平台构建时要注意的 ABI 和编译器差异

steady_clock 的实现细节由标准库决定，不是语言本身保障的。同一份代码在 GCC、Clang、MSVC 下行为一致，但若混用不同标准库（如 Linux 上用 libc++ 编译却链接 libstdc++ 的 .so），时钟对象可能不兼容。

性能影响：所有主流实现都是无锁、寄存器级指令（RDTSC、cntvct_el0 等），调用开销稳定在 20–50 纳秒，远低于任何 syscall。

• 确保 CMake 中 set(CMAKE_CXX_STANDARD 17) 或更高，C++11 是底线，但 C++17 起 steady_clock 必须是单调的
• android NDK r21+ 默认用 libc++，旧版本可能 fallback 到不稳定的 clock_gettime(CLOCK_MONOTONIC)，需显式指定 -DANDROID_STL=c++_shared
• 嵌入式平台（如 ARM Cortex-M）若无硬件定时器支持，steady_clock 可能退化为毫秒级 tick，此时得查 BSP 是否提供 HAL_GetTick 类接口

真正麻烦的从来不是选哪个时钟，而是确保待测代码不被优化、内存访问不被重排、CPU 频率不动态缩放（需要 sudo cpupower frequency-set -g performance）、以及每次测量都清除 cache 和分支预测器状态——这些比时钟本身难控制得多。