阿姆达尔定律：为什么核数翻倍，速度不翻倍？

阿姆达尔定律：为什么核数翻倍，速度不翻倍？

【免费下载链接】hacker-laws🧠 Laws, Theories, Principles and Patterns for developers and technologists.项目地址: https://gitcode.com/GitHub_Trending/ha/hacker-laws

把一个跑 500 秒的批处理任务挪到 8 核机器上，你预期 8 倍加速，实测只有 3 倍。hacker-laws 里的阿姆达尔定律（Amdahl's Law）讲的就是这件事：程序里那部分必须串行执行的逻辑，决定了加速的上限。加核、加线程、加机器，都是同一个道理。

阿姆达尔定律约束的是什么：加速比上限

一句话：给一个程序增加处理器，整体加速比永远不可能超过 1 ÷ 串行部分占比。上限由“有多少比例并行不了”决定，而不是由处理器数量决定。

原理拆解：三个独立的小结论

小结论一：串行部分是“常数项”

拿一个 100 秒的任务举例：30 秒是串行步骤（加载配置、单线程预处理），70 秒可以拆给多个核。无论你上多少核，那 30 秒始终花在一个核上，一分不会少。就像饭店后厨请了 100 个厨师，但前台一小时只能带 20 桌，翻台率还是 20 桌——瓶颈在带不动的那一段，不在干得快的这一段。

小结论二：每加一倍核，收益砍一半

核数每翻倍，并行部分耗时减半，串行部分纹丝不动：从 1 核到 2 核，总时间从 100 秒降到 65 秒；从 2 核到 4 核，只降到 47.5 秒。递减得越来越狠。公式 S(n) = 1 / ((1-P) + P/n) 描述的就是这种衰减，其中 P 是可并行比例，n 是处理器数量。

小结论三：可并行比例越高，长尾越长

hacker-laws 的 README.md 给出的结论很直接：50% 可并行的程序，核数超过 10 之后几乎没有收益；而 95% 可并行的程序，上千核仍能拿到有意义的加速。换句话说，问“我需要多少核”之前，先问“这个程序到底能并行多少”。

算一笔账：如何用阿姆达尔定律估算并行加速上限

用前面的例子，P = 0.7（70% 可并行，30% 串行），单核总耗时 100 秒。n 核时的总时间 = 30 + 70/n，加速比 S(n) = 100 ÷ (30 + 70/n)，逐行算：

表里有两个值得盯住的点：从 8 核加到 32 核，核数翻了 4 倍，加速比只多出 0.53 倍；而无论加多少核，总耗时都不会低于 30 秒。如果你正站在“要不要从 8 核升到 16 核”的决策点上，按 16 核套公式算出的上限约 2.75 倍——实测接近这个数说明硬件没毛病，明显偏低就先查通信与锁开销，而不是继续堆核。

阿姆达尔定律的适用边界

• 问题规模随核数一起变大的场景不适用。加机器时如果数据集、任务量也跟着放大，可并行比例 P 本身会升高，这时应改用古斯塔夫森定律（Gustafson's Law）估算。阿姆达尔定律只管“工作总量固定”的情况。
• 别把公式当实测值。S(n) 是理论上限，实际加速还会被网络延迟、锁竞争、内存带宽侵蚀，通常低于公式算出的数。
• 别用它管人。“给落后的项目加人只会更落后”是布罗克斯定律（Brooks's Law）的领域，人的沟通开销和处理器并行是两回事，README 中两者是分别列出的条目。

落地清单

1. 并行化之前先用 Profiler 测出串行占比——P 未知，一切加速计算都是猜。
2. 实测加速比逼近公式上限时停止加核——此时硬件的边际成本已经超过了收益。
3. 把优化火力调到串行部分：重构热点为流水线或换更高效的算法——改分母比加分子划算。
4. 任务能拆成独立单元就先拆任务——P 抬得越高，上限越宽。

串行占比，是你在动手之前唯一该先写下来的数字。阿姆达尔定律不是拿来背诵的公式，而是买下一颗核之前要先算一遍的账。

【免费下载链接】hacker-laws🧠 Laws, Theories, Principles and Patterns for developers and technologists.项目地址: https://gitcode.com/GitHub_Trending/ha/hacker-laws