跨层性能诊断与设计权衡

动机：优化之前先定位

看到程序慢就增加线程、换算法或扩大 cache，可能只是在优化非瓶颈。组成原理提供一套跨层语言，但真正的诊断必须由测量约束。

从总时间向下分解

先明确墙钟时间由什么构成：

总时间
├── CPU 运行
│   ├── 前端取指/分支
│   ├── 执行端口与数据相关
│   └── cache/TLB/内存等待
├── I/O 等待
├── 锁与线程调度
└── 运行时、系统调用与缺页

再用计时、采样分析器和硬件性能计数器验证。一次测量不能证明因果，但多个相互吻合的指标能缩小范围。

常见证据模式

现象	可能瓶颈	进一步验证
IPC 低、分支错误高	控制流不可预测	分支指令与错误惩罚
L1/L2 miss 高、带宽未满	延迟或局部性差	工作集、访问步长、并发 miss
内存带宽接近平台上限	带宽受限	算术强度、NUMA 分布
CPU 利用率低、I/O wait 高	设备或同步等待	请求队列、系统调用、设备延迟
多线程加速早早饱和	串行段、锁或共享资源	锁竞争、false sharing、Amdahl 上限

计数器名称依处理器而异，且采样与推测执行会让数值并非精确“事件个数”。应关注趋势、比例和多指标交叉验证。

例 1：矩阵遍历

按行存储的矩阵，行优先遍历连续地址，cache line 中多数数据会被使用；列优先遍历大步长跳跃，可能每次只用一小部分块。

两者算法复杂度都为 \(O(n^2)\)，但组成层面的 miss 数和 DRAM 行局部性不同。优化数据布局或循环顺序比提高 ALU 频率更有效。这正是渐近复杂度与存储层次知识的 overlap：前者描述规模增长，后者解释常数和真实瓶颈。

例 2：分支密集查找

二叉搜索每步比较后跳向不同节点。若节点散布在内存，既有不可预测分支，又有 cache miss。把树改成紧凑数组布局、批量处理多个查询，可能同时改善空间局部性和指令级并行。

但无条件改成 branchless 也有代价：可能执行原本不会执行的操作，增加功耗，并在简单核心上无收益。必须测量目标机器与实际输入。

例 3：多核计数器

多个线程对同一原子计数器频繁加一，核心数越多，一致性所有权越频繁迁移。解决方案是每线程局部计数、最后归约。

局部化减少一致性流量，代价是读取全局精确值需要合并，且额外占用内存。若业务要求每次更新立即全局可见，就不能免费采用该优化。

设计权衡表

优化	主要收益	常见代价	适用条件
加深流水线	更高潜在频率	分支惩罚、寄存器功耗	阶段可平衡且预测准确
增大 cache	降低容量 miss	命中延迟、面积、功耗	工作集可被覆盖
预取	隐藏规则访存延迟	带宽与污染	访问模式可预测
SIMD	提高数据吞吐	尾部、分歧、带宽压力	数据并行且布局规则
多线程	利用多核	同步、通信、调试复杂	任务可分且串行段小
DMA 批处理	降低 CPU 搬运开销	队列延迟、缓冲管理	数据块较大或吞吐优先

诊断流程

1. 定义代表性输入、正确性与目标指标；
2. 建立基线，记录波动和机器配置；
3. 判断是计算、前端、内存、I/O 还是同步主导；
4. 构造只改变一个因素的最小实验；
5. 用时间和底层指标同时验证；
6. 应用优化后重新分析，因为瓶颈会移动；
7. 检查功耗、内存占用、尾延迟与可维护性回归。

改进空间与限制

硬件计数器、模拟器和微基准都有观察偏差。微基准隔离机制，却可能不代表真实应用；整机测试真实，却难以归因。最可靠的方法是让模型、微实验和端到端结果互相支持。

未来硬件会继续变化，但“先建立状态与数据流模型，再用证据识别限制资源”的方法不会过时。

自测

1. 算法复杂度相同的两段代码为何可有显著 cache 性能差异？
2. 多线程加速不佳时，怎样区分串行部分、锁竞争和内存带宽瓶颈？
3. 选择一个熟悉程序，写出一个优化假设、两项支持指标和一个可能副作用。