如何使用阿姆达尔定律（总体加速与加速）

Question

回想一下阿姆达尔（Amdahl）关于估算最佳加速比的定律。回答以下问题。

您有一个程序，其中40％的代码在三个处理器上并行处理，仅就这部分代码而言，可以实现2.3的加速。总体速度是多少？

在这个问题上，我很难理解加速和整体加速之间的区别。我知道这个问题的措词一定有区别。

Answer 1

  

Q ：整体加速是多少？

最好不要从原始的和微不足道的阿姆达尔定律公式入手，而是先读一些更多 contemporary view, extending the original，其中讨论了附加的间接费用以及原子性的一个方面。拆分工作进行了解释。

两个部分，
一个通过“本地”加速而加速，
一个整体结果

您原来的问题公式似乎绕过了那里，通过简单地假设（本地网络）加速，解释了实际流程编排开销中的各种问题，其中{{1 }}与下节讨论相关的实现附加开销成本被“隐藏”了，但这种表达方式效率低下：将代码流执行的资源增加三倍，而加速却是2.3倍，而不是3.0倍，因此实际上在初始设置上花费的理论时间超过理论的1/3（附加的开销时间，不存在于纯<PAR>-able代码执行中） + 并行处理（执行The_useful_work，现在是代码执行资源的三倍） + 也终止并返回结果收集（附加的管理时间） ，而不是纯{[SERIAL]代码执行中的代码）显示在“主”代码中。

“隐藏” [SERIAL]代码执行部分的这些自然的进出成本可以简化作业，但是对现实生活成本的正确理解至关重要。 （不要花更多的钱（在现实世界中无法避免的设置和所有其他附加管理费用上）（比希望得到的更多） -获得多处理器利用的拆分处理速度）

[PARALLEL]

---

|-------> time
|START:
|                                                                                        |DONE: 100% of the code
|                                                     |                                  |
|______________________________________<SEQ>______60%_|_40%__________________<PAR>-able__|
o--------------------------------------<SEQ>----------o----------------------<PAR>-able--o CPU_x runs both <SEQ> and <PAR>-able sections of code, in a pure [SERIAL] process-flow orchestration, one after another
|                                                                                        |
|                                                                                        |

净 总体加速（如果未产生其他与流程组织相关的附加管理费用） 是：

|-------> time
|START:                                                         |
|                                                     |         |DONE: 100% of the code  :
o--------------------------------------<SEQ>----------o         |                        :
|                                                     o---------o    ..   ..   ..   ..   ..CPU_1 runs <PAR>'d code
|                                                     o---------o    ..   ..   ..   ..   ..CPU_2 runs <PAR>'d code
|                                                     o---------o    ..   ..   ..   ..   ..CPU_3 runs <PAR>'d code
|                                                     |         |
|                                                     |         |
|                                                     <_not_1/3_> just ~ 2.3x faster (not 3x) perhaps reflects real-costs (penalisations) of new, add-on, process-organisation related setup + termination overheads
|______________________________________<SEQ>______60%_|_________|~ 40% / 2.3x ~ 17.39% i.e. the <PAR>-section has gained a local ( "net"-section ) speedup of 2.3x instead of 3.0x, achievable on 3-CPU-code-execution streams
|                                                     |         |