能耗模型：算法分析中的第三维复杂度

这个系列写到第四篇，来催更的人少了很多，倒是私信里开始有人问：“你前面反复提到能耗模型，能不能专门开一篇讲讲？”正好，这次的稿子就把这个坑填上。

这次聊的核心是算法分析里的能耗模型，以及它和计算效率之间的平衡。传统《算法分析与设计》课程里，大家讨论最多的是时间复杂度和空间复杂度，作业和竞赛评测也都默认“算得快就是赢”。但放到真实环境里，尤其是移动端、嵌入式、数据中心这些场景，能耗往往比时间更致命：手机发烫掉电、边缘设备电池撑不住、数据中心电费压垮预算。说白了，一套算法不仅要算得快，还要算得省，这已经变成算法分析里绕不开的第三维复杂度。

这篇笔记适合正在学算法分析与设计的同学，也适合被线上或现场功耗问题折磨的开发者。我会把能耗模型从公式到实测一步步拆开，给出压箱底的操作方法和避坑经验。

1. 从“算得快”到“算得省”：能耗为什么进了算法分析的视野

1.1 功耗墙和暗硅，是硬件给算法分析出的一道新题

早些年CPU主频提升特别顺利，厂商往上加频率，软件啥都不用改，程序自然变快。可一旦主频爬到3GHz、4GHz之后，散热和功耗彻底扛不住了，这就是常说的“功耗墙”。功耗墙之后，设计者转向堆核心、做乱序执行、加大缓存，但这些措施都需要用功耗换性能。更尴尬的是，半导体工艺到了深亚微米之后，漏电流飞速上涨，芯片哪怕什么都不干，也会持续耗电。

有一个学术圈讨论很多的概念叫“暗硅”：一颗芯片上不可能所有核心同时全速运行，因为全部跑满会瞬间超过热设计功耗，必须让一部分核心“睡觉”，所以芯片上有相当比例的区域在大部分时间都是暗的。这件事对算法分析有个很直接的后果：你分析复杂度时默认的“CPU满频满算”，在真实硬件上根本不存在，必须考虑功率约束和时间约束的折中。

我举一个最简单的例子。一颗移动SoC上通常有大小核，如果一个大核在满频率跑，功耗可以轻松飙到4瓦以上，而小核满载可能也就1瓦。如果你是算法工程师，只盯着时间复杂度选型，一个O(n²)的任务在时间上可行，但持续占用大核导致设备过热降频，反而可能比用O(n log n)但调度到小核的做法更慢、更费电。这就是为什么能耗模型必须成为算法分析的上层约束。

1.2 能耗差距不是纸上谈兵，跑段排序就能看出来

很多人觉得“能耗模型”特别抽象，我先用一个特别直白的对比给你找找感觉。假设现在有一批1万条记录要排序，在普通笔记本上分别跑冒泡排序和快速排序。快速排序可能0.05秒就结束了，冒泡排序可能要3到5秒。CPU在这种短时任务里功耗波动很大，粗略按运行期间平均40瓦来估算：

• 快速排序：40瓦 × 0.05秒 = 2焦耳
• 冒泡排序：40瓦 × 3秒 = 120焦耳

同一份数据，同一个CPU，只是算法不同，能耗差了60倍。你要是把这个任务挪到电池只有几瓦功率预算的嵌入式设备上，冒泡版本甚至可能在跑完之前就把电池电压拖垮了。

这个例子不是为了精确测功耗，而是说明一个规律：能耗和时间复杂度高度相关，但又不完全等价。因为运行功率不是一个常数，它取决于你用了多少个核心、访存是否命中缓存、CPU是否进入了睿频状态。算法消耗的能量，实际上是“功率曲线对时间的积分”，这比单纯数基本操作次数复杂得多，但也正是我们可以优化的空间。

1.3 能耗模型里的三个核心变量

站在算法分析视角，能耗模型不需要一上来就精细到晶体管级别，把握住下面三个变量就够了：

• 总能耗 E：整个程序从启动到结束消耗的能量，单位焦耳。
• 平均功率 P：运行过程中消耗的功率，单位瓦，瓦其实就是焦耳每秒。
• 运行时间 T：程序执行总耗时，单位秒。

三者的关系就是 E = P × T。算法分析要做的，是在给定问题规模和数据分布下，找到一组实现方式，让这个E尽量小，同时不违反任务的截止时间要求。

你可能会问，那这和传统的复杂度分析有什么区别？区别在于，复杂度分析默认每次基本操作的时间代价相等，但能耗模型里每个操作的“功率代价”差异非常悬殊：一次L1缓存命中大约只需要几个纳秒和极低能量，一次主存访问可能要几百个周期；一次整数加法消耗的能量远小于一次除法或一次浮点超越函数调用。所以能耗模型真正要算的，不仅仅是“循环执行了多少次”，而是“这些循环里到底在访问什么硬件资源”。

2. 能耗模型的核心构成：动态功耗与静态功耗的拆解

2.1 动态功耗和静态功耗，两种完全不同的“烧电”方式

芯片功耗通常分成