UnixBench的七个影响要素

最新推荐文章于 2024-09-13 22:31:44 发布

weixin_34343000

最新推荐文章于 2024-09-13 22:31:44 发布

阅读量1.3k

点赞数 2

文章标签： shell

原文链接：https://yq.aliyun.com/articles/674732

版权

前面有两篇分别介绍了UnixBench：

UnixBench的实现介绍
UnixBench算分介绍

这次要介绍下不同场景下，为什么分值有差异，有哪些需要考虑：

影响因素

1. CPU PIN住与非PIN住

这个场景主要是与国内云厂商的对比，他们的vm到现在都是非PIN住，也就是说如果在跑多进程业务，他们可以拿到很高的分值，当然也有概率拿到很低的分值。有时候客户会只比较单进程，但是如Shell Scripts (8 concurrent)，其实还是存在并发的，非绝对意义的单进程，所以CPU核数很重要的。
在主频差不多的情况下，那只能拿ECS的入门级实例（也是非PIN住的）对比，那效果差不多。但是我们推荐的是企业级实例，为什么推荐企业级实例（CPU是PIN住的），参考文章：2018云服务器选型指南·计算篇。那如果推荐了企业级实例，UnixBench的分值可能存在差距，但是如果多开几台友商的vm，就有概率测到vm很低分值的（掉到了一个拥挤的物理机）。

2. 主频差异

任何涉及计算相关的，CPU主频都是非常重要的，甚至是决定性因素。主频越高性能越好。
这时候不同云厂商对比性能的时候，一定要分清是高主频还是中主频，不同厂商即使都是中主频，差别也有点大。所以一定要对齐主频差异，才能做正确的对比。那如果对不齐，就只能讲稳定性了。

3. UnixBench算法缺陷一：Pipe-based Context Switching

UnixBench的子算法：Pipe-based Context Switching在不同的云厂商，性能差距巨大，这个算法的本意就是查看父子进程切换的效率。不同云厂商透露的拓扑结构不一样：
_2018_12_04_3_27_29

友商的做法会导致父子进程在同一个CPU，那么进程的切换成本就很低，这项分值就很高，比在物理机的分值还要高，这是一个不合理的现象。本意是要测父子进程在不同的CPU的进程切换效率，那么怎么办呢：对此我们针对这个程序做了一个简单的优化，确保父子进程在不同的CPU执行。具体测试办法：用aliyun版unixbench。下载unixbench.sh,执行它，会解决下载和执行。

   wget https://raw.githubusercontent.com/aliyun/byte-unixbench/master/unixbench.sh
   sh unixbench.sh

这里有一篇深入解析的文章：燕青： Unixbench 测试套件缺陷深度分析

4. UnixBench算法缺陷二：Double-Precision Whetstone

浮点数运算实现介绍，详见UnixBench的实现介绍
前面说了，主频差异会导致性能有差异，主频越高性能越好，而这个浮点数运算则是恰恰相反，高主频性能越差。
原因是：这个算法的本意是计算在这10秒内，能完成的最多的运算量。浮点数运算主要包含了：加减四则运算，条件切换，三角函数，指数运算。算法认为在一定的运算时间呢，这些运算随着运算量的增大，所需要的时间是线性的，所以才能控制在10秒。算法设计当初，估计都没考虑到主频有天能到3.0+GHz，使得最后一项运算量变成这么大。而这时候随着运算量增加，耗时也呈现指数级增加。而高主频的vm恰恰是前面的运算耗时很少，在2秒内可以完成大量运算，经过估算，以至于最后一次指数运算所需时间恰恰不是线性的了。我把最后一段代码抽取出来:
代码如下：

#include <stdio.h>
#include <math.h>

int main(int argc, char *argv[])
{
    long ix, i, xtra = atol(argv[1]), n8 = 93*x100;
    double x = 0.75;
    double t1 = 0.50000025;
    for (ix=0; ix < xtra; ix++)
    {
        for(i=0; i < n8; i++)
        {
             x = sqrt(exp(log(x)/t1));
        }
    }
}

在一台高主频的vm，做单线程运算的耗时统计如下：

| 运算量 | 耗时 |
| -- | -- |
| 1000 | 0.820 |
| 2000 | 1.509 |
| 3000 | 2.216 |
| 4000 | 2.909 |
| 5000 | 6.527 |

从上表可以看出，到超过4000的时候，其耗时已经非线性。那么这个算法是不公平的，高主频的VM运输量偏大，导致耗时增加，性能分下降。可以做一个简单修改，在第一个for循环里面，每次都做初始化x=0.75，那么可以保证其运输量是线性了。

其他影响因素：

编译选项差异：默认是采用gcc编译，如果采用icc编译性能，可以显著提升。dry2stone整数运算，性能可以提升7.9%。
内核参数调整：打开halt polling，可以让Pipe-based Context Switching性能提升一倍多，但是对应功耗也显著提升，默认云厂商好像都不打开该选项。
进程干扰：unixbench都是些非常基础的进程的操作，所以尽可能地减少其他进程干扰，可以达到最好的性能。