有谁知道任何优化嵌入式设备能耗代码的编译器？答案

【问题标题】：Does anyone know any Compiler which optimizes code for energy consumption for embedded devices?有谁知道任何优化嵌入式设备能耗代码的编译器？
【发布时间】：2011-06-12 09:31:39
【问题描述】：

一般认为更快的代码会消耗更少的能量，因为您可以将 CPU 置于空闲状态更长的时间，但是当我们谈论能量消耗时，有以下一种可能性：

假设有一个指令序列在 1ms 内执行，在执行过程中平均电流消耗为 40mA。 .你的Vdd是3.3V

所以总能量消耗 = V*I*t = 3.3 * 40*10^-3 * 1*10^-3 焦耳 = 13.2*10^-6 焦耳

在另一种情况下，有一个指令序列在 2ms 内执行，在执行过程中平均电流消耗为 15mA。 .and Vdd 为 3.3V

所以消耗的总能量 = V*I*t = 3.3 * 15*10^-3 * 2*10^-3 焦耳 = 9.9*10^-6 焦耳

所以问题来了。 ...是否有任何架构具有不同的指令集来执行具有不同电流消耗的相同任务？

如果有...那么是否有任何编译器会考虑到这一点并生成节能的代码？

【问题讨论】：

一个例子是除以 2 的幂，这可以通过右移来完成。除法和右移都需要 x86 上的一条指令，但我几乎可以肯定右移将使用更简单的电路，从而消耗更少的内存。这是最简单的例子，但我不知道有哪个编译器可以精确优化能耗，也没有任何处理器的数据表隐含提及特定指令的数据消耗。
顺便说一句，你看到那些赞成票了吗？那是因为这个问题很好。

标签： compiler-construction computer-architecture energy

【解决方案1】：

我不知道，但我认为这应该可以使用 LLVM 之类的编译器框架，通过调整指令调度程序的加权算法来实现。

编辑：在 FOSDEM 上有一个关于 Energy Consumption Analytics in LLVM 的讨论。

【讨论】：

【解决方案2】：

在单个指令级别，诸如移位而不是乘法之类的事情肯定会降低电流并因此降低能耗，但我不确定我是否购买了您的示例，即花费两倍的时间但使用一半的电流（对于给定的时钟速率） .用移位和加法代替乘法，使时间加倍，真的需要一半的电流吗？ CPU 中发生了很多其他事情（只是芯片上的时钟分配需要电流），我认为背景电流使用占主导地位。

降低时钟频率可能是降低功耗的最重要措施。尽可能多地并行是降低时钟速率的最简单方法。例如，在显式中断上使用 DMA 允许算法处理在更少的周期内完成。如果你的 CPU 有奇怪的寻址模式或并行指令（我在看你，TMS320），如果你不能将紧密循环的执行时间减半，远低于电流的两倍，我会感到惊讶，从而节省了净能源。在 Blackfin 系列 CPU 上，降低时钟可以降低核心电压，从而显着降低功耗。我想这在其他嵌入式处理器上也是如此。

在时钟频率之后，我敢打赌，功耗主要由外部 I/O 访问决定。在低功耗环境中，诸如缓存未命中之类的事情会伤害您两次——一次是速度，一次是进入外部存储器。因此，例如，循环展开可能会使事情变得更糟，因为乘法所需的指令数量会增加一倍。

所有这一切都是说，创造性的系统架构可能会比告诉编译器更喜欢一组指令而不是另一组指令产生更大的功率影响。但是我没有数字可以支持这一点，我很想看看。

【讨论】：

【解决方案3】：

试试“MAGEEC”。我没有编译器的第一手经验。但是网站上的描述说可以生成节能代码。

【讨论】：

【解决方案4】：

实际上，由编译器完成的任何“代码优化”，比未优化的代码计算答案更快，都是“节能”。（正如另一位发帖人所观察到的，避免缓存未命中是一大胜利）。所以真正的问题是，“哪些优化明确旨在节省能源，而不是减少执行时间？” （注意：一些“优化”减少了代码占用空间（通过将代码序列抽象为子例程等）；这实际上可能会消耗更多的能量）。

一个我在任何编译器中都没有见过的不寻常的方法是改变数据的表示。事实证明，存储/传输 0 位的成本与存储 1 位的成本不同。（我对 TTL 和 CMOS 的经验是“零”更昂贵，因为它们在硬件中实现为一种通过电源电阻的“有源下拉”，导致电流流动从而发热，而“一”是通过相同的下拉让信号“浮动高”来实现）。如果存在偏差，则应实现程序代码和数据以最大化 1 位的数量，而不是 0 位。

对于数据，这应该相对简单。请参阅this paper 以获得对内存中发现的价值的非常好的调查和分析；它包含一些非常棒的图表。一个常见的主题是大量内存位置被一小组不同值的成员占用。事实上，只有极少数的值（最多 8 个）占用最多48% 的内存位置，通常是非常小的数字（论文显示，对于某些程序，很大一部分数据传输是针对小值的，例如 0 到 4，其中 0 基本上是最常见的值） . 如果 0 的存储/传输成本确实比 1 高，那么小的常见值建议以它们的补码格式存储值。这是一个非常容易实现的优化。鉴于这些值并不总是最小的 N 个自然值，可以用 N 替换内存中第 N 个最频繁的值并存储 N 的补码，从而在更接近处理器的位置查找实际值。（论文作者建议使用硬件“值重用”缓存，但这不是编译器优化）。

这对于程序代码来说有点难以组织，因为指令集决定了你能说什么，而且通常指令集是独立于任何能量测量而设计的。然而，人们可以选择不同的指令序列（这就是优化器所做的）并最大化指令流中的一位。我怀疑这对传统的指令集操作码非常有效。一旦肯定可以将变量放置到地址具有大量一位的位置，并且更喜欢使用具有更高数字而不是更低数字的寄存器（在 x86 上，EAX 是二进制寄存器编号 000，EDI 是寄存器编号 111）甚至根据指令执行频率设计指令集，为频繁执行的指令分配更多个1的操作码。

【讨论】：