Dhrystone乱谈

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




某日,在论坛上见两个网友掐 架. A男是藕粉,B男是藕黑.在芙蓉姐姐是否漂亮的问题上争执不下.然后网友C感慨,要是能有一个benchmark来测试人是否漂亮就好了,再也不用争执谁 漂亮谁丑了. 用benchmark一测,得到一个分数,再来一个全国排名,直接印在身份证上. 这下,整个世界清静了.

听完故事,再来看一个广告. 这个是某公司用来忽悠客户的某个CPU IP的参数.

请注意用红线划出来的部分,显示performance 是 2.50 DMIPS/MHz. 如果你是被忽悠的客户,你该如何来看待这个指标呢?

说 DMIPS之前,先说一下在业界比较有名的但是口碑不太好的Dhrystone benchmark.这是诞生在上个世纪80年代的一个用来测试CPU性能的测试用例.把这个benchmark在CPU上一跑,然后看看每秒能跑多少次 这个程序,然后除以1757,从来计算出DMIPS的值.为啥要除以1757呢?因为这个是拿VAX 11/780来做参考的.VAX 11/780每秒能执行1757次的Dhrystone benchmark. 那么来看上面的广告中的2.50 DMIPS/MHz.这个说明Cortex-A9这个IP每秒能跑1757×2.50xFreq=4392.5xfreq 次的Dhrystone程序. 如果Freq为650Mhz的话,那么没秒能跑的Dhrystone程序的次数为4392.5×650=2855125.

听上去不错阿,通过一个benchmrak就能知道不同的CPU之间的性能了.只需要在不同的CPU上都跑这个benchmark,然后比较DMIPS/MHz不就行了吗? 为什么说Dhrystone的口碑不太好呢? 原因就是奸商们滥用了Dhrystone.

上 面我们说在CPU上跑 Dhrystone其实不太准确,准确的说法是在一个系统上跑Dhrystone.这个系统包括硬件如CPU,还包括软件如 OS/Library/compiler. 因此Dhrystone反映的是系统的性能还不单单是CPU的性能. 同时,奸商们为了去忽悠客户,搞应试教育来提高Dhrystone的分数,从来让Dhrystone变得不太那么客观. 通常奸商们使用的方法包括使用特定优化的library.由于在执行Dhrystone 程序的时候,有一些library的函数调用.比如strcpy/strcmp这一类使用比较频繁的函数,如果能有一个优化版本,那么Dhrystone 程序跑起来一定更快. 就象一个富二代和穷二代,输在了起点上,不服气不行阿. 另外,采用优化的编译器也是另外一个方法. 编译器针对Dhrystone做特定的优化,这就相当于考试的时候发现监考的是你家亲戚,爽大了.

另 外,由于微结构的关 系,OS/compiler都会影响到最后的benchmark 得分. 下面来分析一个具体的案例. 在分析案例之前,先给大家出个问题. 现代的CPU的流水线越来越长,那么长的pipeline的好处和缺点是什么? 答不上来的同学复习复习量化. 这个问题也是做CPU相关的公司面试经典问题.

通常来说,长的流水线可以把 CPU的工作切的更细,这样每一个阶段所需要的时间会很少,那 么一个cycle所需要的时间变小,这样就可以提高系统的频率.这个和生产车间细分工种有异曲同工之妙.那么带来的问题是什么呢? CPU和生产车间流水线不同. CPU的执行不是完全顺序的(如果是的话,那该多好阿).在程序中会有各种各样的打乱CPU执行顺序的事情.比如跳转指令. 流水线不喜欢这些指令,因为这会使得已经进入流水线并且已经做了一些事情的指令被flush掉,等于这些工作白做了. 因此长的流水线所带来的问题就是流水线stall带来的代价变大.

那好,了解了流水线的优缺点,下面来说一个案例. 某一款CPU具有18级的流水线,但是其benchmark/MHz的分数反而不如前一代的8级流水线的CPU. 这是为什么呢? 可能的原因大概有这样几个.

(1) 如果CPU的branch prediction预测失败次数比较多,那么长的流水线带来的代价更大
(2) 如果benchmark中跳转指令是寄存器跳转(也就是跳转的目标在寄存器中),那么由于这种情况CPU不能对跳转目标做predict,就回浪费流水线. 长的流水线带来的浪费更大.
(3) TLB缺失的exceptin太多. 长的流水线带来的浪费更大.
(4) benchmark中数据依赖太多
(5) 其他原因(请读者自己补充)

正是由于这一系列的综合因素,导致了太多的流水线stall. 而长流水线对stall比短流水线敏感,导致了benchmark分数/MHz反而不如短的流水线. 当然了由于长流水线能带来更高的频率,因此频率和benchmark/MHz的乘积还是会显著提高的.

那 么即使公平竞争,单纯 Dhrystone用来衡量CPU性能的好坏也是不太恰当的.问题在于Dhrystone benchmark太小,因此能衡量的东西就太少. 吃西瓜吃得快的(如猪八戒)并一定跑步就跑得快. 为了克服Dhrystone的缺点,EEMBC这个机构推出了一系列的benchmark.当然这些都是要收费的.另外,EEMBC还”发扬雷锋精神”, 提供了一个免费的类似于Dhrystone的benchmark,称为CoreMark.其FAQ值得一读.

上述是对Dhrystone以及流水线的一些乱谈的,本文中一定会有一些错误,欢迎大家指出和评论.

(5个打分, 平均:5.00 / 5)

雁过留声

“Dhrystone乱谈”有12个回复

  1. 1help1 于 2010-02-25 7:09 上午

    接触benchmark时间不长,期待大家针对benchmark来点讨论,最好是碰撞。有碰撞是好事,牛顿不也是被碰了一下脑袋瓜子才灵光嘛:)

  2. 陈怀临 于 2010-02-25 7:16 上午

    贤弟,你能否再写一篇综述文章,把CPU方面的各种benchmark的东西简单介绍一下。另外,可以顺便把super computing的东西也cover住。

    不着急,但感觉是个好文章。

  3. 1help1 于 2010-02-25 7:20 上午

    首席,我正有写benchmark 综述的计划。容我些时间 :)

  4. sixshot 于 2010-02-25 5:10 下午

    期待大作

  5. TaoMa 于 2010-02-25 5:24 下午

    “听完故事,再来看一个广告. 这个是某公司用来忽悠客户的某个CPU IP的参数.

    请注意用红线划出来的部分,”
    这个,这个,中间是不是有一副图片?

    linux+firefox 3.5.8, 怎么看不到?

  6. 1help1 于 2010-02-25 6:28 下午

    >linux+firefox 3.5.8, 怎么看不到?

    奇怪,明明之前有图片的. 修正这个问题. Thanks.

  7. 杰克 于 2010-02-25 6:36 下午

    2) 如果benchmark中跳转指令是寄存器跳转(也就是跳转的目标在寄存器中),那么由于这种情况CPU不能对跳转目标做predict,就回浪费流水线. 长的流水线带来的浪费更大.

    这个没有work around吗?

  8. 1help1 于 2010-02-25 6:43 下午

    >这个没有work around吗?
    有.比如, 建立一个table,输入为 寄存器跳转指令的PC,输出为上一次的挑战目标.
    在进行跳转指令的时候,会先lookup这个表.
    有测试表明,这样的方法在某一个IP上大概会有40%的命中率.

    欢迎补充

  9. zhangw 于 2010-02-25 11:39 下午

    高手,您能否把CPU方面的各种benchmark的东西深入介绍一下。我现在一直在做这方面的评测工作,最近由于工作需要也在研究dhrystone和wehtstone,我的邮箱是zhwlove115@163.com,希望大哥不吝赐教,能和小弟通过邮件进一步沟通和交流,小弟感激不尽!!

  10. HornHorn 于 2010-03-05 11:31 上午

    two comments:
    (1) The most popular benchmark for architecture design(for single-threaded) is SPEC. EEMBC is still too toy-like.

    (2) indirect-branch is preditable,
    more results could be found at “Value Based BTB Indexing (VBBI) for Indirect Jump Prediction”

  11. 1help1 于 2010-03-05 9:18 下午

    EEMBC在嵌入式CPU领域say ARM.MIPS,是作为比较重要的benchmark的.

  12. 异步逻辑 于 2012-06-19 5:07 上午

    我也在关注这方面的问题,现在还是没有权威的评测机构和评测程序,都是商家在自卖自夸。