我一直在查看本文有关分布式游戏树遍历的文章，并且（在其他人的帮助下）试图制作软件树遍历的python/mpi4py克隆，以求解2播放器抽象策略游戏。
首先，Wikipedia提供了有关如何"解决"游戏的BREIF描述。
记住已经解决的结果是一种常见的优化，因此不需要进一步的树遍历。由于一组计算机不能在彼此之间互相分享结果，采取了各种方法来解决此问题。论文中的方法（换位表驱动的工作计划）基本上工作如下：
- 给每个计算机1至n的ID（我只是使用了标准MPI等级）
- 在任何特定点上，计算机都可以获得职位。检查位置是在查找表中还是在琐碎的表中完成。如果是这样，请将结果值发送回产生孩子。
- 哈希每个子位置，因此它们的相关值为1至n。将每个位置发送到带有哈希的ID的"正确"计算机。
- 重复直到解决初始位置。
正如论文甚至提到的那样，这种方法的态度有些矛盾，具有极高的沟通速率。
这是：
在一台计算机上似乎可以正常工作。然后，我对学校的集群进行了一些测试，并遇到了一些严重的问题。解决像Tictactoe这样的游戏通常是糟糕的，通常会在"调试模式"（4个节点，20个核心和15分钟的时间限制）中进行计时。
）。我将Tictactoe解决方案数据库保存到了他们所谓的"用户目录"（可以在此处找到更多）。这与通常用于存储数据的"刮擦"目录相反。当我这样做时，Tictactoe的数据库在几秒钟内解决了。
我注意到使用的"划痕"空间"光泽" fs"似乎是"对等"应用程序的糟糕选择：
虽然光泽文件系统可以在许多工作环境中起作用，但 不一定是所有应用程序的最佳选择。最好 适用于超过单个服务器可以容量的用途 提供，尽管在某些用例中，光泽文件系统可以执行 由于其强大，使用单个服务器比其他文件系统更好 锁定和数据相干性。
当前，光泽文件系统不太适合 "点对点"使用模型，客户和服务器正在运行 相同的节点，每个节点共享少量存储，因为缺乏 在光泽软件级别的数据复制。在这种用途中，如果一个 客户端/服务器失败，然后存储在该节点上的数据将不会 可以访问直到节点重新启动为止。
我可能对分布式计算有足够的稳定掌握，但是看起来光泽FS可能不适合适合这种问题。不幸的是，我使用的群集被锁定用于使用光泽FS。另一个选择是像Google Cloud Engine或AWS一样完成任务的方法，但是我对某些点感到困惑：
- 许多抽象似乎吓到了我。所有这些云平台都提供"可扩展的解决方案"，通常涉及"负载平衡"，这不仅是不必要的，而且对算法有害。（必须将位置发送到正确的计算机，因此可以快速查找它们）。Google Cloud Engine或AWS是否提供了足够裸露的骨头以使该算法有效工作？
- 我应该使用什么文件系统？Google Cloud Engine推荐NFS或Gluster，但我不确定。该论文已经过时了，似乎没有使用任何特别的东西。AWS或Google Cloud Engine是否为此类任务提供适当的文件系统？
没有任何代码，也没有描述文件系统的使用方式，很难提供一些宝贵的帮助。无论如何，如果我在行之间阅读
- 您构建了解决方案的"数据库"
- 此"数据库"是在文件系统顶部实现的
- 添加条目是文件创建
- 查找是文件存在检查
我做对了吗？
如果是，那么这不是一个惊喜的表现，这是糟糕的，并且不会扩展。您基本上是在问一个并行文件系统最糟糕的是：从所有节点访问许多元数据，这些节点涉及引擎盖流量以保持对文件系统的一致视图。
您需要多少数据来存储解决方案？
乍一看，将它们存储在旧学校数据库（例如MySQL）中可能会更快。
另一个选项是将其存储在本地文件系统上，并且将远程节点的查询发布到存储数据的任务（创建此文件，是否存在此文件），因此无需保留meta-DATA一致的浓度节点。
更好的版本是让所有节点存储解决方案并回复查询。您可以放置一个解决方案并推断出存储的节点，因此您知道应该要求哪些MPI任务存储解决方案或发出查询。
如果您确实必须使用文件系统，则NFS可能比并行文件系统更好，例如Luster，GlusterFS或GPFS。