新闻中心

EEPW首页 > 嵌入式系统 > 设计应用 > 如何在ARM平台上开发低功耗的软件系统

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

作者:时间:2012-06-21来源:网络收藏

图4:缓存的能量优势

图4摘自普林斯顿(Brooks,2000)一份论文,显示了针对某简单应用基准的三套数据。针对不同的缓存大小,这些条块分别代表性能IP C(单位周期指令数)、时间积(ED P)。总的来说,性能会随着缓存大小的增加而提升。但是,系统的也会增加,因为增大缓存单元会相应增加功耗。功耗时间积允许我们在性能和缓存大小之间取得平衡。在这个例子里,存在一个最佳点,即缓存大小为64k时,此时的功耗时间积最小。

最大限度减少数据内存存取

A RM架构的一个特性是其常量是不确定的,特别是,不可能用单条指令把一个任意32位常量放到一个寄存器中。实际上,所有内存存取必须按寄存器中的地址操作,这就意味着程序需要把这些地址和其他常量频繁地放到寄存器中,而这一点很难做到。解决此问题的标准方法是把常量作为文字数据嵌入到代码段中,在运行时使用PC相关的加载进行加载。

因此,这种最大限度减少常量影响的方法很实用。确保在编译时这些常量是已知的,如果可能,最好能把这些常量嵌入到单条指令中。为了存取全局变量,尽可能减少加载基址指针的需求。这就需要确保全局变量在运行时都在内存中,这样才能使用单个指针存取多个变量。实现这个目标最简单的方式是将全局变量放到一个结构中。

尽管A R M的堆栈访问相对高效(堆栈访问可较好地加载和存储多条指令),但是程序员还可以通过很多方式来减少堆栈访问:减少活动变量、避免占用本地变量地址、可能时充分利用尾部调用优化、将传递到函数的参数数量减少到四个以下、允许编译器主动内联函数等。

递归情形和避免递归情形的做法更加复杂。通常编译器可以对归函数很好地进行尾部优化。实际上将所有数据存储到堆栈中可以比其他做法获得更好的局部性。或许建议可能最好表达为“除非其他做法让数据局部性更糟或您确信编译器可以对递归调用进行尾部优化,否则不要使用递归算法”。应编写异常处理程序,增加尾部连锁的机会,进而避免堆栈环境内不必要的保存和恢复。

现在我们把注意力转到这个问题的第二头大象,即指令执行。

最大限度减少指令数目

事实上,减少指令执行次数本质上与性能优化是相同的,执行的指令数越少,能耗就越低。另外,还要增加一些明显的指针。

首先,正确地配置工具。在编译器和链接器完全了解目标,甚至无法实施一些基本的优化。

编写代码时要保持敏锐,才能避免不必要的操作。对于A R M架构,32位数据类型是高效的:一般8位和16位数据类型,尽管占用的存储空间较少,但是处理效率也较低。在v6和v7架构中,打包和接包指令以及S IM D操作一定程序上对此有些帮助,但是要注意,在主程序中无法从C访问这些指令。

编写循环时要当心

可以按照以下一些简单的规则来编写循环:使用无符号的整数计数器,向下倒数,并把是否等于零作为终止条件。这可以让循环更短,速度更快,使用的寄存器更少。还要记住,要采用矢量化来编写循环。即使在尝试展开和矢量化最简单的循环时,有关控制结构和数据声明的一些简单规则都可以让编译器的作业变得更简单。

图5:循环展开

图5显示了与一个特定循环优化有关的一些数据,这个循环优化就是循环展开(Brooks,2000)。按照预期,随着展开因子的增加,执行时间和指令数目会减少。我们看到了减少循环开销和减少地址计算的效果。功率结果更加有趣,但不太明显。因为预测器可用来训练其行为的分支更少且针对循环结束失败的最终错误预测比例大增,所以随着循环进一步展开,分支预测器的准确性出现下降。但是,因为顺序取指的连续数据流不经常被中断,所以取指阶段的效率可以提升。组合的结果是减少了每条指令的净能耗。

因此尽管执行时间基本上低于展开因子4,但是因为功耗持续降低,所以所有重要的功耗时间积也随之降低。因此有能耗意识的编译器或人员与只考虑执行时间的编译器或人员相比,会更倾向于展开循环。

精度满足需求即可

还必须考虑输出要求的精度。即使有浮点硬件可用,定点实现的计算通常比浮点实现的计算更有效率。如果您正在渲染一个供屏幕查看的图像,可能并不需要完全符合标准,您只需要渲染出可以接受的图像。

对标准M P E G- 4解码函数进行递进优化的一项研究(S h i n,2002)已经表明,把软浮点切换为定点二进制可以把能耗降低72%。精度损失意味着该结果不再符合标准,但是在所研究的系统上仍然足以满足渲染用途。

关于Thumb

T humb指令集专门设计用于改进代码密度,还可以提升窄内存系统的性能。但是,在代码密度确实改进的同时,指令数也同时增加了。这是因为,与A R M指令相比,减少了个别Thumb指令的功能。因此Thumb重新编译会造成能耗增加,这看起来是合理的,而我们看到的事实也的确是这样。

上述研究表明,如果代码大小减少4%,指令执行数增加38%,而能耗增加28%。为了找到第三头大象,我们需要走出处理器及其内存的领域,着眼于范围更大的系统。我们这些天使用的系统已经被我们的硬件设计同事组合到了一起,这个系统提供了大量节能选项。

更广系统中的节能

显而易见,没有使用的组件应尽可能置于低功耗状态。这也是所有敏锐的设计系统不可分割的组成部分,这些组件应包括内存和缓存系统、甚至是处理器本身。在多核系统中,我们必须考虑在处理要求相对低时中止一个或多个内核运行的可能性。

首先,一个很小但值得考虑的问题是:处理外设时,要始终尝试使用中断机制,而不是轮询机制。轮询循环只会耗用能量而无任何目的。几乎所有架构均包括了某种等待中断的指令,可以把这种情况下的系统置于待机状态。对于A R M系统,内核通常带有时钟门控,只保留静态漏电。

通过设计中断架构来增加拖尾连锁,一般可以避免不必要的睡眠唤醒循环。 Cortex-M3架构可以自动实现这一点。



评论


相关推荐

技术专区

关闭