如何在ARM平台上开发低功耗的软件系统

liyf

                    ???? 摘要：在强调便携式设备的电池寿命时，看起来比较奇怪是，很少有软件工程师在其日常项目任务中真正做到了减少能耗。我猜想对这个课题有所想法的那些人可能都是本着荣辱自担的想法才关注此课题的。我们到了要做些改变的时期。随着电池寿命和性能要求的矛盾持续，我们作为软件工程师不得不要用更多时间来找出如何才能以节能方式来设计和编写我们的软件，至少在工具能满足我们要求之前需要这样做。
　　我们这些软件工程师都热衷于为我们遇到的问题找出完美的解决方案。但奇怪的是，我们会发现在这个特定的领域，没有一个完美的解决方案。聪明的技巧可能会节省一些功率，但是这个领域是由其他更简单的因素支配的。就象房间里有几头很大的大象，我们必须要先小心翼翼地猎取我们可以看到的大象，然后再花精力去猎捕体型小的动物。
　　在考量某个系统的功耗时，重要的是要弄清楚我们实际测量的对象是什么。我们说的“节省功耗”可能意味着几个方面。它意味着“功率”还是“能量”。实际上，我们既需要功率也需要能量。大多数手持便携式设备均具有以下两个不同的预算：功率预算——它管理着瞬间功耗、避免过热或产生热应力，而能量预算则管理着长期使用的能量总数。而软件则需要满足短期的功率预算和长期的能量预算。
　　很明显，我们可以把任何设备的功耗降低到接近零，只要不让它做任何操作或任何有意义的操作即可！不得已的是，实现有用的功能就需要耗费能量。因此，我们只能在有意义的操作和节能二者中不断采取折衷方案。为了实现所需的功能，我们必须耗能；但我们必须尽量确保以节能的方式来实现这些功能。
　　功耗时间积??? 有关该主题的学术材料中常用的更好度量方式是采用“功耗时间积”。尽管既没有标准单位也没有具体方法，但是这种度量方式将能耗和性能度量结合到了一起。增加能耗或降低性能会增加功耗时间积的值，因此我们的目标是找出最低的可接受的功耗时间积的值，换句话说，最低的能耗要与允许的时间内所需任务的执行保持一致。
　　能量去哪儿了？ 所有计算器械均会执行两个基本功能。这两个功能都是必需的，没有这两个功能就不能完成任何有意义的任务。
　　我们首先想到的自然是计算或数据处理。通常，计算是对机器寄存器中保存的值实施的操作。为了尽可能高效地实施计算任务，我们需要在最短的时间内执行最少的指令。最重要的是，高效计算允许以下二选一：要么我们可以早点完成计算去睡觉，要么我们调慢时钟且仍然在规定时间内完成计算任务。
　　这里经常被人忽视的是数据通信（数据移动）。在大多数架构中（A R M采用加载/存储架构，也不例外），数据移动是必需的。如果不将信息从一个位置移动到另一个位置且经常返回原来的位置，用户就无法处理任何信息。例如，内存中的值需要移动到寄存器中进行处理，然后把结果写回到内存中。
　　但是哪个耗用的能量更多呢？最大的偿付在哪儿？
　　图1显示了普遍存在的事实，与程序有关的内存存取操作中有大约60%是指令抓取，另外40%才是数据存取。




图2：内存存取能耗
　　图2显示了A R M进行的一些研究。如果执行一条指令的能耗是1，那么，紧耦合存储器(TCM)存取的能耗约为1/25，缓存存取的能耗大约为1/6。而外部R A M存取的能耗则是指令执行能耗的7倍。
　　换言之，对于每次外部R A M存取所用的能耗，我们可以执行7条指令，40次缓存存取或大约170次TCM存取。
　　计算廉价但通信昂贵
　　因此，似乎数据移动要比数据处理更昂贵。因此，第一头大象就是数据效率。
　　我们可以为内存存取的能耗管理提出两个规则。
　　近距离 - 从能量角度讲，内存越靠近核心，访问内存的相对能耗越低。
　　少存取 - 减少内存存取次数比减少指令数量更加重要。
　　充分利用片上存储器
　　从我们的能量图可以清楚地看出，TCM是到目前为止系统具有的最高效存储器类型。不是所有的系统均具有A R M称为TCM的存储器（通过专用和优化的接口连接到内核），但是大部分系统至少具有某种片上快速存储器类型。为了便于讨论，我们指的是常见的片上存储器(SPM)。假定S PM单次存取能耗大约是外部R A M存取能耗的1/170，充分利用这种SPM存储器应该是首选。




图4：缓存的能量优势
　　图4摘自普林斯顿（Brooks，2000）一份论文，显示了针对某简单应用基准的三套数据。针对不同的缓存大小，这些条块分别代表性能IP C（单位周期指令数）、功耗和功耗时间积(ED P)。总的来说，性能会随着缓存大小的增加而提升。但是，系统的功耗也会增加，因为增大缓存单元会相应增加功耗。功耗时间积允许我们在性能和缓存大小之间取得平衡。在这个例子里，存在一个最佳点，即缓存大小为64k时，此时的功耗时间积最小。
　　最大限度减少数据内存存取
　　A RM架构的一个特性是其常量是不确定的，特别是，不可能用单条指令把一个任意32位常量放到一个寄存器中。实际上，所有内存存取必须按寄存器中的地址操作，这就意味着程序需要把这些地址和其他常量频繁地放到寄存器中，而这一点很难做到。解决此问题的标准方法是把常量作为文字数据嵌入到代码段中，在运行时使用PC相关的加载进行加载。
　　因此，这种最大限度减少常量影响的方法很实用。确保在编译时这些常量是已知的，如果可能，最好能把这些常量嵌入到单条ARM指令中。为了存取全局变量，尽可能减少加载基址指针的需求。这就需要确保全局变量在运行时都在内存中，这样才能使用单个指针存取多个变量。实现这个目标最简单的方式是将全局变量放到一个结构中。
　　尽管A R M的堆栈访问相对高效（堆栈访问可较好地加载和存储多条指令），但是程序员还可以通过很多方式来减少堆栈访问：减少活动变量、避免占用本地变量地址、可能时充分利用尾部调用优化、将传递到函数的参数数量减少到四个以下、允许编译器主动内联函数等。
　　递归情形和避免递归情形的做法更加复杂。通常编译器可以对归函数很好地进行尾部优化。实际上将所有数据存储到堆栈中可以比其他做法获得更好的局部性。或许建议可能最好表达为“除非其他做法让数据局部性更糟或您确信编译器可以对递归调用进行尾部优化，否则不要使用递归算法”。应编写异常处理程序，增加尾部连锁的机会，进而避免堆栈环境内不必要的保存和恢复。
　　现在我们把注意力转到这个问题的第二头大象，即指令执行。
　　最大限度减少指令数目
　　事实上，减少指令执行次数本质上与性能优化是相同的，执行的指令数越少，能耗就越低。另外，还要增加一些明显的指针。
　　首先，正确地配置工具。在编译器和链接器完全了解目标平台，甚至无法实施一些基本的优化。
　　编写代码时要保持敏锐，才能避免不必要的操作。对于A R M架构，32位数据类型是高效的：一般8位和16位数据类型，尽管占用的存储空间较少，但是处理效率也较低。在v6和v7架构中，打包和接包指令以及S IM D操作一定程序上对此有些帮助，但是要注意，在主程序中无法从C访问这些指令。
　　编写循环时要当心
　　可以按照以下一些简单的规则来编写循环：使用无符号的整数计数器，向下倒数，并把是否等于零作为终止条件。这可以让循环更短，速度更快，使用的寄存器更少。还要记住，要采用矢量化来编写循环。即使在尝试展开和矢量化最简单的循环时，有关控制结构和数据声明的一些简单规则都可以让编译器的作业变得更简单。




图6：系统组件电源利用
　　其次，对于所有配置而言，每次迭代的能耗从本质上讲是相同的，与时钟速度无关。因此，为了更快地完成任务而启用所有功能并全速运行要比调慢时钟速度更加高效。
??? 多重处理
??? 众所周知，与调高单核的功率相比，采用多核可以获得更高的性能和更好的能效。使用多核系统时，我们必须考虑在不需要时选择中止一个或多个内核。A R M的研究表明，S M PLinux系统中单核循环的成本是50000个周期（大部分周期用于清除一级缓存），这意味着此操作将在几百毫秒内完成，而不是更短的时间内完成，否则其能耗成本将超过其具有的优势。
　　ARM是主动研究型架构，其包含两个内核，一个高性能的内核用于全功能操作，一个较小的配套内核则以较低的性能完成低功率操作。需要较高的处理功率时，系统运行较大的内核。任务完成时，系统可以把所有信息传递给小内核并关闭大内核。需要逆向信息移动时，再切换回大内核。如果这两个内核相连成为相关系统，则切换的能耗成本可降到最低。
　　关于操作系统
　　不巧的是，在操作系统上运行时，应用程序员无法这样灵活处理。缓存配置、S PM使用与否、组件的电源周期等很大程度上都是操作系统架构和设备驱动程序来专门决定的。但是，应用程序员仍然有很多东西需要考虑。
　　研究已经表明，设计不良的进程间通信(I P C)会大大增加系统的能耗。一个简单的技术称为“矢量化”进程间通信，这种技术批量处理小的消息并把大量小的消息作为一个大的消息来发送，这样通常可以减少上下文的切换开销。另外，减少进程数量可明显降低进程间通信的需求。需要频繁通信的进程可以合并成一个进程。
　　在嵌入式Linux中运行的最近研究(Tan, 2003)表明，分析和合理设计进程间通信2 可以潜在改进能耗多达60%。
　　结论
　　尽管我已经强调了许多领域仍然属于学术研究范围，但我们现在还是可以做许多工作。结果相对比较简单：减少外部内存存取，减少指令执行，并在不使用某些单元时关掉它们。
　　在做出这个结论的同时，我想起了2 0 0 9年中期在一次培训课上与客户的一次谈话。这些客户关心如何在包含了N e o n的C or tex-A8平台上实现信号处理算法且想要知道个别指令的确切能耗。我解释说，实际上很多这种信息是未知的，而且不管在什么情况下，很难使用当前的工具得出这些信息。回顾上文，我们已经认识到在捕猎大象的这个长期任务中，这些信息都是无关紧要的。实际上，客户要捕猎的大象与房间中的其他大象相比，非常的小。不管是经过分析还是持续跟踪数据，都可以得出更好的建议，那就是估算每次实现中涉及的数据存取次数和类型。这样，再结合指令计数，可以做出更加明智的选择。与内存存取布置不良相比，个别指令的功耗几乎无关紧要。
　　我们这些软件开发人员要继续对学术和工具供应商施加压力，让他们在下一代工具中构建出这些功能。这不容易但将会实现。
　　最后，我必须提醒大家所有这些取决于您所用的系统、平台、应用程序、操作系统、电池和用户。就像俗话说的“优势各有不同”。