哪个代码消耗更少的能量？答案

【问题标题】：which code is consuming less power?哪个代码消耗更少的能量？
【发布时间】：2012-06-16 04:43:54
【问题描述】：

我的目标是针对某些特殊情况开发和实施绿色算法。我为此开发了两种算法。

一个是没有大的。内存访问（加载和存储）。该模式有时是合并的，有时是非合并的。我假设最坏的情况是大多数访问都会导致缓存失败。请参阅示例代码 sn-p a)。

另一个是大号。的计算，大致相当于下面的代码 sn-p b)。

如何估算每种情况下的功耗。哪一个更节能，为什么？

平台：我将在 Intel I3 处理器、Windows 7、4 GB DRAM、3 MB 缓存上运行这些代码。

注意：我不想使用任何外部功率计。如果您发现代码没有做任何建设性的工作，也请忽略。这是因为它只是完整算法的一小部分。

更新：

这很困难，但并非不可能。人们可以很好地计算出读取 DRAM 和 CPU 的 ALU 进行乘法的成本。唯一的一点是必须具备 DRAMS 和 CPU 的电子学知识，我目前缺乏这些知识。至少在最坏的情况下，我认为这可以很好地成立。最坏的情况意味着没有合并访问，没有编译器优化。

如果您可以估计访问 DRAM 和进行浮点乘法的成本，那么为什么无法估计电流，从而粗略了解这些操作期间的功率？另请参阅我的帖子，我不是在问多少功耗，而是在问哪个代码消耗的功率更少/更多，或者哪个代码更节能？

a) for(i=0; i<1000000; i++)

  {

  a[i]= b[i]; //a, b floats in RAM.  

  {




 b) for(i=1; i<1000000; i++)

  {

   float j= j * i;  //j has some value. which is used later in the program , not  
                    // shown here    

  {

【问题讨论】：

这些在做完全不同的事情；比较它们是什么意思？另外，第二个例子是胡言乱语；它根据自身计算一个局部变量，然后丢弃它。
尝试在您的目标平台上运行代码并使用功率计监控功耗 - 这是 100% 确定是否存在显着差异的唯一方法。
孤立地估计代码位的功耗可能是不可能的；还有太多其他事情发生了（您需要查看编译器优化的结果，而不是原始来源）。我的建议是简单地运行您的代码，并用仪表测量功耗。
@OliCharlesworth，我只向您展示了算法的一小部分，因此您可能会将其视为完全不同的东西，尽管您不必为此担心。我只是需要一个关于代码功耗的逻辑视图。
当其他程序启动（例如服务）时，您可以增加分页。页面错误需要 IO，并且可能会显着改变电源使用情况。无论单个程序与可能消耗能量的虚拟内存的交互效率如何，（普通）单个程序都无法控制。

标签： c memory cpu energy

【解决方案1】：

就像评论者指出的那样，尝试使用功率计。在现代超标量架构上，即使不是不可能，也很难从原始汇编代码估计功耗。

【讨论】：

这很难，但并非不可能。人们可以很好地计算读取 DRAM 和 CPU 的 ALU 进行乘法运算所产生的成本。唯一的一点是必须具备 DRAMS 和 CPU 的电子知识。
@gpuguy：但您还需要考虑缓存访问、虚拟内存系统、TLB、页面错误、分支预测、上下文切换、乱序执行等成本。 .

【解决方案2】：

只要只涉及 CPU 和内存，您就可以假设功耗与运行时间成正比。

这可能不是 100% 准确，但在没有实际测量的情况下尽可能接近。

【讨论】：

这对于现代超标量 CPU 来说并非如此——功耗与指令吞吐量有关，即每个时钟您要实现多少指令，并且可能非常重要，具体取决于您有多少执行单元平均而言，设法保持忙碌。
@PaulR，我仍然认为恒定功率/秒是您可以实际做出的最佳近似值。您指出的内容确实会导致一些偏差，但是：A. 我认为这在实际工作负载中并不重要（单元利用率既不是 0% 也不是 100%）和 B：通过阅读代码来估计这种影响是不切实际的.
好吧，我在运行计算密集型代码时测量了服务器上的功耗和风扇出口温度，我可以告诉你，对于充分利用可用执行单元的高度优化代码，它们都显着增加（特别是 SIMD 代码）。你真的必须测量这些东西——几乎不可能在没有很大误差的情况下进行估计。

【解决方案3】：

您可以尝试使用一些 CPU 监控工具来查看哪种算法会使您的 CPU 发热更多。它不会为您提供可靠的数据，但会显示这两种算法在功耗方面是否存在显着差异。

这里我假设主要的电力消耗者是 CPU，算法不需要大量的 I/O。

【讨论】：

【解决方案4】：

要测量实际功耗，您应该在电源中添加electricity meter（如果使用笔记本，请取出电池）。

请注意，您将测量整个系统的功耗，因此请确保避免干扰参数（任何其他系统活动，即防病毒更新、图形桌面环境、索引服务、（内部）硬件设备），执行重复测量，运行或不运行算法以消除“背景”消耗。如果可能，请使用嵌入式系统。

关于您的算法，实际能效不仅取决于 C 代码，还取决于编译器的性能以及与周围系统交互的运行时行为。但是，作为开发人员，您可以通过以下资源来帮助解决此问题：

特别是看看上面“清单”中的工具段落，因为它列出了一些可以帮助您进行粗略估计的工具（基于应用程序分析）。它列出（除其他外）：

性能监控
PwrTest/Windows 驱动程序工具包
Windows 事件查看器（计时器刻度更改事件、Microsoft-Windows-Kernel-PowerDiagnostic 日志）
英特尔 PowerInformer
Windows ETW（性能监控框架）
英特尔应用能源工具包

【讨论】：

我根本不想使用功率计，这可能无法提供我正在寻找的信息。不过，我基本上是在寻找一个粗略的估计。
分析可以让我了解执行时间，但这可能与功耗不成正比。尽管您提供的链接中的信息对我非常有用。
@gpuguy profiling 涵盖的内容远不止执行时间的简单分析。

【解决方案5】：

好吧，我已经完成了与电子专业的初步研究和讨论。

考虑两个因素可以得到一个粗略的想法：

1- 涉及的电流：更多电流，更多功耗。

2- 时钟频率导致的功耗。功耗随频率的平方而变化。

在 Snippet a) 中，DRAM 和存储器几乎不会消耗太多电流，因此每个过程中的功耗都会非常小

  a[i]= b[i];

操作。上面的操作就是数据的读写。

与 CPU 相比，内存的时钟通常非常小。虽然 CPU 的时钟频率为 3 GHz，但内存的时钟频率约为 133MHz 左右。（并非所有组件都以额定时钟运行）。因此，由于时钟较低，功耗较低。

在sn-p b)中，可以看出我在做更多的计算。由于时钟频率要高几个数量级，这将涉及更多的功耗。

另一个因素是乘法本身将包含几个更高的阶数。与数据读写相比的周期数（假设内存已合并）。

另外，如果有一个选项来测量或大致了解某些代码的功耗（“代码能量”），如下所示（颜色代表您的代码的能效程度，红色表示非常差，并且绿色是高能效的）：

简而言之，鉴于当今的技术，软件估计这样的功率并不是很困难（除了我上面描述的方法之外，还可能采用许多其他参数）。这将有助于更快地开发和评估绿色算法。

【讨论】：