小心了！ Unixbench浮点运算性能压测有坑！

背景

在测试某台服务器（非虚拟机）的基准性能时，我们发现 Unixbench 的某个性能指标低于基准值，低的还不少，有约 20%。

Whetstone 压测分值低

正常的结果本来是这个亚子的。

Whetstone 压测基准值

经过一顿排查，最后发现：

（1）睿频会提高 CPU 浮点等纯计算的性能，但是提高得不多，约 10%~20% 左右，而且可能和负载有一定关系；

（2）上述问题的本质是因为 Whetstone 这个压测程序的缺陷导致的。

虽然得到了一些初步的结果，但是有关 CPU 层面的分析和压测，都是硬核知识，这里尚未触及到皮毛，故在此抛砖引玉一下。

初步测试和分析

由于这些指标涉及的是 CPU 浮点计算性能，通过 perf 和火焰图分析，性能瓶颈不在内核态，用户态也没有异常的热点。

通过 turbostat 和 i7z 工具排查，发现该服务器存在动态睿频，幅度较大。

C0C1C6 turbostat

查看其启动参数，未添加“intel_idle.max_cstate=1 intel_pstate=disable”的参数。加入这两个启动参数之后，重启服务器，CPU的频率和状态也稳定。

C0C1 turbostat

再测试，得到的结果是符合预期。

这里我们补充一下此次测试的服务器 CPU 型号，如下图。

CPU 型号

进一步测试

现在的变量就落在了开关这两个参数上。从 i7z 的监控图可以发现区别，未加参数时，CPU 默认会支持 C0/C1/C6 的Cstate 状态，C0 一般就是 CPU 核在执行指令，也就是工作状态，而当没有指令执行，CPU 会切换到 C1 甚至是 C6 状态。Cstate 的具体描述可以从 Intel 的官方手册中看到。

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）。

C0C1C6 i7z

C0C1 i7z

这里就有疑问了，按理说，参与运算的 CPU 主频越高，性能应该会更好才对，那为什么在 C0C1C6 上实测的 Whetstone 却给出了较低的分数呢？

带着疑问，我们用 perf stat 命令分别抓取了 Whetstone 程序的执行信息，统计发现较大的差异发生在用户态指令数 instruction:u，指令数差了一倍多，而执行时间上，多了 50%。

C0C1C6 perf instuction:u

C0C1 perf instuction:u

开关了上述内核启动参数，就会导致相同的执行程序在指令总上出现差异，看着像是CPU在故意捣乱，加塞了很多指令？这确实有些令人费解。但是Edwin 金总说了，perf 统计的 instruction 数据，是指 CPU retired instruction 的个数。事实确实如此，指令的多少还是主要受控于具体的程序，CPU 不会因为频率变化，产生程序之外的指令（除非是 exception 一类的，那是另外一回事了）。那么问题就应该在 Whetstone 程序了，通过分 其实现源码，我们找到了差异的原因。

初步的结果

原来 whetstone 在执行浮点计算压测之前，有一个固定的步骤是预估待测 CPU 的主频，然后估算出一个工作量（保存在 xtra 变量里）给到压测函数中，再执行压测函数，最后综合 xtra 和压测函数的耗时，得出一个比率即为 CPU 的浮点计算性能值。xtra 的取值特点是：随着预估频率的增大而增大，目的是在一个足够宽的时间段内，压测出一个相对稳定可靠的浮点计算性能值。下图就是作者的注释（居然是在奔腾系列的测试例子，这年代有点久远哈）。

Whetstone 作者注释

这种单一的预估结果来拟合 CPU 的执行频率，也许在早期固定频率的 CPU 上使用是有效的。但是时至今日，情况已经发生了改变。目前，睿频技术已普遍应用，早在 2008 年，Intel 就在其 core i7 处理器中引入了 turbo boost 技术。

Intel 的睿频技术是在处理器功耗设计允许的范围内，短期的抬高 CPU 的核心频率，提升计算性能，但是持续时间并不会很长，因此超频出来的计算能力并不可持续，至少在秒级别是如此（目前较新的 Intel CPU 支持部分 CPU 核心的稳定睿频，这个是一个深刻的话题，待后续研究）。

现在问题很明显了，Whetstone 通过简单的预估 CPU 频率的方式，拟合出一个预估的、固定的 CPU 频率值，并转化成压测的计算量，这种方式显然没有考虑到频率可变的情况，计算的结果自然也不一致不可信。

这也不奇怪，因为 Unixbench 已经存在超过 20 年了，而 GitHub 上的 Whetstone 源码最后的提交日期是十年以前了，没有考虑到 CPU 架构变化和 turbo boost 带来的频率变化等问题也属正常。

Unixbench/master on Github

验证

接下来，我们修改了 Whetstone 的源码，主动控制 Whetstone 的 xtra 变量，经过多次运行、采样和统计，我们得到下面两张图（横坐标是计算量 xtra，纵坐标是 Whetstone 压测程序的耗时 secs）。

首先，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 得出的压测结果实际上是偏低的。