python mpi_并行python还是MPI？

似乎有一些合理的方法来设计这个。

让我把你的工作称为主要工作，9个中间工作，以及中间工作可以衍生的许多内部工作。我假设中间作业在内部作业全部完成后有一个“合并”步骤，而外部作业也一样。

最简单的设计是，主作业触发中间作业，然后在执行合并步骤之前等待它们全部完成。然后，中间作业将触发内部作业，并在执行合并步骤之前等待它们全部完成。

这可以使用单个共享队列，但您需要一个队列，该队列在等待时不会阻塞工作池，而且我认为multiprocessing的Pool和Queue不能在开箱即用的情况下做到这一点。一旦你的所有进程都在等待加入他们的孩子，什么也做不了。

一种方法是改为连续传递样式。如果您知道哪个中间作业将最后完成，则可以将句柄传递给其他中间作业，并让它在这些作业上联接，然后执行合并，而不是外部作业。中间层同样将合并传递到他们的最后一个内部作业。

问题是，即使没有日程安排问题，你通常也无法知道最后要完成什么。因此，这意味着您需要某种形式的共享(例如，信号量)或作业之间的消息传递，以便在它们之间进行协商。你可以在multiprocessing上面做。唯一的问题是它破坏了作业的独立性，而且您突然要处理共享并发的所有恼人问题。

另一种选择是为每个中间作业分别设置池和队列，并在池之间进行某种负载平衡，以确保每个核心运行一个活动进程。

当然，也可以是一个单独的池，它的实现比multiprocessing的要复杂得多，它既可以进行负载平衡，也可以进行协作调度，因此joiner不会阻塞核心。

或者一个超级简单的解决方案：超额调度，并且为简单起见在上下文切换中支付一点成本。例如，即使只有8个内核，也可以运行32个工作线程，因此有22个活动工作线程和10个等待线程。每个核心都有2或3个活动的worker，这会使事情慢一点，但可能不会太糟，至少没有人空闲，除了向multiprocessing.Pool构造函数传递不同的参数之外，您不必编写任何代码。

无论如何，multiprocessing是非常简单的，它几乎没有不适用于其他解决方案的额外概念。所以，在你碰到砖墙或者没有碰到砖墙之前，花在玩它上面的时间可能比事先想清楚它是否对你有用要少。