小心了！ Unixbench浮点运算性能压测有坑！
背景
在测试某台服务器（非虚拟机）的基准性能时，我们发现 Unixbench 的某个性能指标低于基准值，低的还不少，有约 20%。
CPU 进入到 C6 状态时，会关闭更多的 Oncore 组件，同时也会清空 Uncore 的 cache，关闭时钟。这么做带来的好处是省电，但是同时也会带来更长的恢复时延（默认情况下，服务器都会避免出现 CState > C1 的情况以减少服务时延抖动等问题）。
难道是因为 CPU 更多的进入到大于 C1 的模式而导致 CPU 响应延迟增加，进而最终导致性能的降低吗？
实际跑测试程序时，用工具 turbostat 和 i7z 跟踪 Whetstone 运行时 CPU 的状态，奇怪的是，两种情况下，CPU 都是运行在 C0 状态，也就是说，CPU 绝大部分的状态是执行态，全速运行，因为 CPU 状态切换而导致的延迟几乎没有。另外一个现象是，开启 C6 Cstate 的服务器（以下以 C0C1C6 表示支持深度睿频设置的服务器，C0C1 表示固定睿频设置的服务器），运行压测程序的 CPU 主频反而更高（ 3580 MHz > 3098 MHz）。
Intel 的睿频技术是在处理器功耗设计允许的范围内，短期的抬高 CPU 的核心频率，提升计算性能，但是持续时间并不会很长，因此超频出来的计算能力并不可持续，至少在秒级别是如此（目前较新的 Intel CPU 支持部分 CPU 核心的稳定睿频，这个是一个深刻的话题，待后续研究）。
现在问题很明显了，Whetstone 通过简单的预估 CPU 频率的方式，拟合出一个预估的、固定的 CPU 频率值，并转化成压测的计算量，这种方式显然没有考虑到频率可变的情况，计算的结果自然也不一致不可信。
这也不奇怪，因为 Unixbench 已经存在超过 20 年了，而 GitHub 上的 Whetstone 源码最后的提交日期是十年以前了，没有考虑到 CPU 架构变化和 turbo boost 带来的频率变化等问题也属正常。
首先，Whetstone 的内部实现上是包含了 8 种测试，每种测试都会输出一个时间结果绘制到上图中，用 N1~N8 表示（ 其中 N4 因为是整形计算，结果忽略）。上图在相同计算量下的耗时比较来看，支持更高的 turbo boost 睿频的CPU耗时更短，计算性能是更佳的。
其次，在计算量较小，如图横坐标为 4500 以下时，所有测试的结果（耗时）都是线性的，而当横坐标超过 4600 之后，情况发生了转变，N8（sqrt/exp/log）压测的时长出现较大幅度的增长，影响了总体压测耗时的线性关系。这个问题是个还需要进一步分析，目前估计是和计算的数值范围导致处理的代码走入另外的分支，代码量变化有关系，具体还要测试和看看 glibc/math 库的实现。
在此文所述的案例中，C0C1C6 实际的计算性能是更出色的（单核情况下）。但是由于Whetstone在启动阶段预估的 xtra 变量比 C0C1 时的更大，导致其运行的计算指令数更多；另外一方面，Whetstone 最终针对 C0C1C6 设置的 xtra 约为 5700，而 C0C1 的 xtra 约为 4800，此时已经落入了上图的非线性区，C0C1C6 得出的压测结果实际上是偏低的。
