谷动谷力

标题: 【嵌入式】不服?跑个分看看!——Coremark篇 [打印本页]

作者: sunsili    时间: 2024-1-22 11:07
标题: 【嵌入式】不服?跑个分看看!——Coremark篇
本帖最后由 sunsili 于 2024-1-22 11:07 编辑

【嵌入式】不服?跑个分看看!——Coremark篇


在计算机领域,很多无意义的论战都会在“不服跑个分看看”的叫嚣中进入下一个阶段:从原本Battle的议题转移为对跑分软件(Benchmark)严谨性和合法性的争论上——随着某些跑分软件陈芝麻烂谷子的黑料重见天日,群里论战的热情达到了最高潮……

这类盛况在PC和手机领域颇为常见。那么有的小伙伴会问了,在枯燥的MCU生态里,有没这样一个往群里大叫一声“不服?跑个分看看”,然后搬个小板凳躲在角落里吃瓜的机会呢?
哎!还真有。这就是大名鼎鼎的Coremark。根据EEMBC的说法:
CoreMark is a simple, yet sophisticated benchmark that is designed specifically to test the functionality of a processor core. Running CoreMark produces a single-number score allowing users to make quick comparisons between processors.
https://www.eembc.org/coremark/
简单来说,Coremark是一个专门测量嵌入式MCU(或者CPU)性能的跑分软件,用来替代已经过时且充满争议的Dhrystone跑分。Coremark包含了一系列算法:列表操作(查找和排序)、常用的矩阵运算、状态机以及CRC——这样做的目的据说是为了克服Dhrystone过于依赖libc库的缺点。官方甚至专门在网页上开辟了一个段落,细数Coremark相对Dhrysone做了哪些改进,感兴趣的小伙伴可以点击去看一看:
https://www.eembc.org/coremark/

这里记住结论就行:Dhrystone低级、过时、踩一脚;Coremark高级拉一把!


【部署CoreMark从未这么简单】
虽然Coremark的源代码在Github上可以直接下载,但拿回家后还需要针对你的目标处理器进行一番移植。总的来说,移植需要解决两类问题:
哎,巧了不是。如果你使用的是Cortex-M处理器,并且习惯了在MDK环境下耕耘,只要借助 perf_counter 的帮助,在RTE里简单的勾选几下就可以迅速的在任意Cortex-M处理器中部署 Coremark。
首先,关于MDK下实现通用的printf功能,请参考文章《【震惊!】MDK下99%用户都不知道的万能printf方法》,这里就不再赘述。
从 v2.0.0开始 perf_counter 内置了 Coremark,并针对Cortex-M处理器完成了几乎所有的移植工作,这意味着你只需要在RTE中勾选对应的模块,即可完成对Coremark的部署(如下图所示):
如果你已经通过往期文章《【喂到嘴边了的模块】超级嵌入式系统“性能/时间”工具箱》熟悉过perf_counter的使用,那么接下来只要在超级循环里加入如下的代码就大功告成了:
  1. #include "perf_counter.h"

  2. int main(void){
  3.         printf("Coremark 1.0\r\n");        
  4.         coremark_main();

  5.        while(1) {
  6.     }   
  7. }
复制代码

对应的运行效果如下(这里以Cortex-M55 r0p0为例,r0p1跑分会更高一些):
可以看到,这里的跑分结果是 4.367429。
如果你之前从未用过 perf_counter,则推荐通过文章《【喂到嘴边了的模块】超级嵌入式系统“性能/时间”工具箱》来了解详细的部署和使用方式。这里就不再赘述。值得特别强调的是,perf_counter 已经加入 KEIL的官方索引列表,因此小伙伴可以直接从 Pack Installer 中找并安装它的最新版本:
如果你的网络不太好,无法通过Pack Installer直接安装,也可以在关注公众号【裸机思维】后向后台发送关键字 perf_counter 来获取网盘链接。

【常见问题】
Coremark虽然简单直接,但在使用上仍然存在一些注意事项:

Coremark跑分的制约因素


一般来说,Coremark的结果肯定会受到以下几个因素的影响:

1. 优化等级
不要奢望 -O0 能跑出多高的结果。但如果你的项目从来都只用 -O0 那么跑Coremark时也一定要用 -O0 ——因为这反应了你使用时候的真实状况。
很多芯片公司和Arm一样都会用最好的编译器在最高的速度优化下跑Coremark,这意味着,我们通常可以在 Arm Compiler 6下使用 -Omax跑出当前硬件平台的最佳结果。
很多小伙伴可能不知道如何在 MDK 环境下使用 -Omax,因为Optimisation 下拉列表中根本没有 -Omax。-Omax 是一个比 -Ofast要更上一个台阶的优化等级(用过都说好),可以说是MDK的一个隐藏技巧:
需要强调的是,一旦在 Misc Controls 文本框中添加了 -Omax,无论你在 Optimization 下拉列表中选择了哪个优化等级,都会被 -Omax 覆盖掉。为了避免误导后来人,推荐在这种情况下在该列表中选择<default>。

2. 程序存储器的速度以及RAM的访问速度
其实用脚指头想也知道:Coremark的跑分会受到存储器访问速度的影响。很多大公司会将程序保存在 0 wait state 的 RAM中来跑 Coremark,以求获得最佳的结果。

我猜很多小伙伴看到这里可能就炸了:我们平时都是在Flash里跑代码,你拿RAM跑出来的数据糊弄我?这不是欺负老实人么?
实际并非如此,原因如下:
1)对很多大公司来说,他要给客户提供理想状况下所能达到的最高评分,方便用户选型的时候了解芯片的能力上限(如果上限都达不到就别勉强了)
2)很多芯片会专门提供用于运行代码的 PRAM、SRAM或者 TCM(Tightly Couple Memory),因此,只要合理安排程序的存储器布局,在核心应用和算法上,的确可以跑出官方给出的最大性能
从另外一个角度来说,以Cortex-M处理器为例,通过Coremark,对比Arm提供的最高跑分,我们可以很容易的评估当前芯片的 Flash速度是否拖累了处理器——从跑分的差异上判断拖累的程度。比如,很多时候,使用片内Flash跑 Coremark、XIP(QSPI)连接的片外Flash 跑Coremark 可以看出巨大的跑分差异,给了我们一个定量判断性能损失的参考手段——注意,只是参考,不是绝对的。
此外,RAM的速度也会对Coremark产生很大的影响,简单来说,0 wait state的 RAM,1~2个wait state 的 RAM以及 SDRAM 跑Coremark的结果是截然不同的——这同样给了我们一个直观感受不同RAM性能差异的参考手段。
3. 是否存在cache
有没有cache,有多大的cache,以及cache覆盖ROM还是RAM对Coremark结果的影响是巨大的。比如,哪怕你用 XIP 来跑 Coremark(或者用SDRAM来存储数据),只要你Cache到位,其跑分几乎和理想状况相差无几。
以上内容用脚趾都能想出来。接下来给大家说一个由cache引起的反直觉的现象:
前面我们说过,如果你想跑出最佳的跑分,就应该使用编译器的最高性能优化,对Cortex-M和Arm Compiler 6来说就是 -Omax + Link Time Optimisation。
有些芯片虽然为Flash提供了一个专门的Cache,但由于其尺寸有限(通常是为了降低功耗或者芯片面积),会出现 -Omax + Link Time Optimisation优化下跑分反而不如 -Oz 或者 -Os 的情况。
首先这不是编译器的BUG,也不是你忘记给电脑开光导致来了脏东西。原因其实很简单:很多编译器在面向性能优化的时候会进行疯狂的循环展开,这会导致原本小巧的循环体突然体积暴涨——如果循环展开后的体积超过了cache所能容忍的程度,就会在这个关键的循环中频繁出现 cache miss——相当于处理器是直接从Flash上读取代码。相反,在 -Oz 和 -Os 通常不会进行此类循环展开,因此在执行循环热点时,0 wait state的cache发挥了高速缓存应有的作用,与直接在Flash上读取代码相比,极大的提高了程序的运行速度。这里的关键其实是 cache 的大小以及循环展开后的体积。一般来说,大家常用的一线厂商芯片其 Flash Cache尺寸还是很得体的,一般不会出现上述情况,可以放心食用。

Coremark必须跑够10秒以上

这是Coremark为了跑出有效跑分而在算法中做出的硬性规定,如果你的芯片频率过高,则很可能会出现类似如下的提示:

ERROR! Must execute for at least 10 secs for a valid result.
观察 Total time (secs)可以知道Coremark实际运行了多少秒。
要解决这一问题也很简单:直接在工程中定义宏 ITERATIONS,并给出一个较大的值即可,比如3000:
重新编译,调试:

Coremark的结果处理



细心的小伙伴可能会发现一个现象,在很多新闻报道中,某些芯片厂商会声称自己的芯片Coremark跑分高达几千分,为什么我们这里所展示的Coremark跑分只有个位数呢?其实二者都没错,几千分的那个结果是将芯片的频率考虑在内,而这里个位数的跑分是以1MHz作为参考——也就是所谓的 “每兆赫兹 Coremark”——显然,将结果换算成 1MHz 为单位的结果更为直观,也方便大家将不同频率的芯片拿到一起作比较,因此 perf_counter 在移植 Coremark 时也选择以 每MHz Coremark作为结果输出的标准格式。

【说在后面的话】

Battle千万条,拉踩第一条;跑分不规范,亲人两行泪。
感谢大家对 perf_counter 的支持。如果你喜欢我的作品,不妨献上您宝贵的一个 Star:
https://github.com/GorgonMeducer/perf_counter










欢迎光临 谷动谷力 (http://bbs.sunsili.com/) Powered by Discuz! X3.2