现代CPU核心频率动态变化，无法通过/sys或/proc等接口获取精确周期；scaling_cur_freq、cpu MHz、WMI CurrentClockSpeed等均为估算值，误差大且非实时；需用PMU硬件事件（如CYCLES_UNHALTED）直接统计，而非换算频率。
没有直接的“CPU核心频率与周期关系”可编程获取——因为现代CPU的时钟周期不是固定值，频率动态变化，TSC（时间戳计数器）也不再等价于物理周期数。所谓“频率 × 周期 = 1”在运行时几乎不成立。
Linux 下读 scaling_cur_freq 得到的是 kHz，不是周期数
Linux 内核通过 /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 返回当前核心上报频率，单位是 kHz（比如 2400000 表示 2.4 GHz）。它本质是 cpufreq 驱动向内核提交的“目标频率”，不是实时硬件周期测量值。
- 该值不能用于反推单条指令耗时：现代 CPU 有乱序执行、分支预测、缓存命中/未命中等影响，指令周期远非线性
- 读到
0不代表停转，大概率是核心处于 C-state 深度睡眠或驱动未上报（如 intel_pstate 默认禁用scaling_cur_freq） - 不要用它除以
1e9算“纳秒级周期”——误差常达 ±20% 以上，尤其在 Turbo Boost 或节能策略下
Windows 上 CurrentClockSpeed 和 TSC 完全脱钩
WMI 的 Win32_Processor.CurrentClockSpeed 字段返回 MHz 整数，但它是固件/驱动周期性上报的估算值，更新延迟通常 500–2000 ms；而 __rdtsc() 读取的是 invariant TSC（若 CPU 支持），其步进速率恒定，与当前核心频率无关。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
QueryPerformanceFrequency()返回的是高精度计时器频率（通常 10 MHz 或更高），和 CPU 主频毫无关系 - 试图用
__rdtsc()两次差值除以QueryPerformanceCounter()时间差来“反推频率”，会因调度延迟、中断、C-state 退出抖动导致结果不可信 - 即使启用
invariant TSC（CPUID.80000007H:EDX[4]置位），TSC 也只是单调递增计数器，不代表物理周期
别把 cpu MHz 当真，它只是 /proc/cpuinfo 的估算快照
/proc/cpuinfo 中的 cpu MHz 字段是内核在最近一次调度 tick 时对当前核心频率的粗略估算，刷新间隔通常 10–100 ms，且只采样一个核心（通常是 cpu0）。
立即学习“C++免费学习笔记（深入）”；
- 该值可能滞后真实频率变化 100+ ms，无法反映瞬时 boost 或降频事件
- 容器、KVM 虚拟机、某些云主机（如 AWS Nitro）中该字段常被虚拟化层固定为标称值，完全失真
- 它不提供周期信息——你拿到的是 MHz，不是 “每周期多少纳秒”，更不是指令级延迟指标
真正需要周期级精度（比如性能剖析、微基准测试），必须用硬件 PMU（Performance Monitoring Unit）事件，如 INSTRUCTIONS_RETIRED、CYCLES_UNHALTED，配合 perf_event_open()（Linux）或 QueryThreadCycleTime()（Windows，仅限线程级累计）。这些接口返回的是事件计数，不是频率换算值——这也是为什么所有专业性能工具（perf, VTune, Instruments）都绕开“频率→周期”转换，直接统计事件比。
