不可靠。cpu mhz是内核采样值，受dvfs影响实时波动，非标称频率，也不代表硬件能力，可能为0，仅适用于粗略监控。
Linux 下读取 /proc/cpuinfo 中的 cpu MHz 是否可靠？
不可靠。cpu MHz 是内核在采样时刻报告的当前运行频率，受 DVFS（动态电压频率调节）影响，会随负载、温度、电源策略实时波动，不是标称频率，也不代表硬件最大能力。它甚至可能为 0（如 CPU 空闲时被降频至最低档）。
实操建议：
- 仅用于粗略监控或调试参考，不能用于精确计时、性能建模或周期数换算
- 若需稳定值，应读取
model name后查 CPU 型号文档，或用scaling_cur_freq（来自/sys/devices/system/cpu/cpu0/cpufreq/）配合scaling_max_freq判断当前策略上限 - 注意：不同核心可能报告不同值（尤其在 big.LITTLE 架构），需遍历所有
cpuN目录
Windows 上用 QueryPerformanceFrequency 能拿到 CPU 周期频率吗？
不能。QueryPerformanceFrequency 返回的是高精度性能计数器（HPET 或 TSC 经校准后）的**滴答频率**，单位是 Hz，但它不等于 CPU 主频。TSC 在现代 CPU 上通常是恒定不变的（constant_tsc flag），但其频率未必等于标称主频——例如某些 Intel CPU 的 TSC 运行在基础频率（base frequency），而非睿频（turbo）频率；AMD 部分型号则可能按倍频 × 参考时钟（如 100 MHz）计算。
实操建议：
- 该 API 适合测量时间间隔，不适合反推 CPU 周期数
- 若真要估算当前 TSC 对应的等效频率，可用
RDTSC+GetTickCount64差值做短时采样（但误差大、受中断干扰） - 更稳妥的方式是调用 WMI：
Win32_Processor.MaxClockSpeed（返回标称最大频率，单位 MHz，只读，无实时性）
跨平台获取标称最大频率的实用方法（非实时）
没有标准 C++ 接口能直接获取“当前 CPU 周期频率”，因为这本身是个模糊概念：硬件无统一定义，“当前”指瞬时值还是策略上限？是否含 turbo？是否考虑多核异构？因此工业实践普遍退而求其次，取设计规格值。
实操建议：
- Linux：解析
/sys/devices/system/cpu/cpu0/topology/core_cpus_list确认核心拓扑，再读/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq（单位 kHz），除以 1000 得 MHz；注意该值受cpupower策略限制，未必等于 CPU datasheet 标称值 - macOS：用
sysctlbyname("hw.cpufrequency_max", &freq, &size, nullptr, 0)，返回 uint64_t（Hz），通常对应 turbo 频率 - Windows：WMI 查询
Win32_Processor类的MaxClockSpeed字段（MHz），或用GetSystemInfo配合 CPUID 指令手动解码（复杂且需内联汇编） - 注意：所有这些值都是静态配置项，不代表运行时实际周期速率；真正做低延迟或周期级编程（如嵌入式、内核模块），必须用
RDTSC/RDTSCP配合已知时间基准做在线校准
为什么不能用 std::chrono::high_resolution_clock 反推 CPU 频率？
因为 std::chrono::high_resolution_clock 是类型别名，在各平台实现不同：GCC/Clang 下常映射到 clock_gettime(CLOCK_MONOTONIC)（基于内核时钟源，如 HPET 或 arch_timer），而非 TSC；MSVC 下可能映射到 QueryPerformanceCounter。它屏蔽了底层计数器细节，无法暴露原始周期数。
实操建议：
- 不要尝试用两次
now()差值除以纳秒数来“倒推”频率——结果毫无物理意义 - 若需周期级精度，C++20 起可考虑
<version></version>和编译器内置（如 GCC 的__builtin_ia32_rdtsc），但需自行处理序列化（加RDTSCP或lfence）和跨核一致性 - 真实场景中，绝大多数性能分析工具（perf、VTune、Xcode Instruments）都绕过“频率”抽象，直接采集 TSC 差值并结合内核提供的时钟源偏移做校准
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
