【說在前面的話】
在計算機領域，很多無意義的論戰都會在“不服跑個分看看”的叫嚣中進入下一個階段：從原本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做了哪些改進，感興趣的小夥伴可以點選去看一看：
這裡記住結論就行：Dhrystone低級、過時、踩一腳；Coremark進階拉一把！
嵌入式物聯網需要學的東西真的非常多，千萬不要學錯了路線和内容，導緻工資要不上去！
無償分享大家一個資料包，差不多150多G。裡面學習内容、面經、項目都比較新也比較全！某魚上買估計至少要好幾十。
點選這裡找小助理0元領取：加微信領取資料
【部署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的使用，那麼接下來隻要在超級循環裡加入如下的代碼就大功告成了：
#include "perf_counter.h"
int main(void)
{
printf("Coremark 1.0\r\n");
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 覆寫掉。為了避免誤導後來人，推薦在這種情況下在該清單中選擇<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
轉載自：裸機思維
文章來源于【喂到嘴邊了的子產品】不服？跑個分看看！——Coremark篇
原文連結：https://mp.weixin.qq.com/s/DM-U2YFpg_Aid1x7TqIAvw