Parallel processing 如何使用阿姆达尔&x27；s定律（总加速比与加速比）

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

您有一个程序，它有40%的代码在三个处理器上并行，并且仅对于这部分代码，就实现了2.3的加速。总体加速率是多少

在这个问题上，我很难理解加速比和总体加速比之间的区别。我知道这个问题的措辞肯定有区别

Q：总体加速比是多少？ 最好不要从原始和琐碎的阿姆达尔定律公式开始，而是多读一点，其中讨论了附加间接费用，并解释了拆分工作原子性的一个方面

两个部分，
一个通过“局部”加速进行加速，
一个整体结果 您最初的问题公式似乎忽略了这一点，通过简单地假设（净本地）加速，解释了现实世界中流程编排开销的各种问题，其中审查中的

-able

部分相关的实施附加间接费用变得“隐藏”，但表现为一种低效率，即代码流执行的资源是原来的三倍，但加速比只有2.3倍，而不是3.0倍，因此在实际和初始设置上花费的时间超过了理论上的1/3（一种附加开销时间，不存在于纯

[串行]

代码执行中）+并行处理（做有用的工作，现在代码执行资源的容量是原来的三倍）+还终止并将结果收集回（附加开销时间，不存在于纯-

[串行]

代码执行中）到“主”代码中

“隐藏”这些进入/退出

[并行]

-代码执行部分的自然成本简化了作业，但正确理解现实生活中的成本是至关重要的，不要花费太多的钱（在设置和所有其他附加间接成本上，这在现实世界中是无法避免的）比任何人收到的都要多（希望利用多个处理器的分割处理加速）

---

这是对原问题的重新构思。有一个程序，其中40%可以并行。在这40%的部分，与顺序执行相比，并行执行速度提高了2.3倍，即运行速度加快了2.3倍。如果我们使用并行执行，那么与顺序执行相比，整个程序的加速比是多少？

|-------> 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
|                                                     |         |

     ( 60% + ( 40% / 1.0 ) )
  ---------------------------- ~ 1.2921 x
     ( 60% + ( 40% / 2.3 ) )