在枯燥的MCU生態(tài)里，有沒這樣一個往群里大叫一聲“不服？跑個分看看”，然后搬個小板凳躲在角落里吃瓜的機(jī)會呢？

簡單來說，Coremark是一個專門測量嵌入式MCU（或者CPU）性能的跑分軟件，用來替代已經(jīng)過時且充滿爭議的Dhrystone跑分。Coremark包含了一系列算法：列表操作（查找和排序）、常用的矩陣運算、狀態(tài)機(jī)以及CRC——這樣做的目的據(jù)說是為了克服Dhrystone過于依賴libc庫的缺點。

這里記住結(jié)論就行：Dhrystone低級、過時、踩一腳；Coremark高級拉一把！

【部署CoreMark從未這么簡單】

雖然Coremark的源代碼在Github上可以直接下載，但拿回家后還需要針對你的目標(biāo)處理器進(jìn)行一番移植?？偟膩碚f，移植需要解決兩類問題：

提供對printf的重映射支持

提供一個足夠精準(zhǔn)的時間測量手段

哎，巧了不是。如果你使用的是Cortex-M處理器，并且習(xí)慣了在MDK環(huán)境下耕耘，只要借助 perf_counter 的幫助，在RTE里簡單的勾選幾下就可以迅速的在任意Cortex-M處理器中部署 Coremark。

首先，關(guān)于MDK下實現(xiàn)通用的printf功能

從 v2.0.0開始perf_counter 內(nèi)置了 Coremark，并針對Cortex-M處理器完成了幾乎所有的移植工作，這意味著你只需要在RTE中勾選對應(yīng)的模塊，即可完成對Coremark的部署（如下圖所示）：

如果你已經(jīng)通過往期文章《【喂到嘴邊了的模塊】超級嵌入式系統(tǒng)“性能/時間”工具箱》熟悉過perf_counter的使用，那么接下來只要在超級循環(huán)里加入如下的代碼就大功告成了：

#include"perf_counter.h"


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


    }
    
}

可以看到，這里的跑分結(jié)果是4.367429。

如果你之前從未用過 perf_counter，則推薦通過文章《【喂到嘴邊了的模塊】超級嵌入式系統(tǒng)“性能/時間”工具箱》來了解詳細(xì)的部署和使用方式。這里就不再贅述。 值得特別強(qiáng)調(diào)的是，perf_counter 已經(jīng)加入 KEIL的官方索引列表，因此小伙伴可以直接從 Pack Installer 中找并安裝它的最新版本：

如果你的網(wǎng)絡(luò)不太好，無法通過Pack Installer直接安裝，也可以在關(guān)注公眾號【裸機(jī)思維】后向后臺發(fā)送關(guān)鍵字 perf_counter 來獲取網(wǎng)盤鏈接。 【常見問題】

Coremark雖然簡單直接，但在使用上仍然存在一些注意事項：

Coremark跑分的制約因素

一般來說，Coremark的結(jié)果肯定會受到以下幾個因素的影響： 1. 優(yōu)化等級

不要奢望 -O0 能跑出多高的結(jié)果。但如果你的項目從來都只用 -O0 那么跑Coremark時也一定要用 -O0 ——因為這反應(yīng)了你使用時候的真實狀況。

很多芯片公司和Arm一樣都會用最好的編譯器在最高的速度優(yōu)化下跑Coremark，這意味著，我們通?？梢栽?Arm Compiler 6下使用 -Omax跑出當(dāng)前硬件平臺的最佳結(jié)果。

很多小伙伴可能不知道如何在 MDK 環(huán)境下使用 -Omax，因為Optimisation下拉列表中根本沒有 -Omax。-Omax 是一個比 -Ofast要更上一個臺階的優(yōu)化等級（用過都說好），可以說是MDK的一個隱藏技巧：

請在 Msc Controls 中直接添加 -Omax，同時

勾選 Link-Time-Optmisation

需要強(qiáng)調(diào)的是，一旦在 Misc Controls文本框中添加了 -Omax，無論你在 Optimization 下拉列表中選擇了哪個優(yōu)化等級，都會被 -Omax 覆蓋掉。為了避免誤導(dǎo)后來人，推薦在這種情況下在該列表中選擇。

2. 程序存儲器的速度以及RAM的訪問速度

其實用腳指頭想也知道：Coremark的跑分會受到存儲器訪問速度的影響。很多大公司會將程序保存在0 wait state 的 RAM中來跑 Coremark，以求獲得最佳的結(jié)果。

我猜很多小伙伴看到這里可能就炸了：我們平時都是在Flash里跑代碼，你拿RAM跑出來的數(shù)據(jù)糊弄我？這不是欺負(fù)老實人么？

實際并非如此，原因如下：

1）對很多大公司來說，他要給客戶提供理想狀況下所能達(dá)到的最高評分，方便用戶選型的時候了解芯片的能力上限（如果上限都達(dá)不到就別勉強(qiáng)了）

2）很多芯片會專門提供用于運行代碼的 PRAM、SRAM或者 TCM（Tightly Couple Memory），因此，只要合理安排程序的存儲器布局，在核心應(yīng)用和算法上，的確可以跑出官方給出的最大性能

從另外一個角度來說，以Cortex-M處理器為例，通過Coremark，對比Arm提供的最高跑分，我們可以很容易的評估當(dāng)前芯片的 Flash速度是否拖累了處理器——從跑分的差異上判斷拖累的程度。比如，很多時候，使用片內(nèi)Flash跑 Coremark、XIP（QSPI）連接的片外Flash 跑Coremark 可以看出巨大的跑分差異，給了我們一個定量判斷性能損失的參考手段——注意，只是參考，不是絕對的。

此外，RAM的速度也會對Coremark產(chǎn)生很大的影響，簡單來說，0 wait state的 RAM，1~2個wait state 的 RAM以及 SDRAM 跑Coremark的結(jié)果是截然不同的——這同樣給了我們一個直觀感受不同RAM性能差異的參考手段。

3. 是否存在cache

有沒有cache，有多大的cache，以及cache覆蓋ROM還是RAM對Coremark結(jié)果的影響是巨大的。比如，哪怕你用 XIP 來跑 Coremark（或者用SDRAM來存儲數(shù)據(jù)），只要你Cache到位，其跑分幾乎和理想狀況相差無幾。

以上內(nèi)容用腳趾都能想出來。接下來給大家說一個由cache引起的反直覺的現(xiàn)象：

前面我們說過，如果你想跑出最佳的跑分，就應(yīng)該使用編譯器的最高性能優(yōu)化，對Cortex-M和Arm Compiler 6來說就是 -Omax + Link Time Optimisation。

有些芯片雖然為Flash提供了一個專門的Cache，但由于其尺寸有限（通常是為了降低功耗或者芯片面積），會出現(xiàn) -Omax + Link Time Optimisation優(yōu)化下跑分反而不如 -Oz 或者 -Os 的情況。

首先這不是編譯器的BUG，也不是你忘記給電腦開光導(dǎo)致來了臟東西。原因其實很簡單：很多編譯器在面向性能優(yōu)化的時候會進(jìn)行瘋狂的循環(huán)展開，這會導(dǎo)致原本小巧的循環(huán)體突然體積暴漲——如果循環(huán)展開后的體積超過了cache所能容忍的程度，就會在這個關(guān)鍵的循環(huán)中頻繁出現(xiàn) cache miss——相當(dāng)于處理器是直接從Flash上讀取代碼。

相反，在-Oz 和 -Os 通常不會進(jìn)行此類循環(huán)展開，因此在執(zhí)行循環(huán)熱點時，0 wait state的cache發(fā)揮了高速緩存應(yīng)有的作用，與直接在Flash上讀取代碼相比，極大的提高了程序的運行速度。

這里的關(guān)鍵其實是 cache 的大小以及循環(huán)展開后的體積。一般來說，大家常用的一線廠商芯片其 Flash Cache尺寸還是很得體的，一般不會出現(xiàn)上述情況，可以放心食用。

Coremark必須跑夠10秒以上

這是Coremark為了跑出有效跑分而在算法中做出的硬性規(guī)定，如果你的芯片頻率過高，則很可能會出現(xiàn)類似如下的提示：

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

觀察Total time (secs）可以知道Coremark實際運行了多少秒。

要解決這一問題也很簡單：直接在工程中定義宏 ITERATIONS，并給出一個較大的值即可，比如3000：

重新編譯，調(diào)試：

Coremark的結(jié)果處理

細(xì)心的小伙伴可能會發(fā)現(xiàn)一個現(xiàn)象，在很多新聞報道中，某些芯片廠商會聲稱自己的芯片Coremark跑分高達(dá)幾千分，為什么我們這里所展示的Coremark跑分只有個位數(shù)呢？ 其實二者都沒錯，幾千分的那個結(jié)果是將芯片的頻率考慮在內(nèi)，而這里個位數(shù)的跑分是以1MHz作為參考——也就是所謂的 “每兆赫茲Coremark”——顯然，將結(jié)果換算成 1MHz 為單位的結(jié)果更為直觀，也方便大家將不同頻率的芯片拿到一起作比較，因此 perf_counter 在移植 Coremark 時也選擇以 每MHz Coremark作為結(jié)果輸出的標(biāo)準(zhǔn)格式。

審核編輯：劉清