4、CPU性能测试：CoreMark标准测试、Dhrystone测试、多核负载均衡分析
CPU性能测试，说白了就是看看这颗芯片到底有多能打。在座舱系统里，CPU要同时处理导航、语音、仪表、娱乐等多个任务，性能不够就会卡顿，甚至黑屏。我见过不少项目，前期选型只看主频，结果跑起来才发现单核性能根本扛不住。
今天咱们就聊聊三个核心测试：CoreMark、Dhrystone，还有多核负载均衡分析。这些都是我实际项目中反复用过的，踩过坑，也总结了一些经验。
4.1 CoreMark标准测试
CoreMark是目前业界最主流的CPU性能基准测试之一。它不像某些跑分软件那样只测浮点或整数运算，而是模拟了真实嵌入式场景中的多种工作负载。
CoreMark测试的内容包括：
- 列表操作（查找、排序、插入、删除）
- 矩阵运算（矩阵乘法、矩阵转置）
- 状态机模拟
- CRC校验
我个人习惯用CoreMark来评估座舱SoC的单核性能。为什么？因为它测试的是处理器执行真实代码的能力，而不是单纯的理论峰值。
关键指标：CoreMark/MHz。这个值越高，说明每MHz能完成的工作越多。座舱芯片通常要求在2.0以上才算合格。
在QNX上跑CoreMark很简单。我一般这样操作：
# 下载CoreMark源码
wget https://github.com/eembc/coremark/archive/main.zip
# 解压并进入目录
unzip main.zip
cd coremark-main
# 编译（针对QNX aarch64）
make PORT_DIR=posix CC=aarch64-unknown-nto-qnx8.0.0-gcc
# 运行
./coremark.exe跑完之后，你会看到类似这样的输出：
2K performance run parameters for coremark.
CoreMark Size : 666
Total ticks : 12345
Total time (secs): 12.345
Iterations/Sec : 810.04
Iterations : 10000
Compiler version : GCC 8.3.0
Compiler flags : -O2 -DPERFORMANCE_RUN=1
CoreMark Score : 810.04嗯，这里要注意：一定要用-O2或-O3优化编译。我见过有人用-O0跑，结果分数直接腰斩，还以为芯片有问题。
我的经验：在座舱项目中，我通常会在不同频率下跑CoreMark，比如1.2GHz、1.5GHz、1.8GHz，然后绘制一条频率-性能曲线。这样能看出芯片的线性度，也能发现散热降频的拐点。
4.2 Dhrystone测试
Dhrystone是更老牌的CPU性能测试，主要衡量整数运算能力。虽然它已经有些年头了，但在嵌入式领域依然有参考价值。
Dhrystone测试的特点：
- 纯整数运算，不涉及浮点
- 测试字符串操作、指针、函数调用等
- 结果以DMIPS（Dhrystone Million Instructions Per Second）表示
为什么还要用Dhrystone？因为座舱系统中大量代码是C/C++写的，整数运算占了很大比重。CoreMark虽然更全面，但Dhrystone在评估编译器优化效果时特别有用。
注意：Dhrystone的代码量很小，容易受缓存影响。我曾经在某个项目中发现，同样的芯片，L1缓存大小不同，Dhrystone分数能差30%。所以对比时一定要确保缓存配置一致。
在QNX上跑Dhrystone，我一般用这个流程：
# 获取Dhrystone源码（网上有很多版本，我用的是经典版）
wget http://www.netlib.org/benchmark/dhrystone-c.tar.gz
tar -xzf dhrystone-c.tar.gz
cd dhrystone-c
# 编译
aarch64-unknown-nto-qnx8.0.0-gcc -O2 -o dhrystone dhry_1.c dhry_2.c
# 运行
./dhrystone输出结果类似：
Dhrystone Benchmark, Version 2.1
Microseconds for one run through Dhrystone: 0.55
Dhrystones per Second: 1818181.8
VAX MIPS rating = 1.03这里有个坑：VAX MIPS rating是相对值，以VAX 11/780为基准（1 MIPS）。现代芯片动辄几百上千，这个数字看看就好，重点看Dhrystones per Second。
4.3 多核负载均衡分析
单核性能再强，也架不住座舱系统里几十个进程同时跑。多核负载均衡，说白了就是让每个核都忙起来，别让一个核累死，其他核闲死。
我在项目中遇到过这样的情况：某个核CPU占用率冲到95%，其他核只有20%。结果系统整体响应变慢，用户滑动屏幕都卡。这就是典型的负载不均。
多核负载均衡分析的关键指标：
| 指标 | 说明 | 理想值 |
|---|---|---|
| CPU利用率标准差 | 各核利用率之间的差异程度 | < 10% |
| 最大核利用率 | 最忙核的利用率 | < 80% |
| 核间迁移次数 | 进程在不同核之间切换的频率 | 越低越好 |
在QNX上，我常用top和pidin来观察负载分布：
# 查看每个核的利用率
pidin -p cpu
# 输出示例
CPU0: 45% user, 10% system, 45% idle
CPU1: 80% user, 5% system, 15% idle
CPU2: 30% user, 8% system, 62% idle
CPU3: 20% user, 5% system, 75% idle看到CPU1跑到80%，其他核闲得发慌，这就是问题。
负载均衡分析步骤：
- 用
pidin -p cpu采集各核利用率，持续30秒 - 用
pidin -t查看每个线程的CPU亲和性 - 分析哪些进程占用了最多的CPU时间
- 检查是否有进程被绑定到了特定核
我曾经遇到一个案例：某个音频处理线程被绑定到了CPU0，而CPU0还要处理中断和调度。结果音频偶尔出现爆音。解决办法很简单——把音频线程迁移到空闲核上。
优化负载均衡的常用手段：
- 调整亲和性：用
ThreadCtl(_NTO_TCTL_RUNMASK, ...)将关键线程绑定到特定核 - 使用中断负载均衡：QNX支持将中断分配到不同核，避免中断风暴
- 调整调度策略：对实时任务用FIFO调度，对普通任务用Round Robin
我的建议：不要盲目把所有线程都分散到所有核上。核间通信是有开销的。对于紧密耦合的任务，把它们放在同一个核上反而更快。你想想看，如果两个线程频繁交换数据，却分在两个核上，缓存命中率会大幅下降。
4.4 综合测试策略
在实际项目中，我不会只跑一个测试就下结论。我的做法是：
- 先跑CoreMark，评估单核综合性能
- 再跑Dhrystone，验证整数运算和编译器优化效果
- 最后做多核负载分析，确保系统能充分利用所有核
这三个测试结合起来，基本能全面反映CPU在座舱场景下的真实表现。我记得有一次，某款芯片CoreMark分数很高，但多核负载一上去就发热降频。这就是典型的「纸面性能」和「实际性能」的差距。
避坑指南：我曾经在测试时忽略了散热条件，结果跑出来的数据比量产车高了20%。后来才发现，测试时芯片是裸片加散热片，而量产时是封闭在座舱模块里。所以，一定要在目标散热条件下测试。
好了，CPU性能测试这部分就聊到这儿。下一章咱们会讲内存和存储性能测试，那又是另一番天地了。