算法能耗模型：为什么更快的算法反而更耗电？

我最近在做一块低功耗嵌入式平台的算法移植，被一个现象搞得很困惑：把一个排序模块从快排换成堆排序，理论上比较次数更稳定，跑下来的时间确实快了15%，可是整板功耗反而涨了一截。这让我重新审视算法分析中一个长期被忽略的维度——能耗模型。我们在课程和面试里反复比较时间复杂度和空间复杂度，但很少有人把能耗当成一等的评估标准。可在移动设备、边缘计算、数据中心这些场景里，能耗模型和计算效率的平衡，往往比单纯看耗时更关键。这篇内容我把自己踩过的坑、实测数据和沉淀下来的方法论整理出来，希望对做算法选型和能耗优化的朋友有实际帮助。这也是我这个系列里围绕能耗问题做的第四次系统整理，前几篇偏硬件和体系结构，这篇会把重点放到算法分析本身。

1. 算法分析多了个能耗维度之后，很多“最优解”要重写了

1.1 传统复杂度分析没回答的问题

传统算法分析回答的是：输入规模 n 趋近无穷时，操作次数随 n 怎么增长。这个框架非常优雅，但它隐含地假设所有操作代价一样。实际硬件上，一次乘法指令和一次缓存未命中的代价不同，一次浮点运算和一次内存访问的能耗也不同。当我们把能耗这个维度加进来，“最优算法”的定义就要重新讨论。

以排序为例，快速排序平均情况 O(n log n)，在教科书和工程里都被认为是不错的选择。但快排的递归深度、分支预测失败率、缓存局部性在不同数据分布下波动很大。堆排序呢？它的比较次数稳定，但访问模式是跳跃式的，缓存命中率很差。在特定输入规模下，堆排序的能耗可能比快速排序低，也可能高得多。这些差异只有在能耗模型下才看得出来。

我这么说不是要否定复杂度分析，它仍然是算法设计的骨架。问题在于：很多工程决策完全依赖渐进复杂度排序，把这个排序当成唯一真理，忽略了常数因子、访存模式、运行时功耗行为这些在能耗视角下同样关键的因素。做与传统复杂度分析互补的能耗评估，往往能发现“标准答案”外的更优解。

1.2 能耗为什么进入算法评估视野

原因很现实：算法跑在哪，功耗就在哪被看见。移动端 App 里一个低效算法不仅仅是让用户等，还会缩短续航；数据中心的节能调度中，同一个大数据任务用不同算法执行，耗电差异可以到两位数百分比；在电池供电的 IoT 设备上，算法能耗直接决定电池能用几个月而不是几周。

超算领域早就有了 Green500 这类能耗榜单，说明在性能之外，能耗已经成为一个独立且可量化的评估维度。算法分析作为一切计算系统的基础，自然也需要把能耗模型纳入分析框架，而不是把它当成编译器或硬件的“锅”。尤其在三五年内，边缘设备、可穿戴设备、嵌入式传感器只会越来越多，跑在上面的算法到底“吃多少电”，会成为系统设计能否成立的前置条件，而不是上线后才发现的问题。

1.3 为什么谈算法能耗要落在“能耗模型”上

直接看设备功耗行不行？理论上可以，实际上问题很大。设备功耗包含的东西太多：屏幕、无线模块、风扇、其他进程、温度变化。这些和算法本身没有因果关系。一段排序算法运行期间，屏幕功耗可能占了 80%，算法自身的贡献被完全淹没。

所以我们真正关心的是“由算法执行直接贡献的动态能耗”加上“算法调度对系统状态的影响”。这两部分必须通过一套模型来抽象和分解，才能在不同硬件、不同系统环境下比较不同算法。这套模型的核心思想就是分清楚哪些功耗是算法引起的，哪些是系统本来就有的，哪些是环境噪声。层次化拆解是做这件事的基础，也是我接下来要展开的内容。

2. 能耗模型的层次拆解：别把系统功耗当算法功耗

2.1 硬件层的物理基础

数字电路里的动态功耗大概可以用一个公式概括：

code复制P_dynamic = α * C * V² * f

α 是翻转率（switching activity），表示电路节点在单位时间内发生 0→1 或 1→0 翻转的比例；C 是等效电容；V 是工作电压；f 是时钟频率。

从这个公式能看出两个算法相关的问题。

第一个是 α。算法不同，执行的指令序列不同，电路翻转率不同。搜索引擎里更密集的运算会让总线和 ALU 翻转更多，能耗自然更高。这个微观层面的差异最终会表现为指令级别的能耗差异，不同指令类别之间的能耗差距可达数倍甚至一个数量级。

第二个是 f。频率是硬件状态，不是算法直接决定的，但是算法的并行度和计算密度会影响系统选择多高的频率运行（DVFS，即动态电压频率调节），这是一个间接影响的通道。算法负载越重，系统越倾向于拉高频率，电压也随之升高，而功耗公式里 V 是平方项，影响会被急剧放大。这也是后面要重点讲的一个矛盾点。

除了动态功耗，还有静态功耗（漏电流），在先进制程里占比越来越大，不过它和算法执行的关系较弱，更多取决于芯片温度和工艺参数。温度上来后漏电流增加，静态功耗也跟着涨，这会让长时间高负载运行的算法背上额外的能耗开销。

2.2 系统层：算法没法脱离系统谈能耗

算法跑在操作系统上，操作系统决定它用几个核、内存如何分配、何时读写磁盘。一个算法如果频繁在 cache 和内存之间换数据，内存控制器就要持续工作，这部分能耗会算到内存子系统的头上，但根因是算法的访存模式。

举个实际例子：同样是数组求和，按行遍历一个大二维数组，和一个隔行跳跃遍历，耗时可能差 5 倍以上，能耗差距也类似。这不是 CPU 指令数量的差别，而是 cache miss 导致的 DRAM 访问能耗。系统级能耗模型（比如 Intel RAPL 对内存域的计算）可以捕捉到这种差异，但前提是你读得懂那个数字。

我做能耗对比时比较重视一个原则：算法能耗不是孤立的 CPU 数字，而是“算法在特定系统调度策略下、消耗的整条资源链路上的能量”。换句话说，操作系统用什么调度算法、内存分配策略是什么、磁盘是否进入了低功耗状态，都会显著影响同一个算法的能耗表现。想要在测试中看到干净的结果，就得把这些系统变量尽量控制住。

2.3 算法层：指令流与访存模式

从算法分析角度看，能耗相关要素可以归纳成几类：

• 指令数，更准确的是“指令类别的加权能耗”，不同指令能耗差异很大
• 访存次数与局部性，缓存命中与否带来的能耗差别可能是数量级的
• 分支行为，分支预测失败带来的流水线冲刷，会让前面预取的指令全部作废
• 并行度，决定多核参与程度，多核齐上会增加总功耗但可能缩短时间
• 数据依赖，影响指令级并行（ILP），最终反映在单位时间能完成的有效工作上

这些要素和时间复杂度、空间复杂度直接相关，但相关方式不是简单的线性。一个 O(n²) 但 cache 友好的算法，在实际数据规模下能耗可能低于一个 O(n log n) 但 cache 不友好的算法。拿二维数组遍历来说，如果内层循环按列访问而不是按行访问，矩阵规模一旦超过 cache 容量，cache miss 会急剧上升，总的能耗可能翻一倍不止。渐进复杂度相同的两个实现，能耗体现也可能差很多。

2.4 层次错配的测量陷阱

我在刚开始做能耗研究时最常犯的错，就是把整机功耗直接除以算法运行时间，得到一个“每算法平均功耗”，然后拿这个数字做不同算法的对比。

问题是整机功耗包含大量和算法无关的部分。正确做法是把能耗分解成四块。

只有在控制前三者、或者在能耗测量工具可以按域拆分（如 Intel RAPL 按 package、core、uncore、dram 拆分）的情况下，得到的对比才是可信的。在实际研究里，我常用 RAPL 的 package 和 dram 两个域来评估算法能耗，系统级“减基线”的方法只在没法做分域测量时才用，而且结论会保守很多。

3. 时间复杂度和能耗并非线性关系：快算法可能更费电

3.1 一个反直觉现象：更快的算法更耗电

理论上，算法跑的时间越短，总能耗应该越低，因为能耗 = 功率 × 时间。但如果算法在更短时间内使用了更高功率，总能耗完全可能上升。典型场景是并行化：把一个任务拆到 8 个核并行执行，完成时间缩短到原本的 1/6，但 8 个核同时高负载运行，package 功耗从几瓦跳到十几瓦，最终总能耗可能翻倍。

这不是假设，在我自己的多线程测试里就遇到过。一个并行的图像处理任务，2 线程版本用时 9 秒、总能耗约 48J，8 线程版本用时 4 秒、总能耗约 85J。时间少了一半多，能耗却多了将近一倍。如果只看计算效率，8 线程完胜；如果把能耗算进成本，结论完全反过来。

这个例子说明：时间是效率指标，能耗是能量指标，两者的最优解并不重合。在算法设计阶段就把这两个指标分开考虑，能避免很多上线后的能源账单麻烦。

3.2 能量复杂度与能耗延迟积

学术上其实有“能量复杂度”（energy complexity）这个形式化概念：对于某个算法，可以在特定硬件模型下定义其最坏情况能耗随输入规模增长的阶数。不过因为它依赖具体硬件，实际研究里更常见的做法，是把能耗纳入多目标分析：

code复制E(n) = P_avg × T(n)

P_avg 依赖工作负载特征，T(n) 是运行时间。两个算法可能 T(n) 相同，但 P_avg 不同，总能耗就不同。

一个实用的量化工具是“能耗延迟积”（Energy-Delay Product，EDP）：

code复制EDP = E × T

EDP 把能耗和延迟压缩成一个指标，避免只优化时间或只优化能耗的偏科。在处理器设计领域 EDP 用得非常多，算法选型时同样可以参考。如果一个算法在能耗和延迟的二维坐标里，落在其他算法的左下方（能耗更低、时间更短），那它无脑可取；大部分情况下没有这种好事，需要根据业务场景选择一个方向偏移的权重。

3.3 缓存局部性带来的“常数反杀”

用一个很直观的例子说明：快速排序分区时访问是线性扫描的，局部性不错；但递归到小数组后，函数调用和分支开始主导。归并排序则需要额外空间拷贝，大量数据搬运。在小规模数据（比如几千个 int），插入排序由于极好的局部性和最少的分支，实测能耗和耗时都可能优于快排和归并排序——尽管渐进复杂度差了一个量级。

这不是说渐近复杂度没意义，而是说在能耗视角下，“常数因子”变得重要了。小的常数、好的 cache 行为，可以在小规模上抵消复杂度优势。我在测试一个数据库的排序模块时就有过类似经历：数据量在五万以下时，简单插入排序比快排的变体表现更稳定，功耗也更低，换到百万级别才反过来。工程里如果数据规模通常比较小，把快排作为默认选择的惯性思维反而可能不是最优解。

3.4 DVFS 让“快”与“省”的边界更模糊

现代 CPU 几乎都有 DVFS。算法阶段性地低负载（比如等待内存）时，系统会降压降频去省电；算法持续高负载时，系统会提频并把功耗拉高。结果就是：一个“快”算法可能把系统推向高频高功耗区间，反而让整体能耗上升；一个稍微慢一点、但是负载平稳的算法，可能让 DVFS 停留在中低频，节能效果更好。

这个观点在实操中可以观察到：对同一个多线程加密算法，限制频率到 2.4GHz 跑，虽然完成时间比 3.0GHz 慢 20%，但 package 能耗可能低 30% 甚至更多。这不是说频率越低越好，因为频率太低会导致时间拉长，漏电流和系统基础功耗占比上升，总能耗反而回升。存在一个“能量最优点频率”，值得实测找到。

所以在做算法能耗评估时，如果不想让 DVFS 干扰结论，最简单的方法是锁频测试。锁频测完干净对比之后，再放开频率看看真实系统里的表现。两个层面都测一下，既能看出算法本身的差异，也能看出它在真实调度策略下的鲁棒性。

4. 在评估阶段就把能耗拉进来的三个可落地做法

4.1 用“指令类别加权”做能耗估算

在设计或选型阶段，不需要精确实测也能做粗略排序。方法是把候选算法的主要步骤映射到三类操作：算术/逻辑运算、访存（分 cache hit 和 cache miss）、控制流开销（分支预测失败、函数调用）。给每类一个相对能耗权重，用权重乘数量估算算法的相对能耗。

不同架构的权重不同，但大体量级可以参考：一次 cache miss 的能耗可以相当于 20 到 50 次整数加法；一次分支预测失败带来的流水线冲刷能耗，也远高于一条普通指令。估算精度不需要太高，目的是把明显能耗不友好的候选方案先筛掉。

以前面提到的数组求和为例：

code复制for (i = 0; i < n; i++) {
    for (j = 0; j < n; j++) {
        c[i][j] = a[i][j] + b[i][j];  // 连续访问，cache 友好
    }
}

按行优先访问时，cache 命中率高，可以估算为 n² 次算术操作加 n²/8 次 cache miss（假设一个 cache line 能装 8 个 float）。如果改成列优先访问，cache miss 比例可能上升到 n²/2，能耗估算立刻翻好几倍。这是写代码之前就能做出的判断，不需要等到上板实测。

4.2 实测阶段的分域测量

当估算表明多个候选方案接近时，就需要实测。下面是我常用的工具组合。

实测步骤建议按这个顺序来：

1. 固定频率，关掉或锁定 DVFS，这一步能挡掉一大半的测试噪声
2. 隔离 CPU，通过亲和性把进程绑到指定核心，避免调度迁移
3. 多次运行，丢弃第一次 warm-up，取中位数而非平均数
4. 记录 package 和 dram 域的能耗计数
5. 保证所有对比组使用相同的编译选项和优化级别

附上一个简单的用 perf 读取 RAPL 能耗的脚本示例：

bash复制# 固定 CPU 频率（不同系统命令有差异，以你的环境为准）
cpupower frequency-set -g userspace
cpupower frequency-set -f 2400000

# 关闭睿频（Intel 平台，存在对应 sysfs 节点时）
echo 1 | sudo tee /sys/devices/system/cpu/intel_pstate/no_turbo

# 循环多次读取能耗
for i in 1 2 3 4 5 6 7; do
    perf stat -e power/energy-pkg/ -e power/energy-ram/ ./run_alg > /dev/null
done

跑完之后，从输出里读出每个域的能量值，按 7 次取中位数，作为该算法的代表能耗。如果某次的耗能明显偏离，保留记录并回头检查是否有系统干扰，不要直接删除。

4.3 用 EDP 或多目标约束选型

把实测得到的能耗和延迟放回业务场景里决策。下面这个表是我做选型时常用来跟同事对齐的参考模板。

强调一点：这个表里的“推荐决策方式”不是死的，关键是让相关方明确说出自己的首要指标。我见过不少项目，聊到后面发现大家连“这个场景到底是要省电还是要快”都没对齐，后面所有优化工作都在左右摇摆。把决策维度摆到桌面上，比任何技术技巧都重要。

5. 实测对比：几类典型算法在能耗与效率上的表现反差

5.1 排序：小规模数据下插入排序常被低估

以 10^4 个 int 排序为例，在固定 2.4GHz、单核、连续运行多轮的条件下，快速排序的理论优势在缓存面前被大幅削弱：插入排序的嵌套循环极短，分支预测率很高，局部性好到几乎不产生 cache miss；快速排序有递归调用和分区的额外访问。实测能耗上，我见到过插入排序比快速排序低 5% 到 15% 的案例，同时耗时也低一些——不是渐进上，而是真实常数上。

这个结论不是说“插入排序优于快排”，而是提醒：完全不考虑数据规模和分布特征的工程场景里，教科书复杂度排序不能直接等于能耗排序。如果你处理的排序数据经常是几千到几万的规模，先用插入排序、再在大规模时切换到快排，比一开始就无脑上快排更合理。

5.2 矩阵乘法：访存模式主导能耗

拿两个 128×128 float 矩阵相乘做例子：

• 朴素 ijk 版本：访问 a 按行、访问 b 按列，b 的 cache miss 非常严重
• ikj 版本（把 j 放到最内层）：a 和 b 都按行访问，cache 友好
• 分块版本（tile 16×16）：进一步利用 cache 块，减少反复加载

实测时间和能耗几乎成正比，分块版本能耗可以只有朴素版本的一半，甚至更低。这个例子最直观的结论是：在算法设计阶段，访存优化带来的能耗收益比减少浮点次数更明显。因为一次 cache miss 的能耗可以相当于几十次浮点运算，你用高级算法省下百分之二十的浮点次数，但代价是访存模式变差，很可能得不偿失。

5.3 图遍历：递归开销是隐藏的电费

在稠密图上做 DFS，递归深度大，栈帧在 cache 里来回颠簸；而 BFS 用显式队列，内存访问模式更线性。我在一个有 20 万节点的图上对比过，BFS 比递归 DFS 在时间和能耗上都更稳。DFS 的优势只有在改成显式栈时才接近 BFS。

这个例子说明：同一个复杂度、不同实现风格，能耗差异也很大。算法对比照里如果把“递归 DFS”和“显式栈 DFS”混为一谈，结论会被实现细节带偏。做能耗评估时，对比的粒度应该是“具体实现”，而不是“抽象算法”。

5.4 怎么读这些结果的“单位”

能耗单位层面，RAPL 给出的是焦耳，package 能耗对秒级任务通常在几十焦到几百焦之间；如果除以任务时间得到平均功率，这个数字在对比时要小心，因为耗时不同，平均功率会掩盖总能耗。我做对比时优先看总能耗，平均功率只作为辅助参考。

下面这个示意表展示了我在相同测试条件下的相对趋势，具体数值随平台和编译器差异会变，但方向有代表性。

我特意说明这是“相对趋势”而不是精确绝对值，因为能耗测量受平台影响太大。如果你在某个场景得到相反的相对关系，不一定是错误，很可能是硬件特性不同，把平台参数记录下来会对后续分析更有帮助。

6. 那些实测里最容易翻车的干扰项

6.1 DVFS 和睿频是头号敌人

如果不锁频，同一段代码在不同时间跑能耗可能差 20% 以上。系统负载变化、温度变化都会影响 DVFS 决策，最终导致测试结果不可复现。做法是测试前用 cpupower 把调频器设为 userspace 并固定频率，关闭睿频。要注意 BIOS 和容器环境不一定允许修改这些设置，至少要保证对比的组在相同频率下交替测试。

如果实在无法锁频，也有变通办法：记录每次运行时的平均频率，选择频率接近的运行结果来比较。这个办法精度差一些，但还是能去掉不少噪声。

6.2 后台进程与热漂移

后台 cron、日志写入、自动更新、甚至某个 IO 等待都会污染 package 能耗读数。解决方法是：

• 测试机最小化运行，关 GUI、禁用后台服务
• 每个算法多次运行后取中位数而不是均值
• 算法间随机交替顺序，抵消温度漂移

热漂移是另一个真实问题：机器刚启动时温度低、功耗低；连续跑几轮后温度升高，漏电流增大，静态功耗上升。这会造成“先跑的算法能耗低”的假象。交替顺序加上每轮之间固定冷却时间，可以缓解这个问题。如果测试完发现一个算法总是第一个跑时能耗最低，大概率是热漂移在起作用，不是算法本身有多优秀。

6.3 用平均数还是中位数

能耗分布不是正态的，偶发的系统中断会把一次运行拉得很高。用算术平均数会被极端值带偏，中位数更稳健。我在做对比时一般取 7 次运行的中位数，并记录最小值和最大值，如果极差超过 10%，就要回去检查是否有系统干扰。

这里的 7 次不是严格的统计结论，而是性价比比较高的一个选择。次数太少压不住噪声，次数太多会拉长测试时间，导致温度漂移变大。如果你对精度要求更高，可以把次数提到 11 到 15 次，并在每轮之间增加固定的冷却等待时间。

6.4 测量工具自身的开销

用 perf stat 监听 RAPL 本身开销很小，但如果在脚本里还挂了 profile 工具、或把输出打到终端，耗时会明显增加。把工具开销控制在可忽略范围，尤其别在热循环里加 printf。我见过有人在每次循环里打印进度，结果打印本身的能耗比算法还高，整个测试白做。

另一个细节是：perf stat 读 RAPL 事件需要权限，某些环境下要设 perf_event_paranoid 为 -1 或者使用 sudo。提前确认权限，不要等脚本跑到一半才发现读数全是 0。

6.5 快照式测量的误区

还有一种常见误区：用整板功耗减基线来计算算法能耗。理论上可行，但基线本身波动可能比算法增量还大，所以减法结果的置信区间很宽。能用分域测量（RAPL 的 package/dram）就用分域测量，不要迷信整板相减。

这里有个替代方案：如果只能用整板功率计，那就在基线状态下连续记录 30 秒以上的功率分布，得到基线平均值和方差；算法运行后记录另一个分布，只有两个分布的差异远大于基线方差时，才把差值当作算法的有效能耗。否则就把测试环境噪声降下来再测。

做完整套能耗评估之后，我对“算法快慢”的理解确实变了。现在做技术选型时我会多问自己一句：这个方案的能耗画像是什么？它在快的同时，是把系统推向了高频高功耗区间，还是能平稳利用资源？这个问题带来的信息量，很多时候比单纯对比耗时和复杂度更有价值。如果你手上的项目也正面临类似的选择，建议先把能耗指标放进评估体系里，哪怕只是粗略估算，也会让决策明显更稳。