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

【说在前面的话】

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高级拉一把！

• 提供对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的部署（如下图所示）：

#include "perf_counter.h"
int main(void){        printf("Coremark 1.0\r\n");        coremark_main();        while(1) {
    }    }

可以看到，这里的跑分结果是 4.367429。

• Coremark跑分的制约因素

不要奢望 -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 覆盖掉。为了避免误导后来人，推荐在这种情况下在该列表中选择。

其实用脚指头想也知道：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性能差异的参考手段。

有没有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 的情况。

• Coremark必须跑够10秒以上

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

ERROR! Must execute for at least 10 secs for a valid result.

观察 Total time (secs）可以知道Coremark实际运行了多少秒。

重新编译，调试：

• Coremark的结果处理
  

如果你喜欢我的思维、觉得我的文章对你有所启发，

请务必 “点赞、收藏、转发” 三连，这对我很重要！谢谢！

欢迎订阅 裸机思维