Reno5 Pro+艺术家限量版图片欣赏：首款电致变色量产手机，到底有多酷？
06-21
背??景 在测试某台服务器（非虚拟机）的基准性能时，我们发现Unixbench的某性能指标比基准值低很多，大约在20%左右。油石压力测试成绩低的正常结果最初归功于这个子。
经过检查Whetstone压力测试基准值，我们最终发现：（1）睿频会提高CPU浮点等纯计算的性能，但幅度不大，大约10%~20%，可能与此有关与负载。 ; （2）上述问题的本质是油石压测程序存在缺陷造成的。
虽然已经取得了一些初步成果，但CPU层面的分析和压测都是硬核知识。这里我们还没有触及表面，所以我在这里简单介绍一下。
初步测试分析：由于这些指标涉及CPU浮点计算性能，通过perf和火焰图分析，性能瓶颈不在内核态，用户态也没有异常热点。通过使用turbostat和i7z工具排查，发现服务器存在动态turbo频率，幅度较大。
C0C1C6 Turbostat 检查其启动参数，未添加参数“intel_idle.max_cstate=1 intel_pstate=disable”。添加这两个启动参数后，重新启动服务器，CPU频率和状态就会稳定。
C0C1涡轮增压器再次进行测试，结果符合预期。这里我们添加本次测试的服务器CPU型号，如下图。
为了进一步测试CPU模型，当前变量落在开关的两个参数上。从i7z的监控图可以发现差异。
当不添加参数时，CPU默认支持C0/C1/C6的Cstate状态。 C0一般是CPU核执行指令，也就是工作状态。
当没有指令执行时，CPU就会进行切换。到C1甚至C6状态。
Cstate的具体说明可以参见Intel官方手册。当CPU进入C6状态时，会关闭更多Oncore组件，清除Uncore缓存，并关闭时钟。
这样做的好处是省电，但也会带来较长的恢复时延（默认情况下，服务器会避免出现CState>C1的情况，以减少服务时延抖动等问题）。是否是因为CPU更多地进入比C1更大的模式，CPU响应延迟增加，最终导致性能下降？实际运行测试程序时，使用turbostat和i7z工具来跟踪Whetstone运行时CPU的状态。
奇怪的是，这两种情况下，CPU都运行在C0状态，也就是说CPU的大部分状态都是执行状态。全速运行，几乎没有CPU状态切换带来的延迟。
另一个现象是，对于C6 Cstate开启的服务器（以下C0C1C6代表支持深度睿频设置的服务器，C0C1代表固定睿频设置的服务器），运行压力测试程序的CPU频率较高（MHz > MHz） 。 C0C1C6 i7z C0C1 i7z 这里有一个问题。
从逻辑上讲，参与计算的CPU频率越高，性能越好。那么为什么在 C0C1C6 上测量的油石得分较低呢？带着疑问，我们使用perf stat命令来捕获Whetstone程序的执行信息。
统计发现，差异较大的是用户态指令的数量：u。指令数量增加了一倍以上，执行时间也增加了。
50%。 C0C1C6 perf Instrumentation:uC0C1 perf Instrumentation:u 打开和关闭上述内核启动参数会导致同一执行程序的指令总数存在差异。
看起来CPU是故意惹麻烦，塞进很多指令？这确实有些令人费解。但Edwin Jin先生表示，perf统计的指令数据是指CPU退役的指令数。
情况确实如此。指令数量仍然主要由具体程序控制。
CPU不会因为频率变化而产生程序外的指令（除非是异常，那就另当别论了）。那么问题应该出在油石程序上。
通过分析其实现源码，我们找到了差异的原因。初步结果显示，油石在进行浮点计算压力测试之前，有一个固定的步骤，预估待测CPU的主频，然后预估一个工作负载（保存在xtra变量中）交给压力测试函数，然后执行压力测试函数，最后将xtra的耗时与压力测试函数的耗时相结合，得到一个比值，即为CPU的浮点计算性能值。
xtra 的值的特征是随着估计频率的增加而增加。目的是在足够宽的时间段内衡量一个相对稳定可靠的浮点计算性能值。
下图是作者的笔记（其实是Pentium系列的测试例子，有点老了）。 Whetstone 作者指出，这个单一估计用于拟合 CPU 的执行频率，并且可能对早期的固定频率 CPU 有效。
但今天，情况发生了变化。目前，涡轮增压技术已得到广泛应用。
早在2000年，英特尔就在其酷睿i7处理器中引入了睿频加速技术。 Intel的睿频技术就是在短期内提高CPU的核心频率，在处理器功耗设计允许的范围内提高计算性能。
不过持续时间并不是很长，因此超频获得的算力至少是不可持续的。第二层也是如此（目前较新的Intel CPU支持部分CPU核心稳定的睿频频率，这是一个深刻的话题，有待后续研究）。
现在问题就很明显了。 Whetstone只是估算CPU频率，拟合一个估算的、固定的CPU频率值，并将其转换为压力测试的计算量。
这种方法显然没有考虑到可变频率。这种情况下，计算出来的结果自然不一致，也不可靠。
这并不奇怪，因为 Unixbench 已经存在了 20 多年，而 GitHub 上 Whetstone 源代码的最后一次提交日期是十年前。没有考虑到Turbo Boost带来的CPU架构变化和频率变化等问题，这很正常。
Github上的Unixbench/master验证 接下来我们修改了Whetstone的源码，主动控制了Whetstone的xtra变量。经过多次运行、采样、统计，得到以下两张图（横坐标为计算量xtra，纵坐标为油石，压力测试过程耗时为秒）。
首先，Whetstone的内部实现包含8种类型的测试。每次测试都会输出一个时间结果并绘制在上图中，用N1~N8表示（其中N4为整数计算，结果被忽略）。
从上图中相同计算量下的时间消耗对比来看，支持Turbo Boost频率越高的CPU花费的时间越少，计算性能越好。其次，当计算量较小时，当图中横坐标如下时，所有测试的结果（耗时）都是线性的。
当横坐标超过时，情况发生变化，N8(sqrt/exp/log)压测时间明显增加，影响了整体压测时间的线性关系。这个问题需要进一步分析。
目前估计与数值范围的计算导致处理代码进入另一个分支以及代码量的变化有关。具体来说，我们需要测试并查看 glibc/math 库的实现。
在本文描述的案例中，C0C1C6的实际计算性能更好（单核情况）。但由于Whetstone在启动阶段估计的xtra变量比C0C1大，导致运行的计算指令较多；另一方面，油石最终对C0C1C6的xtra为约，而C0C1的xtra为约，这就陷入了上图中的非线性区域，而C0C1C6得到的压力测量结果实际上偏低。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-18
06-21
06-18
06-18
最新文章
【玩转GPU】ControlNet初学者生存指南
【实战】获取小程序中用户的城市信息（附源码）
包雪雪简单介绍Vue.js：开学
Go进阶：使用Gin框架简单实现服务端渲染
线程池介绍及实际案例分享
JMeter 注释 18 - JMeter 常用配置组件介绍
基于Sentry的大数据权限解决方案
【云+社区年度征文集】GPE监控介绍及使用