1. 课程导入与性能剖析全景
科学计算程序的性能问题往往不是“代码写得慢”这么简单。一个在单核上运行良好的数值核函数，扩展到 64 个 MPI 进程后可能只获得 8 倍加速；一段在 CPU 上耗时 2 秒的矩阵乘法，迁移到 GPU 后可能因为主机与设备之间的数据搬运而变得更慢。性能剖析（profiling）的任务，就是在这些现象背后找到时间究竟花在哪里、为什么花在那里、改动什么才能让它变少。本课程围绕这一目标展开，本章先建立全景认知：明确剖析的目标与核心度量，理解瓶颈定位的整体流程，并认识贯穿后续章节的工具链。
剖析的目标：从“感觉慢”到“可解释的耗时分布”
性能剖析不是盲目调优，而是有明确产出的工程活动。一次有效的剖析至少应回答三个问题：程序的热点在哪里（哪些函数、循环、通信操作占据了主要时间）；热点的性质是什么（计算密集、内存带宽受限、同步等待、I/O 阻塞还是负载不均）；以及改进空间有多大（理论上限与当前实测的差距）。因此，剖析的最终交付物通常不是一句“某函数很慢”，而是一份带量化的耗时分解：例如“总墙钟时间 120 s，其中稀疏矩阵向量乘占 68 s，MPI_Allreduce 占 21 s，其余为 I/O 与初始化；SpMV 的有效浮点吞吐仅为峰值的 11%，判断为访存带宽受限”。这样的结论才能直接指导下一步动作。
四个核心度量：吞吐量、延迟、加速比、可扩展性
性能讨论必须建立在统一的度量语言上，否则很容易各说各话。以下四个概念构成本课程的基本词汇表。
- 吞吐量（Throughput）：单位时间内完成的有效工作量，如 GFLOP/s、GB/s、迭代步/秒。它衡量“单位时间产出多少”，是判断计算资源是否被充分利用的主要指标。
- 延迟（Latency）：完成单次操作或单个任务所需的时间，如一次内存访问的纳秒数、一次 MPI 消息的微秒数、一个时间步的墙钟秒数。延迟关注“一次要等多久”，与吞吐量并不等价：流水线和批量处理可以提高吞吐量，却未必降低单次延迟。
- 加速比（Speedup）：S(n) = T(1) / T(n)，即基准规模或基准配置下的时间与改进后时间之比。使用时必须声明基准：是相对单核、相对单进程，还是相对上一版代码。
- 可扩展性（Scalability）：规模增大时性能如何变化。强扩展固定问题规模、增加进程数，考察时间能否按比例下降；弱扩展固定每进程工作量、整体放大问题，考察时间能否基本保持不变。常用效率 E(n) = S(n)/n 衡量并行收益的衰减程度。
需要强调的是，这些度量之间存在权衡。提高并行度通常提升吞吐量，但会引入通信与同步，抬高单步延迟；向量化与缓存分块提升吞吐量，却可能增加代码复杂度与寄存器压力。剖析的价值就在于用数据揭示当前程序处在哪条权衡曲线上，以及是否偏离了合理位置。
瓶颈定位的整体流程
面对一个性能不达预期的程序，推荐按“先宏观、后微观，先测量、后假设”的顺序推进，避免一上来就盯着某段代码做微优化。整体流程可概括为五步：
- 明确目标与基准：确定要优化的指标（墙钟时间、吞吐量还是内存占用）、代表性输入规模、运行环境（核数、编译选项、MPI 版本），并记录当前基线数据。没有基线的优化无法证明有效。
- 宏观测量：先用轻量手段获得总时间分解，如计时器打点、
/usr/bin/time、作业调度系统的资源统计，判断时间大致分布在计算、通信、I/O 还是初始化阶段。 - 定位热点：用采样或插桩剖析器获得函数级、循环级甚至指令级的耗时分布，结合调用图确认热点是否位于预期位置。
- 判定瓶颈性质：对热点做针对性测量，如用硬件计数器看 CPI、缓存命中率、内存带宽利用率，用通信剖析看消息大小分布与等待时间，从而区分计算受限、访存受限、同步受限等类型。
- 验证与迭代：实施改动后回到同一基准复测，确认收益并检查是否引入新的瓶颈（例如优化了计算却让通信占比上升）。
这五步并非严格线性：宏观测量发现通信占比异常时，可能直接跳到通信剖析；微观测量发现缓存命中率极低时，也可能回头调整数据布局这一“宏观”决策。但“先测量、后假设”的原则不变。
工具链概览与选用原则
性能工具数量众多，但按观测粒度可以排成一条清晰的层次线，上图下半部分给出了对应关系。系统层工具几乎零开销，适合建立第一印象；函数层剖析器通过采样或插桩给出热点排名，是日常使用频率最高的一类；硬件计数器层回答“为什么慢”的机理问题；并行与通信层则专门处理多进程、多线程场景下的等待与失衡。选用时遵循一条朴素原则：先用粗粒度工具缩小范围，再用细粒度工具确认性质。直接对全程序开启指令级追踪，往往得到海量数据却难以解读，还会因观测开销扭曲被测对象本身。
另一个容易被忽视的要点是观测开销。采样剖析通常开销在百分之几，插桩剖析可能达到数倍，而全量事件追踪可能让程序慢一个数量级。开销不仅影响测量效率，还可能改变瓶颈位置——例如插桩放大了函数调用成本，使原本访存受限的程序看起来像调用开销受限。因此，任何剖析结果都应先问一句：这个数字是在多大观测开销下得到的？必要时用两种手段交叉验证。
一个贯穿全课的小例子
为使后续章节有共同参照，这里给出一个示例场景（参数为教学假设，非实测）：某二维泊松方程求解器，网格 4096×4096，采用 Jacobi 迭代 500 步，单进程墙钟约 96 s。用计时器打点得到：迭代主体 91 s，初始化与 I/O 约 5 s。进一步用函数级剖析发现，spmv_kernel 占迭代时间的 74%，其余为向量更新与收敛判断。用 perf stat 观察该核函数，每步实际搬运约 1.6 GB 数据、完成约 0.34 GFLOP，对应算术强度约 0.21 FLOP/Byte，远低于常见处理器的带宽拐点，因此判定为访存带宽受限而非浮点能力不足。这一判断直接决定了优化方向应是改善数据布局与分块复用，而不是替换更快的数学库。后续章节将围绕这类判断反复演练。