当向我们的硬件添加越来越多的处理能力时，阿姆达尔定律让我们计算程序的最大理论加速。这可以通过T = 1 / ((1-P) + (P/N))where(1-P)是顺序的程序部分来说明，并且(P/N)是可以从加速中受益的部分。现在，阿姆达尔定律遗漏了开销因素。要将其计入其中，我们可以说
T = 1 / ((1-P) + 0(N) + (P/N))哪里0(N)表示随着计算节点数量的增加而增加的同步工作量。
现在我的问题是：如何计算程序的最大加速比0(N)？假设我们有一个程序，其顺序部分为25%，并行部分为75%。
让我们从一个报价开始：
阿姆达尔定律遗漏的是开销因素。
虽然我支持当代对使用 **开销-幼稚公式的批评**，但我必须首先反对，1967 年发表的 Gene AMDAHL 博士的论点一直持续到今天，因为他的开创性工作与该领域有关进程执行，而不是在CPU/GPU/MMC/FPGA 设备编程的上下文中伴随调度的不同代码执行技巧的纯执行[SERIAL]、只是[CONCURRENT]执行或真正执行的派生字段。[PARALLEL]
考虑到这些附加成本，原本纯[SERIAL]语法的代码，通过新的、特殊的、元#decorated 或直接语法元素的附加块得到扩展，这些元素被解释并可能被编译成机器相关机器的新部分-代码。
这些新部分通常会引入 O(1) 附加成本，而执行它们不会保持恒定的 TimeDOMAIN 和 SpaceDOMAIN 成本（通常主要是多项式 wrt SPACE，花费更多时间作为移动所需数据的有限资源的影响对于此类衍生/分布式流程相关操作（参数传输+返回结果））
如果您引入同步成本，那么到目前为止[PARALLEL]，真正的流程执行不再是真正的流程，而是[PARALLEL]从完全独立的流程[PARALLEL]调度领域返回到[SERIAL]有点半[PARALLEL]（如果不是）的纯排序但只是- [CONCURRENT]）代码执行部分，从属于某种外部强制执行的策略（无论是透明同步还是资源池限制的受控执行编排等）
问：如何计算程序的最大加速比
0(N)？
重新阅读有关附加开销和工作原子性的部分，而是使用原始阿姆达尔定律的开销严格和资源感知重新制定。
pSO:= [PAR]-Setup-Overhead add-on
pTO:= [PAR]-Terminate-Overhead add-on
对于小规模问题，成本的总和 -参数传输的pSPACE + pTIME附加成本（在一定程度上取决于数据传输量的大小）加上最初pSO + pTO是大部分时间cTIME + cSPACE新流程的附加成本（es ) 在 localhost O/S 内或在（可能是异构的）分布式系统配置期间进行实例化，以便满足并欢迎新进程执行它并在完成后终止它，这很容易超过来自( ( 1 - s )/N )诸如此类的好处案件将永远不会获得一点加速，而是诉诸于支付更多的附加成本，这比以往任何时候都能够并且将被 Amdahl 的论点证明是合理的。这绝不是阿姆达尔博士的错，是吗？
对于大型和计算密集型的计算任务，pSO + pTO可以通过拆分和（很大程度上取决于s确定“并行部分”的剩余部分( 1 - s )）[PARALLEL]努力得到一些令人愉快的加速：
在这些大而密集的cTIME + cSPACE情况下，主要变量不会对数据造成太大破坏，但与数据相关的初始参数 + 返回值传输的相对可忽略的部分。
对于甚至无限多的 CPU ( 1 - s ) = 75%，加速比基本上小于 4 。
有了最佳基准，所有附加开销和给定一些已知的处理粒度和工作原子性，您将获得净加速预期，这将接近最终的处理，同时给出所有适当的步骤对于具有竞争条件的非阻塞执行和 O/S 限制规避技术以适当的形式和方式实施。