在生成数据的同时写入数据的最快方法答案

【问题标题】：The fastest way to write data while producing it在生成数据的同时写入数据的最快方法
【发布时间】：2012-01-03 16:15:20
【问题描述】：

在我的程序中，我正在模拟一个 N 体系统以进行大量迭代。对于每次迭代，我都会生成一组 6N 坐标，我需要将其附加到文件中，然后用于执行下一次迭代。该代码是用 C++ 编写的，目前使用ofstream 的方法write() 在每次迭代时以二进制格式写入数据。

我不是这个领域的专家，但我想改进这部分程序，因为我正在优化整个代码。我觉得与在每个周期写入计算结果相关的延迟会显着降低软件的性能。

我很困惑，因为我没有实际并行编程和低级文件 I/O 方面的经验。我想到了一些我认为可以实现的抽象技术，因为我正在为具有 Unix 操作系统的现代（可能是多核）机器编程：

以 n 次迭代的形式将数据写入文件中（似乎有更好的方法可以继续...）
使用 OpenMP 并行化代码（如何实际实现缓冲区以使线程适当地同步，并且不重叠？）
使用mmap（文件大小可能很大，大约GB，这种方法是否足够健壮？）

但是，我不知道如何最好地实现它们并适当地组合它们。

【问题讨论】：

“我觉得与在每个周期写入计算结果相关的延迟会显着降低软件的性能。”你有感觉还是你分析了你的代码？
您是否分析过代码以确保您对延迟的感觉是正确的？
@LightnessRacesinOrbit 同时写入数据和进行计算的最快技术是什么以及如何实现它们。我知道这是一个非常基本的问题，但我不是实现简单优化（例如缓冲区）的专家。所以我想知道我应该学习哪些 API 和技术
如果您想要智能建议，您需要提供一些数字。
N-Body 问题通常需要对每次迭代进行 O(n^2) 次操作。写入数据需要 O(n) 次操作。假设您的程序符合这些一般性，您会发现优化每次迭代会比尝试优化输出产生更好的结果。当然，在您按照 Alessandro 的建议完全分析您的程序以查看瓶颈所在之前，您不应该相信我的话。

标签： c++ optimization file-io parallel-processing

【解决方案1】：

当然，在每次迭代中写入文件效率低下，并且很可能会减慢您的计算速度。（根据经验，取决于您的实际情况）

您必须使用producer -> consumer 设计模式。它们将通过队列连接起来，就像传送带一样。

生产者会尽可能快地生产，只有在消费者无法处理时才会放慢速度。
消费者会尽可能快地“消费”。

通过将两者分开，您可以更轻松地提高性能，因为每个过程都更简单，彼此之间的干扰更少。

如果生产者更快，您需要改进消费者，在您的情况下，通过以最有效的方式写入文件，最有可能逐块写入文件（如您所说）
如果消费者速度更快，您需要改进生产者，最有可能通过您所说的并行化它。

无需对两者进行优化。只优化最慢的（瓶颈）。

实际上，您使用线程和它们之间的同步队列。有关实现提示，请查看here，尤其是第 18.12 节“生产者-消费者模式”。

关于流管理，您必须通过选择“最大队列大小”并在队列空间不足时让生产者等待来增加一点复杂性。然后小心死锁，仔细编码。（请参阅我提供的维基百科链接）

注意：使用 boost 线程是个好主意，因为线程不是很便携。（嗯，它们是从 C++0x 开始的，但 C++0x 的可用性还不是很好）

【讨论】：

但是，鉴于数据的大小，如何处理生产者速度如此之快以至于在消费者设法将其保存到磁盘之前无法存储在内存中的情况？
@Fiat Lux 好吧，如果您生成数据的速度比存储在文件系统上的速度快，那么您将遇到一个非常基本的问题，完全独立于您使用的任何软件技巧。如果您的带宽太小，您迟早会用完缓冲区空间，然后您无论如何都必须处理这种情况。
@FiatLux 这就是为什么我说“生产者......只有在消费者无法处理时才会放慢速度”。我进行了编辑以添加指向实施示例的链接+建议的改进。如果内存已满，您将不得不让生产者等待。

【解决方案2】：

最好将操作拆分为两个独立的进程：data-producing 和 file-writing。 Data-producing 将使用一些缓冲区进行迭代数据传递，file-writing 将使用队列来存储写入请求。然后，data-producing 会发布一个写请求并继续，而file-writing 会在后台处理写操作。

基本上，如果数据的生成速度远快于其存储速度，那么您很快就会将大部分数据保存在缓冲区中。在这种情况下，您的实际方法似乎是相当合理的，因为几乎无法通过编程方式来改善这种情况。

【讨论】：

为什么你认为你可以比 OS 块缓存做得更好？
@SteveC 因为通常以确定的方式实现算法比依赖于实现相关的特性要好。我的意思是，块缓存是好，但它可能适合也可能不适合特定情况。它可能不那么便携，它可能不那么快，等等，而且 OP 也不是太具体:)
在这种情况下，您不应该经过两层缓冲，而只是绕过文件系统并写入原始磁盘。那是“更具确定性”，您可以“使其适合特定情况”。就个人而言，我怀疑你能比文件系统作者做得更好。
@SteveC：我什至不会尝试，但你错过了重点。即：通用程序语言与任何不可靠的操作系统支持无关（而 C++ 是）。操作系统缓冲可能由于多种原因被关闭或完全不存在，除非明确要求或保证它的存在，否则我们不能依赖它。

【解决方案3】：

如果您不想在不同的线程中进行操作，您可以尝试使用aio_write()，它允许异步写入。本质上，您为操作系统提供写入缓冲区，该函数立即返回，并在您的程序继续执行时完成写入，您可以稍后检查写入是否已完成。

此解决方案仍然存在其他答案中提到的生产者/消费者问题，如果您的算法生成数据的速度超过了写入速度，最终您将耗尽内存来存储算法和写入之间的结果，所以你必须尝试一下，看看效果如何。

【讨论】：

【解决方案4】：

"使用 mmap（文件大小可能很大，在 GB 的数量级上，这是方法足够健壮吗？）”

mmap 是操作系统加载程序、共享库和页面/交换文件的方法 - 它与任何其他文件 I/O 一样强大且通常具有更高的性能。

但是在大多数操作系统上，在使用映射文件时扩展映射文件的大小是不好的/困难的/不可能的。因此，如果您知道数据的大小，或者您只是在阅读，那就太好了。对于您不断添加的日志/转储，它不太适用 - 除非您知道某个最大大小。

【讨论】：

我知道数据的大小，但是如果我有几千兆字节的文件，32位系统不会有问题吗？
@Fiat - 这是 mmap 的一大优势。您可以使用偏移量将多个视图映射到文件中，这样您就可以使用窗口访问文件的任何部分，只要您的 FS 允许。详细信息取决于您的操作系统