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

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

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

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

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 动态功耗和静态功耗，两种完全不同的“烧电”方式

芯片功耗通常分成两部分，公式写成：

P = P_dynamic + P_static

动态功耗发生在晶体管开关翻转时，近似公式是：

P_dynamic ≈ α · C · V² · f

其中 α 是活动因子，也就是单位时间内有多少门电路在翻转；C 是电容负载；V 是工作电压；f 是时钟频率。这个公式对算法分析特别有意义，因为 α 和你的代码行为强相关：循环越多、并行度越高、缓存miss越多，门电路翻转就越频繁。而 V 和 f 是CPU运行状态决定的，算法没法直接改，但可以通过调度策略间接影响。

静态功耗则是漏电流导致的，就算没有晶体管翻转，电流也在悄悄漏掉。现代CPU在待机时会把大部分计算单元断电，只保留少量唤醒逻辑，目的就是把静态功耗压到极低。但算法一旦把核心唤醒，静态功耗就成了“底噪”，你跑不跑计算它都在耗。

用一个生活化类比来说，动态功耗像客厅里亮着的灯，按需要开关；静态功耗更像智能音箱的待机电源，你睡觉它也在耗电。以前芯片漏电小，大家不关心底噪；现在制程到了几纳米，静态功耗占比越来越高，算法写完就完事、不管核心状态的做法越来越行不通。

2.2 访存和并行度，对能耗的影响远比你想象中大

CPU内部有一个比算法复杂度更底层的能耗分层：寄存器访问最便宜，L1次之，L2、L3越来越贵，访问主存DRAM则是最贵的。不同层级之间能量消耗差距可以达到数量级。这意味着两个时间复杂度相同、但访存模式不同的实现，能耗可能差别两三倍以上。

我实测过一个很典型的例子：同样的矩阵乘法，三重循环的顺序分别是i-j-k和i-k-j，两者大O复杂度完全一样，但前者对B矩阵是列访问，每次都需要跨越整行，cache miss率极高；后者调整成行访问后，数据局部性大幅改善。在我的测试机器上，N=1024时前者比后者慢了3到4倍，能耗也差不多是3倍以上。所以，算法分析里只看“大O”是远远不够的，还要看操作背后映射到存储层次时到底产生了多少次cache miss。

并行度对能耗的影响需要分开看。并行会导致功率上升，因为多个核心同时翻转；但是如果任务能在更短时间里完成，总能耗反而可能下降。比如一个任务串行需要10秒、平均功耗5瓦，能耗是50焦耳；并行后2秒跑完，但是两个核心都在满载，平均功耗可能到18瓦，能耗是36焦耳，反而省了。可如果并行化引入太多锁竞争和调度开销，运行时间压不下去，那多核全开就只是白白抬高功率，总能耗会涨，这个平衡要靠测量来定。

2.3 能效指标到底怎么选：能量延迟积的计算口径

讨论能耗和计算效率的平衡时，双方都得有一个共同的“打分标准”。工业界最常用的有三种口径：

• 纯能耗E：只关心跑完任务消耗多少焦耳，适合续航敏感的移动设备和物联网终端。
• 能量延迟积（EDP）：E × T，既看重能耗，也看重耗时。
• 能量延迟平方积（ED2P）：E × T²，对延迟更敏感，适合在线服务这种用户体验优先的任务。

我举个例子说明这几个指标的差异。算法A运行5秒、平均功耗100瓦，能耗是500焦耳；算法B运行12秒、平均功耗30瓦，能耗是360焦耳。如果只看能耗，B完胜。但如果这是一次用户请求，体验上要求10秒内返回，B就不合格了。这时用EDP来看，A是2500，B是4320，A反而综合更优。

我在算法分析讨论区里经常看到有人说“XX算法功耗最低”，但他没说清楚是哪个指标口径下的最低。不同的场景，目标函数完全不同。做嵌入式固件的人应该直接看E，做云服务的人应该看EDP或ED2P，做CPU调度的得再加上功率上限约束。指标没定清楚之前，一切优化讨论都是在空转。

3. 平衡能耗与计算效率的策略，从算法层一路打到系统层

3.1 算法层的首要工作：先消灭冗余计算

在讨论任何复杂调度或者DVFS技巧之前，先把算法本身的冗余度降下来，这是能耗优化性价比最高的一步。时间复杂度从O(n²)降到O(n log n)，不仅省时间，也几乎同步降低动态功耗的累积量。而且，现代CPU的睿频机制还会放大这种收益：任务越短，CPU能以越高频率快速跑完，然后马上进入低功耗状态，平均功耗反而更低。

具体实操时，我建议按下面这个顺序做“能耗审计”：

1. 把热点函数单独拎出来，跑profile，看它占总运行时间比例。
2. 检查是否存在重复计算可以在循环外提，比如循环内不变的表达式。
3. 看数据结构和访问模式，能改成顺序访问的就不要随机访问，能压缩的尽量不要用指针链式结构。
4. 评估能否用近似算法减少计算量，尤其图像处理、搜索推荐这类对精确度不那么敏感的任务。

很多开发者一上来就调编译器选项和CPU频率，结果热点里有大量自己都能看出来的低效代码，纯属浪费。

3.2 编译器层：优化选项背后其实是能耗杠杆

编译器优化选项和能耗的关系值得单独拿出来讲。-O0 编译出来的程序指令数多，可能还会频繁访问栈，动态功耗自然高；-O2 以上会做向量化、循环展开、公共子表达式消除，指令数大幅下降。指令少了，CPU需要翻转的门电路就少了，能耗自然降。这相当于不用改代码，白拿了一部分能效收益。

但编译器层也有坑。过度的循环展开会让代码体积膨胀，指令缓存压力变大，极端情况下反而因为I-cache miss让能耗上升。我个人的经验是默认用 -O2，对热点循环单独尝试 #pragma GCC unroll 做手工展开，不要无脑上 -O3。还有一个细节：尽量打开 -march=native 让编译器针对当前CPU生成指令，它对能效的影响有时比优化级别还明显。

需要注意的是，编译器优化等级不同，跑出来的能耗对比也会失真。如果你要对比两个算法的能耗，必须在同一个优化级别下编译，否则你测出来的不是算法差距，而是编译器生成代码质量的差距。

3.3 系统层：DVFS和降频，有时候慢下来反而更划算

动态电压频率调节技术DVFS是操作系统层最常见的功耗控制手段。为什么它可以优化能耗？因为动态功耗近似正比于电压的平方和频率的一次方。当CPU降低频率时，内核往往也可以同步降低电压，功耗会以非线性方式下降。举个例子，假设频率从3.0GHz降到2.4GHz，电压需要对应从1.1V降到1.0V左右，动态功耗大约是原来的 (1.0² × 2.4) / (1.1² × 3.0) ≈ 66%，而运行时间增长到1.25倍，总能耗大约是原来的82%。如果任务不卡截止时间，这笔账是划算的。

在Linux下调整CPU调频策略的命令大概是：

bash复制# 查看当前可用调频策略
cpupower frequency-info

# 切到节能策略，频率会按负载动态调整
sudo cpupower frequency-set -g powersave

# 强制跑最高性能档
sudo cpupower frequency-set -g performance

# 把最小和最大频率限定在一个区间
sudo cpupower frequency-set -d 1.2GHz -u 2.4GHz

这类优化对算法调度的意义在于，你不能假设CPU一直在最高频运行。如果算法里有很多短小的忙等循环、频繁检查标志位，CPU会一直处于高频率等待状态，功耗很高却没产出。更好的做法是把忙等改成真正的阻塞等待或睡眠唤醒，让调度器有机会把核心切到低功耗的C状态。

3.4 异构计算：把任务塞给对的核，而不是最强的核

现在的手机SoC普遍是“大核+小核”结构，桌面端也有P核和E核的搭配。一个很重要的算法设计思路是：根据任务特征选择处理器，而不是无脑抢大核。大核高性能高功耗，适合对延迟敏感且运行时间短的任务；小核能效比高，适合后台型、长尾型任务。

调度能耗感知的任务分配时，我一般会看两个维度：一是任务的延迟容忍度，二是任务的计算密度。延迟敏感的前台任务放P核，后台同步、日志压缩这类计算密集但不太抢时间的任务放E核。甚至同一段代码，通过taskset绑定核心就能看出明显能耗差异。

在Linux上可以把进程绑到特定核心：

bash复制# 查看CPU拓扑
lscpu -e

# 把程序绑定到CPU 0-3（假设是小核区间）
taskset -c 0-3 ./algorithm_task

不过这里有一个容易翻车的地方：大小核的边界不是每次都能准确识别，而且固件调度策略可能动态迁移任务。做对比实验前一定要先确认任务真的跑在目标核心上，可以用perf stat看上下文切换次数来判断任务有没有被迁走。

4. 实测记录：用RAPL给一个矩阵乘法算法做能耗体检

4.1 从哪读CPU功耗：RAPL工具链折腾记录

理论讲再多，都不如让算法在真机上跑一遍能耗来得直观。这里用的核心技术是Intel和AMD CPU普遍支持的RAPL接口，全称Running Average Power Limit。它通过芯片内部的功耗计数器，每隔一段时间记录处理器消耗的能量，误差对工程优化来说完全够用。

我在Linux上最常用的测量命令是perf，直接指定energy-pkg事件就行：

bash复制sudo perf stat -e task-clock,power/energy-pkg/ ./matmul

运行结束后，perf会打印消耗的时间毫秒数，以及能耗值焦耳。这样一次测量就把时间、功率和能耗全部拿到手。

如果你还想看实时功耗曲线，可以用turbostat，它以固定间隔输出CPU封装功耗：

bash复制sudo turbostat --quiet --show PkgWatt,PkgTmp --interval 1 ./matmul

需要注意，RAPL测的是CPU封装层面的功耗，不包含内存、主板、硬盘的功耗。对纯计算型算法来说，CPU功耗已经能看出量级差异；但如果你的程序大量访问内存，还想把内存功耗也算上，那就得借助主板上的功率计或专门的功耗分析仪了。

4.2 两个版本的矩阵乘法怎么对比

实现两个循环顺序不同的矩阵乘法版本，核心代码差异就在循环嵌套上。先看朴素版，注意内层循环对B是按列访问：

c复制#define N 1024
static double A[N][N], B[N][N], C[N][N];

void mul_ijk(void) {
    for (int i = 0; i < N; i++) {
        for (int j = 0; j < N; j++) {
            double s = 0;
            for (int k = 0; k < N; k++) {
                s += A[i][k] * B[k][j];   // B[k][j] 按列访问
            }
            C[i][j] = s;
        }
    }
}

另一个版本改成i-k-j循环，这样B是连续行访问，A也能复用缓存行：

c复制void mul_ikj(void) {
    for (int i = 0; i < N; i++) {
        for (int j = 0; j < N; j++) {
            C[i][j] = 0;
        }
    }
    for (int i = 0; i < N; i++) {
        for (int k = 0; k < N; k++) {
            double aik = A[i][k];
            for (int j = 0; j < N; j++) {
                C[i][j] += aik * B[k][j];  // B[k][j] 按行连续访问
            }
        }
    }
}

编译时用同一个优化级别：

bash复制gcc -O2 -march=native -o matmul matmul.c

然后分别用perf测量两个版本：

bash复制sudo perf stat -e power/energy-pkg/ ./matmul_ijk
sudo perf stat -e power/energy-pkg/ ./matmul_ikj

在我当时测试的那台x86笔记本上，结果大致是：ijk版本跑了80多秒，能耗接近2900焦耳；ikj版本只跑了14秒，能耗在640焦耳左右。不过我要强调，这个数值受CPU型号、频率策略和内存带宽影响很大，你自己的机器测出来可能是另一组数，但“ikj比ijk省好几倍能量”这个结论基本是稳定的，因为差距主要来自cache miss的减少。

4.3 数据解读与三点测量建议

拿到perf输出后，有两个数字特别值得琢磨：一是能耗的绝对值，二是能耗和运行时间的关系。如果两个版本运行时间差不多但能耗差很多，说明它们耗电行为差异主要来自访存和指令调度；如果两个版本能耗差不多但时间差很多，那说明功率差异基本被时间抵消了，需要结合EDP判断。

测量能效时，几个坑很值得说一下：

1. 不要只跑一次就下结论。CPU频率受温度影响很大，连续跑几轮之后散热降频会让后面几次测量明显变慢变耗电。建议每次测试之间休息十几秒，同一版本跑3次取中位数。
2. 确保系统后台尽量干净。浏览器、编译任务、系统更新都会让功耗曲线出现毛刺，严重影响对比。可以临时关闭Wi-Fi和各州通知，在纯命令行环境下测试。
3. 对比实验要锁核心和频率。如果允许，把测试进程绑定到同一个核心，并且限定frequency governor为performance，否则CPU睿频带来的波动会掩盖代码本身的差异。

5. 平衡能耗与效率时的常见误区与排查备忘

5.1 时间复杂度降了，能耗反而涨了，先查访存和并行开销

有次我给一个文本处理任务做优化，把匹配算法从O(n²)优化到O(n log n)，本以为能耗会明显下降。结果实测发现能耗几乎没有变化，当时有点懵。后来profile一看，优化后的算法引入了大量指针跳转和散列访问，cache miss率高得离谱。每个miss都需要访问主存，而主存访问的能量成本是缓存访问的几十倍，这部分开销把算法复杂度下降省下的能量全吃回去了。

这给了一个很重要的教训：复杂度优化的收益，必须落实到实际访存行为的改善上，才能真正转化为能耗收益。否则纸面上再漂亮，硬件还是会用“能耗惩罚”给不友好的代码模式记账。

5.2 只统计CPU功耗，结果漏掉了内存和整个平台

很多初学者会把RAPL测到的CPU功耗当成全部系统功耗。但程序一旦出现大量内存分配和访问，内存控制器的耗电也不可忽略，风扇转速、NVMe读写、网络收发也会增加功耗。对云上部署来说，还有服务器散热和供电损耗，行业里通常用PUE这个系数把基础设施用电折算进来。

保守的做法是，做细致对比时再外接一台功耗仪测交流输入端的整机功耗。比如市场上几十块钱的智能插座就能看视在功率，虽然精度一般，但数量级和趋势不会被误导。对于找量级差距这事，它比单纯看CPU计数器靠谱得多。

5.3 把“CPU占用率低”直接当成“省电”，这是最容易翻车的判断

CPU占用率低不等于省电。如果系统时不时被唤醒做一秒半秒的短任务，CPU没机会进入深度的C-state，频率也可能一直停留在较高档位。这种情况下的平均功耗，往往比一个连续跑5秒就结束的任务还高。就好比家里每个房间的灯轮流闪一下，虽然每盏灯亮的时间都很短，但总耗电可能比一个房间安安静静亮很久还高。

算法分析里尤其要警惕定时器密集型任务。有些代码每隔几十毫秒醒来检查一次队列，虽然是O(1)复杂度，但对电源管理非常不友好。优化方向是把多次短唤醒合并成一次长处理，或者使用事件驱动而不是轮询，让CPU真正睡过去。

5.4 对比实验的公平性问题：编译器、频率和负载都要管住

做算法A与算法B的能耗对比时，最容易出问题的是变量没控制住。编译器开了不同优化级别，一个用了向量化一个没用；跑A时候系统后台有编译任务，跑B时候后台安静；甚至两次测试间隔不同，CPU温度也不一样，这些都会造成能耗数据失真。

我总结了一个简单规矩：对比实验开始时，先固定CPU频率、固定编译器版本和优化参数、固定任务绑定核心，记录系统负载为空闲状态；然后像做科学实验一样记录环境变量，再做数据收集。否则得出的结论只适合写写博客，不适合当作工程决策依据。

5.5 一个小提醒：能耗分析不是给算法设计增加负担，而是给复杂度的第三维度补课

工作里做过几个低功耗项目之后，我的体会是，能耗模型和计算效率并不是非此即彼的对立关系。真正的好算法，是在了解目标平台功耗行为的前提下做出来的。很多时候你在算法层多花一点心思减少访存，在系统层配合调度策略切到合适的频率，能耗和性能会同时变好，根本不需要做痛苦的取舍。

在算法分析与设计的学习路径里，如果能把能效指标当成验收标准之一，训练出来的直觉会比单纯刷题的广度实用很多。这篇内容算是对能耗模型的一个系统性补全，实际做项目时先从简单的RAPL测量开始，积累几组自己平台上的能耗数据，比套用任何通用结论都更有价值。