rdtsc是最直接的CPU周期级计时方案，因其直接读取硬件时间戳计数器且不依赖系统时钟或内核调度；但需配合cpuid序列化、核心绑定、禁用动态调频等措施保障精度。
为什么 rdtsc 是最直接的方案
在 x86/x64 Linux 或 Windows 上，想精确到 CPU 周期级别测一段代码耗时，rdtsc（Read Time Stamp Counter）指令是唯一能直接返回当前 CPU 周期数的硬件机制。它不依赖系统时钟、不受调度器干扰，也不经过内核——只要你在同一物理核心上运行且关闭频率缩放，结果就接近真实周期数。
但要注意：rdtsc 返回的是自上电以来的累计周期数，不是 wall-clock 时间；它在多核、超线程、动态调频（如 Intel SpeedStep）下会不准；现代 CPU 还可能乱序执行导致读取时机偏移。
实操建议：
- 用
cpuid指令序列化前后，避免指令重排影响计数精度：cpuid; rdtsc - 绑定线程到单个 CPU 核心（Linux 用
taskset -c 0 ./a.out，Windows 用SetThreadAffinityMask） - 临时禁用 Turbo Boost 和变频（如 Linux 下写
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor为performance） -
rdtsc在某些虚拟机中被禁用或模拟，返回值不可靠——务必在裸金属或支持 TSC virtualization 的 VM 中测试
C++ 中怎么安全调用 rdtsc
不能直接写汇编裸调——不同编译器、ABI、优化等级下寄存器使用规则不同。推荐用内联汇编封装成函数，并强制输出到 uint64_t。
立即学习“C++免费学习笔记（深入）”；
GCC/Clang 示例：
static inline uint64_t rdtsc() {
unsigned int lo, hi;
__asm__ volatile ("cpuid\n\t"
"rdtsc" : "=a"(lo), "=d"(hi) :: "rax", "rbx", "rcx", "rdx");
return ((uint64_t)hi << 32) | lo;
}
MSVC 对应写法（需启用内联汇编，仅 x86）：
static inline uint64_t rdtsc() {
uint64_t t;
__asm {
cpuid
rdtsc
mov dword ptr[t], eax
mov dword ptr[t+4], edx
}
return t;
}
关键点：
- 必须加
volatile，否则编译器可能把rdtsc移出待测区域 - 输出约束要明确指定
"=a"(lo), "=d"(hi)，不能只写"=r"——rdtsc固定输出到eax:edx - 不要用
__rdtsc()内建函数（如 MSVC 的），它不带cpuid序列化，测小段代码时误差常达百周期以上
测什么？怎么避免常见偏差
你真正想测的往往不是“整段函数”，而是其中几行关键计算逻辑。但直接在前后插 rdtsc()，很容易把分支预测失败、缓存未命中、寄存器压力等间接开销也算进去，尤其当被测代码太短（
实用做法：
- 把待测代码放在循环里重复 N 次（N ≥ 1000），测总周期再除以 N——摊平测量噪声和固定开销
- 每次循环前加
cpuid，但只在循环外做一次rdtsc起始和结束，否则cpuid本身也占周期 - 避免测含内存分配、系统调用、锁、函数调用的代码——这些行为会跳出 CPU 流水线，周期数失去可比性
- 用
__builtin_ia32_lfence()（GCC）或_mm_lfence()（Intel intrinsics）替代部分cpuid，开销更小但序列化强度略弱
替代方案：perf_event_open 更可靠但更重
如果你在 Linux 上，且需要跨核心、跨 CPU、或长期稳定监控，perf_event_open 系统调用 + PERF_COUNT_HW_CPU_CYCLES 是更健壮的选择。它由内核统一管理 TSC 映射，自动处理频率切换补偿（启用 freq mode 后），还能过滤中断、上下文切换等干扰。
但它不是“周期计数器”而是“性能事件计数器”，有如下限制：
- 每次调用涉及一次系统调用，开销约 100–300 周期，不适合测
- 需要
CAP_SYS_ADMIN或/proc/sys/kernel/perf_event_paranoid≤ 2 - 返回值是“硬件周期事件发生次数”，不是绝对 TSC 值，无法做差值得到精确区间周期
- 必须用
ioctl(fd, PERF_EVENT_IOC_ENABLE)/DISABLE控制采样窗口，不能像rdtsc那样自由插桩
真要高精度、低开销、可控性强，rdtsc 加严格环境控制仍是首选。只是别忘了：TSC 不是万能尺子，它是 CPU 内部的一个计数器，而你的代码运行效果，终究取决于 cache line 对齐、分支预测器状态、甚至上一条指令的尾部——这些，没有哪个计数器能替你看到。
