部署CoreMark从未这么简单

在枯燥的MCU生态里，有没这样一个往群里大叫一声“不服？跑个分看看”，然后搬个小板凳躲在角落里吃瓜的机会呢？

简单来说，Coremark是一个专门测量嵌入式MCU（或者CPU）性能的跑分软件，用来替代已经过时且充满争议的Dhrystone跑分。Coremark包含了一系列算法：列表操作（查找和排序）、常用的矩阵运算、状态机以及CRC——这样做的目的据说是为了克服Dhrystone过于依赖libc库的缺点。

这里记住结论就行：Dhrystone低级、过时、踩一脚；Coremark高级拉一把！

【部署CoreMark从未这么简单】

虽然Coremark的源代码在Github上可以直接下载，但拿回家后还需要针对你的目标处理器进行一番移植。总的来说，移植需要解决两类问题：

提供对printf的重映射支持

提供一个足够精准的时间测量手段 

哎，巧了不是。如果你使用的是Cortex-M处理器，并且习惯了在MDK环境下耕耘，只要借助 perf_counter 的帮助，在RTE里简单的勾选几下就可以迅速的在任意Cortex-M处理器中部署 Coremark。

首先，关于MDK下实现通用的printf功能

从 v2.0.0开始 perf_counter 内置了 Coremark，并针对Cortex-M处理器完成了几乎所有的移植工作，这意味着你只需要在RTE中勾选对应的模块，即可完成对Coremark的部署（如下图所示）：

如果你已经通过往期文章《【喂到嘴边了的模块】超级嵌入式系统“性能/时间”工具箱》熟悉过perf_counter的使用，那么接下来只要在超级循环里加入如下的代码就大功告成了：

 

#include "perf_counter.h"


int main(void)
{
    
    printf("Coremark 1.0
");
    
    coremark_main();
    
    while(1) {


    }
    
}

对应的运行效果如下（这里以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 覆盖掉。为了避免误导后来人，推荐在这种情况下在该列表中选择。

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作为结果输出的标准格式。 

审核编辑：刘清