1. 项目概述从一次性能“反直觉”的发现说起几年前我在一个嵌入式项目里遇到了一个挺有意思的现象。当时手头有两块开发板一块是基于三星S3C2410ARM920T内核的Mini2410另一块是基于英特尔XScale PXA270ARMv5TE架构的EduKit-IV。项目需要在上面跑一个基于Qt的图形界面Qtopia 4.3。按理说PXA270的主频更高架构也更现代跑起来应该更轻松才对。但实际部署后通过NFS挂载相同的根文件系统来运行完全一样的Qtopia程序结果却让人大跌眼镜在2410上界面操作流畅CPU占用率也不高而在270上界面明显卡顿top命令一看CPU几乎被吃满风扇呼呼转。这不对劲。硬件规格上PXA270是完胜的。直觉告诉我问题可能出在软件层面比如编译器优化、库的差异或者更根本的——CPU的整数运算性能。为了验证这个猜想我决定搬出一个“老古董”但极其经典的基准测试工具Dhrystone。它的好处是纯粹、简单代码量小能相对公平地反映CPU执行整数指令和常用数据结构的效率。我当时的思路是剥离掉图形库、文件系统、网络等复杂因素就在一个“纯净”的Linux环境下用完全相同的交叉编译器生成同一个Dhrystone可执行文件分别在两块板子上跑看看最底层的CPU“算力”到底差多少。于是就有了本文开头的那些测试数据。我写这篇文章就是想完整复盘那次从发现问题、选择工具、搭建环境、执行测试到分析结果的整个过程。这不仅仅是记录一次测试更是想分享在嵌入式开发中当遇到性能与预期不符时如何系统地、由底向上地进行排查和验证的思路。无论是做产品选型、性能调优还是单纯的技术摸底这套方法都很有用。2. Dhrystone基准测试的核心原理与局限在动手之前我们得先搞清楚手里的工具到底是什么。Dhrystone诞生于1984年由Reinhold P. Weicker设计其名字源于另一个更古老的浮点测试基准Whetstone“磨刀石”Dhrystone意为“干石头”强调其测试的是整数性能。它的核心思想是通过模拟一个典型的系统编程环境如编译器的代码生成、操作系统的内核例程中的操作混合来评估CPU的性能。2.1 Dhrystone测试了什么它的源码主要由C语言编写包含了当时乃至现在程序中最常见的一些操作过程调用/返回大量的函数调用测试栈操作和寄存器管理效率。指针操作频繁的指针赋值、解引用模拟数据结构如链表、树的访问。整数运算各种整型的赋值、比较、算术运算加、减、乘、模运算等。控制流if-elseswitch-casewhilefor循环。数组与字符串一维数组的访问、字符串的赋值与比较。记录结构体操作结构体的赋值、作为参数传递、访问其成员。程序的核心是一个循环反复执行一系列上述操作的固定组合。最终输出的结果单位是“Dhrystones per second” (DPS)即每秒完成了多少次完整的Dhrystone循环。数值越高通常表示CPU的整数处理能力越强。2.2 为什么在嵌入式领域依然有参考价值尽管Dhrystone年代久远并且因为过于简单而被更复杂的基准测试套件如SPEC CPU所取代但在资源受限的嵌入式领域它仍有其独特的价值轻量级代码量小编译快可以在资源极其有限的裸机或RTOS上运行。可移植性极佳纯C代码几乎可以在任何有C编译器的平台上编译运行。对比性强当严格控制变量同一份源码、同一个编译器、相同的编译选项、相似的系统负载时它在不同硬件平台上的跑分能直观地反映CPU核心在整数运算和基本控制逻辑上的相对性能差异。这正是我用来对比2410和270的初衷。辅助编译器评估通过比较同一硬件上不同编译器或不同优化等级编译出的Dhrystone成绩可以评估编译器优化效果。2.3 必须了解的局限性与“坑”然而盲目相信Dhrystone的绝对数值是危险的。我们必须清楚它的局限性不能代表整体系统性能它完全不测试浮点、图形、I/O、内存带宽、缓存效率、多核并发等现代处理器至关重要的特性。一个Dhrystone分数高的CPU跑大型应用或游戏可能很慢。易被“针对性优化”由于代码公开且模式固定聪明的编译器可以进行极具攻击性的优化比如将整个循环展开、内联所有函数、甚至预计算大部分结果导致测试分数虚高但完全偏离了“模拟典型程序”的初衷。这也是后来Dhrystone声名狼藉的主要原因。“VAX MIPS”的误导历史上常将Dhrystone分数除以1757旧版或更复杂的因子换算成“VAX MIPS”相对于DEC VAX 11/780的性能倍数。这个换算早已过时且不准确绝对不要用这个值来跨架构比较。内存影响虽然主要测CPU但若CPU缓存或内存速度成为瓶颈也会影响分数。实操心得在嵌入式开发中Dhrystone的最佳用途是“控制变量的相对比较”。比如比较同一块板子上不同编译器gcc vs. armcc的效果或者比较同系列不同主频的芯片。如果要进行跨架构比较如ARM vs. RISC-V必须极其谨慎最好辅以其他更全面的测试。3. 构建与测试环境搭建详解回到我的案例目标是公平比较ARM9S3C2410和XScalePXA270。公平的前提是环境尽可能一致。3.1 硬件平台简介Mini2410 (S3C2410)CPU核心ARM920T ARMv4T架构。主频通常运行在200MHz或266MHz我的板子是200MHz。特性带16KB I-Cache和16KB D-CacheMMU支持可以运行Linux。EduKit-IV (PXA270)CPU核心Intel XScale ARMv5TE架构。主频通常运行在200MHz至624MHz我的板子设定在约400MHz级别具体由Bootloader设定。特性更高效的流水线支持Thumb指令集增强通常带有更大的缓存。从纸面参数看PXA270在架构和主频上都占优。3.2 软件与环境统一为了消除操作系统和文件系统的差异我采用了NFS网络文件系统根目录的方式。这意味着两块开发板在启动时都从同一台PC服务器上挂载完全相同的根文件系统。这样它们运行的用户空间程序、库文件、甚至脚本都是一模一样的。编译工具链这是关键中的关键。我必须使用同一个交叉编译器来为两块ARM板子生成代码。我当时使用的是自己构建的arm-linux-gcc 3.4.1工具链。确保编译器路径、版本、内置库完全一致。Dhrystone源码我使用的是经典的Dhrystone 2.1版本也就是上文附件链接中的源码。这个版本足够稳定。编译与配置解压源码后主要需要关注dhry.h和dhry_1.cdhry_2.c。在dhry.h中通常需要根据平台定义一些宏比如HZ系统时钟滴答频率。但在Linux用户态下Dhrystone程序自己会通过times()或clock()等系统调用获取时间所以通常不需要修改。编写一个简单的MakefileCC /path/to/your/arm-linux-gcc CFLAGS -O2 -static TARGET dhry all: $(TARGET) $(TARGET): dhry_1.c dhry_2.c $(CC) $(CFLAGS) -o $ $^ clean: rm -f $(TARGET) *.o重点解释编译选项-O2启用常用的优化使生成的代码具有较好的性能同时避免像-O3或-funroll-loops那样可能对Dhrystone产生过于“投机”的优化。-static静态链接。这是非常重要的一步。它将所有库函数如printf,times都打包进最终的可执行文件。这样做可以消除不同板子上动态链接库libc版本或性能差异带来的影响让测试更纯粹地反映CPU执行这段特定代码的能力。执行make生成一个名为dhry的静态链接ARM可执行文件。3.3 测试执行与数据记录将编译好的dhry文件放在NFS根文件系统的某个路径下例如/home/root。确保系统空闲通过串口或ssh登录到开发板。在测试前运行top或htop查看系统负载确保没有其他非必要进程大量占用CPU。理想状态是只有基本的系统守护进程。运行测试Dhrystone程序通常支持一个-I-参数这个参数的含义在不同的实现中可能略有不同在一些版本中它用于抑制某些输出或进行特殊迭代。在我的测试中就是使用./dhry -I-这个命令。程序会运行一段时间通常是10秒左右然后输出一行结果。多次采样任何性能测试单次运行都有偶然性。为了得到稳定结果我连续运行了10次如原文所示。记录下每一次的 “Dhrystone per second” 数值。数据处理计算这10次结果的平均值并观察其波动范围标准差或最大值/最小值。波动很小说明测试环境稳定结果可信。4. 测试结果分析与问题深挖现在让我们直面那些令人惊讶的数字Mini2410 (ARM920T ~200MHz)平均约26,920 DPSPXA270 (XScale ~400MHz)平均约118,240 DPSPXA270的得分大约是Mini2410的4.4倍。这个倍数关系首先印证了PXA270的CPU核心在纯整数运算能力上确实远强于ARM920T这符合其更新的架构和可能更高的主频预期。但是这反而让最初的Qtopia性能问题显得更加诡异了为什么一个整数算力强4倍多的CPU跑同样的图形界面反而更卡顿、CPU占用率更高这说明Qtopia的性能瓶颈根本不在于CPU的整数计算能力。Dhrystone测试帮助我们排除了一个主要的怀疑方向。那么问题可能出在哪里呢我们需要将视线从CPU核心移开看向系统的其他部分图形渲染与浮点Qtopia涉及大量的图形渲染、图像缩放、混合等操作。这些操作可能严重依赖浮点运算或SIMD指令。ARM920T和早期的XScale都没有硬件浮点单元FPU浮点运算是通过软件库模拟的速度极慢。但XScale的MMU和缓存架构差异可能导致软件浮点库的效率也不同。此外如果Qt的图形后端如LinuxFB使用了某些需要特定CPU指令优化的功能而编译器没有为PXA270生成最优代码也会导致性能差异。内存子系统这是最大的怀疑对象。图形界面需要频繁地在帧缓冲Framebuffer中进行读写操作这对内存带宽和延迟极其敏感。SDRAM性能Mini2410和PXA270使用的SDRAM类型、位宽、时钟频率、时序参数可能完全不同。即使CPU核心更快如果内存带宽是瓶颈整体性能也会被拖累。PXA270虽然核心快但它的内存控制器性能可能并未与核心性能成比例提升或者我板子的SDRAM配置并非最优。缓存效率图形操作的数据访问模式大块、连续但通常不重复与Dhrystone的小数据量、高局部性模式截然不同。PXA270的缓存策略如写回、写通和容量对于图形数据流可能不如ARM920T的有效。缓存失效Cache Miss会导致CPU长时间等待内存从而利用率显示为100%。系统调度与中断Linux内核的调度器、时钟中断频率HZ在不同平台上可能有细微差别。如果PXA270平台的中断处理或进程调度开销更大在响应GUI的频繁事件鼠标、定时器时就会显得吃力。编译器与库的细微差别虽然我们用同一个编译器编译了Dhrystone但Qtopia本身是一个庞大的库其编译过程可能启用了不同的架构特定优化如-mcpu参数。也许为2410编译的Qt库无意中更适合其内存访问模式或者为270编译的库存在某些低效的代码路径。排查技巧实录当Dhrystone测试结果与复杂应用性能表现相悖时下一步应该使用更针对性的性能剖析工具。perf或oprofile在运行Qtopia时使用这些工具分析热点函数看时间是消耗在CPU运算上还是在内存访问cache-misses、系统调用或IO等待上。内存带宽测试运行如mbw、lmbench等工具直接测试两块板子的内存拷贝、延迟带宽。图形性能测试使用简单的帧填充测试如fbtest或Qt自带的性能示例隔离图形渲染环节。5. 嵌入式性能评估的完整方法论那次经历给了我一个深刻的教训嵌入式性能评估绝不能只看CPU主频或一两个基准测试分数。必须建立一个系统化的、分层的评估体系。5.1 分层评估模型一个嵌入式系统的性能可以从下到上分为多个层次每一层都可能成为瓶颈层级评估重点常用工具/方法说明CPU核心整数/浮点算力、指令效率、流水线Dhrystone, CoreMark, Whetstone, 微架构分析最底层如本文所做。CoreMark比Dhrystone更现代、更合理。内存子系统带宽、延迟、缓存效率lmbench,mbw, 自定义DMA/拷贝测试, 缓存分析工具往往是图形、视频等数据密集型应用的瓶颈。总线与IO外设访问速度、中断延迟自定义IO压力测试ioport/mmap读写基准影响存储、网络、显示等外设性能。编译器与库代码生成质量、库函数优化同一代码不同编译器/选项对比 反汇编分析软件栈的基础效率。操作系统任务切换开销、系统调用、内存管理cyclictest(实时性),perf系统开销分析影响多任务响应和确定性。中间件与运行时协议栈、虚拟机、图形引擎效率特定基准测试 (如LuaJIT, OpenGL ES CTS)如Qt、Java ME的性能。最终应用用户体验、端到端延迟、吞吐量应用场景模拟 真实负载测试综合体现是检验前面所有层次的最终标准。5.2 如何设计一个有效的对比测试明确目标你要对比什么是CPU、内存、还是整个系统在特定任务下的表现控制变量像我做的那样尽可能让除了被测对象之外的一切保持一致相同的软件镜像、相同的测试工具、相同的系统状态空闲、相同的物理环境温度。选择合适的工具微观对比CPU/内存使用CoreMark, lmbench, STREAM等专业微基准测试。宏观对比系统使用行业标准测试套件如SPEC CPU整数/浮点 EEMBC嵌入式领域 或针对性的测试如glmark2-es2图形。多维度采样单次运行不可靠。必须多次运行计算平均值、标准差并观察最差情况。结合 profiling基准测试告诉你“是什么”性能剖析Profiling告诉你“为什么”。一定要用perf、gprof、valgrind --toolcallgrind等工具分析热点找到真正的瓶颈。关注能效对于嵌入式设备性能除以功耗能效往往比绝对性能更重要。在测试时如果条件允许应同步测量核心电压和电流计算不同负载下的能耗。5.3 关于Dhrystone在现代嵌入式开发中的使用建议可以用的场景快速验证一个裸机或RTOS新移植的BSP和工具链是否基本工作正常。在同一架构、同一编译器下对比不同优化等级-O0vs-O2的效果。作为一个极简的、可移植的“冒烟测试”程序。不建议用的场景作为选择芯片或评估系统性能的主要依据。比较不同架构如Cortex-M vs. RISC-V的CPU性能。向客户或上级汇报性能数据除非他们非常了解并同意其局限性。如果一定要用请务必使用-O2优化避免使用-O3或-funroll-all-loops。使用静态链接 (-static)。报告时明确说明测试条件编译器、版本、优化选项、运行环境。最好同时提供CoreMark分数作为对照。6. 从源码到实践编译运行你自己的Dhrystone为了让你能亲手复现和体验这里给出一个更详细的、可直接操作的指南。6.1 获取与准备源码你可以从很多开源网站或基准测试合集里找到Dhrystone 2.1。它的结构通常很简单dhrystone/ ├── dhry.h // 头文件包含全局定义和函数声明 ├── dhry_1.c // 主程序包含main函数、计时逻辑和结果输出 └── dhry_2.c // 包含Dhrystone核心算法的函数有时还会有一个dry.c或dhrystone.c的包装文件。核心就是前三个。6.2 为你的平台编译假设你正在为ARM Linux交叉编译。检查并修改dhry.h打开dhry.h 查看是否有需要定义的宏。例如旧版本可能需要#define HZ 100来定义系统时钟频率。但在使用times()或clock_gettime()的现代实现中这通常不需要。确保#ifdef和#endif部分适合你的编译器。一般保持默认即可。编写Makefile 创建一个Makefile 内容如下。请将CROSS_COMPILE替换成你的工具链前缀。# 工具链设置 CROSS_COMPILE arm-linux-gnueabihf- CC $(CROSS_COMPILE)gcc CFLAGS -O2 -static -Wall # 如果目标板是软浮点使用 -mfloat-abisoftfp 或 -mfloat-abisoft # CFLAGS -mfloat-abisoftfp # 如果目标板是硬浮点使用 -mfloat-abihard # CFLAGS -mfloat-abihard -mfpuvfpv3 TARGET dhrystone SRCS dhry_1.c dhry_2.c OBJS $(SRCS:.c.o) all: $(TARGET) $(TARGET): $(OBJS) $(CC) $(CFLAGS) -o $ $(OBJS) %.o: %.c dhry.h $(CC) $(CFLAGS) -c $ -o $ clean: rm -f $(TARGET) $(OBJS) # 一个方便的目标用于将编译好的程序复制到NFS目录 deploy: $(TARGET) cp $(TARGET) /你的/nfs/根文件系统路径/home/root/编译 在终端执行make。如果一切顺利你会得到一个名为dhrystone的静态链接的ARM可执行文件。6.3 在目标板上运行与解读输出将dhrystone文件拷贝到开发板可以通过NFS、SCP、U盘等方式。在开发板的终端中运行./dhrystone。你可能会看到类似这样的输出Dhrystone Benchmark, Version 2.1 (Language: C) Program compiled without register attribute Please give the number of runs through the benchmark:程序会询问你要运行多少次循环。直接按回车它会使用一个默认的大数值如10000000运行足够长的时间10秒。程序运行结束后会输出详细结果通常包括Final values of the variables used in the benchmark: Int_Glob: 5 Bool_Glob: 1 Ch_1_Glob: A Ch_2_Glob: B Arr_1_Glob[8]: 7 Arr_2_Glob[8][7]: 100000010 Ptr_Glob- Ptr_Comp: 0x... Discr: 0 Enum_Comp: 2 Int_Comp: 17 Str_Comp: ... Next_Ptr_Glob- Ptr_Comp: 0x... Discr: 0 Enum_Comp: 1 Int_Comp: 18 Str_Comp: ... Microseconds for one run through Dhrystone: 0.3 Dhrystones per Second: 3333333.3“Final values...”这部分是校验和用于确保程序逻辑正确执行没有因编译器错误优化而导致错误。你应该将其与官方参考值或在不同平台运行的第一遍结果进行对比确保一致。“Microseconds for one run...”执行一次Dhrystone循环所需的微秒数。“Dhrystones per Second” (DPS)这是我们最关注的数字即每秒执行的循环次数。注意事项有些移植版本像我用的那个可能通过-I-这样的参数来抑制中间输出或改变迭代方式。请务必查阅你所用源码包中的README或注释了解正确的运行参数。多次运行取平均值并确保系统在空闲状态。7. 常见问题与排查技巧实录在实际操作中你可能会遇到以下问题**Q1: 编译时出现undefined reference totimes错误。** **A1:** 这是因为在非Linux环境如一些裸机或RTOS环境下times()系统调用不存在。你需要修改dhry_1.c 中的计时函数。通常需要替换为平台特定的高精度计时器例如对于裸机可以使用CPU的周期计数器如ARM的PMCCNTR。对于某些RTOS使用其提供的tick或clockAPI。修改后可能需要定义HZ宏来将计时器单位转换为秒。Q2: 在开发板上运行速度慢得不可思议或者快得离谱。A2:慢得离谱检查是否使用了-O0无优化编译。务必使用-O2。同时确认编译器的-mcpu或-march选项是否正确设置了目标CPU架构。快得离谱检查编译器是否进行了过度优化。尝试去掉-funroll-loops等激进选项。最极端的情况是编译器可能将整个循环计算优化成了常量。可以检查反汇编代码或者尝试在循环计数器等变量前加上volatile关键字但这会改变测试性质仅用于诊断。Q3: 两次运行的结果差异很大。A3:确保测试时系统空闲。关闭不必要的后台进程、网络服务等。如果板子有动态频率调整DVFS如CPUfreq请在测试前将调控器设置为performance模式并锁定在最高频率echo performance /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor。关闭其他核心如果是多核echo 0 /sys/devices/system/cpu/cpu1/online(对于cpu1)。进行热启动先运行一次测试让CPU缓存“热”起来然后连续运行多次取后几次的结果。Q4: 我想对比A53和M4内核Dhrystone结果有意义吗A4: 意义非常有限。Cortex-A53应用处理器和Cortex-M4微控制器设计目标、内存架构、支持的指令集完全不同。Dhrystone主要反映整数和控制逻辑性能但M4可能没有缓存而A53有。这会对测试结果产生巨大影响。两者的编译器优化策略差异极大。它们运行的软件生态Linux vs. 裸机/RTOS完全不同系统开销不在一个量级。 更合理的对比方式是为每个平台选择其典型的应用场景和测试集如A53跑CoreMark/Linpack M4跑EEMBC的IoT相关测试套件。Q5: 除了Dhrystone现在嵌入式领域更推荐用什么A5:CoreMark由EEMBC维护专门为嵌入式系统设计代码模式更合理避免了Dhrystone许多可被投机优化的问题。它是目前首选的、免费的、轻量级CPU整数性能基准测试。EEMBC Benchmark Suites行业标准包含多个针对不同领域的测试套件如IoTMark, ULPMark需要会员资格但结果权威。SPEC CPU 2017桌面和服务器的黄金标准极其庞大和复杂但对于高性能嵌入式应用处理器如Cortex-A72/A76的评估有参考价值。行业特定测试图形用GLBenchmark/GFXBench网络用iperf存储用fio等。那次对2410和270的测试虽然最终没有直接解决Qtopia卡顿的问题那需要更深入的内存和图形剖析但它像一把精准的手术刀帮我排除了CPU整数算力这个错误答案将排查方向清晰地引向了内存子系统和图形渲染流程。在嵌入式开发中这种“大胆假设小心求证用简单工具排除复杂干扰”的思路其价值远超过任何一个具体的测试分数。工具会过时但系统化的性能分析思维永远不会。下次当你遇到“这板子怎么跑得没那个快”的疑惑时不妨也从一次干净利落的Dhrystone测试开始。
嵌入式性能评估：从Dhrystone基准测试到系统化排查方法
1. 项目概述从一次性能“反直觉”的发现说起几年前我在一个嵌入式项目里遇到了一个挺有意思的现象。当时手头有两块开发板一块是基于三星S3C2410ARM920T内核的Mini2410另一块是基于英特尔XScale PXA270ARMv5TE架构的EduKit-IV。项目需要在上面跑一个基于Qt的图形界面Qtopia 4.3。按理说PXA270的主频更高架构也更现代跑起来应该更轻松才对。但实际部署后通过NFS挂载相同的根文件系统来运行完全一样的Qtopia程序结果却让人大跌眼镜在2410上界面操作流畅CPU占用率也不高而在270上界面明显卡顿top命令一看CPU几乎被吃满风扇呼呼转。这不对劲。硬件规格上PXA270是完胜的。直觉告诉我问题可能出在软件层面比如编译器优化、库的差异或者更根本的——CPU的整数运算性能。为了验证这个猜想我决定搬出一个“老古董”但极其经典的基准测试工具Dhrystone。它的好处是纯粹、简单代码量小能相对公平地反映CPU执行整数指令和常用数据结构的效率。我当时的思路是剥离掉图形库、文件系统、网络等复杂因素就在一个“纯净”的Linux环境下用完全相同的交叉编译器生成同一个Dhrystone可执行文件分别在两块板子上跑看看最底层的CPU“算力”到底差多少。于是就有了本文开头的那些测试数据。我写这篇文章就是想完整复盘那次从发现问题、选择工具、搭建环境、执行测试到分析结果的整个过程。这不仅仅是记录一次测试更是想分享在嵌入式开发中当遇到性能与预期不符时如何系统地、由底向上地进行排查和验证的思路。无论是做产品选型、性能调优还是单纯的技术摸底这套方法都很有用。2. Dhrystone基准测试的核心原理与局限在动手之前我们得先搞清楚手里的工具到底是什么。Dhrystone诞生于1984年由Reinhold P. Weicker设计其名字源于另一个更古老的浮点测试基准Whetstone“磨刀石”Dhrystone意为“干石头”强调其测试的是整数性能。它的核心思想是通过模拟一个典型的系统编程环境如编译器的代码生成、操作系统的内核例程中的操作混合来评估CPU的性能。2.1 Dhrystone测试了什么它的源码主要由C语言编写包含了当时乃至现在程序中最常见的一些操作过程调用/返回大量的函数调用测试栈操作和寄存器管理效率。指针操作频繁的指针赋值、解引用模拟数据结构如链表、树的访问。整数运算各种整型的赋值、比较、算术运算加、减、乘、模运算等。控制流if-elseswitch-casewhilefor循环。数组与字符串一维数组的访问、字符串的赋值与比较。记录结构体操作结构体的赋值、作为参数传递、访问其成员。程序的核心是一个循环反复执行一系列上述操作的固定组合。最终输出的结果单位是“Dhrystones per second” (DPS)即每秒完成了多少次完整的Dhrystone循环。数值越高通常表示CPU的整数处理能力越强。2.2 为什么在嵌入式领域依然有参考价值尽管Dhrystone年代久远并且因为过于简单而被更复杂的基准测试套件如SPEC CPU所取代但在资源受限的嵌入式领域它仍有其独特的价值轻量级代码量小编译快可以在资源极其有限的裸机或RTOS上运行。可移植性极佳纯C代码几乎可以在任何有C编译器的平台上编译运行。对比性强当严格控制变量同一份源码、同一个编译器、相同的编译选项、相似的系统负载时它在不同硬件平台上的跑分能直观地反映CPU核心在整数运算和基本控制逻辑上的相对性能差异。这正是我用来对比2410和270的初衷。辅助编译器评估通过比较同一硬件上不同编译器或不同优化等级编译出的Dhrystone成绩可以评估编译器优化效果。2.3 必须了解的局限性与“坑”然而盲目相信Dhrystone的绝对数值是危险的。我们必须清楚它的局限性不能代表整体系统性能它完全不测试浮点、图形、I/O、内存带宽、缓存效率、多核并发等现代处理器至关重要的特性。一个Dhrystone分数高的CPU跑大型应用或游戏可能很慢。易被“针对性优化”由于代码公开且模式固定聪明的编译器可以进行极具攻击性的优化比如将整个循环展开、内联所有函数、甚至预计算大部分结果导致测试分数虚高但完全偏离了“模拟典型程序”的初衷。这也是后来Dhrystone声名狼藉的主要原因。“VAX MIPS”的误导历史上常将Dhrystone分数除以1757旧版或更复杂的因子换算成“VAX MIPS”相对于DEC VAX 11/780的性能倍数。这个换算早已过时且不准确绝对不要用这个值来跨架构比较。内存影响虽然主要测CPU但若CPU缓存或内存速度成为瓶颈也会影响分数。实操心得在嵌入式开发中Dhrystone的最佳用途是“控制变量的相对比较”。比如比较同一块板子上不同编译器gcc vs. armcc的效果或者比较同系列不同主频的芯片。如果要进行跨架构比较如ARM vs. RISC-V必须极其谨慎最好辅以其他更全面的测试。3. 构建与测试环境搭建详解回到我的案例目标是公平比较ARM9S3C2410和XScalePXA270。公平的前提是环境尽可能一致。3.1 硬件平台简介Mini2410 (S3C2410)CPU核心ARM920T ARMv4T架构。主频通常运行在200MHz或266MHz我的板子是200MHz。特性带16KB I-Cache和16KB D-CacheMMU支持可以运行Linux。EduKit-IV (PXA270)CPU核心Intel XScale ARMv5TE架构。主频通常运行在200MHz至624MHz我的板子设定在约400MHz级别具体由Bootloader设定。特性更高效的流水线支持Thumb指令集增强通常带有更大的缓存。从纸面参数看PXA270在架构和主频上都占优。3.2 软件与环境统一为了消除操作系统和文件系统的差异我采用了NFS网络文件系统根目录的方式。这意味着两块开发板在启动时都从同一台PC服务器上挂载完全相同的根文件系统。这样它们运行的用户空间程序、库文件、甚至脚本都是一模一样的。编译工具链这是关键中的关键。我必须使用同一个交叉编译器来为两块ARM板子生成代码。我当时使用的是自己构建的arm-linux-gcc 3.4.1工具链。确保编译器路径、版本、内置库完全一致。Dhrystone源码我使用的是经典的Dhrystone 2.1版本也就是上文附件链接中的源码。这个版本足够稳定。编译与配置解压源码后主要需要关注dhry.h和dhry_1.cdhry_2.c。在dhry.h中通常需要根据平台定义一些宏比如HZ系统时钟滴答频率。但在Linux用户态下Dhrystone程序自己会通过times()或clock()等系统调用获取时间所以通常不需要修改。编写一个简单的MakefileCC /path/to/your/arm-linux-gcc CFLAGS -O2 -static TARGET dhry all: $(TARGET) $(TARGET): dhry_1.c dhry_2.c $(CC) $(CFLAGS) -o $ $^ clean: rm -f $(TARGET) *.o重点解释编译选项-O2启用常用的优化使生成的代码具有较好的性能同时避免像-O3或-funroll-loops那样可能对Dhrystone产生过于“投机”的优化。-static静态链接。这是非常重要的一步。它将所有库函数如printf,times都打包进最终的可执行文件。这样做可以消除不同板子上动态链接库libc版本或性能差异带来的影响让测试更纯粹地反映CPU执行这段特定代码的能力。执行make生成一个名为dhry的静态链接ARM可执行文件。3.3 测试执行与数据记录将编译好的dhry文件放在NFS根文件系统的某个路径下例如/home/root。确保系统空闲通过串口或ssh登录到开发板。在测试前运行top或htop查看系统负载确保没有其他非必要进程大量占用CPU。理想状态是只有基本的系统守护进程。运行测试Dhrystone程序通常支持一个-I-参数这个参数的含义在不同的实现中可能略有不同在一些版本中它用于抑制某些输出或进行特殊迭代。在我的测试中就是使用./dhry -I-这个命令。程序会运行一段时间通常是10秒左右然后输出一行结果。多次采样任何性能测试单次运行都有偶然性。为了得到稳定结果我连续运行了10次如原文所示。记录下每一次的 “Dhrystone per second” 数值。数据处理计算这10次结果的平均值并观察其波动范围标准差或最大值/最小值。波动很小说明测试环境稳定结果可信。4. 测试结果分析与问题深挖现在让我们直面那些令人惊讶的数字Mini2410 (ARM920T ~200MHz)平均约26,920 DPSPXA270 (XScale ~400MHz)平均约118,240 DPSPXA270的得分大约是Mini2410的4.4倍。这个倍数关系首先印证了PXA270的CPU核心在纯整数运算能力上确实远强于ARM920T这符合其更新的架构和可能更高的主频预期。但是这反而让最初的Qtopia性能问题显得更加诡异了为什么一个整数算力强4倍多的CPU跑同样的图形界面反而更卡顿、CPU占用率更高这说明Qtopia的性能瓶颈根本不在于CPU的整数计算能力。Dhrystone测试帮助我们排除了一个主要的怀疑方向。那么问题可能出在哪里呢我们需要将视线从CPU核心移开看向系统的其他部分图形渲染与浮点Qtopia涉及大量的图形渲染、图像缩放、混合等操作。这些操作可能严重依赖浮点运算或SIMD指令。ARM920T和早期的XScale都没有硬件浮点单元FPU浮点运算是通过软件库模拟的速度极慢。但XScale的MMU和缓存架构差异可能导致软件浮点库的效率也不同。此外如果Qt的图形后端如LinuxFB使用了某些需要特定CPU指令优化的功能而编译器没有为PXA270生成最优代码也会导致性能差异。内存子系统这是最大的怀疑对象。图形界面需要频繁地在帧缓冲Framebuffer中进行读写操作这对内存带宽和延迟极其敏感。SDRAM性能Mini2410和PXA270使用的SDRAM类型、位宽、时钟频率、时序参数可能完全不同。即使CPU核心更快如果内存带宽是瓶颈整体性能也会被拖累。PXA270虽然核心快但它的内存控制器性能可能并未与核心性能成比例提升或者我板子的SDRAM配置并非最优。缓存效率图形操作的数据访问模式大块、连续但通常不重复与Dhrystone的小数据量、高局部性模式截然不同。PXA270的缓存策略如写回、写通和容量对于图形数据流可能不如ARM920T的有效。缓存失效Cache Miss会导致CPU长时间等待内存从而利用率显示为100%。系统调度与中断Linux内核的调度器、时钟中断频率HZ在不同平台上可能有细微差别。如果PXA270平台的中断处理或进程调度开销更大在响应GUI的频繁事件鼠标、定时器时就会显得吃力。编译器与库的细微差别虽然我们用同一个编译器编译了Dhrystone但Qtopia本身是一个庞大的库其编译过程可能启用了不同的架构特定优化如-mcpu参数。也许为2410编译的Qt库无意中更适合其内存访问模式或者为270编译的库存在某些低效的代码路径。排查技巧实录当Dhrystone测试结果与复杂应用性能表现相悖时下一步应该使用更针对性的性能剖析工具。perf或oprofile在运行Qtopia时使用这些工具分析热点函数看时间是消耗在CPU运算上还是在内存访问cache-misses、系统调用或IO等待上。内存带宽测试运行如mbw、lmbench等工具直接测试两块板子的内存拷贝、延迟带宽。图形性能测试使用简单的帧填充测试如fbtest或Qt自带的性能示例隔离图形渲染环节。5. 嵌入式性能评估的完整方法论那次经历给了我一个深刻的教训嵌入式性能评估绝不能只看CPU主频或一两个基准测试分数。必须建立一个系统化的、分层的评估体系。5.1 分层评估模型一个嵌入式系统的性能可以从下到上分为多个层次每一层都可能成为瓶颈层级评估重点常用工具/方法说明CPU核心整数/浮点算力、指令效率、流水线Dhrystone, CoreMark, Whetstone, 微架构分析最底层如本文所做。CoreMark比Dhrystone更现代、更合理。内存子系统带宽、延迟、缓存效率lmbench,mbw, 自定义DMA/拷贝测试, 缓存分析工具往往是图形、视频等数据密集型应用的瓶颈。总线与IO外设访问速度、中断延迟自定义IO压力测试ioport/mmap读写基准影响存储、网络、显示等外设性能。编译器与库代码生成质量、库函数优化同一代码不同编译器/选项对比 反汇编分析软件栈的基础效率。操作系统任务切换开销、系统调用、内存管理cyclictest(实时性),perf系统开销分析影响多任务响应和确定性。中间件与运行时协议栈、虚拟机、图形引擎效率特定基准测试 (如LuaJIT, OpenGL ES CTS)如Qt、Java ME的性能。最终应用用户体验、端到端延迟、吞吐量应用场景模拟 真实负载测试综合体现是检验前面所有层次的最终标准。5.2 如何设计一个有效的对比测试明确目标你要对比什么是CPU、内存、还是整个系统在特定任务下的表现控制变量像我做的那样尽可能让除了被测对象之外的一切保持一致相同的软件镜像、相同的测试工具、相同的系统状态空闲、相同的物理环境温度。选择合适的工具微观对比CPU/内存使用CoreMark, lmbench, STREAM等专业微基准测试。宏观对比系统使用行业标准测试套件如SPEC CPU整数/浮点 EEMBC嵌入式领域 或针对性的测试如glmark2-es2图形。多维度采样单次运行不可靠。必须多次运行计算平均值、标准差并观察最差情况。结合 profiling基准测试告诉你“是什么”性能剖析Profiling告诉你“为什么”。一定要用perf、gprof、valgrind --toolcallgrind等工具分析热点找到真正的瓶颈。关注能效对于嵌入式设备性能除以功耗能效往往比绝对性能更重要。在测试时如果条件允许应同步测量核心电压和电流计算不同负载下的能耗。5.3 关于Dhrystone在现代嵌入式开发中的使用建议可以用的场景快速验证一个裸机或RTOS新移植的BSP和工具链是否基本工作正常。在同一架构、同一编译器下对比不同优化等级-O0vs-O2的效果。作为一个极简的、可移植的“冒烟测试”程序。不建议用的场景作为选择芯片或评估系统性能的主要依据。比较不同架构如Cortex-M vs. RISC-V的CPU性能。向客户或上级汇报性能数据除非他们非常了解并同意其局限性。如果一定要用请务必使用-O2优化避免使用-O3或-funroll-all-loops。使用静态链接 (-static)。报告时明确说明测试条件编译器、版本、优化选项、运行环境。最好同时提供CoreMark分数作为对照。6. 从源码到实践编译运行你自己的Dhrystone为了让你能亲手复现和体验这里给出一个更详细的、可直接操作的指南。6.1 获取与准备源码你可以从很多开源网站或基准测试合集里找到Dhrystone 2.1。它的结构通常很简单dhrystone/ ├── dhry.h // 头文件包含全局定义和函数声明 ├── dhry_1.c // 主程序包含main函数、计时逻辑和结果输出 └── dhry_2.c // 包含Dhrystone核心算法的函数有时还会有一个dry.c或dhrystone.c的包装文件。核心就是前三个。6.2 为你的平台编译假设你正在为ARM Linux交叉编译。检查并修改dhry.h打开dhry.h 查看是否有需要定义的宏。例如旧版本可能需要#define HZ 100来定义系统时钟频率。但在使用times()或clock_gettime()的现代实现中这通常不需要。确保#ifdef和#endif部分适合你的编译器。一般保持默认即可。编写Makefile 创建一个Makefile 内容如下。请将CROSS_COMPILE替换成你的工具链前缀。# 工具链设置 CROSS_COMPILE arm-linux-gnueabihf- CC $(CROSS_COMPILE)gcc CFLAGS -O2 -static -Wall # 如果目标板是软浮点使用 -mfloat-abisoftfp 或 -mfloat-abisoft # CFLAGS -mfloat-abisoftfp # 如果目标板是硬浮点使用 -mfloat-abihard # CFLAGS -mfloat-abihard -mfpuvfpv3 TARGET dhrystone SRCS dhry_1.c dhry_2.c OBJS $(SRCS:.c.o) all: $(TARGET) $(TARGET): $(OBJS) $(CC) $(CFLAGS) -o $ $(OBJS) %.o: %.c dhry.h $(CC) $(CFLAGS) -c $ -o $ clean: rm -f $(TARGET) $(OBJS) # 一个方便的目标用于将编译好的程序复制到NFS目录 deploy: $(TARGET) cp $(TARGET) /你的/nfs/根文件系统路径/home/root/编译 在终端执行make。如果一切顺利你会得到一个名为dhrystone的静态链接的ARM可执行文件。6.3 在目标板上运行与解读输出将dhrystone文件拷贝到开发板可以通过NFS、SCP、U盘等方式。在开发板的终端中运行./dhrystone。你可能会看到类似这样的输出Dhrystone Benchmark, Version 2.1 (Language: C) Program compiled without register attribute Please give the number of runs through the benchmark:程序会询问你要运行多少次循环。直接按回车它会使用一个默认的大数值如10000000运行足够长的时间10秒。程序运行结束后会输出详细结果通常包括Final values of the variables used in the benchmark: Int_Glob: 5 Bool_Glob: 1 Ch_1_Glob: A Ch_2_Glob: B Arr_1_Glob[8]: 7 Arr_2_Glob[8][7]: 100000010 Ptr_Glob- Ptr_Comp: 0x... Discr: 0 Enum_Comp: 2 Int_Comp: 17 Str_Comp: ... Next_Ptr_Glob- Ptr_Comp: 0x... Discr: 0 Enum_Comp: 1 Int_Comp: 18 Str_Comp: ... Microseconds for one run through Dhrystone: 0.3 Dhrystones per Second: 3333333.3“Final values...”这部分是校验和用于确保程序逻辑正确执行没有因编译器错误优化而导致错误。你应该将其与官方参考值或在不同平台运行的第一遍结果进行对比确保一致。“Microseconds for one run...”执行一次Dhrystone循环所需的微秒数。“Dhrystones per Second” (DPS)这是我们最关注的数字即每秒执行的循环次数。注意事项有些移植版本像我用的那个可能通过-I-这样的参数来抑制中间输出或改变迭代方式。请务必查阅你所用源码包中的README或注释了解正确的运行参数。多次运行取平均值并确保系统在空闲状态。7. 常见问题与排查技巧实录在实际操作中你可能会遇到以下问题**Q1: 编译时出现undefined reference totimes错误。** **A1:** 这是因为在非Linux环境如一些裸机或RTOS环境下times()系统调用不存在。你需要修改dhry_1.c 中的计时函数。通常需要替换为平台特定的高精度计时器例如对于裸机可以使用CPU的周期计数器如ARM的PMCCNTR。对于某些RTOS使用其提供的tick或clockAPI。修改后可能需要定义HZ宏来将计时器单位转换为秒。Q2: 在开发板上运行速度慢得不可思议或者快得离谱。A2:慢得离谱检查是否使用了-O0无优化编译。务必使用-O2。同时确认编译器的-mcpu或-march选项是否正确设置了目标CPU架构。快得离谱检查编译器是否进行了过度优化。尝试去掉-funroll-loops等激进选项。最极端的情况是编译器可能将整个循环计算优化成了常量。可以检查反汇编代码或者尝试在循环计数器等变量前加上volatile关键字但这会改变测试性质仅用于诊断。Q3: 两次运行的结果差异很大。A3:确保测试时系统空闲。关闭不必要的后台进程、网络服务等。如果板子有动态频率调整DVFS如CPUfreq请在测试前将调控器设置为performance模式并锁定在最高频率echo performance /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor。关闭其他核心如果是多核echo 0 /sys/devices/system/cpu/cpu1/online(对于cpu1)。进行热启动先运行一次测试让CPU缓存“热”起来然后连续运行多次取后几次的结果。Q4: 我想对比A53和M4内核Dhrystone结果有意义吗A4: 意义非常有限。Cortex-A53应用处理器和Cortex-M4微控制器设计目标、内存架构、支持的指令集完全不同。Dhrystone主要反映整数和控制逻辑性能但M4可能没有缓存而A53有。这会对测试结果产生巨大影响。两者的编译器优化策略差异极大。它们运行的软件生态Linux vs. 裸机/RTOS完全不同系统开销不在一个量级。 更合理的对比方式是为每个平台选择其典型的应用场景和测试集如A53跑CoreMark/Linpack M4跑EEMBC的IoT相关测试套件。Q5: 除了Dhrystone现在嵌入式领域更推荐用什么A5:CoreMark由EEMBC维护专门为嵌入式系统设计代码模式更合理避免了Dhrystone许多可被投机优化的问题。它是目前首选的、免费的、轻量级CPU整数性能基准测试。EEMBC Benchmark Suites行业标准包含多个针对不同领域的测试套件如IoTMark, ULPMark需要会员资格但结果权威。SPEC CPU 2017桌面和服务器的黄金标准极其庞大和复杂但对于高性能嵌入式应用处理器如Cortex-A72/A76的评估有参考价值。行业特定测试图形用GLBenchmark/GFXBench网络用iperf存储用fio等。那次对2410和270的测试虽然最终没有直接解决Qtopia卡顿的问题那需要更深入的内存和图形剖析但它像一把精准的手术刀帮我排除了CPU整数算力这个错误答案将排查方向清晰地引向了内存子系统和图形渲染流程。在嵌入式开发中这种“大胆假设小心求证用简单工具排除复杂干扰”的思路其价值远超过任何一个具体的测试分数。工具会过时但系统化的性能分析思维永远不会。下次当你遇到“这板子怎么跑得没那个快”的疑惑时不妨也从一次干净利落的Dhrystone测试开始。
