C MPI并行化有助于多次读取大量数据

我被要求对现有的c程序进行并行化，以减少其运行时间。 我只有一些（非常有限的）使用基本MPI的经验（我所有的编程知识都是自学的，所以有点参差不齐）。我目前正试图找出最好的并行化方法

目前，在主循环的每次迭代（M=迭代次数）期间，程序顺序访问一组输入文件（N=文件数量）-每个文件的长度都不同。读取所有输入文件后，程序对数据进行排序并更新一组输出文件。N和M在开始时都是已知的，并且N总是大于M。事实上，N太大，无法将所有输入数据读取到内存中，因此每次读取文件时，只保留与主循环迭代相关的信息

我相信我可以使每个主循环迭代独立，但每个迭代仍然需要访问所有N个文件。使用OpenMPI（技术上是运行在Rocks上的OpenRTE 1.6.2，即RedHat Linux）并行化此程序的最佳方式是什么

我的第一个想法是简单地将输入文件的读入分成多个线程——每个线程处理文件的子集，然后在最后对输入进行排序

我的第二个想法是在线程之间拆分主M循环，这将更好地利用MPI。但这种方法是否需要在每个线程中复制所有输入文件（以避免读取冲突）？如果是这样，我担心复制文件可能会抵消并行主循环所获得的任何时间。此外，除了为每种方法建立一个测试程序外，还有没有更简单的方法来确定哪种方法更快

编辑：文件系统是NFS

在阅读了注释之后，我返回并对代码运行了一些测试。程序93%的运行时间用于读取数据。从已经说过的话来看，仅仅并行化似乎不是最好的解决方案。在这一点上，似乎有必要真正研究程序的计算，并尽量减少读入要求

---

非常感谢您的回复

根据评论回复，如果文件系统是NFS，您的意思是您正在通过网络读取文件？如果将文件数并行化，这可能会产生很大的问题。如果N太大，则有可能一次超过最大打开文件指针数，这通常在/etc/security/limits.conf中定义。 我知道shell类型是csh还是tcsh，如果在提示符处键入

limit

，它将显示所有这些值。很抱歉，我忘记了在bashshell中显示它的命令。 然后还可能导致NFS过载，以及lan或wan带宽问题。如果您的网络速度为100 mbps，则最多每秒只有12 MB的数据。如果你不检查它，你怎么知道它不是以每秒千字节为单位的值呢

---

如果程序运行时的最大原因是读取数据，那么您可能对此无能为力。除了NFS问题之外，我建议考虑如何命令硬盘驱动器（无论它位于何处）读取每个数据块/文件。我认为，通常最好只有一个文件指针尽可能按顺序读取磁盘驱动器中的数据，这将让您决定如何缓冲要在程序中使用的数据。如果你有足够的内存，你需要做数学和计算。如果没有，那么这将是您需要增加的，否则您将不得不依赖磁盘i/o，这是一个杀手。

到NFS的并行i/o是一件愚蠢的差事。MPI实现将尽最大努力，但NFS——除了串行之外——提供了可怕的一致性语义。客户端写入在某个未定义的时间显示给其他进程。您可以关闭每个操作的缓存和fcntl锁，但仍然无法获得预期的一致性

---

MPI实现提供了NFS支持，因为NFS无处不在，但如果分析确定I/O实际上是您的一个重要瓶颈，您可以部署PVFS/OrangeFS之类的东西，而无需付出更多的努力。

您将在哪种文件系统上运行？这对并行化有多大帮助完全取决于文件系统的类型。单个本地文件系统或共享NFS的回报将很快递减。如果您有一个并行文件系统，例如lustre，或者如果您将文件分发到许多本地文件系统，那么您可能会看到一些性能改进，但您需要调查文件系统可以处理多少持续带宽以及在什么条件下。您可能会发现，一对固态驱动器比数小时的工程工作更便宜，性能也更高。我认为在决定优化什么之前，您需要仔细衡量I/o和处理之间的平衡。我使用的是一个具有4个节点（每个节点24个处理器）的Rocks集群。文件系统是NFS。除此之外，如果不先查阅Rocks手册，我就不会知道关于该系统的任何其他信息。在进入MPI之前，您是否分析过串行程序？它在I/O和计算上花费了多少时间？NFS不是并行文件系统-从多个节点访问共享存储不太可能提供高带宽，因此I/O将仍然是您的主要瓶颈，如果它占用大部分执行时间，您将无法获得任何值得添加MPI的速度提升。