File io 读取大文件时是否会占用CPU

假设我想在我的2核机器上执行以下操作：

读取一个非常大的文件

计算

文件读取操作是否需要消耗1个内核？之前我只创建了两个线程，一个用于读取文件，一个用于计算？我应该创建一个额外的线程来进行计算吗

谢谢

编辑

---

谢谢大家，我们应该经常考虑文件I/O是否阻止了计算。现在让我们考虑文件I/O永远不会阻止计算，你可以认为计算不依赖于文件的数据，我们只是为了将来的处理而读取文件。现在我们有2个核心，我们需要读取一个文件，我们需要进行计算，这是创建3个线程的最佳解决方案吗，1个用于读取文件，2个用于计算，正如大多数人已经指出的那样：读取文件只消耗很少的CPU？

这取决于您的硬件配置。通常，由于内存不足，读取不是CPU密集型的。但是，如果它从其他应用程序中启动交换，那么它可能会非常昂贵。但还有更多

如果可以的话，不要一下子读一个大文件 如果你的文件很大，当你不需要一次读取整个文件时，你应该使用顺序处理。试着分块消费是可能的

例如，要对一个大文件中的所有值求和，不需要将该文件加载到内存中。你可以把它分成小块进行处理，把总数累加起来。在大多数情况下，内存是一种昂贵的资源

阅读是循序渐进的 文件读取操作是否需要消耗1个内核

是的，我认为大多数低级读取操作都是按顺序实现的（使用1个内核）

如果使用，您可以避免在读取操作时阻塞，但这只是相同的“小块读取”技术的变体。您可以一次启动几个小型异步读取操作，但在使用结果之前，您必须始终检查操作是否已完成

另请参见本节（参见相关问题）

并行读取和计算 之前我只创建了两个线程，一个用于读取文件，一个用于计算？我应该创建一个额外的线程来进行计算吗

这取决于，如果您需要所有数据来启动计算，那么就没有理由并行启动计算。它必须有效地等待，直到阅读完成

如果即使使用部分数据也可以开始计算，则可能不需要一次读取整个文件。通常情况下，最好不要使用大型文件

你的瓶颈是什么-计算还是IO？

---

最后，您应该知道您的任务是受计算约束还是受输入输出约束。如果它受到输入输出子系统性能的限制，那么并行计算就没有什么好处。如果计算是非常CPU密集型的，并且读取时间可以忽略不计，那么并行计算将使您受益匪浅。输入输出通常是一个瓶颈，除非你在做一些数字运算。

我认为这取决于你正在执行的计算。如果您正在进行非常繁重的计算，那么我建议对应用程序进行线程化。读取文件只需要很少的CPU资源，因此，线程化应用程序所产生的开销可能会降低速度

---

另一个要考虑的问题是，如果需要在计算之前加载整个文件，如果是这样，则根本不需要在线程中读取它，因为在完成另一个动作之前，您必须完成一个动作。p> 这是一个很好的并行化候选者，因为这里有两种类型的操作—磁盘I/O（用于读取文件）和CPU负载（用于计算）。因此，第一步是编写应用程序，使文件I/O不会阻塞计算。您可以通过一次读取一点文件并将其传递给计算线程来实现这一点

但是现在你说你有两个你想要利用的核心。您关于并行化CPU密集型部分的第二个想法是正确的，因为只有在使用多个处理器的情况下，我们才能并行化计算任务。但是，在这种情况下，应用程序的阻塞部分可能仍然是文件I/O，这取决于许多因素，判断什么级别的并行化是合适的唯一方法是基准测试

---

所以需要注意的是：多线程处理很难而且容易出错，如果您只能选择一个，那么最好使用正确的代码而不是快速代码。但是我并不反对线程，正如你可能从网站上的其他人那里发现的那样。

你问题的措辞有点令人困惑。你能清理一下吗？这还取决于你使用的控制器类型-例如IDE比SCSI使用更多的CPU。我问这个问题的原因是我怀疑文件读取操作不会消耗太多的CPU资源（HDD密集型），如果是这种情况，我不需要给它一个专用的内核来读取文件，然后我可以利用2核进行计算。（假设数据总是准备好的）实际上，您可以使用异步输入输出。在这种情况下，如何对读取进行排队取决于操作系统（在读取完成之前，应用程序不会被阻止）。另请参见检查相关问题的答案。然而，它是一种通过小块读取文件的相同技术的变体（在使用读取缓冲区之前，您仍然必须检查aio_返回）。“读取文件对CPU的要求非常低”-对，但如果按顺序执行，它仍然会阻止CPU密集型操作。这就是我们使用线程的原因。如果我在一台2核机器上创建了3个线程，我担心频繁的上下文切换——如果像我说的那样文件读取会消耗大量CPU，那么唯一确定的方法就是基准测试。但我认为在这种情况下，不等待文件读取完成就开始计算的好处将远远超过上下文swi的成本