1. 一个具体问题
一次数据处理任务要一百分钟，其中二十分钟用于串行读取和最终汇总，八十分钟可以分给多个处理器。团队准备把机器从四核升级到四十核，并期待十倍提升。为什么购买很多并行资源后，用户感知的等待时间仍然下降有限？
2. 一句话解释
固定工作量下，只加速一部分工作时，总体收益受到未被加速部分的限制。
3. 出处与原意
Gene Amdahl 在 1967 年讨论大规模计算能力时强调串行部分的约束。今天常见的加速比公式是这一论点的简化模型。其前提是同一个问题规模与可比较的执行方式，不能直接拿来解释工作量同时增长的实验。
4. 原理与机制
令 p 为原始单处理器运行时间中可并行的比例，N 为理想处理器数量，则加速比 S(N)=1/[(1−p)+p/N]。分母表达新时间相对于旧时间的比例。N 趋近无穷大时，若 p 小于 1，上限是 1/(1−p)。这里忽略通信、同步、负载不均和资源竞争，因此它往往是乐观估计。若增加缓存改变了访存行为、或换了算法，观测到的结果可能超出简单模型，因为实验的假设已经改变。
这个分析也适用于不完全并行的优化：若原来一半时间花在查询，查询快十倍，整体加速也只有约一点八二倍。测量必须涵盖等待与准备时间，而不能只截取最亮眼的计算片段。多次运行时还应使用相同输入与相近资源条件，报告分布或波动范围；如果只比较最好的一次，很容易把环境噪声误判为优化效果。
5. 一个完整案例
假设案例：前述任务 p=0.8，使用四个处理器的理想时间是 20+80/4=40 分钟，加速比为 2.5；换成四十个则是 22 分钟，而不是四分钟。即使并行资源无限，仍至少要二十分钟。团队据此比较另一项改造：把串行读取和汇总从二十分钟减为五分钟，四处理器时就能做到二十五分钟。随后用计时剖析检查这五分钟能否实现，并把真实调度开销加回预算。计算没有替团队选方案，却指出了应测量的瓶颈。
6. 适用条件与反例
适合估算固定批次处理、单次请求链路或固定测试集的优化上限。不能把“串行比例是二成”看成永久事实；它随输入规模和实现变化。也不应只优化比例最大的模块：成本、可靠性以及是否影响关键路径同样重要。
7. 今天可以尝试的行动
对一项慢任务记录完整墙钟时间，明确其中可以被此次改动加速的区间。先计算两倍、十倍和无限加速三个情形，再决定是否投入。如果理论上限都不足以达标，应改变串行步骤、问题规模或目标，而不是继续盲目加机器。