Parallel processing 并行化计算最大加速比

阿姆达尔定律让我们计算出，当我们的硬件增加越来越多的处理能力时，程序的最大理论加速比。这由

T=1/（（1-P）+（P/N））

表示，其中

（1-P）

是程序的顺序部分，而

（P/N）

是可以从加速中受益的部分。 现在阿姆达尔定律忽略的是间接费用因素。为了计算，我们可以说

T=1/（（1-P）+0（N）+（P/N））

其中

0（N）

表示随着计算节点数量的增加而增加的同步工作

---

现在我的问题是：我如何在考虑

0（N）

的情况下计算程序的最大加速比？假设我们有一个程序，它的顺序部分是25%，平行部分是75%，让我们从一个引用开始：

阿姆达尔定律漏掉的是管理费用的因素

虽然我支持当代的公式，但我必须首先反对Gene AMDAHL博士1967年发表的论点，因为他的开创性工作与流程执行领域有关，而不是纯

[串行]

，只是-

[并发]

或True-

[并行]的派生领域

在CPU/GPU/MMC/FPGA设备编程环境中执行不同的代码执行技巧

考虑到这些附加成本，原本纯粹的代码语法会被额外的新的、特殊的、元修饰的或直接的语法元素块扩展，这些语法元素会被解释，并可能被编译成依赖于机器的机器代码的新部分

这些新部件通常会引入O（1）附加成本，而执行这些附加成本不会保持不变的时域和空域成本（通常主要是多项式wrt空间，由于移动此类衍生/分布式流程相关操作所需的数据的资源有限，会花费更多时间）（参数传输+返回的结果））

在引入同步成本的情况下，到目前为止，真正的-

[PARALLEL]

进程执行将停止成为真正的

[PARALLEL]

-进程执行，并从完全独立的

[PARALLEL]

-进程调度区域返回到纯

[SERIAL]

-排序的半

[PARALLEL]

（如果不是，但只是-

[CONCURRENT]

）代码执行的部分，与某种外部强制的策略（透明同步或资源池限制管理的执行编排等）相协调

Q：我如何在考虑

0（N）

的情况下计算程序的最大加速比

重新阅读有关附加管理费用和工作原子性的章节，并使用原始阿姆达尔定律

pSO:= [PAR]-Setup-Overhead     add-on
pTO:= [PAR]-Terminate-Overhead add-on

对于小规模问题，参数传输的附加成本（

pSPACE+pTIME

add-on-costs）加上初始

pSO+pTO

的总成本-，大部分时间

cTIME+cSPACE

新流程实例化的附加成本在本地主机O/S内部或（潜在的异构）配置期间，为了满足并欢迎新流程执行它并在完成后终止它，可以轻松地超过

（（1-S）/N）带来的好处

这样的案例永远不会得到一点提速，而是会付出比以往任何时候都要多的附加成本，而且会被阿姆达尔的论点所证明。这绝不是阿姆达尔博士的错，不是吗

对于大型和计算密集型的计算任务，

pSO+pTO

可以通过拆分和（取决于

s

，确定“并行部分”的剩余部分为

（1-s）

）

[Parallel]

努力可能会带来一些令人愉快的加速效果：

在这些大而密集的情况下，主要变量对数据相关初始参数+返回值传输的影响不大，但相对可忽略的部分是

cTIME+cSPACE

数据相关初始参数+返回值传输

使用

（1-s）=75%

时，即使是无限多个CPU，其加速比也基本上小于4

---

通过最佳基准测试，所有附加组件开销以及已知的处理粒度和工作的原子性也可以确定，您将获得净加速预期，这将接近最终的处理，同时考虑到使用竞争条件和O/S限制避免技术的非阻塞执行的所有适当步骤以适当的形式和方式重新就位。

让我们从一个报价开始：

阿姆达尔定律漏掉的是管理费用的因素

虽然我支持当代的公式，但我必须首先反对Gene AMDAHL博士1967年发表的论点，因为他的开创性工作与流程执行领域有关，而不是纯

[串行]

，只是-

[并发]

或True-

[并行]的派生领域

在CPU/GPU/MMC/FPGA设备编程环境中执行不同的代码执行技巧

考虑到这些附加成本，原本纯粹的代码语法会被额外的新的、特殊的、元修饰的或直接的语法元素块扩展，这些语法元素会被解释，并可能被编译成机器相关的新部分