微控制器的性能分析技术的介绍与了解

基准测试让您比较处理器，但仍有很多变化。理解和运行标准基准可以让设计人员更好地了解和控制他们的应用程序。

比较微处理器从未如此简单。即使比较通常具有相同基本架构的所有变体的处理器的台式计算机或膝上型计算机也可能令人沮丧，因为与“更差”的数字相比，具有更快数字的计算机可能运行缓慢。在嵌入式世界中，事情变得更加艰难，其中处理器和配置的数量实际上是无限的。

基准测试是解决这一难题的常用方法。多年来，Dhrystone基准（Whetstone基准测试中的一个游戏，其中包括Dhrystone省略的浮点运算）是城里唯一的游戏。但是，它有许多重大问题。其中最主要的是它不反映任何实际计算，它只是试图模仿各种操作的统计频率。此外，编译器通常可以在编译时执行大部分计算，这意味着在运行基准测试时不必完成工作。

对基准测试的真正考验是，在详细查看结果（特别是那些最初看起来很奇怪的结果）时，您可以合理化为什么结果看起来像他们一样。理想的基准测试将提供纯粹反映处理器性能的分数，与系统的其他部分无关。不幸的是，这是不可能的，因为没有处理器孤立地运行：所有处理器必须与内存交互 - 高速缓存，数据存储器和指令存储器，每个处理器可能会或可能不会以完整的处理器频率运行。此外，这些处理器必须全部运行由编译器生成的代码，并且不同的编译器生成不同的代码。

即使是相同的编译器也会根据编译代码时选择的优化设置生成不同的代码。这种差异是无法避免的，但要避免的主要是将实际的基准代码优化掉。

尽管结果可能取决于编译器和内存，但您应该只能根据处理器本身，编译器（和设置）以及内存速度来解释任何此类结果。 Dhrystone基准测试的情况并非如此。然而，嵌入式微处理器基准联盟（EEMBC）最近的CoreMark基准测试已经克服了这些缺陷，并且被证明更加成功。点击EEMBC在2009年开发并公开发布了CoreMark基准（现已由超过4，100名用户下载）。它已经适用于众多平台，包括Android。开发人员特别注意避免旧基准测试的陷阱。通过查看CoreMark基准测试的工作原理以及一些示例结果，我们可以看到它不仅可以成为性能的可靠指标，还可以帮助确定微控制器和编译器性能的改进位置。

CoreMark基准程序

CoreMark基准程序使用三种基本数据结构来表示实际工作。第一个结构是链表，它执行指针操作。第二个是矩阵;矩阵运算通常涉及严格优化的循环。最后，状态机需要难以预测的分支，并且其结构比用于矩阵运算的循环要少得多。

为了保持尽可能多的嵌入式系统的可访问性，无论大小，该程序都有2 kb的代码占用空间。图1说明了程序的工作原理。前两个步骤可能看似微不足道，但它们实际上非常重要 - 它们是确保编译器无法预先计算任何结果的步骤。直到运行时才知道要使用的输入数据。

图1：CoreMark基准测试过程。

大部分基准工作负载发生在主工作循环中。扫描其中一个数据结构，即链表。每个条目的值确定是否要执行矩阵操作或状态机操作。重复该决策操作步骤直到列表用尽。此时，单个迭代完成。重复工作循环直到至少10秒钟。实施10秒要求以确保足够的数据以提供有意义的结果。如果运行时间小于此值，那么基准程序将不会报告结果。但是，如果用户在模拟器上运行基准测试，则可以修改此时间要求。

主要工作完成后，使用公共循环冗余校验（CRC）功能;它可以作为一种自我检查，以确保在执行过程中（偶然或其他方面）没有出错。假设一切都结束，程序将报告CoreMark结果。此数字表示每秒执行时间的主工作循环的迭代次数。点击虽然大多数基准用户都是诚实的，但确保任何基准测试方案都有针对滥用的保护措施始终是非常重要的。有人可以尝试篡改结果的两种主要方式：编辑代码（在移植层内除外），因为代码必须以源代码形式提供，并且只是伪造结果。 CRC有助于检测代码损坏时可能出现的任何问题，并且EEMBC技术中心的认证是最终仲裁者。没有人需要对他们的结果进行认证，但认证增加了显着的可信度，因为它证实了中立的第三方获得了相同的数字。

调整基准测试运行

当程序查找用于初始化数据的用户参数时，您不会显式提供原始数据。这将是太多的工作，它还将通过仔细选择初始化数据开辟操纵的可能性。相反，程序会查找必须由用户设置的三粒种值。

这些数字以对用户不透明的方式指导数据结构中值的初始化。虽然它们充当“种子”，但没有随机因素。结构是完全确定的，并且具有相同种子的基准的多次运行将导致相同的执行和结果。

您可能还需要调整基准来考虑系统分配内存的方式。具有充足资源的系统可以简单地使用heap和malloc（）调用。这允许在需要时进行每次内存分配，并确保所需的内存量。然而，这种灵活性需要付出代价，更好的系统需要更快的方式来使用内存。

最快的方法是完全预分配内存，但使用不可行的链表操作。中间方法是创建许多预定义的内存块（内存池），可以根据需要进行分配。权衡是你不能选择每个块中有多少内存 - 你得到一个固定大小的块。移植层允许您使基准测试适应被评估系统上使用的内存分配方案的类型。并行性是您可以利用的另一个特性，如果您的系统支持它。您可以为并行操作构建CoreMark基准，指定在执行期间生成的上下文（线程或进程）的数量。但是，您应该避免使用CoreMark来表示处理器的多核性能，因为由于其小尺寸，该基准测试肯定会线性扩展99.9％。

了解结果

当然，这是您对基准测试结果所做的事情，可能导致混淆（有意或无意）。出于这个原因，EEMBC强加了严格的报告要求。 CoreMark网站http://www.coremark.org提供了报告结果的位置，您不能只输入一个CoreMark分数。还有一些其他关键变量可能会影响您的结果。

最大的是使用的编译器和编译基准时设置的选项。您必须在提交结果时报告该信息。

第二个主要影响因素是分配内存的方式 - 如果它不是堆（malloc），您必须报告所采用的方法。

第三个因素，在相关时，是并行化。您必须报告创建的上下文的数量。

还有另一种方法可以报告结果。您可以将时钟频率标准化，而不是指定原始CoreMark值，以便专注于架构效率。这是一个CoreMark/MHz值，用于衡量每百万个时钟周期的迭代次数。如果报告此编号，则还必须报告相对于处理器时钟速度的内存速度。如果可以相对于处理器频率配置高速缓存频率，则还必须报告该配置。

查看某些特定结果可以帮助显示各种所需报告元素如何与不同的基准分数相关联，以及在报告结果时识别这些元素的重要性。随后的所有数字均来自CoreMark网站上公开的结果列表。

编译器版本的简单影响可以在表1的结果中看到。使用较新的编译器版本，ADI公司的处理器显示速度提高了10％，可能表明新编译器的工作做得更好。 Microchip示例显示了两个更远的GNU C编译器（gcc）版本之间的差异。对于两个恩智浦处理器，所有编译器都是同一版本的微妙变体，从而最大限度地减少了差异。

ProcessorCompilerCoreMark/MHz模拟器件BF536gcc 4.1.21.01gcc 4.3.31.12Microchip PIC32MX36F512Lgcc 3.4.4 MPLAB C32 v1.00-200710241.90gcc 4.3.2（Sourcery G ++ Lite 4.3-81）2.30NXP LPC1114Keil ARMcc v4.0.0.5241.06gcc 4.3 .3（红色代码）0.98NXP LPC1768ARM CC 4.01.75Keil ARMCC v4.0.0.5241.76表1：不同编译器对CoreMark结果的影响。即使使用相同的编译器，不同的设置当然会产生不同的结果因为编译器试图以不同方式优化程序。表2显示了一些示例结果。

ProcessorCompilerSettingsCoreMark/MHzMicrochip

PIC24JF64GA004gcc 4.0.3 dsPIC030，Microchip v3_20-Os -mpa1.01-031.12Microchip

PIC24HJ128GP202gcc 4.0.3 dsPIC030，Microchip v3.12-031.86-mpa1.29Microchip

PIC32MX36F512Lgcc 4.4.4 MPLAB C32 v1.00-20071024-021.71-031.90表2：更改编译器设置会产生不同的CoreMark结果。

第一个例子（PIC24JF64GA004），针对较小的代码尺寸进行优化需要降低约10％的基准性能。在第二种情况下，差异更为显着，在设置过程抽象优化标志（-mpa）时运行速度降低30％。最后一个处理器上的编译器设置之间的差异也反映了优化量的差异，从-O3设置提供的更高速度优化中获益大约10％。

内存的影响可以在表3中看到。在第一种情况下，当时钟频率超过闪存可以处理的频率时，会引入等待状态，从而降低CoreMark/MHz数量。类似地，在第二种情况下，DRAM无法跟上50 MHz以上的处理器，因此存储器和处理器之间的时钟频率比降至1：2，从而降低了CoreMark/MHz数量。

ProcessorClock

SpeedMemory NotesCoreMark/MHzCoreMarkTI OMAP 3530500Code in FLASH2.4212106002.191314TI Stellaris LM3S9B96 Cortex M3501：1内存/CPU时钟不可能超过50 Mhz1.9296801.60128表4：更改缓存大小对CoreMark结果的影响。 》然而，在这两种情况下，时钟频率的增加都大于运行效率的降低，因此原始CoreMark数量仍然随着时钟频率的增加而增加;它只是没有像频率那样增加。点击最后，缓存大小的影响可以在表4中看到。这里，代码适合第一个配置的2 kb缓存，但它完全填充缓存。堆栈上的所有函数参数都不适合，因此会有一些缓存未命中。在第二种情况下，缓存具有两倍的容量，这意味着它不会遇到与第一个示例中相同的缓存未命中，从而为其提供更好的分数。

ProcessorCompilerCoreMark/MHzAnalog器件BF536gcc 4.1.21.01表3：内存设置对CoreMark结果的影响。

请注意，与第一种情况的三级流水线相比，第二种情况有五级流水线。由于状态机示例的广泛分支，较长的管道应该导致性能下降。当分支被错误预测时，较长的管道需要更长的时间来重新填充。因此，较高的CoreMark分数表明较大的缓存超过了这种降级。

所有这些例子中的得分都证明了两个事实。首先，单个数字（在本例中为CoreMark/MHz）可以准确地表示底层微控制器架构的性能;后面的例子清楚地表明了这一点。其次，背景是重要的。编译器可以影响它生成的代码执行的程度。这几乎应该是显而易见的 - 人们花费大量时间来开发和改进编译器以改进他们创建的结果，但“好”结果取决于您的目标是快速代码还是小代码。更快的代码将运行得更快，更小的代码将不会运行（除非它实际上有助于优化内存或缓存利用率）。但是，这些例子显示的最重要的事情是结果之间的差异有合理的解释。它们不是由一些实际的基准测试代码引起的，这些代码可能有利于一个微控制器架构而不是另一个，或者是编译器直接丢弃代码。从这个意义上讲，CoreMark基准测试是公平和平衡的，可以真实地反映编译器和体系结构，而且只能反映编译器和体系结构。