在枯燥的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) {


    }
    
}

可以看到，這里的跑分結果是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作為結果輸出的標準格式。

審核編輯：劉清