【嵌入式】不服？跑个分看看！——Coremark篇

sunsili

【嵌入式】不服？跑个分看看！——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上可以直接下载，但拿回家后还需要针对你的目标处理器进行一番移植。总的来说，移植需要解决两类问题：

• 提供对printf的重映射支持
• 提供一个足够精准的时间测量手段
  

哎，巧了不是。如果你使用的是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. 
   
3. int main(void){
   
4.         printf("Coremark 1.0\r\n");        
   
5.         coremark_main();
   
6. 
   
7.        while(1) {
   
8.     }   
   
9. }

复制代码

对应的运行效果如下（这里以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的一个隐藏技巧：

• 请在 Msc Controls 中直接添加 -Omax，同时
• 勾选 Link-Time-Optmisation
  

需要强调的是，一旦在 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

---